>We are using Firefox version 36.0.4 as my WebRTC client and on the other side we have our private client (connected through Janus GW plugin) generating h264 >stream using Cisco open h264 version 1.3.
As of Firefox 38 we're using the packetization upstreamed from the webrtc.org code v4.0 so it could give different results. I recommend trying testing with Dev Edition. >Big RTP packets (more than 8K) that are generated from our private client and are passed through the Janus GW are dropped in the network and so we decided to >limit the NAL unit size to 2K. >However, when we tried to limit the NAL unit size to 2k using the "uiMaxNalSize" parameter in the "SEncParamExt" structure during encoder initialization, open >h264 library didn't limit the single NAL unit size to 2K. >Do we need to set (initialize) any other parameter to limit the NAL size to 2K when we initialize the Cisco open h264 library??? >I'll leave this to Ethan to answer; however if you're trying to use Mode 0 (or multiple NALs/frame in Mode 1) you should limit the size to < 1500 (likely around >1200 to deal with possible VPN/etc scenarios, SRTP overhead, etc). There was a bug in this area IIRC in OpenH264 (again, I'll leave it to Ethan to comment in >detail). If you take a look here - https://github.com/cisco/openh264/blob/master/module/gmp-openh264.cpp and search for 'maxPayloadSize' you'll see they're also setting uiSliceSizeConstraint which may be what you need to do. -EH On Thu, Apr 2, 2015 at 5:41 PM, Randell Jesup <rje...@mozilla.com> wrote: > On 4/2/2015 2:15 PM, Kannan Murali wrote: > >> Hi: >> >> We are using Firefox version 36.0.4 as my WebRTC client and on the other >> side we have our private client (connected through Janus GW plugin) >> generating h264 stream using Cisco open h264 version 1.3. >> >> Big RTP packets (more than 8K) that are generated from our private client >> and are passed through the Janus GW are dropped in the network and so we >> decided to limit the NAL unit size to 2K. >> >> However, when we tried to limit the NAL unit size to 2k using the >> "uiMaxNalSize" parameter in the "SEncParamExt" structure during encoder >> initialization, open h264 library didn't limit the single NAL unit size to >> 2K. >> Do we need to set (initialize) any other parameter to limit the NAL size >> to 2K when we initialize the Cisco open h264 library??? >> > > I'll leave this to Ethan to answer; however if you're trying to use Mode 0 > (or multiple NALs/frame in Mode 1) you should limit the size to < 1500 > (likely around 1200 to deal with possible VPN/etc scenarios, SRTP overhead, > etc). There was a bug in this area IIRC in OpenH264 (again, I'll leave it > to Ethan to comment in detail). > > Also, we tried to break up big NAL unit into multiple fragmented units >> (up to 2K), but it didn't work either. We applied the following rules while >> fragmented the big NAL Units: >> >> 1. We maintained the same RTP timestamp for all the fragmented units RTP >> packets. >> >> 2. We incremented the sequence number for all the fragmented units RTP >> packets. >> >> 3. We only set the marker bit on for the last fragmented unit RTP packet >> and for the rest of the fragmented units RTP packets we set the marker bit >> off. >> >> 4. First fragmented unit RTP packet starts (after the RTP header) with >> the start code (00 00 00 01), followed by 0x7c (FU Indicator - which >> indicates the FU-A type), followed by 0x85 (FU header - which indicates >> that this is the first FU, and it's IDR type) and then followed by the >> payload. >> > > There are no start codes in H264 in RTP -- and even if there were, it > would be inside the fragmentation, not outside it. RFC 6184 has detailed > rules and packet layouts showing how it's done. > > 5. The middle fragmented unit RTP packet starts (after the RTP header) >> with 0x7c (FU Indicator - which indicates the FU-A type), followed by 0x05 >> (FU header - which indicates that this not the first or last FU, and it's >> IDR type) and then followed by the payload. >> >> 6. The last fragmented unit RTP packet (after the RTP header) starts >> with 0x7c (FU Indicator - which indicates the FU-A type), followed by 0x45 >> (FU header - which indicates that this is the last FU, and it's IDR type) >> and then followed by the payload. >> > > Those are likely OK, but realize a p-frame can be fragmented too once the > bandwidth goes above ~350kbps, so they're not all IDR NALs. > > -- > Randell Jesup, Mozilla > > _______________________________________________ > dev-media mailing list > dev-media@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-media > _______________________________________________ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
