GNOME Bugzilla – Bug 654666
mpeg4videoparse: Fix failure to find frames on some streams
Last modified: 2011-11-30 10:17:04 UTC
I recorded samples in 640x480 and in 1280x1024 with the same app. The app uses the following pipeline inside: appsrc ! gdppay ! filesink. Then I'm trying to play the samples with the following pipeline: ~/bin/gstreamer/bin/gst-launch-0.10 -v --gst-plugin-path=/home/user/bin/gstreamer/lib filesrc location=record_640.gdp ! gdpdepay ! mpeg4videoparse ! xviddec ! xvimagesink It plays samples recorded in 640x480 but it fails in 1280x1024 with the following error: <mpeg4vparse0> error: No valid frames found before end of stream The samples can be downloaded here: http://good.net/dl/au/a3db/samples_640_and_1280.tar.gz
Note that the following pipeline nevertheless plays the file in 1280: ~/bin/gstreamer/bin/gst-launch-0.10 -v --gst-plugin-path=/home/user/bin/gstreamer/lib filesrc location=record_1280.gdp ! gdpdepay ! ffdec_mpeg4 ! xvimagesink
Is this the .gdp file where you just dump a stream you receive via UDP into appsrc/a gdp file, without packet re-ordering and somesuch?
When my app assembles a single frame from UDP packets it checks for the sequence number of packets to go strictly in ascending order. If this condition breaks then the app doesn't push the buffers to appsrc. So you can be sure the frames are assembled good. The proof if that 640x480 stream works besides it assembled from packets with length of approximate 1400 bytes the same way as 1280x1024 stream (and also I have checked 720x576 stream from similiar camera).
I see the status is "NEEDINFO". I don't understand what exactly info is needed?
Created attachment 194117 [details] [review] mpeg4videoparse: fix number of bytes read for fixed time increment The spec I found says "16 bits". The existing code used log2(somevalue)+1. ffmpeg uses log2(somevalue-1)+1. The code now uses log2(somevalue-1)+1, and this makes it work with some sample video without breaking another sample. Now, I'm far from certain I've got the right spec, I found it by searching the internet, so...
Any progress on this?
It fixes the issue for the test case. However, I did not find an authoritative source for the exact value. So I'm tempted to push...
I think it's safe if it works for you and is the same that is done in ffmpeg.
Which revision contains fixed sources?
It's in git master, it will be in the next -bad release (0.10.23) (assuming the mpeg4videoparse port to codecutils didn't break anything, that is)