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.