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. > > -EH > > > On Fri, Feb 27, 2015 at 12:54 AM, <[email protected]> wrote: > > > You were right setting the preferred codec to 126 fixed our problem, > > firefox is able to decode our video stream. > > > > Thanks! > > > > Do you know if Open264 will have support for more payloads, profile levels > > and packetization modes in the future? Is there a roadmap that we can > > follow? > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media > >
We have an application that expects profile-level-id=42801F;packetisation-mode=0, and it doesn't decode the openH264 video sent from firefox. Is it possible to specify the profile level and packetisation mode that firefox sends or is our application stuck in the dark ages? I tried to modify the SDP just before setLocalDescription is called, but this had no effect on the SDP that was sent by firefox. 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. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
