decodebin3: improve decoder selection
authorMichael Olbrich <m.olbrich@pengutronix.de>
Fri, 11 Jun 2021 07:02:29 +0000 (09:02 +0200)
committerEdward Hervey <bilboed@bilboed.com>
Mon, 19 Jul 2021 08:56:35 +0000 (08:56 +0000)
commit5bfb78aa287c3aabbf0525f35e2de66955c3781f
tree18872a7c9adee3b1fbfe29564c38bc9c8378b83e
parent210cf85fdc77b91b02b02fe1449d90f91f3dd167
decodebin3: improve decoder selection

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: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1201>
gst/playback/gstdecodebin3.c