GNOME Bugzilla – Bug 580749
[rtph263pay] Undefined/Strange/Odd behaviour when encountering encoder specific extension in rtph263pay
Last modified: 2010-04-16 15:47:37 UTC
In the setup, I am using gstreamer to receive h263 rtp from a Bosh Dinion XF DN IP camera. When sending the stream to a hardware encoder after being repackaged by gstreamer, the hardware decoder chokes on the gstreamer stream. The issue seems about the adding of 00 00 00 00 by Bosh in the H263 stream. After running rtph263depay and repayloading it with rtph263pay; some strange issues are centred around the packet containing the end marker bit and the PSC (Picture Start Code). In the original encoder; each end frame is immediately followed by a PSC frame. In the gstreamer code; we have - 1. Invalid h263 packet (determined by wireshark). The issue seems to by around the fact that the payload is only 4 bytes long (consistently) - 2. end of frame. The payload contains the 00 00 00 00 bytes - 3. PSC frame. When inspecting the h263pay code; there seems to be some knowledge about this since gst_rtp_h263_pay_gobfiner explicitly checks for four 0x00 bytes. If it does, it returns the last byte before these padded bytes. It then packages there bytes before the padding; uses the 00 00 00 00 bytes for the end of frame packet en then continues. In the original stream, the 00 00 00 00 bytes are also used in the end of frame packet; but are not split off from the original payloaded stream. I've patched the code to drop this 'garbage' from the stream; equally able to decode the stream using ffmpeg_h263 (still not solving my hw decoder issue though). The size of the packets seems more logical; though this might break Bosh HW decoders (considering the 00 00 00 00 seems to be an extension their own). I am wondering what the approach should be in this case, under the assumption that the 00 00 00 00 really is a vendor incompatibility in the payload stream as I'm being told. Somehow; the cross over of this from the payload to the rtp domain seems not quite correct (especially considering the 2-byte 4-byte n-byte packet payloads in the RTP frame transition sequence) and considering that the 00 00 00 00 in the original stream is considered normal (black box) payload without special treatment (looks the preferred approach to me).
Created attachment 133561 [details] [review] remove 00 00 00 00 bytes from stream
gdp dump before entering rtph263pay http://crichton.homelinux.org/~marc/downloads/gstrtph263pay-before.gdp
There may already have been some changes in rtph263pay, as latest version does not produce any 4-byte buffers or so, and keeps the appending 00 bytes as they are (which does not bother the decoder). However, decoder produces 704x480 output, which is not a h263 resolution, so this looks like h263p which is not so expressed in the caps (btw, nor does the stream seem to have properly keyframe marked buffers). So, closing as there does not seem to be much appropriate rtph263pay involvement/problem here.