GNOME Bugzilla – Bug 610172
inconsistent h263pay/h263depay behaviour
Last modified: 2010-04-30 14:39:53 UTC
I am trying to decode h263 coming from a Bosch encoder. By coincidence I noticed the following: does NOT decode: gst-launch udpsrc uri=udp://226.255.0.68:6000 caps="application/x-rtp, clock-rate=(int)90000, encoding-name=(string)H263, media=(string)video, payload=(int)34" ! rtph263depay ! ffdec_h263 ! xvimagesink force-aspect-ratio=True sync=True does decode: gst-launch udpsrc uri=udp://226.255.0.68:6000 caps="application/x-rtp, clock-rate=(int)90000, encoding-name=(string)H263, media=(string)video, payload=(int)34" ! rtph263depay ! rtph263pay ! rtph263depay ! ffdec_h263 ! xvimagesink force-aspect-ratio=True sync=True instead of just ... ! rtph263depay ! ... ... ! rtph263depay ! rtph263pay ! rtph263depay ! ... behaves better. I can only guess at this time that feeding it through the payloader parses the data in some format that the depayloader or decoder can handle better.
Can you attach some sample data? like a tcpdump of the udp packets?
Or gdp dump (udpsrc ! ... ! gdppay ! filesink location=h263.gdp)
yeah, in a sec, was still writing the reports ;-)
gst-launch udpsrc uri=udp://226.255.0.68:6000 caps="application/x-rtp, clock-rate=(int)90000, encoding-name=(string)H263, media=(string)video, payload=(int)34" ! gdppay ! filesink location=h263pay.gdp see http://crichton.homelinux.org/~marc/downloads/h263pay-bug-610172.gdp.gz
The problem seems to be in the h263 payload header coming from the encoder. It marks every frame's first fragment as being keyframe and subsequent fragment as not being a keyframe. The net effect with rtph263depay is that all output buffers are marked as delta unit, so ffdec_h263 discards waiting for a keyframe. It works running it through rtph263pay because that one does some bitpicking and then marks the I bit properly. I have some patches pending for rtph263depay that should also take care of this (basically bitpick each frame's Mode A first fragment for the correct I bit).
Previous commits also help, but the following one finishes it: commit 0206b67b1dad066472e6557f6ada167a91c8ea6f Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Fri Apr 16 17:21:50 2010 +0200 rtph263depay: extra keyframe info from PTYPE header ... as opposed to taking it from h263 payload header, which need not be so reliable. Fixes #610172.