[Bug 792693] New: decodebin3: high cpu usage after eos

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=792693

            Bug ID: 792693
           Summary: decodebin3: high cpu usage after eos
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fengalin at free.fr
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 367094
  --> https://bugzilla.gnome.org/attachment.cgi?id=367094&action=edit
Patch

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.