No, you’re correct, you just argued that plex wasn’t distancing itself from piracy, and I explained my position (and I suspect plex’s position). Ethically I don’t consider backing up your media piracy, even though by legal definition it may be considered that, it’s not really in the spirit of what anti-piracy laws are about. I also don’t consider sharing with a small group of friends and family (just as I would loan out my physical media to these people) to be in the spirit of the laws that are attempting to combat piracy. If the world would stick to those ethics and morals, I don’t think piracy laws would exist in the first place rendering this conversation moot. The law is there to stop the widespread theft of intellectual property that is damaging to the creator…
Breaking DRM may be alright to us for stuff we legitimately bought, but the companies that put the stuff out don’t support it. I bought Knight Rider on Blu-ray TWICE and still had a problem ripping one disc out of the bunch. Millcreek basically told me to go F myself when I merely mentioned a computer. I didn’t say I was copying them. Even though you can buy legitimate software players that doesn’t break the DRM, but decrypts discs the way they are meant to be decrypted, these companies only believe you should be allowed to go to a store to buy a hardware player to play their content.
Oh for sure, I am not arguing that Warner Brothers is ok with you decrypting and backing up your disk, they’re not. But I feel that’s because of how rampant piracy is. Lets just say that everyone who has a copy of the movie, paid for a copy of the movie. And those people all backed them up and didn’t give the backups away online. I don’t think Warner Brothers would have a problem with you making a digital backup at that point, because it wouldn’t be taking anything away from them. They likely, to increase profits, would stop putting DRM measures into their disc creation to make it easier to facilitate. That’s just my hypothesis, but there’s no real way to test it because people will continue to pirate.
Copy Protection isn’t really DRM. DRM generally involve active rights management, via an online or connected system. basic copy protection is more passive. Like garbling disc data in a way only certain CDROMs can read (PS1) or requiring HDCP for playing streams (dvd/BR) so you can’t just output it straight from the disc to an encoder without some extra software. DRM, to me, means its locked down and tied to a specific user identity. Copy protection just presents passive roadblocks to moving video you’ve purchased a license for from a physical disc to some other format.
So what is the point of having the whole “Versions” functionality available in the first place. Would they have gone through the effort of designing the system if you had to manually select versions? One would think there would be the ability to detect the player’s capabilites (like when it requests a transcoded size, for instance). I’m sure there are cases where the info might not be readily available, or some older TVs players might be old and janky, but updated android/iOS stuff should be readily able to do this stuff.
Either way I’ve got my 4k->1080p transcode ready so I might give it a whirl and see what happens.
I ask myself the same question every time.
Something I’ve said numerous times, even created a post about it in the feature suggestions, but no one thought it was a good idea apparently.
You would think, right? But I am just going by what I was told.
Po-tay-toe puh-tah-toe I think… DRM literally means Digital Rights Management, so I think anything that encompasses protecting the rights of digital media (including copy protection) falls into that overall category. That’s just how I view it…
Well so I have 3 versions of the SW 4k77 movie, all in one library. One is the original quality. One is a transcoded downsampled 4k x265 version (half filesize) the 3rd is 1080p converted one. If i go to the movie (with the 3 chip on the file icon) and hit play on the web browser, it direct plays the 1080p x264 version. This is verified through Tautulli.
I’ll check on my AppleTV but I expect the same.
My experience as a UX designer in software, most software engineers aren’t able to explain things to laymen. Also, many engineers don’t actually understand how users want their software to work. Seems like there is a disconnect between the Plex devs and the plex community
I wonder if that has to do with x264 vs x265, all of my content, including my 1080p content is x265. Browsers do not support x265 at all and will always transcode it, but x264 plays just fine direct play as you’ve witnessed. I’d be interested in seeing which it chooses if the 1080p file was also x265 (obviously it will transcode either way, but will it pick the 4K file at that point, or the 1080 file?)
Yea i’ll try to investigate that at some point.
AppleTV does direct Play just fine and defaults to the 1080p encode.
I tried on my iPhone XS and it is able to Direct Play both the 22mb/s and the 56mb/s 4K versions perfectly fine over WiFi, which is a bit surprising, tbh. It defaults to the 4k version because the screen size is so big, evidently. So thats cool.
Now granted none of this will work like that streaming remotely, but still, local streaming seems just fine for all of this. I did switch wifi off and streamed over LTE and it was transcoding down to .7mbps 240p or something abysmal, so maybe I need to sort out my quality settings there. Transcode pegs the processor pretty high on my server but it didn’t affect the direct play that was playing on my TV concurrently. In fact even the direct play 4k over wifi was smooth for both sources.
Now to try a x265 version. I’ll have to get a NVENC transcode scheduled to run tonight. My HTPC is too loud (SFF with only a CPU fan spinning at 3k rpm gets loud) to have it running during the day so I’ll queue it up for this evening and see if I can get it done quickly enough to test. I might just transcode the x264 file as that will be loads faster, my CPU absolutely chokes decoding the 4k x265 file in handbrake so it becomes the bottleneck for the GPU. That or NVENC isn’t actually working, it was maxing out at 25fps regardless of the encode settings when I ran it earlier for the x264 encode.
The major upside of all this, is my 4 1/2 year old daughter is now REALLY into Star Wars since she saw me put it on earlier for testing. So thats awesome, haha.
picking the ‘appropriate version’ from multiple qualities is something they have been working on at both client and server levels.
if you read the release note threads, you can find specific mentions of such.
is it perfect? no, but it may work for some people in some cases
and at least they have been working on it
25fps on NVENC 4K HDR file sounds about right, I get 50-ish fps in StaxRip on a 1070Ti, and when I use CPU only on a Ryzen 7 2700x, I get 2.5 fps. So depending on which GPU you have, I’d say 25fps is definitely NVENC and not Processor
Ahh, that would make more sense as to why my testing was abysmal (6 months ago) and his testing now seems to be working… 
Maybe I can combine libraries sooner rather than later
Its SDR, not HDR, so that might make it go faster. My GPU is a GTX 970 so its a bit slower. I’m assuming the CPU is the bottleneck because during the encode the CPU is pegged at 100% across all 4 threads. EIther way its barely real-time so it takes a while.
And if this working is new, its clear they’re making improvements, which is great. Keep it up Plex Devs!
This has been surprisingly accurate so far. It’s a recently-added feature that I really appreciate.
The behavior is better but still not intelligent enough. I am making SDR versions of HDR versions by Dolby Vision tone mapping. The reason to do this is 1) to provide remote clients 20Mbps 4K versions that don’t look weird, and 2) oddly enough in general the 4KHDR->4KSDR versions look better than similarly provided 1080p versions even on 1080p displays. Also, playing on ipads or other devices >1080p resolution, a high res SDR alternative to the HDR version is desirable. However, Plex can’t tell the difference between 4K file types. I guess it thinks “if it’s 4K it must be HDR” and will ALWAYS default to playing the 4K HDR vs 4K SDR file on any device. Some of the 4KSDR files I have are Main10 encoded and some are not. Of course all are in the BT709 space.
What Plex now needs is a bit deeper dig into the client’s playback scenario. Namely, it needs to query the client “Can you play BT2020 (or P3 too I guess) 4K HDR” and if not, it’s gotta stay away from playing that 4K HDR file. Needless to say, the playback of 4K HEVC or 4K Main10 (ie 10 bit) HEVC files encoded in the BT709 color space are transcoded with perfect colors (of course) to any client (be they 4K HDR or 1080p clients or iphones or whatever) by existing PMS infrastructure. PMS doesn’t have a 4K problem per se. It’s a BT2020->BT709 problem where we are struggling.
I am going to place this observation in feature requests too. I just hope I’m phrasing the “problem” correctly for people to understand. I believe that really good looking and proper tone mapping in real time or faster is a long time coming. There is a real “art” to going from BT2020 to BT709 and trade offs are inevitable. I used to think it’s just boom straightforward but the more I have delved into it, well, the less I’m satisfied with MadVR’s “choices” which admittedly are frame by frame analyses but I think Dolby Vision does a better job. You can, fortunately, achieve this with $299 software (not cheap I know) at home.
I have not looked into the choices made by MadVR, but so far every 4k HDR disc I have backed up looks a hell of a lot better if it’s played back using MadVR renderer on Media Player Classic Home Cinema than if it’s transcoded by Plex and played back via Chromecast on the same TV.
I understand that MadVR may be taking some kind of shortcut to make things work, but at some point arguing against results just doesn’t matter. It’s like the old debate people used to have about emulators. Sure in an ideal world you wanted them to perfectly emulate the original hardware, but if you had working rom files for 90% of the released games for a given emulator somebody spending a couple of extra years to build something that got the last 10% working would hardly be remembered by anyone even if it only made them work perfectly because of it’s low level emulation.
Also I see people writing there have been made some kind of improvement. Is this only available on the Windows OS running with hardware acceleration enabled or something because it all looks just as bad as it did back in early 2019 when my Linux server is transcoding.
This is only available on the Windows OS running with display hardware acceleration (Nvidia in my case) enabled, yes - the player is capable of doing tone mapping client-side so the server doesn’t have to transcode anything and the colors don’t get garbled. It works quite well for me, the Win client can now basically direct play anything regardless of what the screen is capable of displaying.
Can you clarify what you are saying here? Are you saying running a plex for windows client with display acceleration enabled that we can play transcoded HDR to SDR and have proper (SDR) tone mapping?
I can’t speak to this with authority for other users, but I can say that when I use the up-to-date Win10 desktop Plex client to watch a 4K HEVC HDR remux on a PC with an old Intel CPU and a recent Nvidia GPU, and no HDR display (an old 1080p screen in fact, though IPS), the movies are showing up perfectly with the HDR colors fully mapped into SDR (quite nicely in my opinion though I haven’t compared any of them with a 1080p master). The PMS dashboard confirms the video streams are being direct-played to the desktop client, so all the processing is obviously taking place locally on my PC and not on the server.
I can confirm the same behavior on my system with anAMD processor, Nvidia GPU and a basic 1080p display. However, trying to play the same file on that computer via the Plex website transcodes and looks washed out.
I see this as well. It direct streams them, so no server-side transcoding is required, and my client (10xx nvidia) correctly avoid the washed out tone-mapping issue. Similarly, IOS direct streams and avoids the issue. When I use the web client, it needss to server side transcode, and it looks washed out. Avoiding the server side transcoding looks to be the difference.
This topic is on when you do need to transcode, but it is nice to see it works as expected when it is not done. thaks for confirming.
