mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-04 13:45:52 +00:00
5bfb78aa28
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> |
||
|---|---|---|
| .. | ||
| adder | ||
| app | ||
| audioconvert | ||
| audiomixer | ||
| audiorate | ||
| audioresample | ||
| audiotestsrc | ||
| compositor | ||
| encoding | ||
| gio | ||
| overlaycomposition | ||
| pbtypes | ||
| playback | ||
| rawparse | ||
| subparse | ||
| tcp | ||
| typefind | ||
| videoconvert | ||
| videorate | ||
| videoscale | ||
| videotestsrc | ||
| volume | ||
| meson.build | ||