[gst-devel] problem when playing an mpeg4 video

[Sedji Gaouaou]

Well, I have now tested this command line:
gst-launch -v filesrc location= mnt/video/AVI/MPEG4/Myfile.avi ! 
avidemux name=demux demux.video_00 ! queue ! x170 output=RG
B16 inbuf-thresh=0000 output_width=480 output_height=240 ! fakesink 
sync=True

And it is really peculiar because the file play until the end,and the 
timestamp displayed are all correct...

I am now really confused :)

Le 3/3/2010 1:26 PM, Sedji Gaouaou a écrit :
> Hi
>>
>>     Is your decoder outputting properly timestamped buffers ? Replace
>> "ximagesink display=:0.0" with "fakesink sync=True" and use the '-v'
>> argument of gst-launch.
>>
>>     With that you will be able to see the timestamp/durations of the
>> buffers entering fakesink. You should normally see continuously
>> increasing value.
>>
>
> I will try that to check the timestamp of each frame.
>>>
>>> It works for a while, but at some point I have this error:
>>>
>>> WARNING: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
>>> A lot of buffers are being dropped.
>>> Additional debug info:
>>> gstbasesink.c(2572): gst_base_sink_is_too_late ():
>>> /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
>>> There may be a timestamping problem, or this computer is too slow.
>>>
>>> I am using the gstreamer_0.10.25.
>>>
>>> I have noticed that this message comes from the gstbasesink.c, and I
>>> also noticed that if I change the timestamp of my decoded frame to
>>> "GST_CLOCK_TIME_NONE", then I don't see the problem anymore(but of
>>> course the file is played in fast forward...)
>>
>>     If it manages to play it that fast in this case... that means your
>> decoder is fast enough, which points even more to the fact that the
>> buffers coming out from your decoder are wrongly timestamped.
>>
>>>
>
> The point I don't understand then, is why the file is correctly played
> for a while and all of a sudden I have some errors.
> For instance the file last about 20 minutes, I have errors towards the
> 15th min.
>
> I was first thinking that maybe some buffers were overwritten and so the
> displayed missed some frames. In that case if the timestamp were set to
> GST_CLOCK_TIME_NONE, then any overwritten buffers will not cause any
> problems...
>
> But I am not really sure, it is just a guess...
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>