GNOME Bugzilla – Bug 313970
ffdec_mpeg4 detects wrong framerate with some files
Last modified: 2005-10-12 07:47:02 UTC
For some files ffdec_mpeg4 in gst-ffmpeg 0.8.6 tries to set a framerate of 30000 and thus fails to link to the videosink. [gst-0.8] arwed@Otherland:~/Movies$ gst-launch-0.8 playbin uri=file://test.avi RUNNING pipeline ... Waiting for the state change... ERROR (0x8069958 - 312353:20:50.685226000) GST_PADS( 7609) gstpad.c(2562):gst_pad_set_explicit_caps:<ffdec_mpeg40> failed to negotiate (try_set_caps with "video/x-raw-yuv, width=(int)352, height=(int)256, framerate=(double)30000, format=(fourcc)I420, pixel-aspect-ratio=(fraction)1/1" returned REFUSED) ERROR: from element /internal_thread/decoder/ffdec_mpeg40: Internal GStreamer error: pad problem. File a bug. Downgrading gst-ffmpeg to 0.8.5 fixes that problem, upgrading to cvs of 2005-08-19 doesn't.
Created attachment 50993 [details] test file producing the broken behaviour
Got exactly the same problem. It may have something to do with variable bit rate movies where time_base is used for precision instead of frame rate. Precision seems to be measured in frames/millisecond in ffmpeg while framerate is measured in frames/second. The code in gstffmpegcodecmap.c doesn't seem to differentiate between variable and constant framerate. Both, the attached test case and my test video, are DivX 5 movies. They play fine with gst-ffmpeg 0.8.5, ffplay, xvidcore.
*** Bug 314971 has been marked as a duplicate of this bug. ***
Well, i've looked at the problem. ffmpeg reports the video as having 30000fps (i've also tried with current cvs). In ffmpeg.c:3097 there is this check: if (enc->time_base.den != rfps || enc->time_base.num != rfps_base) { fprintf(stderr,"\nSeems that stream %d comes from film source: ... } where enc->time_base is the "framerate" information found by the decoder and rfps the information found by the demuxer. Then: /* update the current frame rate to match the stream frame rate */ frame_rate = rfps; frame_rate_base = rfps_base; so ffmpeg always use the framerate information found by the demuxer. If you try: gst-launch-0.8 filesrc location="ffmpeg3000fps.avi" ! avidemux ! fakesink -v you can see that the framerate is found correctly(framerate=(double)29.9699999). So... what can we do? ffdec should set the framerate property only when there isn't one already? Ronald, any idea?
More news in this thread: http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-September/003874.html
*** Bug 317040 has been marked as a duplicate of this bug. ***
Created attachment 52741 [details] [review] first try This patch uses the demuxer framerate if avaible. Otherwise it'll use ffmpeg's one. I've done some tests and it seems to work fine.. please review :)
Looks good, thanks. I'll do a new release shortly, I messed up 0.8.6 a bit, I'm affraid... Or maybe having bugs is just normal. :).
Created attachment 52909 [details] [review] second patch This patch fixes the previous patch (oops) and fix also #317596. yeah, it's normal to make bugs ;) I'll work better on this patch later (i hope..)
*** Bug 317370 has been marked as a duplicate of this bug. ***
Fixed. I've applied the second patch. Please help me testing :)
This patch solves all my bugs !! (slow mpeg and some other unable to read !!) Thank you very much !!
*** Bug 318634 has been marked as a duplicate of this bug. ***