Hello,
I am currently working on a gstreamer plugin for the atmel at91sam9m10(source can be found here: http://www.at91.com/linux4sam/bin/view/Linux4SAM/SAM9M10Gstreamer). It embeds a video decoder, and I am trying to make it works. Currently I am testing it doing: gst-launch filesrc location= mnt/video/AVI/MPEG4/myfile.avi ! avidemux name=demux demux.video_00 ! queue ! x170 output=RGB16 inbuf-thresh=0000 output_width=480 output_height=240 ! ximagesink display=:0.0 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...) I am quite stuck with this issue, so any idea will be great!! Regards, Sedji ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
You can try setting "max-size-buffers" property in queue element to some number ( optimum ) .
On Wed, Mar 3, 2010 at 2:57 PM, Sedji Gaouaou <[hidden email]> wrote: Hello, -- Regards, Sudarshan Bisht ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Maybe your hardware is slow , and thats where the sink is dropping frames. You can verify this by using sync=false after ximagesink, which in a way you already did by using GST_CLOCK_TIME_NONE. Check with other stream , maybe a .mov/mp4 file using qtdemux.
- kapil On Wed, Mar 3, 2010 at 3:45 PM, sudarshan bisht <[hidden email]> wrote: You can try setting "max-size-buffers" property in queue element to some number ( optimum ) . -- http://www.linkedin.com/in/kapilagrawal ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Thank you for your answers.
I am currently trying to play with the "max-size-buffer" property. I have already try to do "sync=false" and I have exactly the same result as setting the timestamp of ech frame to "GST_CLOCK_TIME_NONE": it is working, the file play until the end. Actually I have the problem only if the movie is long/big enough(more than 8 min...) Le 3/3/2010 11:32 AM, Kapil Agrawal a écrit : > Maybe your hardware is slow , and thats where the sink is dropping > frames. You can verify this by using sync=false after ximagesink, which > in a way you already did by using GST_CLOCK_TIME_NONE. Check with other > stream , maybe a .mov/mp4 file using qtdemux. > > - kapil > > On Wed, Mar 3, 2010 at 3:45 PM, sudarshan bisht > <[hidden email] <mailto:[hidden email]>> wrote: > > You can try setting "max-size-buffers" property in queue element to > some number ( optimum ) . > > On Wed, Mar 3, 2010 at 2:57 PM, Sedji Gaouaou > <[hidden email] <mailto:[hidden email]>> wrote: > > Hello, > > I am currently working on a gstreamer plugin for the atmel > at91sam9m10(source can be found here: > http://www.at91.com/linux4sam/bin/view/Linux4SAM/SAM9M10Gstreamer). > It > embeds a video decoder, and I am trying to make it works. > > Currently I am testing it doing: > gst-launch filesrc location= mnt/video/AVI/MPEG4/myfile.avi ! > avidemux > name=demux demux.video_00 ! queue ! x170 output=RGB16 > inbuf-thresh=0000 > output_width=480 output_height=240 ! ximagesink display=:0.0 > > > 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...) > > I am quite stuck with this issue, so any idea will be great!! > > Regards, > Sedji > > > ------------------------------------------------------------------------------ > 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 > [hidden email] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > -- > Regards, > > Sudarshan Bisht > > ------------------------------------------------------------------------------ > 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 > [hidden email] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > -- > http://www.linkedin.com/in/kapilagrawal > > > > ------------------------------------------------------------------------------ > 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Administrator
|
In reply to this post by Sedji Gaouaou
On Wed, 2010-03-03 at 10:27 +0100, Sedji Gaouaou wrote:
> Hello, > > I am currently working on a gstreamer plugin for the atmel > at91sam9m10(source can be found here: > http://www.at91.com/linux4sam/bin/view/Linux4SAM/SAM9M10Gstreamer). It > embeds a video decoder, and I am trying to make it works. > > Currently I am testing it doing: > gst-launch filesrc location= mnt/video/AVI/MPEG4/myfile.avi ! avidemux > name=demux demux.video_00 ! queue ! x170 output=RGB16 inbuf-thresh=0000 > output_width=480 output_height=240 ! ximagesink display=:0.0 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. > > > 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. > > I am quite stuck with this issue, so any idea will be great!! > > Regards, > Sedji > > > ------------------------------------------------------------------------------ > 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Is your problem still valid for small .avi files. If yes try large .mov/.mp4 files using qtdemux ?
On Wed, Mar 3, 2010 at 6:30 PM, Sedji Gaouaou <[hidden email]> wrote: Well, I have now tested this command line: -- http://www.linkedin.com/in/kapilagrawal ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Hi,
Le 3/4/2010 6:06 AM, Kapil Agrawal a écrit : > Is your problem still valid for small .avi files. If yes try large > .mov/.mp4 files using qtdemux ? > I didn't tried .mov/.mp4 files, but I have try to use another renderer. Instead of using ximagesink I have tried fbdevsink, and it is working!!I can play a "long" avi file with this command line: gst-launch filesrc location= mnt/video/AVI/MPEG4/Seinfel d_timestamp.avi ! avidemux name=demux demux.video_00 ! queue ! x170 output=RGB16 inbuf-thresh=0000 output_width=480 output_height=240 ! fbdevsink So basicly I would like to know what can go wrong in ximagesink? Maybe my system is to slow to run the X11 needed? I have an ARM926 running at 400MHz. Regards, Sedji ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |