After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 633981 - rtph264depay fails with some streams
rtph264depay fails with some streams
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-04 11:59 UTC by Nicola
Modified: 2011-06-01 01:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2010-11-04 11:59:11 UTC
Please take a look to the test video you can download from:

http://77.43.75.110/temp/h264.gdp

if you try to see the video with a pipeline such this:

gst-launch-0.10 filesrc location=h264.gdp ! gdpdepay ! ffdec_h264  ! xvimagesink

you'll see bad things when the overlayed time is at:

11:55:32
11:55:42
11:56:00
11:56:05
11:56:53
11:56:57

if you remux this video as mkv you can play it fine, is this a gdppay/depay bug?
Comment 1 Nicola 2010-11-04 16:34:57 UTC
the problems disappear if I convert the file as follow:

gst-launch-0.10 filesrc location=h264.gdp ! gdpdepay ! rtph264pay ! rtph264depay byte-stream=false ! h264parse ! gdppay ! filesink location=h264_1.gdp

or if I save the source stream with a pipeline such this:

rtspsrc ... ! rtph264depay byte-stream=false ! rtph264pay ! rtph264depay byte-stream=false ! h264parse ! gdppay ! filesink location=h264.gdp

so this seems a problem in rth264depay, I have to repay with gstreamer to make gstreamer depay correctly,

please note that h264.gdp and h264_1.gdp should have the same sizes but this is not true, if I repeat the same pipeline on h264_1.gdp I obtain an output file of the same size as h264_1.gdp as excepted, so the source have something that gstreamer doesn't like,

hope this test can help to find the problem,

regards
Nicola
Comment 2 Olivier Crête 2010-11-04 17:08:29 UTC
I suspect this may be the same as bug #632945, you may want to try the last -good pre-release (0.10.25.4) ?
Comment 3 Nicola 2010-11-04 17:59:16 UTC
just installed a chroot with ubuntu and gstreamer-ppa:

dpkg -l | grep good
ii  gstreamer0.10-plugins-good           0.10.25.4-1~lucid1           GStreamer plugins from the "good" set

the problem still happen, so this seems another problem
Comment 4 Mark Nauwelaerts 2010-12-06 14:00:43 UTC
I don't see any (visual) problems with the stream at the indicated times.
However, there do tend to be some decoder complaints around those times.
Equally however, those complaints remain constant through all the pipeline transformations given above (i.e. complaints/problems do not go away when run through another pair of (de)payloading or h264parse). 

So, it would seem the problem is in the stream itself.
Comment 5 Nicola 2010-12-06 14:25:47 UTC
with my gstreamer installation the video is completly grey with this pipeline at the indicated times:

gst-launch filesrc location=h264.gdp ! gdpdepay ! ffdec_h264 ! xvimagesink

and the problem disappear if I convert the file as described in comment 1
Comment 6 David Schleef 2011-06-01 01:22:16 UTC
This plays completely fine with ewh264dec.  ffdec_h264 prints some errors, but it's a bit finicky about bitstream errors that ewh264dec recovers from.

I don't see a bug here.  It would be nice if ffmpeg was a bit better about error recovery, but that's not our domain.

Please reopen if there is any additional information.