[gstreamer-bugs] [Bug 538176] State change trouble with decodebin and empty files

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=538176

  GStreamer | gstreamer (core) | Ver: 0.10.18

Jorn Baayen changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED




------- Comment #4 from Jorn Baayen  2008-06-13 20:00 UTC -------
(In reply to comment #2)
> Just some quick comments (have only glanced at the code, not tried it):
> 
>   - it's generally a bad idea to use gst_element_get_state (..., NONE)
>     in a real application, because it won't ever return if an error
>     occurs outside of the state change function (e.g. an error in
>     the streaming thread)
> 
>   - downward state changes are immediate, you don't need to do a
>     _get_state() after a _set_state (pipeline, NULL). (And in
>     general, waiting for a state change with get_state usually
>     only really needs to be done if _set_change() returned
>     STATE_CHANGE_ASYNC, as it will usually only for state
>     changes to PAUSED/PLAYING).

Yes, the above patch is only for testing purposes which is why it is not
included in the gaku svn trunk.

To elaborate, our real problem is not _get_state() not returning, but rather
the pipeline being confused after having met an empty file: no more tags are
found for successive streams. _get_state() not returing appears to be a mere
symptom of this. I've included it in the bug report as I thought it might help
to track down the problem.

>  - if you just want the tags, it's easiest to set the pipeline
>    to PAUSED state and then do something like:
> 
>      msg = gst_bus_poll (pipeline_bus,
>                          GST_MESSAGE_TAG |
>                          GST_MESSAGE_ASYNC |
>                          GST_MESSAGE_EOS |
>                          GST_MESSAGE_ERROR);
> 
>    in  a loop until you get ASYNC, EOS or ERROR. This will iterate the
>    main context though; gst_bus_pop_filtered() does the same thing without
>    iterating the default main context.

Yes but that would block the main loop wouldn't it? Our code is meant to be
able to scan for metadata while any UI running in the same thread would stay
responsive.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=538176.