So I have many files that are encoded in HEVC, with the MP4 container and AAC audio. I chose all these for maximum compatibility, but for a long time I couldn’t figure out why my iPhone and iPad could not direct-play those videos. Then when I found out that Plex players don’t seem to support the 10-bit color profile. I did not expect this, especially because the native video player on iOS does support my files as is. I’d expect the Plex player to support more, not less (Apple usually is really restrictive of what they support).
So it would be great if 10-bit HEVC support was added to more devices. I can only test iPhone and iPad, on those it doesn’t work – I tried both the new and the old player. But I’d also want support on Android, on PlayStation, on Xbox, on Apple TV etc. so as many people as possible can play my videos when I invite them to my library.
Plex does support HEVC 10-bit in most of our apps. If it direct plays depends on the device itself. The device must support hevc or 10-bit via hardware. What exact models are you testing with?
FYI - I can direct play hevc 10-bit HDR videos on by 8th gen iPad.
Agreed. Much of my media is HEVC Main 10, and will Direct Play or Direct Stream to any remotely modern Apple device, as well as the other devices you mention.
Can you share samples and/or XML Info from a few problematic videos?
I’m using an iPhone 12 Pro Max. I’ll do some more testing and provide the requested details as soon as I have the time.
Is there a list of compatible devices anywhere? Or what’s the technical requirement exactly, how could I look up if a specific Android device owned by a member in my family supports 10-bit HEVC?
Plex doesn’t publish a list of devices that are compatible with every video and audio attribute. Plex apps query the OS for capabilities at playback time, since it can change based on OS version and configuration and settings.
There are other attributes of a file that might be problematic. You mentioned color space.
If you share media samples, media info, XML info, server logs, or client logs after playback, folks can give some indication of what’s going on.
If you’re encoding these yourself, you could also share more info about the settings you’re using.
@anon18523487 Thank you for the link. But what do I need to look out for to know that it will support 10-bit? For example on the Google Pixel 3a XL page, I can’t find “10-bit” mentioned.
@Volts I use HandBrake to compress my 4K movies to a remote-friendly 720p size (I keep the original, of course). Then I play this 720p file in Plex within my home WiFi and it transcodes it. As soon as I change the output from “x265 10-bit” to just “x265” direct-play starts working. That’s why I think it’s the 10-bit … here’s my HandBrake settings:
Funny thing is, I just tried with a file just now again and it did direct-play this time. I’ll post more details when I have the time to investigate more. Unfortunately I already deleted the files I tested when I posted this and started re-encoding them with only the 8-bit change, which works.
Unfortunately, it doesn’t look like that is specifically listed. In most cases, if a device supports HEVC, it will support HDR. Not always, but these 2 do go hand-in-hand very often.
It could also be due to the audio you are using. In that example, you have DTS-Hd HRA and TrueHD. If the audio has to be transcoded then the video will be direct streamed (copied into the HLS stream with the transcoded audio). Some devices do not support hevc in a direct stream, which will force a transcode.
@anon18523487 I’m not talking about direct-playing the original file, but the encoded 720p file, which has 160kbps stereo AAC, no DTS-HD etc. – I totally understand the original file situation, which is why I compress these files in the first place, so I have direct play, even when playing remotely (hopefully), but it didn’t even work locally.
A nice trick when testing Handbrake encoding settings is to just encode the first chapter.
The advantage of 10-bit encoding is slightly better resistance to color banding, and sometimes slightly better encoding size efficiency. It is slower when encoding though. You wouldn’t be losing so much by going to 8-bit, especially at 720p & RF25.
Almost any device with an HEVC decoder supports the Main 10 profile. The iPhone certainly does.
(Note that 10-bit encoding doesn’t imply HDR, but HDR does imply Main 10.)
Most of your settings seem fine and should be generally compatible with modern devices.
I would change 60 FPS to “Same as source”.
I would consider disabling decomb, it shouldn’t be needed for any progressively encoded movie. Probably not doing any harm.
Your audio looks OK to me - 2-channel AAC should be highly compatible.
Do you notice any difference when playing with Subtitles enabled vs. Not?
Ah sorry. Those were the original. I missed that you were converting those. My comment still applies. Although for an iPad or Android device, that shouldn’t trigger a transcode. I just tried playing a 1080p HEVC HDR file and it direct played.
I would actually recommend changing it to 30 fps. Some devices do not support certain codecs at 60 fps. I don’t have any 60 fps HDR files at the moment to test, but this is also a strong possibility for the transcode.
@Volts I’m only maxing out to 60 FPS, so technically it should be the same as “Same as source” unless I had content with >60 FPS (which I don’t).
Thank you for the tip to disable decomb, I just read up what it’s doing and you’re right that I could probably disable it. It was turned on by HandBrake for basically any of their profiles, that why I kept it on.
And I always had subtitles turned off in my tests to ensure that’s not the culprit.
@Jeehut what do you see on resulting files that actually have lower framerate, but are encoded with this “variable 60” setting in Handbrake? Do they end up as “what’s in the file, or 60, whichever is lower?”?
There can be a difference between the FPS stored in the headers of a file, vs. the FPS stored in each frame of a file.
I know the iPhone 12 can record higher framerate video, but I think it just skips frames on playback.
That also doesn’t guarantee that the Plex player is happy to play back a file with higher FPS in the headers/container.
I have now changed my settings to “same as source”, but when I open any of the files with the previous settings in Quick Time and use Cmd+I, I shows me 23.97 as the FPS. Don’t know if HandBrake is analyzing the content and making that decision, or if Quick Time is checking the contents and detects that it’s effectively 23.97 even if the headers say “up to 60 FPS” … feel free to share your learnings once you’ve elaborated.
You are using the setting of variable frame rate with a peak of 60 so some players may see this as 60 fps. They just look at the file’s header to see what’s in the file. This may not be a problem, but to avoid future problems, it’s best not to do this unless this is really what you want.
