Skip to content

decodebin3: improve decoder selection

Michael Olbrich requested to merge mol/gst-plugins-base:decodebin3 into master

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.

Before a new decoder is created, a caps query is already used to test if the last encoder can be reused. If this fails then we know that this type cannot be used. So use this information when the new type is selected.

Note: gst_element_factory_get_element_type() only returns a valid type if the factory was already loaded. This is not a problem here: We only care if it matches the type of the previous decoder and for that type, the factory is already loaded.

This does not fix all theoretical cases, but usually there is at most one hardware decoder available that could fail, so it should cover most use-cases.

Merge request reports