problem when playing an mpeg4 video

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

problem when playing an mpeg4 video

Sedji Gaouaou
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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Sudarshan Bisht
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,

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&#174; 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



--
Regards,

Sudarshan Bisht

------------------------------------------------------------------------------
Download Intel&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Kapil Agrawal
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 )  .

On Wed, Mar 3, 2010 at 2:57 PM, Sedji Gaouaou <[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&#174; 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



--
Regards,

Sudarshan Bisht

------------------------------------------------------------------------------
Download Intel&#174; 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




--
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------
Download Intel&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Sedji Gaouaou
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&#174; 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&#174; 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&#174; 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&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Edward Hervey
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&#174; 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&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Sedji Gaouaou
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&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: 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&#174; 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&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Kapil Agrawal
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:
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&#174; 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&#174; 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



--
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------
Download Intel&#174; 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
Reply | Threaded
Open this post in threaded view
|

Re: problem when playing an mpeg4 video

Sedji Gaouaou
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&#174; 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