After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 462558 - Regression in async state change handling
Regression in async state change handling
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: 0.10.14
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-01 18:29 UTC by Jan Schmidt
Modified: 2007-08-02 11:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug log 1 (4.62 KB, application/x-gzip)
2007-08-01 18:33 UTC, Jan Schmidt
  Details
debug log 2 (3.69 KB, application/x-gzip)
2007-08-01 18:33 UTC, Jan Schmidt
  Details
potential patch (3.23 KB, patch)
2007-08-02 10:56 UTC, Wim Taymans
committed Details | Review

Description Jan Schmidt 2007-08-01 18:29:46 UTC
Attempting to play a musepack file in playbin no longer succeeds in pre-rolling with the current 0.10.13.4 pre-release.

The problem seems to be caused by the state-change changes since 0.10.13, specifically the handling of async-start/async-done messages.

Attaching some munged gst debug logs that show the sequence. The problem seems to be that the fakesink which decodebin uses to trigger an async state change sends an async-start message, and is then removed before decodebin actually finishes changing state. When it is removed, it sends an async-done, which is not forwarded by decodebin because it has not yet finished changing state, despite the fact that decodebin did originally send an async-start to the parent when it received the original async-start from its child fakesink.

The end result is that playbin thinks decodebin is still changing state asynchronously when it has in fact already completed.
Comment 1 Jan Schmidt 2007-08-01 18:33:18 UTC
Created attachment 92876 [details]
debug log 1

gzipped & munged debug log (I stripped some columns) that shows the sequence occurring when playing a musepack file embedded in an APE tag.
Comment 2 Jan Schmidt 2007-08-01 18:33:57 UTC
Created attachment 92877 [details]
debug log 2

gzipped & munged debug log (I stripped some columns) that shows the sequence occurring when playing an MP3 file embedded in an ID3 tag.
Comment 3 Jan Schmidt 2007-08-01 18:35:20 UTC
The big difference between the 2 scenarios seems to be that musepackdec is pull-based and sends tags to the src pad much sooner than the mp3 decoder, causing the decodebin-fakesink to be removed much sooner.
Comment 4 Wim Taymans 2007-08-02 09:56:07 UTC
It's because decodebin resyncs when iterating over its children (because fakesink was removed in the middle). It then forgets that there was an async element previously that is now gone and therefore does not post an ASYNC_DONE message.
Comment 5 Wim Taymans 2007-08-02 10:56:26 UTC
Created attachment 92909 [details] [review]
potential patch

Don't forget about the fact that some element went ASYNC even after a resync. This makes us post the ASYNC_DONE message correctly.
Comment 6 Jan Schmidt 2007-08-02 11:01:33 UTC
Rock! Please commit :)
Comment 7 Wim Taymans 2007-08-02 11:15:33 UTC
        * gst/gstbin.c: (gst_bin_change_state_func),
        (bin_handle_async_done), (gst_bin_handle_message_func):
        Don't forget about the fact that some element went ASYNC even after a
        resync. This makes us post the ASYNC_DONE message correctly.
        Fixes #462558.