GNOME Bugzilla – Bug 738131
playbin: Bogus results from GST_STATE_NULL (audio-)sink
Last modified: 2014-12-05 07:00:05 UTC
I'm currently investigating playbin being used to switch from A+V files to Video only and back to A+V. The problem I'm encountering is the following: 1) Play a A+V file, two sinks are chosen (or specified, doesn't matter), configured, linked, set to PLAYING ... 2) The source switches from A+V to Video-only (by emitting no-more-pads, adding a new video pad, and removing the old ones), eventually playbin switches to that new group, disables the audio sink on playsink (reconfiguring it), sets the cached audio_sink to GST_STATE_NULL. Everything plays fine. 3) The problem arises when switching back to A+V. As decodebin tries to autoplug the new audio and video pads, it will emit the autoplug-continue signal, which playsink will try to answer ... by querying the cached sinks. 3.1) So far, so good (your sink might be able to handle compressed formats, such as AC3) ... except that the cached sink (in playbin's GstSourceGroup->*_sink) is NOT the one used and NOT in a state >= GST_STATE_READY 3.2) As a result, when asking whether the sink accepts the given caps (say AC3) the sink might say yes (like pulsesink has ac3 in its pad templates and since it's in GST_STATE_NULL it will accept it), which will result in playbin telling decodebin it should stop auto-plugging on those caps (ac3) 3.3) decodebin exposes the ac3 pad, playbin tries to link it to a compatible sink (at this point it *will* set the sink to >= READY before linking)... except it fails because the (hardware/device backing the) audio sink doesn't accept AC3 => negotiation fails I have temporarily worked around the issue in playbin's autoplug_continue_cb and autoplug_select_cb by only checking whether a sink accepts the given caps iif it's in GST_STATE(sink) >= GST_STATE_READY ... but it feels hackish. Any comments/ideas ?
Created attachment 288028 [details] [review] playbin: Only check sinks which are in >= GST_STATE_READY Otherwise we endup with bogus caps intersection (from the pad template caps and not from what the actual hardware/device supports)
Comment on attachment 288028 [details] [review] playbin: Only check sinks which are in >= GST_STATE_READY Why only for group->audio_sink and not video/text sink too? Also isn't that code setting the sinks to READY before?
(In reply to comment #2) > (From update of attachment 288028 [details] [review]) > Why only for group->audio_sink and not video/text sink too? It wasn't meant to be the final/official commit. Just a demonstration of how I circumvented the issue. > Also isn't that code setting the sinks to READY before? Which one ? autoplug-continue, for example, will happen at any time. If you're currently in a video-only pipeline, then group->audio_sink *is* in GST_STATE_NULL.
(In reply to comment #3) > > Also isn't that code setting the sinks to READY before? > > Which one ? autoplug-continue, for example, will happen at any time. If > you're currently in a video-only pipeline, then group->audio_sink *is* in > GST_STATE_NULL. activate_sink() (not called by autoplug_continue apparently, only autoplug_select), which should also activate those sinks for video-only pipelines. I mean, how can playbin know at that point that it is video-only if it doesn't have finished autoplugging all streams?
won't calling activate_sink on the SourceGroup sinks cause problems later on ?
Created attachment 291935 [details] [review] playbin: Only check sinks which are in >= GST_STATE_READY Otherwise we endup with bogus caps intersection (from the pad template caps and not from what the actual hardware/device supports)
Should this be backported to 1.4 also ? commit 6a2f017bfa9cb73c6db65eea0b84b1d5b56febb7 Author: Edward Hervey <bilboed@bilboed.com> Date: Wed Oct 8 08:54:57 2014 +0200 playbin: Only check sinks which are in >= GST_STATE_READY Otherwise we endup with bogus caps intersection (from the pad template caps and not from what the actual hardware/device supports) https://bugzilla.gnome.org/show_bug.cgi?id=738131