I see comments about HDR gaming from people who obviously don't do it. Tons of people hook up their PC's to tv for gaming. Yes, HDR introduces latency but it's minimal with any decent tv. And, these setups are common enough that several tv makers consider PC gamers when designing their panels now. For the vast majority of gamers, the tiny added latency and small fps drop are non-issues.
Regarding those who think HDR on Linux is a total waste, and aside of the reasons it's not that were already mentioned... Linux is a very popular choice when it comes to htpc's. There are countless little stb's that run Linux as dedicated htpc's, and tons of people who use Linux for hosting lan media servers/clients.
It sounds like some of the people with the most negative things to say about HDR seemingly have little or no experience with it. HDR is popular and it's here to stay. To suggest companies are smart for resisting it is nonsensical. Since when do companies benefit by being last to the party?
More HDR Display Bits On The Way For The Linux 5.3 Kernel
Collapse
X
-
Originally posted by holunder View Post
This hasn’t anything to do with 'buggyness' my dear, no Linux player supports HDR and its color spectrum at the moment: https://github.com/mpv-player/mpv/issues/5521
Leave a comment:
-
-
Originally posted by carewolf View Post
Downconverter? you mean from BT2020 to sRGB? That is not a thing that needs to exist on a platform level, that is a trivial piece of a video decoding pipeline. If that is missing that is a player issue, if the player doesn't do the color-conversion the player is broken, in fact allmost all videos are not in sRGB either, so colorspace conversion is a standard step in any video playback. You have the decoding stop of video to a native color-space (BT709 YUV for most HD content) (BT2020 for UHD), and then you have the transform step to something native, and then you have playback. To get all the extra colors working we are missing the support in the playback step, but the colors that ARE supported should look correct if your player isn't buggy.
Leave a comment:
-
-
Originally posted by holunder View Post
But it’s more than that. 4K movies are typically encoded in H.265 with BT.2020 and your Linux player cannot display it correctly at the moment, no matter what your monitor is capable of. There only exists a live-downconverter as a ffdshow filter for Windows (which does consume a lot of power) but not for Linux. So, a modern graphics stack which natively supports the BT.2020 color space will be a win. Currently, BT.2020 movies look flat and pale.
Leave a comment:
-
-
Originally posted by debianxfce View Post
YouTube have realized that not everyone have a 8K freesync 2 hdr monitor. So there is no point to create high end material when the public has poorer viewing devices and media.
Leave a comment:
-
-
Originally posted by carewolf View Post
No monitor (or TV) can show the full BT.2020 color space. What you mean is that they fullfill the VESA HDR specs which says they should be able to show most of the DCI-P3 (which is bigger than sRGB, but smaller than BT.2020).
Leave a comment:
-
-
Originally posted by debianxfce View Post
YouTube have realized that not everyone have a 8K freesync 2 hdr monitor. So there is no point to create high end material when the public has poorer viewing devices and media.
Leave a comment:
-
-
Originally posted by Space Heater View PostWhat all still needs HDR support so that HDR works on the Linux desktop? Once the core DRM layer and Intel+AMD drivers (kernel and mesa?) have support, are we still waiting on X11, Wayland, and Kwin/Mutter/<insert compositor>?
Leave a comment:
-
-
Originally posted by holunder View Post
HDR monitors are compatible with the BT.2020 color specification which does color-accuracy a huge favor. UHD BDs and 4K streaming services are using this.
Leave a comment:
-
Leave a comment: