On 5/21/2015 9:36 AM, [email protected] wrote:
Thanks for your help. I managed to have Firefox decode the incoming stream by
changing the profile-level-id in the SDP to 42e01F, so negotiation succeeded,
video channels set up. Great, but...
Our endpoint fails to decode the openH264 stream sent by Firefox. On analysis
(by my colleague) the NALU header received is 0x78 indicating STAP-A. Our
endpoint does not specify packetisation-mode (I believe the default is 0?) so
surely this NALU value should not have been sent?
If the negotiation was for mode 0, then we shouldn't send a STAP-A - if
so it's a bug. Please file a bug including the SDP. That may be a
regression from 37 to 38 (when we did a major code update of webrtc.org
code, and picked up some new packetization code). And a quick glance at
that new code doesn't show anything that can check the mode, so likely
that's the case. Almost certainly the only STAPs will be SPS+PPS or
SPS+PPS+IFrame. Likely we need to add a field for mode in codecSpecific
and feed that down to the packetizer in some manner, and cause that to
skip both FUA and STAP-A processing. (FUA isn't a big deal since you
should have configured your encoder for a low NAL size anyways).
I'll note that it's very hard to find true mode-0 devices that can be
coerced to interop with webrtc (always through a gateway of some sort).
--
Randell Jesup
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
