[Bug 784599] kmssink: support videooverlay interface

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #359676|none                        |needs-work
             status|                            |

--- Comment #75 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Review of attachment 359676:
 --> (https://bugzilla.gnome.org/review?bug=784599&attachment=359676)

My impression is that this patch contains code that should have been added with
the "can-scale" property patch. I think it overall looks better, but yet I
think there is issues.

If you cannot scale, you should always prepend a fixed width/height caps in
getcaps() ("can-scale" patch should have something). This provide upstream a
recommended size, this is what ximagesink will do.

A bigger problem is the following. My screen is 1080p, I have a 100x100 pip
that I'm displaying, my driver cannot scale. It's currently at 0,0, I want it
to be at 200,200. I receive the renegotiation, which I ignore, because I don't
want a new size. And finally the render rectangle is never updated. I think we
should apply the rectangle immediately when the size does not change. In fact,
I would always apply the rect immediatly and crop by default. Delaying the rect
should maybe be an option as it's behaviour can be surprising. An example, it
does not take effect if paused.

::: sys/kms/gstkmssink.c
@@ +111,3 @@
+  GST_OBJECT_LOCK (self);
+  if (self->can_scale) {
+    self->preferred_rect.x = x;

I'd rename this one render_rect. It's not just a preference, this is the size
we are currently rendering to.

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