In Soviet Plex, 4K transcodes you!
5 Likes
that is not the case on IOS devices, i get awesome colors on iphone xr + iphone X
4K HDR to 1080p
What an apologia.
It’s the opposite.
This is an idée fixe for you, and still a kluge.
1 Like
Thoughts:
- NVIDIA’s consumer cards have an intentional limitation where HW decodes are limited (to one? two?) stream-wise. The professional, ie Quadro, cards don’t have that limitation.
- Don’t sweat HW decode quality. It really only gets to be a visible issue if you are transcoding down to the 2Mbps or less range. If you are transcoding 4K or 1080p high bit rate to 20Mbps or 12Mbps e.g., the quality is pristine… but…
- For your 4K transcodes, don’t you notice the muted, washed out colors? In this situation, whenever Plex transcodes 4K for now, the video quality will be WORSE than Bluray. Since Plex can’t transcode 4K correctly and/or across multiple use scenarios, you don’t wanna even think about 4K transcoding at present.
I would summarize the OP’s post into five words: don’t† transcode 4K with Plex. Any solution which achieves that is the “right” solution.
† there is an exception to every rule. “Don’t transcode” means don’t let the server transcode. Some clients, like iOS or Windows players e.g., will transcode the 4K stream to sub-4K resolutions just fine, keep colors intact, etc.
Plex does transcode INTO 4K.
Interesting. If you can play 4k x264 you should be able to play 4k hevc, so you shouldn’t be transcoding at all in this case.
You will notice however that the source is HEVC 4k and is being transcoded to x264 4k.
You still lose any HDR.
That looks like a transcode due to pgs subtitles being burned.
I believe shield should be able to use pgs subtitles without transcoding, perhaps check your subtitles settings and/or try it with subtitles disabled to see if you can direct play it.
1 Like
“f you can play 4k x264 you should be able to play 4k hevc, so you shouldn’t be transcoding at all in this case.”
But it is transcoding. I know the “switches to flip” to get it to not transcode… but depending on the file being played, you have to fiddle with crap lots of times, at different times, to get Plex not to transcode. It really likes to transcode.
There is in reality and “in the real world” a plethora of situations where a user has 4K-capable equipment, but Plex will still transcode the 4K file regardless.
I know, I know… you say this is the user’s problem, not Plex’s per se.
In your theory of use, if the user has a system that won’t play DTS audio… the user should just never play DTS audio so that Plex won’t have to transcode that. Or, keep a non-DTS file and a DTS file around for multiple use scenarios.
But, still, it would be better if Plex could properly transcode 4K when it is deciding to transcode. It almost does. This will be a moot point when (and it will) Plex tone maps colors properly.
(In my case above, it is transcoding at 0.5 speed because my server was also making thumbnails of this file at the same time which always pegs the CPU at ~100%. Usually it will transcode 4K with plenty of overhead, using about 40% GPU and 20% CPU only.)
Oh and another Plex “bug”… it makes thumbnails of 4K files with washed-out colors; ie, the thumbnails are crappy-looking. That is annoying too.
Same problem, essentially: you’re taking snapshots of an HDR video file and displaying them on a non-HDR computer screen with no tone-mapping. It’s a common complaint on movie torrent sites were users complain of poor colour quality screen grabs for 4k content when they’re looking at them in a web browser on a PC 
I edited the statement to remove the 1080 reference, thanks.
plex transcodes when the client cannot play the content as is (or at least it believes the client can’t).
if your content matches your setup, then no transcoding needed.
as far as color mapping, multiple people have stated that is both single threaded and CPU bound, so gpu isn’t going to help on the server side.
as for the client side, some clients can do some color mapping (or color correcting it seems), but is entirely client dependent and not every client can or will be able to do so.
1 Like
“you’re taking snapshots of an HDR video file and displaying them on a non-HDR computer screen with no tone-mapping”
No, the thumbnails are of poor quality whether you’re viewing them on an HDR 4K screen or not (example: you’re watching a 4K HDR movie in 4K HDR on a 4K HDR screen direct playing; fast forwarding or rewinding GUI shows thumbnails of poor quality). It involves PMS not correctly doing the tone-mapping at the moment of thumbnail generation.
4 Likes
plex uses the same transcoder to generate the thumbnails as it does to transcode.
therefore there isn’t any color mapping there either.
so just like when any hdr video is transcoded to anything, the colors are jacked up, it is the same with images generated from the video by the same transcoder.
understand that without color mapping done at the transcoder then all hdr data is lost.
the plex clients that can do color correction are doing it without any hdr data, they are simply attempting to shift the jacked up colors to a more normal color palette.
this isn’t the same as true HDR > SDR conversion.
Everyone wants the same thing, one source file that can be transcoded to any client local or remote within the limitations of the connection and client.
We are not there yet.
We are not going to be there even when there is hardware decode and encode support.
We may or may not see transcoder level hdr/sdr conversion, and if/when we do it is not likely to be real time, at any time soon.
So people can continue to whine and moan, or they can match their content to the capabilities of their clients and be happy.
1 Like
“plex uses the same transcoder to generate the thumbnails as it does to transcode. therefore there isn’t any color mapping there either.”
Of course there is. If there were NO color mapping, there’d be no colors. There IS (BT2020 wide gamut to BT709 SDR) color mapping. And it is wrong/unaesthetic.
Everyone who is “whining and moaning” as you say is already doing real-time HDR->SDR conversion. For example, play a 4K HDR video in MPC on Windows 10 PC with a basic graphics card on a 1080p LCD screen. The colors are correct; the PC (and GPU) are real-time “transcoding” converting HDR->SDR, and 4K->1080p.
“the plex clients that can do color correction are doing it without any hdr data, they are simply attempting to shift the jacked up colors to a more normal color palette. this isn’t the same as true HDR > SDR conversion.”
The Plex clients in this situation are shifting BT2020 (& HDR info) into BT709 properly. Not sure by what you mean “shift the jacked up colors.” They (the clients) are in essence taking one color space and “fitting” it into another color space; neither one is jacked up.
FFMPEG has right now the ability to do real-time HDR->SDR conversion. Plex uses FFMPEG. And obviously in Infuse those people are already doing the dynamic range compression HDR->SDR real time properly too. Plex servers are PLENTY powerful to transcode 4K files into 1080p; they are already doing the math real-time shifting HDR->SDR. It’s just that they are doing the math poorly. Decisions are being made; someone just needs to tweak the decisions being made by the server to get it to shift HDR->SDR properly.
So again I don’t know what you mean by “[HDR->SDR conversion] is not likely to be real time, at any time soon.” Do you mean in Plex? If you mean anywhere… sorry I am already doing it. I just wish Plex, which uses FFMPEG for Pete’s sake, would “turn it on” because as I said (and as you know) PLEX IS ALREADY DOING HDR->SDR TONEMAPPING TRANSCODING REAL TIME. It’s just sh*tty and unaesthetic as I mentioned. We can quibble over the conversion particulars (dynamics, contrast, black levels, perceptual vs relative colorimetric etc etc), but right now it’s just wrong.
EDIT1: Some clients will not extract the DTS core from a DTS-MA track, even though they can play DTS just fine. Roku is one of these clients.
EDIT2: 4K HDR and x265 and x264 are not really related (and x264 is not really 264… but whatever). No one can get a consumer 4K HDR file which is encoded in the h264 codec. However, one could transcode an h265 4K HDR (ie BT2020 10bit) into a h264 4K HDR file. If one wanted. So that Plex can’t, or doesn’t transcode h265 to h265 is not the “Plex problem” with HDR per se.
That is not transcoding, that is just decoding the colors and remapping to match the screen. Totally different. Transcoding involves reading the entire video data, not just color and converting it to another video format.
No Plex is not. I’m not sure you understand what tone-mapping is.
1 Like
As you may already know they are working on a ffmpeg update.
You will just have to wait patiently (or not) with the rest of us until they ‘turn it on’ and see if accomplishes all you wish.
as far as what I mean by the jacked up colors is the same thing you are complaining about. They aren’t correct for the display and they aren’t being converted so they look normal. Why you want to argue about ‘jacked up’ is beyond me.
tell that to the hundreds or thousands of people complaining about buffering or failure to play because their server aint powerful enough.
just because YOU may have a sufficiently powerful enough server, doesn’t mean that everyone does or will.
I’m just going by other comments posted in this forum and elsewhere that ostensibly know more than I do about how it works.
see also @ https://stevens.li/guides/video/converting-hdr-to-sdr-with-ffmpeg/
As to the first point, yes I get that it’s not “true” transcoding. It’s really decoding. However, up until relatively recently the ability to decode 4K HDR properly for 1080p SDR displaying wasn’t even happening.
As to the second point. When Plex transcodes e.g. a 4K HEVC HDR stream into 4K H264, clue us into how the BT2020 wide gamut colors are mapped into a BT709 space? To me, that is tone mapping; and we know we have some sort of HDR->SDR conversion taking place, somehow. Is it “non-computational”? (I don’t know any other way to phrase that.)
Not sure what you’re saying here. If a device can decode 4k content, we send it the 4k and let it decode itself. If you mean having the app decode 4k and scale it to 1080, right, that wasn’t available until we switched to the newer video player in some apps.
It’s not, that’s what I mean by we there is no tone mapping. We basically take the color value from BT2020 and place it directly into the BT709 space. Since it can’t handle the value, it gets cut off which is why the colors look wrong.
This will be fixed in a future PMS update where we will do an actual conversion (i.e. tone map).
1 Like
Well yeah, it goes without saying, if your server is not powerful enough to transcode 4K->1080p, it will not transcode 4K. Some people buy servers not powerful enough to transcode 1080p->480p. I don’t see you saying “Plex is only for direct playing 1080p, never try to transcode 1080p.”
However, if one has a server plenty powerful enough to transcode 4K->1080p, and a good gaming PC with a 9900 processor and a 1080 card can e.g., one has a Plex server PLENTY powerful enough to transcode 4K->1080p.
Well that is tone-mapping. However it is perhaps “truncated” tone-mapping. Or very data deficient tone-mapping… that’s what I meant by “non-computational” and was my theory on how Plex was doing the tone mapping. It’s much like when a photographer shoots a 14-bit or 12-bit RAW file with his camera and then displays it on a computer monitor in RAW format (and most computer monitors can only do 8-bit color e.g.). It looks “blah” and bad. One must perform some sort of image manipulation/post-processing to reveal the image dynamics actually contained in the file.
Plex is not “post-processing” properly as of now (and instead just “plopping” BT2020 into BT709) but to hear that it will properly tone-map in the future is all I needed to hear. Clearly it’s needed!
You gave a blanket statement that plex servers are PLENTY powerful to transcode 4k files into 1080p.
this statement is patently false.
decoding hevc is incredibly more difficult than x264 and generally has only become popular due to the availability and support of gpu assistance.
even with a 9900 processor, cpu alone can only handle so much (whatever that may be).
Ha, well I didn’t mean to lie! I was assuming a layer of common sense. For example, let’s say: people are plenty capable of looking both ways when crossing the street. Clearly, blind people can not do this. So “people are plenty capable of looking both ways when crossing the street” is also patently false too. You got me there.
However, be that as it may, “decoding hevc is incredibly more difficult than x264… even with a 9900 processor, cpu alone can only handle so much” is actually false-ish too. Not true-ish?
Here I am playing a 4K HEVC file (on a 1080p monitor, in MPC 64). You can see that really it’s not that difficult for the PC to decode it.
1 Like
