<slomo> ad-n770: hi, let's discuss your playbin2 change from today... there's a bug about it and it's not really clear that your fix is the right thing to do
<ad-n770> slomo: sure
<slomo> ad-n770: the thing is, that it's entirely unexpected for the application if a sink is used that wasn't set by the application. it has absolutely no control over the sink and weird stuff could happen. just consider e.g. a gst-clutter application where you want the clutter sink to be used and now suddenly playbin2 decides to use xvimagesink, which then pops up a new window and everything becomes weird
<slomo> ad-n770: the more natural behaviour is to just fail if the manually specified sink can't cope with the stream. in the end the application *asked* for this sink to be used
<slomo> ad-n770: why would it want a random sink that playbin2 thinks might be better?
<__tim> I consider the previous behaviour a bug
* slomo too
<ad-n770> well from my point of view the final goal of playbin is to play the media
<ad-n770> if there's the proper elements to play the media it should pay it with the best intention
<__tim> but it should play the media where requested, not into random places/windows
<ad-n770> if like you said a new window is oppened then it's clear that's something wrong in the application
<slomo> even if it's completely unexpected? would you also want playbin2 to show the video of a video stream if the application selected to not play the video? ;)
<__tim> the real problem is not with the application
<ad-n770> if it just doesn't play this is not clear
<__tim> the real problem is that the decoder is not compatible with the chosen sink and shouldn't have been selected in the first place
<slomo> ad-n770: xvimagesink automatically creates a new window and it will be selected by playbin2 in some cases over the selected sink. and the application can't know that some weird other sink was selected
<ad-n770> __tim: real problem is the application forcing a certain sink
<ad-n770> instead of trying to autoplug one that can be used
<__tim> that's perfectly legitimate
<slomo> ad-n770: exactly, if it doesn't want that it shouldn't force a certain sink... or it should live with the problem that the sink might not work with the stream ;)
<__tim> imagine a thumbnailer setting gdkpixbufsink as video sink. We most certainly don't want that ever pop up any windows
<__tim> +to
<ad-n770> this would be nice if for example the decodebin pipeline choses the decoder that matches the configured sink instead of being to late to not being able to link with it
<slomo> ad-n770: it will do that
<__tim> yes, solving that all nicely needs some more thought/work
<slomo> ad-n770: we only assume that every sink supports the "raw" caps, but other than that it chooses the decoder with the highest rank that can output something the sink can handle (or raw caps)
<ad-n770> slomo, please point the code where this is done
<ad-n770> I see the decoder plugged with the highest rank with no concern if the sink would be able to cope with it
<slomo> ad-n770: the autoplug-* signals of decodebin2, that are handled in playbin2
<ad-n770> then problem is autovideosink ?
<ad-n770> because it exposes ANY in the sinkpad ?
<slomo> might be, i don't know which problems you're trying to solve though ;)
<ad-n770> slomo, I'm not caching how the decoder with a higher rank is discarded if it's not compatible with the configured sink
<ad-n770> let's say there's 2 deocoders in the system one can generate raw video and the other can't
<ad-n770> but highest rank is for the one that doesn't generate raw video
<ad-n770> so the one with highest rank that is compatible with the configured sink should be slected
<slomo> yes
<slomo> that will happen
<slomo> otherwise it's a bug
<ad-n770> then I think it's a bug because it doesn't seems to happen
<ad-n770> and I don't see in the code how it could work as you said
<slomo> ad-n770: look at the autoplug-* signal handlers
<ad-n770> I'm looking at them now
<slomo> ad-n770: playbin2 checks the configured sink everywhere and also has code to autoplug a compatible sink if none was specified by the application
<ad-n770> slomo: at autoplug_factories_cb
<slomo> and autoplug_select_cb and autoplug_continue_cb
<ad-n770> should playbin2 skip decoders that can't produce for the configured sink ?
<slomo> yes and it will (except the assumption that every sink handles raw formats)
<ad-n770> I dont see how
<slomo> hmm, actually... you're right
<slomo> it will plug the decoder and then later notice that it can't convert/decode to a format supported by the sink and fail
<ad-n770> that's good because this is the issue
<ad-n770> I mean that playbin should play the media when it have all elements to do it
<slomo> how is this related to your change?
<ad-n770> this allows continue playing like it did in last two years
<ad-n770> so it won't break current working use cases
<slomo> why? because a random sink is selected that can handle the format while the configured one doesn't?
<ad-n770> yes
<ad-n770> it still play the media
<ad-n770> you can say that it plays in a bad way
<slomo> and it could even cause worse situations than not being able to play the media at all
<slomo> it doesn't in your application because it relies on undocumented and broken behaviour though
<slomo> the real solution would be to make decodebin2/playbin2 a bit more intelligent with the selection of decoders
<slomo> and make it actually aware of decoders and that they should output something that could be accepted by sinks
<ad-n770> well I will be happy that you'll revert my change when this is handled
<slomo> ad-n770: i think it will be reverted in any case, even if we don't implement the correct solution for this problem in the near future. the behaviour with your change reverted is at least sensible, deterministic, expected and causes less problems (and we all agree that the behaviour after your change is simply broken)
<__tim> that change will be reverted because the behaviour is broken
<ad-n770> well as ever you can what you want
<ad-n770> I'm not happy because a lot of users will lost something that was working for past two years
<__tim> well, even with the change, the behaviour will be broken in e.g. (current versions of) totem
<slomo> ad-n770: which decoders are we talking about here btw? implementing the correct autoplugging behaviour in decodebin2/playbin2 should be a matter of maybe one week work for one person (making it aware of decoders and doing a more intelligent selection based on the configured sink and what the decoder can output)
<slomo> make that "at most one week"
<ad-n770> well at least playbin2 should post a nice error message for the behaviour 
<__tim> that would be good, yes :-)
<ad-n770> well I'm going for food, 
<ad-n770> we talk later
<slomo> hmm, will be hard to distinguish this from the case where a decoder is missing
