Created attachment 367094 [details] [review]
Patch: avoid looping on final eos event

After eos, decodebin3 enters a loop sending eos events which causes high cpu usage.

Here is a description of the problem:

- decodebin3-parse, parse_chain_output_probe
    (last src pad of the parse chain for an input stream):
  When an eos event is received for current input stream:
    if all input streams are eos:
(A)   send a "regular" eos event to each multiqueue sink pads
    else:
(B)   send a "decodebin3-custom-eos" eos event
      to current slot's multiqueue sink pad
    drop current eos event

- decodebin3, multiqueue_src_probe (multiqueue sink pad for an input stream)
  When an eos event is received from the parse chain for current input stream:
    if the eos event is a "decodebin3-custom-eos": (coming from (B))
      if all input and output streams are eos:
(D)     send a stream-start and then a "regular" eos event
        to each multiqueue sink pads
      drop current eos event
    else: ("regular" eos, coming from (A)... or from (D) or (E)!)
     if all inputs stream and output streams are eos:
(E)     send a stream-start and then a "regular" eos event
        to each multiqueue sink pads

The issue happens when we reach (D) or (E) as a "regular" eos event is sent back to the multiqueue sink pads which will lead to another (E), etc.

Since reaching a proper sequence is tricky (1), I tried to come up with a solution with as little impact as possible. What I did was marking the eos event from (D) and (E) as "decodebin3-custom-final-eos", so that we can differentiate it from the eos event coming from (A) and avoid doing (E) again and again.

The way the bin is designed, eos events are propagated downstream after all input and output streams are eos. Actually, the stream which initiated (E) let its eos event received from (A) propagate, then it would also let the eos event from (E) propagate. Not only an eos event could be sent twice (and more since we were looping on (E)) but also, it wasn't consistent with the same situation initiated from (D). For consistency among all streams, I decided to drop the event received from (A) and let the event received from (E) propagate. I hope the fact that it is marked as "decodebin3-custom-final-eos" won't impact downstream.

---

(1) https://bugzilla.gnome.org/show_bug.cgi?id=785951