search

Maria1099 / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

Quality difference for WHD between 1 vs 2 thread encoding #497

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Encode WHD sequence for:
1) 1 thread
2) 2 threads

The 2 thread results (2 runs were done, which are not bitexact as expected) 
have visibly local degradation on face areas, e.g., in frames 268, 272, 280; 
whereas the 1 thread result does not.

The run was for 3 temporal layers (with long-term reference shut off). Did not 
see the same kind of difference for 1 temporal layer.

Expected result: regardless of temporal layer structure, should expect results 
from 2 threads to not be visibly worse than 1 thread.

Test sequence and results (decoded .yuv file and encoded bitstream .bit) are 
at: /home/marpan/issue_2threads_whd

Original issue reported on code.google.com by marpan@google.com on 26 Oct 2012 at 2:11

GoogleCodeExporter commented 9 years ago

Original comment by marpan@google.com on 26 Oct 2012 at 4:28

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 26 Oct 2012 at 9:35

GoogleCodeExporter commented 9 years ago 
Effect is easily reproducible with webrtc off-line test. The issue 
(degraded/poor macroblocks) seems to only happen with temporal layers = 3 and 
denoising on. 

Have not seen the degradation with denoiser off or with temporal layers =1,2.  

Reducing the motion threshold of the denoiser does not seem to resolve the 
issue (unless the motion threshold is 0 which means we only denoise ZERO MV).

The effect seems to only occur on the middle layer (second enhancement) frames 
of tl-=3.

Original comment by marpan@google.com on 31 Oct 2012 at 10:10

GoogleCodeExporter commented 9 years ago

Original comment by marpan@google.com on 31 Oct 2012 at 10:57

GoogleCodeExporter commented 9 years ago 
To reproduce: check out webrtc

Set temporal layers = 3 in 
/src/webrtc/video_coding/main/source/codec_database.cc (line 96)

Set _incomingFrameRate = _userFrameRate (to fix frame rate for encoder) in 
/src/webrtc/video_coding/main/source/media_optimization.cc
(line 672)

Run video_coding_test in trunk/out/Release folder:
./video_coding_test -n 1 -f 30 -b 500 -w 1280 -h 720 -i testnoise.yuv 

(testnoise.yuv is in /home/marpan/issue_2threads_whd)

WebrRTC wrapper is set to use 2 threads for image sizes > 4CIF, so 2 threads 
will be used for WHD.

Within about 3 runs, one of them should show the degradation on some frame in 
the face region (later frame after say frame 240). The degradation is typically 
on a few macroblocks, and then disappears after a few frames (because of the 
anchoring of the temporal pattern every 8 frames).

Original comment by marpan@google.com on 31 Oct 2012 at 11:30

GoogleCodeExporter commented 9 years ago 
Run video_coding_test in trunk/out/Release folder (at ~1000k):
./video_coding_test -n 1 -f 30 -b 1000 -w 1280 -h 720 -i testnoise.yuv 

The effect does not seem to be reproducible with the off-line vp8 encoder 
(vp8_scalable_patterns).

Original comment by marpan@google.com on 31 Oct 2012 at 11:45

GoogleCodeExporter commented 9 years ago 
Issue has been resolved with fix merged in libvpx:
https://gerrit.chromium.org/gerrit/#/c/39297/

Original comment by marpan@google.com on 10 Dec 2012 at 4:14

GoogleCodeExporter commented 9 years ago 
in addition to https://gerrit.chromium.org/gerrit/#/c/39382/

Original comment by slavarn...@google.com on 10 Dec 2012 at 7:15