[Bug 784599] kmssink: support videooverlay interface

[GStreamer (GNOME Bugzilla)]

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

--- Comment #60 from Haihua Hu <jared.hu at nxp.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #59)
> (In reply to Haihua Hu from comment #57)
> > 0:00:08.763964814  3486     0x2c77f4a0 DEBUG                kmssink
> > gstkmssink.c:962:gst_kms_sink_calculate_display_ratio:<kmssink0> scaling to
> > 320x264
> > 
> > I think this calculation is not correct. It will respect to this actually
> > display width and height in millimeter but not pixel size. I don't know why
> > here should do like this.
> 
> The trace is missleading, but the calculation is correct. It's the right
> value you should pass to gst_video_sink_center_rect() when scaling to
> compensate the different pixel ratio between video pixels and display pixels.
> 
> When the driver does not scale, then it cannot do DAR compensation. As we
> don't know that it's scaling in advance, we cannot do much about it. We
> endup having to render the buffer incorrectly. This would be done by
> ignoring DAR compensation. So we would just skip
> gst_kms_sink_calculate_display_ratio() when can_scale is FALSE and hardcode
> SINK_WIDTH/HEIGHT to vinfo.width/height.

This is an good ideal，but the problem is that we don't know for sure whether
the driver support scale until we try to show first frame. How to solve this
problem?

> 
> Then, when you renegotiate, and you have can_scale = FALSE, you should
> fixate the pixel-ascpect-ratio to the display pixel aspect ratio. This way,
> upstream scaler can take case.
> 
> The original_width/height is to my opnion useless. What you want instead, is
> create a caps with <preferred>/<range>. The preferred width/height is the
> display size (which you already have).

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