Skip to content

decodebin3: Race with input collection handling

With the new collection refactoring from March, decodebin3 expects "collections" to be present for all input/inputstream. That is, the code assumes that any GST_EVENT_STREAM_START (i.e. beginning of a stream) that reaches the output of the internal multiqueue:

  • Will have a matching collection
  • For every upstream (or computed) collection detected on input, the app/user must have a guaranteed way to specify what selection he wants for that collection, by synchronously responding to GST_MESSAGE_STREAM_COLLECTION with a GST_EVENT_SELECT_STREAMS

In this case, we are focusing on the default behaviour of decodebin3 within uridecodebin3 and playbin3, which is that upstream urisourcebin will provided parsed elementary streams along with a GST_EVENT_STREAM_COLLECTION specifying the streams present.

But there is a race in the way this is handled, and we end up with the following situation

  • Multiple streaming threads are pushing data into different decodebin3 sink pad
  • In this scenario, we will not forward any event forward if the DecodebinInput does not have a specified collection. Events are just accumulated.
  • The "first" stream that receives a GST_EVENT_STREAM_COLLECTION will compute/update the input collection (with the INPUT LOCK taken) and post a message (without the INPUT LOCK taken) to inform the user
  • But the problem is that other threads will:
    • Not take the INPUT LOCK to check whether they can forward events (because a input collection is properly set)
    • And even if they did, the input lock is not taken when posting the message

Therefore, the code needs to be made more robust to make this input collection handling "atomic"

  • The INPUT_LOCK should be taken when checking if the input collection is set or not
  • An extra "posting collection" boolean and conditional should be added to DecodebinCollection, so that other incoming threads can be throttled during that posting