Announcement

Collapse
No announcement yet.

More HDR Display Bits On The Way For The Linux 5.3 Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Space Heater View Post
    What 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>?
    Yes, we are waiting for protocol extensions and somebody to define how SDR and HDR content should mix. Then we need framework and application support.

    Comment


    • #12
      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.
      Just because you are poor doesnt mean that everybody else has a 1366x768 monitor like you.

      Comment


      • #13
        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).
        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.

        Comment


        • #14
          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.
          So you have absolutely no idea what's the fundamental difference between still photos and videos?

          Comment


          • #15
            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.
            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.

            Comment


            • #16
              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.
              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

              Comment


              • #17
                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
                That's what I said, there is no way to output it, but that doesn't mean you can't convert from HDR to SDR, which is why I was asking what you if that was what you meant by a downconverter, because with real HDR support, you wouldn't be converting "down".

                Comment


                • #18
                  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?

                  Comment

                  Working...
                  X