Subject: [rtcweb] Giri Mandyam's response / h261 performance (Was: Straw Poll on Video Codec Alternatives)

From: Hervé W. <[email-masked]>
Date: Sun, 12 Jan 2014 12:25:22 +0100

On 12 January 2014 06:00, Mandyam, Giridhar wrote:
> 6. All entities MUST support H.261
>
> a. Are you in favor of this option [Yes/No/Acceptable]: NO
>
> b. Do you have any objections to this option, if so please summarize them:
>
>                Section 7 of
> https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/ provides
> performance data for H.264.  I do not believe that H.261 would provide
> equivalent or superior performance under identical testing conditions, and
> no data has been provided to the IETF or on the mailing lists proving
> otherwise.  This option would allow a presumably inferior codec (H.261) to
> be the fallback option. Moreover, this does not allow interop with legacy
> systems and standards such as 3GPP IMS Video Telephony.

Here's some performance data

time  ./x264-r2377-1ca7bb9.exe sign_irene_cif.y4m --profile baseline
-o irene-unspec.264
encoded 540 frames, 37.73 fps, 362.40 kb/s
real    0m14.501s

time  ffmpeg -i sign_irene_cif.y4m -g 100   irene-unspec.h261
real    0m2.118s

time  ./x264-r2377-1ca7bb9.exe sign_irene_cif.y4m --profile baseline
--preset ultrafast  -o irene-unspec.cbp.ultrafast.264
encoded 540 frames, 238.31 fps, 871.36 kb/s
real    0m2.449s

time  ffmpeg -i sign_irene_cif.y4m -g 100 -b:v 362571  irene-362571.h261
real    0m2.307s

time  ./x264-r2377-1ca7bb9.exe sign_irene_cif.y4m --profile baseline
--preset ultrafast --bitrate 363  -o irene-363k.cbp.ultrafast.264
encoded 540 frames, 247.03 fps, 362.39 kb/s
real    0m2.344s

  956K  irene-unspec.264
2.3M    irene-unspec.cbp.ultrafast.264
  956K  irene-363k.cbp.ultrafast.264
  595K  irene-unspec.h261
 1023K  irene-362571.h261

ffmpeg -i irene-unspec.264 -f yuv4mpegpipe -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Total: 0.967268  (Y': 0.964929  Cb: 0.971758  Cr: 0.97213 )

ffmpeg  -i irene-unspec.h261 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Warning: framerates do not match.
info1.fps_n=25 info1.fps_d=1 info2.fps_n=30000 info2.fps_d=1001
Total: 0.900451  (Y': 0.889181  Cb: 0.930285  Cr: 0.915696)

ffmpeg  -i irene-362571.h261 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Warning: framerates do not match.
info1.fps_n=25 info1.fps_d=1 info2.fps_n=30000 info2.fps_d=1001
Total: 0.928367  (Y': 0.923392  Cb: 0.942237  Cr: 0.934402)

ffmpeg  -i irene-363k.cbp.ultrafast.264 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Total: 0.934904  (Y': 0.925319  Cb: 0.956247  Cr: 0.951901)

./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m sign_irene_cif.y4m
Opening sign_irene_cif.y4m...
Opening sign_irene_cif.y4m...
Total: 1         (Y': 1         Cb: 1         Cr: 1       )

- Hervé

---

From: Maik Merten <[email-masked]>
Date: Sun, 12 Jan 2014 14:14:08 +0100

Hello Hervé,

thanks for conducting some tests. I see that you're using the ffmpeg 
H.261 encoder, which by default makes no use of H.261 in-loop filtering, 
which is designed to avoid buildup of high-frequency noise caused by the 
full-pel motion compensation.

In my experience, enabling that filter (-flags loop) will yield a 
visually more pleasing result. I expect that SSIM may "confirm" this (as 
much as objective measurement correlates to subjective quality), and 
wonder if this in fact the case in your experimental setup.

Best regards,

Maik

Am 12.01.2014 12:25, schrieb Hervé W.:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Hervé W. <[email-masked]>
Date: Sun, 12 Jan 2014 15:02:28 +0100

Hi Maik,

On 12 January 2014 14:14, Maik Merten wrote:
> Hello Hervé,
>
> thanks for conducting some tests. I see that you're using the ffmpeg H.261
> encoder, which by default makes no use of H.261 in-loop filtering, which is
> designed to avoid buildup of high-frequency noise caused by the full-pel
> motion compensation.
>
> In my experience, enabling that filter (-flags loop) will yield a visually
> more pleasing result. I expect that SSIM may "confirm" this (as much as
> objective measurement correlates to subjective quality), and wonder if this
> in fact the case in your experimental setup.
>
> Best regards,
>
> Maik

time  ffmpeg -i sign_irene_cif.y4m -g 100 -flags loop -b:v 362571
irene-362571.loop.h261
real    0m2.779s

time  ffmpeg -i sign_irene_cif.y4m -g 100 -flags loop -b:v 265k
irene-265k.loop.h261
real    0m2.750s

time  ffmpeg -i sign_irene_cif.y4m -g 100  -b:v 265k    irene-265k.h261
real    0m2.361s

1046657  irene-362571.h261
1047453  irene-362571.loop.h261
 785192  irene-265k.h261
 785149  irene-265k.loop.h261

ffmpeg  -i irene-362571.loop.h261 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Warning: framerates do not match.
info1.fps_n=25 info1.fps_d=1 info2.fps_n=30000 info2.fps_d=1001
Total: 0.926998  (Y': 0.91992   Cb: 0.94383   Cr: 0.938477)

ffmpeg  -i irene-265k.loop.h261 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Warning: framerates do not match.
info1.fps_n=25 info1.fps_d=1 info2.fps_n=30000 info2.fps_d=1001
Total: 0.915997  (Y': 0.906586  Cb: 0.938329  Cr: 0.931311)

ffmpeg  -i irene-265k.h261 -f yuv4mpegpipe  -v -1 - |
./daala/daala-HEAD-b2fa2c0/tools/dump_ssim.exe -s -r
sign_irene_cif.y4m -
Opening sign_irene_cif.y4m...
Opening -...
Warning: framerates do not match.
info1.fps_n=25 info1.fps_d=1 info2.fps_n=30000 info2.fps_d=1001
Total: 0.914378  (Y': 0.906122  Cb: 0.936377  Cr: 0.925403)

Lower bitrates seem to benefit (more) from the loop flag than the
higher bitrates.

- Hervé