[Bug 784599] kmssink: support videooverlay interface
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Aug 8 09:28:35 UTC 2017
https://bugzilla.gnome.org/show_bug.cgi?id=784599
--- Comment #58 from Haihua Hu <jared.hu at nxp.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #56)
> Review of attachment 356624 [details] [review]:
>
> I tried to fix it myself, but it's not exactly trivial. I have reverted it,
> so we gain time to fix it properly.
>
> ::: sys/kms/gstkmssink.c
> @@ -1327,3 @@
> - } else {
> - src.w = GST_VIDEO_INFO_WIDTH (&self->vinfo);
> - src.h = GST_VIDEO_INFO_HEIGHT (&self->vinfo);
>
> Removing this code is what caused the regression. The idea in this blob is
> to replace src.w/h scaled value with non-scaled one. With this patch, you
> don't do that anymore, as a result, you give a scaled value to
> drmModeSetPlane which can lead to ENOSPC.
>
> Now, the old code is assuming that if the driver cannot scale, you don't
> need to clip the src rectangle (that DRM will clip for us. I would need to
> refer to the doc on what shall be expect from drivers. I should probably
> hack the can_scale locally to be able to test that.
Yes, it is the reason why this issue happen, when display is not a regular
screen, the GST_VIDEO_INFO_WIDTH and GST_VIDEO_INFO_HEIGHT will be different
with the video size in video info, caps. So this two value should never use for
fb size.
>
> @@ +1447,3 @@
> +
> + if ((result.y + result.h) > self->vdisplay)
> + src.h = self->vdisplay - result.y;
>
> Here that code seem wrong, you check if result (the destination rectangle)
> overflow the display, but clip the src rectangle.
we should clip the video can not been displayed, other wise driver will return
error
>
> @@ +1457,3 @@
> + if (!self->can_scale) {
> + result.w = src.w;
> + result.h = src.h;
>
> What if the src.w/h is larder then your display ?
>
> @@ +1631,3 @@
> sink->plane_id = -1;
> + sink->original_width = -1;
> + sink->original_heigth = -1;
>
> This need to be reset on _start() I believe. Though, I'm not even sure we
> need this.
We need this info, when driver not support scale, then we need send the new
size upstream to find some sw scale do this, we prefer to keep aspect ratio
then we need know the original video size. I will reset it in _start()
I will try to fix those issues and re-upload my patch
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list