GNOME Bugzilla – Bug 722316
playbin: flac playback broken
Last modified: 2014-11-08 14:14:35 UTC
Errors out with: analyze_new_pad:<decodebin0> New pad in a chain that is already complete and flow unlinked. Not sure where the problem is, uridecodebin ! pulsesink works fine.
Works here, with core/-base/-good from 10 mins ago, as well as from a couple days ago (ish), sing gst-launch-1.0 playbin uri=file:///path/to/flac
I can confirm this here, happens with files created like: > gst-launch-1.0 audiotestsrc num-buffers=1000 ! flacenc ! oggmux ! filesink location=test.ogg > gst-launch-1.0 audiotestsrc num-buffers=1000 ! flacenc ! filesink location=test.flac Playing the Ogg file doesn't even error out properly with gst-play-1.0.
Still works for me with those two files, gst-launch-1.0 and gst-play-1.0. I have libflac 1.2.1-6 (Ubuntu). That's the most obvious possible difference I can think of.
1.3.0-2 here but that really shouldn't make a different. It's decodebin that goes crazy here :)
Works for me, too, both .flag and .ogg samples, with both gst-launch-1.0 and gst-play-1.0
I guess that means that Tim or I have to debug it ourselves ;)
It works with decodebin and uridecodebin but fails with playbin. Reverting baseparse, decodebin/uridecodebin/playbin/playsink or audiodecoder to 1.2.2 does not make a difference.
That's because sfdec feels responsible for flac too and is preferred over flacdec for some reason (bug 1), then sfdec fails to go to READY but decodebin does not clean up properly before it tries to link in flacdec (bug 2).
And sfdec fails to go to PAUSED (not READY) because it can only work in pull mode, but flacparse is in front of it and doesn't allow that obviously.
And sfdec is only used because of playbin's autoplug handling. Anyway, I have fixes. Will push after some further testing.
Works again now, now just needs the fix in decodebin to properly handle final (!) elements failing to PAUSED. Each of these changes fixes the problem individually btw ;) commit 1f9c30569467c77c64b8ba34ff10f274db6e4e9b Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Jan 18 13:06:29 2014 +0100 sfdec: This is a decoder, not a demuxer Don't confuse autopluggers! https://bugzilla.gnome.org/show_bug.cgi?id=722316 commit 4f8f5918be3a72ed627dd37939aa1fa26735fd73 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Jan 18 13:31:06 2014 +0100 playbin: Insert decoders without GstAVElement information between the other Otherwise they would be preferred over all decoders independent of their ranks. https://bugzilla.gnome.org/show_bug.cgi?id=722316 commit 6b46019abfe57308ebc297322dcd89e7b7c144eb Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Jan 18 13:12:16 2014 +0100 playbin: Only put parsers and sinks first, not all non-decoders https://bugzilla.gnome.org/show_bug.cgi?id=722316
Created attachment 266607 [details] [review] WIP: decodebin: Connect elements further after they've reached PAUSED successfully Otherwise we won't be able to handle failing "final" elements, because connecting further will expose pads already for them. OTOH connecting elements further after PAUSED will break with elements that activate in pull mode as we might miss buffers, caps or added pads because we connect for all this only later.
This needs some further thought as explained in the commit message... any ideas that don't require refactoring a lot of the autoplugging logic in decodebin? You need to revert the other commits above to reproduce the problem :)
commit 994680b04eb390a116a9b5bda2abd647df233be3 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Jul 10 12:50:17 2014 +0200 decodebin: Only link elements further after setting them to PAUSED They might fail to go to PAUSED, and when connecting them further we might already expose their srcpads on decodebin if we're unlucky. This prevents us to handle failures going to PAUSED gracefully.