[gst-devel] GST_FLOW_WRONG_STATE

Tue Dec 14 22:22:13 CET 2010

Thank you for all of your input. Unfortunately I did not write the decoders
at all, but I do have the source code. What is considered as decoder
latency? Is it the time for decoder to set up or something else?
Cheers
Ogi

On Thu, Dec 9, 2010 at 7:45 PM, ved kpl <ved.kpl at gmail.com> wrote:

> On Fri, Dec 10, 2010 at 1:39 AM, Radivoje Jovanovic
> <radivojejovanovic at gmail.com> wrote:
> > It seems like we are on a good path. after I tried the pipeline:
> >  gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t ! queue
> > max-size-time=0 max-size-bytes=0 ! mpeg4dec ! MY_VIDEO_SINK t. ! queue
> >   ! faad ! alsasink
> >    (so I only give time and bytes for video side) the video and audio
> worked
> > just fine.
> >
> > Unfortunately this trick does not work for the other decoder I have which
> > decodes h264 videos.
> >
> > Even with the pipeline:
> >  gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t ! queue
> > max-size-time=0 max-size-bytes=0 ! h264dec ! MY_VIDEO_SINK t. ! queue
> >   ! faad ! alsasink
> > The pipeline is stuck. This all has nothing to do with
> GST_FLOW_WRONG_STATE
> > since this error pops up all the time after CTRL-C operation. Any idea
> why
> > would h264 get stuck?
>
>   To start off, try setting max-size-time/bytes/buffers=0 on the both
> the queues (no limits)
>  If it works, it indicates that your h264dec has a very high
> latency..and you can
>  narrow to the problem from here.
>
> > Another question is if I am giving too much memory to gstreamer with
> > max-size-time=0 max-size-bytes=0?
>
>  Well, It would depend on your codec details (resilution, etc),
>  environment/platform. You could possibly track down the issue.
>
> > Cheers
> > Ogi
> >
> >
> > On Wed, Dec 8, 2010 at 8:27 PM, ved kpl <ved.kpl at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> One possible reason could be that one of the queues is getting full
> >> while the other remains empty
> >> because of
> >> (a) continuous audio/video buffers for a considerably longer time,
> >> longer than the what the queues can hold.
> >> (b) high latency at the your video decoder (mpeg4dec).
> >> Hence the streaming thread is blocked & one of the sinks is not able
> >> to commit the state to PAUSED.
> >> (because it has not received a buffer yet).
> >>
> >> Yo can also set async=FALSE on the sinks and see. (not recommended)
> >>
> >> You can try disabling the the max time & max bytes properties of the
> >> queue.
> >> Try the following pipeline
> >>
> >>  gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t ! queue
> >> max-size-time=0 max-size-bytes=0 ! mpeg4dec ! MY_VIDEO_SINK t. ! queue
> >> max-size-time=0 max-size-bytes=0 ! faad ! alsasink -v
> >>
> >> Note that this will increase the mem usage.. and even more if u set
> >> max-size-buffers=0 as well. (queue without any limits!)
> >>
> >> Vikram
> >>
> >> On Thu, Dec 9, 2010 at 9:44 AM, ved kpl <ved.kpl at gmail.com> wrote:
> >> > On Thu, Dec 9, 2010 at 6:26 AM, Radivoje Jovanovic
> >> > <radivojejovanovic at gmail.com> wrote:
> >> >> So the pipeline I am using is:
> >> >> gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t ! queue  !
> >> >> mpeg4dec ! MY_VIDEO_SINK t. ! queue ! faad ! alsasink
> >> >> This pipeline will hang and after CTRL-C the mpeg4dec will show the
> >> >> message
> >> >> that is the result of calling gst_push_pad. This gst_push_pad will
> >> >> return
> >> >> GST_FLOW_WRONG_STATE.
> >> >>
> >> >> If I run gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t !
> >> >> queue
> >> >> ! mpeg4dec ! MY_VIDEO_SINK
> >> >> the video will play just fine
> >> >>
> >> >> If I run:
> >> >> gst-launch-0.10 filesrc location=MY_MOVIE ! qtdemux name=t ! queue !
> >> >> faad !
> >> >> alsasink
> >> >> the audio from the audio will play just fine.
> >> >>
> >> >> I am not sure which code would be helpful since I have a lot of it.
> >> >> Thanks for the GST_DEBUG info.
> >> >>
> >> >> Ogi
> >> >>
> >> >>
> >> >> On Wed, Dec 8, 2010 at 4:05 PM, Tim-Philipp Müller <t.i.m at zen.co.uk>
> >> >> wrote:
> >> >>>
> >> >>> On Wed, 2010-12-08 at 12:53 -0800, Radivoje Jovanovic wrote:
> >> >>>
> >> >>> > I have a video sink and ALSA driver to be used to play videos on
> the
> >> >>> > platform. If I play video or audio by them self everything works
> >> >>> > fine,
> >> >>> > but if I specify the whole pipeline for video and audio, the video
> >> >>> > decoder (in pipeline right before the sink) comes back with the
> >> >>> > message:
> >> >>> > "The decoded frame did not successfully push out to downstream
> >> >>> > element"
> >> >>> > The message comes because the gst_pad_push have returned with
> >> >>> > GST_FLOW_WRONG_STATE instead GST_FLOW_OK.
> >> >>> >
> >> >>> > Any idea why this might happen?
> >> >>>
> >> >>> It usually helps if you post your exact pipeline and/or any code
> >> >>> snippets that go with it.
> >> >>>
> >> >>> FLOW_WRONG_STATE is what you get when a pad is flushing, which may
> be
> >> >>> normal (happens during a flushing seek, to make the old streaming
> >> >>> thread
> >> >>> stop) or because you forgot to set an element into PAUSED/PLAYING
> >> >>> state
> >> >>> (e.g. because you added it from a pad-added or new-decoded-pad
> >> >>> callback
> >> >>> or so).
> >> >>>
> >> >>> The GST_DEBUG=*:5 log might give you more information (just grep for
> >> >>> wrong-state and read the lines before that).
> >> >>>
> >> >>> Cheers
> >> >>>  -Tim
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> ------------------------------------------------------------------------------
> >> >>> This SF Dev2Dev email is sponsored by:
> >> >>>
> >> >>> WikiLeaks The End of the Free Internet
> >> >>> http://p.sf.net/sfu/therealnews-com
> >> >>> _______________________________________________
> >> >>> gstreamer-devel mailing list
> >> >>> gstreamer-devel at lists.sourceforge.net
> >> >>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> This SF Dev2Dev email is sponsored by:
> >> >>
> >> >> WikiLeaks The End of the Free Internet
> >> >> http://p.sf.net/sfu/therealnews-com
> >> >> _______________________________________________
> >> >> gstreamer-devel mailing list
> >> >> gstreamer-devel at lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF Dev2Dev email is sponsored by:
> >>
> >> WikiLeaks The End of the Free Internet
> >> http://p.sf.net/sfu/therealnews-com
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101214/77ffb96d/attachment.htm>