On 3/5/2015 10:21 AM, [email protected] wrote:
On Friday, February 27, 2015 at 3:40:19 PM UTC, Ethan Hugg wrote:
The team currently working on OpenH264 is doing features that make the
conferencing use cases better (CABAC, T8x8, Chroma QP/QP scaling).
The packetization is done on the Firefox side in the WebRTC code. All the
implementors I know of are currently using mode 1. I order to see what
needs to be changed for mode 0 we'll probably need help from someone who
has a use case that requires mode 0.
There's a bug in the mode 0 code (though Firefox would talk to itself);
Ethan had a fix for it but we didn't have any good devices to test it
against. I believe he's un-rotting the patch currently.
I'm not a codec man, but my colleague says that fragmentation introduces a
delay, so mode 0 was chosen when our application was originally developed.
Fragmentation will mean that each fragment can't be decoded as it comes
in (which you can in Mode 0); however a final frame won't be available
until all NALs for the frame have been decoded in mode 0 anyways, so
unless you output incomplete frames, the only real difference would be
that on packet loss, the entire frame is lost (or delayed until
NACK/retransmit); in mode 0 you can decode the parts that aren't missing
and display an incomplete frame - however, all following frames either
must be blocked or allowed to decode-with-errors while waiting for an IDR.
(Depending on the decoder, it might even be possible to decode Mode 1
packets as they come in if you can block the decoder when it gets to
data you haven't received yet.)
The net result is that almost all modern H.264 equipment uses Mode 1
(which also gets better compression). When I built a consumer
videophone in 2003, I didn't even bother with mode 0 support initially
until I had to add interop support to it a few years later, and then
only because the spec required it and some HW devices out there only
supported mode 0.
--
Randell Jesup, Mozilla
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
