GNOME Bugzilla – Bug 670199
Nice RTP MPEG4/H.264 hardware encoder stream not supported
Last modified: 2012-06-07 12:09:34 UTC
Nice probably does something non-standard with H.264 (based on passed debugging on MPEG4 of this manufacturer) user data; which chokes the rtph264depay parser. The network (RTP/H264) stream can be found on: http://crichton.homelinux.org/~marc/downloads/nice-h264--226-255-1-201-5000.gdp.xz A MPEG4 variant that is supported by GST and where the assumption is based on is: http://crichton.homelinux.org/~marc/downloads/nice-mpeg4--226-255-5-201-5000.gdp.xz
This encoder sets the RTP extension bit.
BaseRTPDepayload should just ignore the extension already.. That said, if I push these packets over udpsink and capture them with wireshark, they're definitely invalid. Can you capture the RTP stream directly using tcpdump/wireshark and try to have wireshark dissect it ?
Looks strange: Looks as if the extension header and the payload specific headers are mixed up at first glance. When adding 1 more word to the header (maybe the payload specific one and the extension are mixed up) seems to get me a bit further, but I need to compile gst-ffmpeg tomorrow to see what the visual effect is. It's still not good, so I might be wrong... I'll post a pcap tomorrow.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT >= 96 | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |Profile-specific ext header ID | Extension header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | date (YYYYMMDD) | Ext. Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | status (0=OK) | Ext. Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub Type (4=MPEG4, 6=H.264) | Ext. Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time (HHMMSSCC) | Ext. Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F Type| resolution | Ext. Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media | Media | Media | Media | Media | Media | Media | Media F Type = Frame Type = (0=Intra, 1=P-Frame) The extension header is relevant only on first packet of a frame. Note that it is not a standard H.264 RTP format as we do not supply the H.264 RTP header. Moreover, the stream is already prepared for decoding as it contains the SPS/PPS NALs and also user data NAL all preceded by 00 00 01 and the specific NAL code (7 for SPS, 8 for PPS and 6 for user-data). Note also that when a user-data NAL is encountered (00 00 01 06) the next NAL should not be searched for directly by looking for the next 00 00 01 pattern, but the user-data NAL should be skipped. The format of the user-data NAL is 00 00 01 06, then one byte of user-data type, 5 in our case, and the next byte is the user-data size. This amount of bytes should be skipped and the NAL analysis should continue from that point.
Added a 2 minute pcap http://crichton.homelinux.org/~marc/downloads/nice-h264.pcap.xz
I tried loading your file in wireshark and using their H.264 parser, and it also can't make any sense out of that stream. Having the extension bit set but the "defined by profile" field set to 0 is unconventional (by which I mean wrong). That said, this format seems to have nothing to do with the format defined in RFC 3984 that is supported by rtph264depay, if you want to support this format, you should probably write your own depayloader.
The cap I uploaded was all all multicast traffic, so there will be some cruft in there. As for the depayloader; I suspected as much when I got the mail; but thought to provide the follow up information in any case. W hat seems to make matters more difficult is that they have some kind of 'hop' system in between which converts from one non-standard format to another non-standard format. This being said, the 'nicertph264depay' seem to become more and more the option to go for.
This is a proprietary stream mangling. Fixing this requires writing a dedicated depayload module for this specific encoder.