[Bug 784599] kmssink: support videooverlay interface

[GStreamer (GNOME Bugzilla)]

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

--- Comment #59 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(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.

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.