[gst-devel] GST_FLOW_WRONG_STATE

[Radivoje Jovanovic]

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?
Another question is if I am giving too much memory to gstreamer with
max-size-time=0 max-size-bytes=0?
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101209/e91f581f/attachment.htm>