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
[email protected]
https://lists.mozilla.org/listinfo/dev-media
