[Bug 731782] New: waylandsink: video position is wrong when caps change and the sink is embedded in another window

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=731782
  GStreamer | gst-plugins-bad | git

           Summary: waylandsink: video position is wrong when caps change
                    and the sink is embedded in another window
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: george.kiagiadakis at collabora.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


When waylandsink is embedded with GstVideoOverlay inside another window and the
caps change (possibly because we are switching from one video to another), the
aspect ratio preservation algorithm changes the viewport size and the
subsurface position correctly, but although the size changes, the position
doesn't. This is because the subsurface position is essentially the parent
surface's state, so we have to commit the parent, over which we have no control
inside waylandsink.

There are two possible solutions to this:

1) Extend the GstWaylandVideo interface to include some API that allows us to
inform the parent that we want it to re-layout the video subsurface and do the
same dance that we do on window resizing, but extending it so that we make sure
the new video buffer is committed before the parent commits its new state. I am
not fond of this idea as it will add much complexity for the application and
high risk for deadlocks if not implemented correctly, but it has the advantage
of using only one subsurface (which is supposedly faster - not sure how much,
or if it's worth consideration at all)

2) Add another subsurface layer between the video subsurface and the parent
surface. This subsurface would be the "video area" surface, which is going to
statically cover the whole render rectangle (as set from GstVideoOverlay) and
provide the "black border" background. Then the video subsurface will be
stacked on top of it and will take the size of the video, respecting the aspect
ratio. By having this, when we want to change just the size of the video
surface, without touching the application surface, we can commit its new
position relative to the video area surface without synchronizing with the
application. This also has the feature of allowing us to draw the black borders
inside waylandsink, instead of expecting the application to do it, if we want.
The drawback is that we add complexity for the compositor. I think, however,
that it will have a better result.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.