[Bug 757376] New: playbin: have-context and need-context messages are lost

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 757376
           Summary: playbin: have-context and need-context messages are
                    lost
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: vjaquez at igalia.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Working on bug 754820, I have had to revamp the context handling in
gstreamer-vaapi. WIP branch:
https://github.com/ceyusa/gstreamer-vaapi/commits/gstcontext

I'm facing a problem that in a simple playbin (either using gst-launch or
gst-play) the display context, created by vaapisink it is not shared in the
pipeline, and the vaapidecode ends creating its own.

As far as I understand this is problematic flow:

1\ playbin instantiates the video sink (vaapisink) and set it in READY state.
   NOTE: at this moment the video sink is not attached to any bin.

2\ When turning into READY state, the start() vmethod is called, and it looks
for a display context. As the element is isolated, the upstream and downstream
messages fail. Then the element creates a need-context message and post it in
the bus. 

3\ As in the bus there is no a handler assigned yet, the message is queued.

4\ The video sink then creates its own display, and post a have-context message
in to the bus, which is queued too.

5\ When the application assign the bus watcher, the bus dispatches all the
queue messages. The applications usually doesn't handle the context messages,
since they are processed sync and the watcher do async operations.

Thus, the need-context and have-context messages are lost.

6\ decodebin instantiates the decoder (vaapidecoder) which in its open()
vmethod looks for a display context. At this moment the video sink is not
plugged, so the downstream query is lost.

7\ the decoder post the need-context message in the bus, which the bin forwards
up to the application and the message is finally ignored.

8\ the decoder creates it own display context and post a have-context.

9\ An we have duplicated display (one in the video sink and one in decoder),
and  the video might never get rendered.

I have written a proof-of-concept patch for gst-play.c which, such as in
gstbin, collects the incoming have-context messages, and when a need-context
message arrives, it is looked in the context list and set to the source element
if found.

Obviously, as the application watcher dispatches the messages async, I needed
to add a hackish usleep after sending the need-context message by the decoder.

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