GNOME Bugzilla – Bug 524346
Framerate not being displayed correctly on running gst-discover.py
Last modified: 2008-04-01 14:01:00 UTC
Please describe the problem: I have found that using asf encoded videos, the framerate is not correctly reported by the gst-discover example. I will try to attach a sample file that has 29,97FPS and gst-discover reports 25/1 Steps to reproduce: 1. Run gst-discover.py with the sample attached as uri/source Actual results: Framerate is shown as 25/1 Expected results: Framerate of the file is 29,97 Does this happen every time? Yes Other information:
Created attachment 108009 [details] sample video file for testing File sample being used. Generated from the original file using: mencoder THE\ BACKWOODS\ PARTE\ UNICA.sample.wmv -endpos 500kb -ovc copy -oac copy -o sample.wmv
That might be caused by: gstffmpegdec.c:636:gst_ffmpegdec_setcaps:<ffdec_wmav20> forcing 25/1 framerate Just a few lines later everything is done properly though, i.e. 29.97 fps for the video and whatever framerate for the audio.
it seems to work here too. I ran gst-discover and it reports: wim@metal:~/gst/head/gst-python/examples$ ./gst-discover /home/wim/data/sample.wmv media type: video/x-msvideo has video: True video caps: video/x-raw-yuv, width=(int)320, height=(int)240, framerate=(fraction)2997/100, format=(fourcc)I420 video width (pixels): 320 video height (pixels): 240 video length (ms): 10143 framerate (fps): 2997/100 has audio: True audio caps: audio/x-raw-int, rate=(int)48000, channels=(int)2, signed=(boolean)true, endianness=(int)1234, width=(int)16, depth=(int)16 audio format: integer sample rate (Hz): 48000 sample width (bits): 16 sample depth (bits): 16 audio length (ms): 10922 audio channels: 2 wim@metal:~/gst/head/gst-python/examples$ This is with CVS gstreamer and gst-python
I can't see why it would fail. Can you run gst-discover like: GST_DEBUG=*avi*:5,*ffmpeg*:5 gst-discover /path/to/file >debug.log 2>&1 And then attach a gzipped debug.log to this bug report?
Created attachment 108060 [details] Debug log
(In reply to comment #4) > I can't see why it would fail. Can you run gst-discover like: > > GST_DEBUG=*avi*:5,*ffmpeg*:5 gst-discover /path/to/file >debug.log 2>&1 > > And then attach a gzipped debug.log to this bug report? > media type: video/x-ms-asf has video: True video caps: video/x-raw-yuv, width=(int)320, height=(int)240, framerate=(fraction)25/1, format=(fourcc)I420 video width (pixels): 320 video height (pixels): 240 video length (ms): 5972783 framerate (fps): 25/1 has audio: True audio caps: audio/x-raw-int, rate=(int)48000, channels=(int)2, signed=(boolean)true, endianness=(int)1234, width=(int)16, depth=(int)16 audio format: integer sample rate (Hz): 48000 sample width (bits): 16 sample depth (bits): 16 audio length (ms): 5972783 audio channels: 2
Can you make this file available? the file you provided earlier is an avi file, while the file in your example seems to be an asf file.
(In reply to comment #7) > Can you make this file available? the file you provided earlier is an avi file, > while the file in your example seems to be an asf file. > (In reply to comment #7) > Can you make this file available? the file you provided earlier is an avi file, > while the file in your example seems to be an asf file. > I am sorry Tim, I am trying to get the sample of the original file without changing its original properties but my lack of knowledge on video encodings and its tools are giving me a hard time. The original file has over 600Mb. Thanks Mesquita
You could try: $ head --bytes=999k bigfile.asf > bigfile-head.asf That's likely to have all the important information in it.
Created attachment 108080 [details] CORRECT video stream Now it outputs the correct (incorrect) information: media type: video/x-ms-asf has video: True video caps: video/x-raw-yuv, width=(int)320, height=(int)240, framerate=(fraction)25/1, format=(fourcc)I420 video width (pixels): 320 video height (pixels): 240 video length (ms): 5972783 framerate (fps): 25/1 has audio: True audio caps: audio/x-raw-int, rate=(int)48000, channels=(int)2, signed=(boolean)true, endianness=(int)1234, width=(int)16, depth=(int)16 audio format: integer sample rate (Hz): 48000 sample width (bits): 16 sample depth (bits): 16 audio length (ms): 5972783 audio channels: 2 Thank you for the head tip.
Now we are allright. Thanks for the TIP. PS: Sorry, forgot to set the first attachment as obsolete. Mesquita
I am sorry and I re-read my last reply and I thought that it did not make much sense. The possible bug persists, but now the samples and debug information are correct. Thanks, Mesquita
asfdemux does not seem to have a framerate for video and seems to hardcode the framerate to 25/1 in pull mode. In push mode it plays with the average frame durations to guess a framerate.
argh, asfdemux is too broken too fix this.
* gst/asfdemux/gstasfdemux.c: (gst_asf_demux_add_video_stream), (gst_asf_demux_process_ext_stream_props): Instead of adding a fixes 25/1 framerate to the video caps, use the average frame duration in the extended properties of the video stream as the framerate. Fixes #524346.