QVideoWidget looks incorrect(ly tonemapped) on HDR-enabled displays on Windows

I was trying to see the current state of support for rendering onto HDR-enabled swapchains with Multimedia. QVideoWidget, that is backed by a QVideoWindow and so a native window, automatically opts in to extended linear sRGB color buffers (so scRGB + FP16), when supported. On the QRhi level we currently support this on Windows (with D3D) and on macOS (with Metal).
The latter (macOS) was demoed a long time ago when the Multimedia renewal for Qt 6 was done and this initial support for true HDR output was added. I have not seen this in action on Windows so far. So I tried it now.

Testing the videowidget example on a HDR-enabled display on Windows, it seems to correctly hit the HDR output path, which is good. However, the rendered results are somehow off looking. It almost looks like SDR content rendered on a HDR output without correcting the white level

Photo of the screen that hopefully illustrates the problem. (bad quality, but taking direct screenshots are not obvious to me right now due to HDR content appearing different in the screenshots than on screen)

On the left, VLC (or Media Player etc. all give similar results) while on the right, it's the videowidget example.

Disabling the HDR output toggle in QVideoWindow (i.e. pretending there is no HDR output support) at
https://code.qt.io/cgit/qt/qtmultimedia.git/tree/src/multimedia/video/qvideowindow.cpp#n156
makes the result better looking, in the sense that the colors will not look so completely off. Thus the assumption that something is not entirely correct in the video rendering pipeline when it comes to tonemapping and such.