Wowza Community

Help with RTP fragmentation encoding (FU-A) packets

I have a stream source which provides me H264 NAL units. I’m writing an Android app that first compiles individual NAL units into a Complete Access Unit and then runs this entire packet through the Android MediaCodec for display. I take this same packet and attempt to create RTP packets to send to Wowza using RTSP/RTP.

I originally misread the RTP spec and instead send individual NAL units (not complete access units) to Wowza, which is didn’t like very much. Using FFMpeg for testing, I was able to encode a complete access unit using single NAL unit mode (RTP) and display a proper test video using FFPlay. I am processing HD video, so I need to packetize the NAL units using fragmentation in order to fit the data inside the UDP MTU limit size. So, I turned my attention to RTP non-interleave mode and the FU-A fragmentation scheme. Using FFMpeg again for testing, I am able to receive and play RTP fragmented packets in FFplay properly.

Wowza does not like my packetization. Not only will it not play in the test players, but it will not record the stream either. When I used the Single NAL Unit mode, Wowza would not display the video but would at least record it (although only about 1/3rd of the video looked proper because of overwhelming the UDP MTU size). Using FU-A fragmentation, Wowza will not record anything.

This leads me to believe my packetization scheme may not be correct. Below is a sample of my log file output. According to the flags, this should compose a complete access unit.

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 90 00 03 77 fc 00 00 00 00 1c 89 10 17 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227324 st:true - - - 321.895

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 91 00 03 78 60 00 00 00 00 1c 09 35 06 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227424 st:false - - - 321.895

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 92 00 03 78 c4 00 00 00 00 1c 09 37 49 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - nalUnit: hdr:9 sz:1287:1291 typ:AUD - - - 321.896

2015-08-20 20:42:14 EDT comment server DEBUG 200 - writePacket[vid]: sz:1296 tc:1440117733928:227324:1440117734116:0 key:false

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227524 st:false - - - 321.897

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 93 00 03 79 28 00 00 00 00 1c 09 fe 8b }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227624 st:false - - - 321.898

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 94 00 03 79 8c 00 00 00 00 1c 09 63 0c }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227724 st:false - - - 321.9 -

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 95 00 03 79 f0 00 00 00 00 1c 09 bd 15 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227824 st:false - - - 321.901

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 96 00 03 7a 54 00 00 00 00 1c 09 36 95 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:227924 st:false - - - 321.902

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1032] {80 e3 f0 97 00 03 7a b8 00 00 00 00 1c 49 63 c7 }

2015-08-20 20:42:14 EDT comment server DEBUG 200 - FU-A: tc:228024 st:false - - - 321.903

2015-08-20 20:42:14 EDT comment server DEBUG 200 - rtp[trackID=0:1300] {80 63 f0 98 00 03 7b 1c 00 00 00 00 1c 89 09 10 }

SO, can anyone tell me if this log file looks normal? Also, am I correct in assuming that Wowza will not record nor play any stream that it can’t decode properly? Am I also correct in assuming FFMpeg is more robust in its decoding since it can play my stream fine? I don’t see any sort of error in the log file about not being able to decode, play, record … nothing.

I determined what the problem was. My packetization was incorrect - in case anyone ever searches for this (tech support did not understand what was wrong).

RTP to Wowza needs to encapsulate each individual NAL unit, not a complete access unit. However, it’s very sensitive to timestamps. All of the individual NAL units that compose the complete access unit must have different sequence numbers (incrementing) but the same RTP packet timestamp. I’m guessing this is how Wowza knows they came from the same access unit. The same rule applies for fragmented packets inside a complete NAL unit. Increment the sequence, maintain the timestamp.