Michael Olbrich authored Jun 11, 2021 and Edward Hervey committed Jul 19, 2021

Currently the decoder selection is very naive: The type with the highest
rank that matches the current caps is used. This works well for software
decoders. The exact supported caps are always known and the static caps are
defined accordingly.
With hardware decoders, e.g. vaapi, the situation is different. The decoder
may reject the caps later during a caps query. At that point, a new decoder
is created. However, the same type is chosen an after several tries,
decodebin fails.

To avoid this, do the caps query while adding the decoder and try again
with other decoder types if the query fails:

1. create the decoder from the next matching type
2. add and link the decoder
3. change the decoder state to READY
4. do the caps query
   if it fails then remove the decoder again and go back to 1.
5. expose the source pad
6. sync the decoder state with the parent.

This way, the decoder is already part of the pipeline when the state change
to READY happens. So context handling should work as before.

Exposing the source pad after the query was successful is important:
Otherwise the thread from the decoder source pad may block in a blocked pad
downstream in the playsink waiting for other pads to be ready.
The thread now blocks trying to set the state back to NULL while holding
the SELECTION_LOCK. Other streams may block on the SELECTION_LOCK and the
playsink never unblocks the pad. The result is a deadlock.

Part-of: <gstreamer/gst-plugins-base!1201>