Re: [rtcweb] New VP8 vs H.264 tests uploaded

["Mo Zanaty (mzanaty)" <[e-mail]>]

Check your output x264 streams for fillers. If you see fillers (NAL unit type 12), you are wasting bandwidth. In the example below, almost half the bitrate was wasted on fillers and other stuff (SEI) that are not real frames. Over RTP, you would waste even more than half the link bandwidth since the small SEIs would incur the full overhead of separate RTP packets. (40 bytes of RTP/UDP/IP overhead for 10 bytes of SEI.)

Mo


From: [e-mail] [mailto:[e-mail]] On Behalf Of Sergio Garcia Murillo

El 05/04/2013 1:28, Mo Zanaty (mzanaty) escribió:
Realtime/low latency and constrained bitrate are obviously important for the actual implementation used. Thomas was pointing out that these factors have nothing to do with the codec technology itself, since they are purely encoder implementation optimizations. There is nothing in the VP8 or H.264 standard that uniquely provides realtime/low latency or constrained bitrate. Those are attributes of encoder implementations which are not part of the standard.

So the question was whether we care about evaluating codec technology or specific implementations. If the former, then tests should be staged in the same way codec experts evaluate codec technology/tools. If the latter, then tests should be staged using the target implementations.

I'm not aware of conferencing applications which use x264, because it was designed and optimized for transcoding (dvd rips to blu-ray) not conferencing. Most importantly, x264 cbr mode is inappropriate for conferencing since it is for broadcast MPEG transport streams that must be absolutely CBR to avoid M2TS-mux overflow or underflow, and it will actually insert filler data instead of real frame data to hit the CBR rate exactly. Looking at the results which show the worst H.264 bitrate (62% above VP8) in gipsrecstat_1280_720_50_1485kbps.mkv, there is almost as much filler data as real frame data, meaning the true bitrate of real frame data is almost half what is reported in the results. (See attached if it makes it through.)

I have been using x264 with very good results in my mcu implementation, the parameters I use are:

    params.rc.i_rc_method           = X264_RC_ABR;
    params.rc.i_bitrate                   = bitrate;
    params.rc.i_vbv_max_bitrate = bitrate;
    params.rc.i_vbv_buffer_size   = bitrate/fps;
    params.rc.f_vbv_buffer_init    = 0;
    params.rc.f_rate_tolerance    = 0.1;
    params.b_intra_refresh           = 1;

I have a smooth and constant bitrate near the target bitrate, which is something I still have not been able to do with VP8 encoder yet (if someone nows the trick, it will be very welcome!).

Best regards
Sergio