GNOME Bugzilla – Bug 668909
[0.11] typefindelement is broken
Last modified: 2012-02-08 13:36:30 UTC
This patch http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?h=0.11&id=bf0964b63a1283eb38a6d803e7a54b07b9e9a7e5 has broken typefind. Now typefind sends SEGMENT event from loop in pull mode, which causes really bad things to demuxers. i.e. matroskademux resets current offset on new segment and the event comes while parsing is already in progress.
Do you have some more details or a way to reproduce it? typefind only sends a single SEGMENT event if it is driving the pipeline (i.e. the loop function is running). This shouldn't happen when matroskademux is linked to typefind, in that case matroskademux will try to activate itself in pull mode and typefind would be deactivated and only passthrough the pull_range() calls. During my tests matroskademux was working fine
Well, the pipeline is quite complex, but it starts with filesrc and decodebin2. What happens is that the typefindelement does activate its pads (stacktrace below) The state change results in gst_type_find_element_activate_sink being called where it does a scheduling mode query and activates the pad in pull mode (starting the task). force_caps is null, which seems like the only way to prevent activation. It is quit possible that matroska-demux works for you, it's quite racy, as the segment is send in another thread. Stacktrace:
+ Trace 229548
Maybe sticky events are not being cleared when typefind pads change scheduling mode or so?
Still, should the loop even be started in the first place?
> Still, should the loop even be started in the first place? Yes, we really want to move typefinding into a streaming thread (i.e. start up a loop), even when it's done in pull mode, instead of doing it from the application thread that does the state change.
Sticky events are cleared when pads are deactivated. So, do you have a simple testcase to reproduce this? :)
I can reproduce some problems. Seems that the typefind sinkpad is not deactivated from PULL mode when upstream wants to go in PULL mode.
Ok, so typefind's own loop thread should only be used if the sinkpad is activated in PULL mode and the srcpad is activated in PUSH mode. In all other cases typefind uses a different streaming thread (from upstream if PUSH/PUSH and from downstream if PULL/PULL). This means that the loop thread must only be started if both pads are activated that way and it must be stopped again if one of the pads gets deactivated/activated in a different mode.
commit 27d639ec09d6853a374d4dd8b548f2a1dbd47de6 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Feb 8 14:32:01 2012 +0100 typefind: fix race in pad mode change Fixes #668909 and presumably also #669483
*** Bug 669483 has been marked as a duplicate of this bug. ***