Building a graph for HDR10 output - stumped at sink

[Nicolas Dufresne]

Le mar. 29 mars 2022 20 h 20, Bill Hofmann <bill.hofmann at gmail.com> a
écrit :

> Thanks for the very helpful feedback. I am able to connect to kmssink, and
> after specifying connector-id and (the correct, I think) plane-id, I get
> video out from the non-X view. Defaults don't work there, but that's
> manageable. Clearly not yet HDR (haven't made changes to kmssink yet).
>
> HOWEVER, performance is exceptionally poor - whereas vaapisink is able to
> keep up with 4k30 P010 without a problem (in a window on the desktop),
> kmssink seems to run at about 15fps. As someone relatively new to this
> whole process, what's the best way to debug these performance issues?
> Looking at debug all the way up to 9, there isn't (of course) any helpful
> logged info at least that's helpful to me.  I'll note autovideosink also
> has performance issues (but again isn't full screen or non-X).
>

There is poorly implemented vsync in kmssink, combined with DRM emulation
of the legacy API kmssink uses, the frame rate get halved. The only
solution I have for now is to comment out the legacy vsync  code, the
emulation will sync already.

The use a queue before the sink, ensure the byte size is large enough for
4K.

Long term solution is to move on to atomic API. There is a MR for that, but
last time I checked it was of poor quality and the author wasn't replying.


> A little more context - this is an "embedded" Linux situation - will never
> be other than full screen video (likely no UI), so there is no need for
> interop with desktop functionality.
>

I would really like to see this type of use cases improve. This is common
in NXP and Xilinx SDK, though they hold downstream patches to workaround
this.

Meanwhile, be aware that Weston + waylandsink works better, Weston
automatically (and smartly) use HW layer. The limitation is that it only
works in combination of a GPU, it's not supported by the pixman backend
(yet?).


> -Bill
>
> On Sun, Mar 27, 2022 at 6:05 AM Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
>
>>
>>
>> Le sam. 26 mars 2022 21 h 45, Bill Hofmann via gstreamer-devel <
>> gstreamer-devel at lists.freedesktop.org> a écrit :
>>
>>>
>>> So.  What's the next step here? Is this a big gap in kmssink? Is there
>>> another sink I should be trying?
>>>
>>
>> There is no mainline HDR10 support on Linux outside of vendors BSP (NXP
>> to note one vendor). Vendors seems to want to compete on this feature, and
>> don't really work very hard to come up with generic implementation.
>>
>> That being said, if the kmssink is sufficient for your use case, then its
>> the smallest way forward, since you don't need a new Wayland protocol and
>> compositors support. What I'm uncertain though is if this will work with
>> the fact the kmssink code base have aged and isn't using the newest DRM API
>> (atomic kms). But other then that, if you have done that in the past, this
>> is plain C and mapping the caps field to the DRM properties is all you
>> need. Unlike HDR10+, the metadata does not change every frames.
>>
>>
>> Regards,
>> Nicolas
>>
>> p.s. vaapipostproc have a HDR to SDR converter to help improve SDR output
>> quality
>>
>>>
>
> --
> Bill Hofmann
> +1 510 387-0952
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220330/9b82f415/attachment.htm>