Building a graph for HDR10 output - stumped at sink

Nicolas Dufresne nicolas at
Sun Mar 27 13:05:01 UTC 2022

Le sam. 26 mars 2022 21 h 45, Bill Hofmann via gstreamer-devel <
gstreamer-devel at> 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.


p.s. vaapipostproc have a HDR to SDR converter to help improve SDR output

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list