@SirMaster did the file you were attempting to play on chrome happen to have dovi?
It happens with all files whether they are HEVC with or without Dovi, and also H.264 files.
I can’t play any files from Chrome when I have the HEVC transcoding enabled, but they all play when it’s disabled.
They all play fine to my iPhone with the HEVC transcoding enabled.
And I am always forcing to transcode to 3mbit in this case.
If that’s the case, can you make an extra effort to always Direct Stream subtitles if compatible? For example on my TV the subtitles have to be burned-in even though my TV understands SRT while on my Fire TV Stick they get Direct Streamed instead. That’s a difference between 100% and 20% CPU usage! If that’s somehow not possible it rather transcode it to SDR than risk a worse user experience by buffering/stuttering constantly (and I know that in the past burn-in meant unwatchable for me).
We already make a best effort to direct play subtitles whenever possible
1 Like
@SirMaster as far as i am aware you are the only user expiriancing this issue with chrome. Are you using the latest version?
I do have the latest version.
However it looks like I was able to resolve the issue by resetting some settings in chrome://flags related to video playback.
I tried Edge and Firefox too, and they both worked fine, but they transcoded to H264 with the HEVC enabled. I guess I am not sure of the state of HEVC support in those browsers.
However, Chrome was playing transcoded to HEVC after I reset those flags settings, so that’s cool.
is it possible to have the optimise setting use a slower preset to get better quality because the quality using hevc is better then 264 sure but its still not that great, using plex i can optimise a video at twice the speed of handbrake but end up with twice the bitrate for the same quality and twice the file size.
@Ari would you be willing to attach your logs with subtitle burn in so I can double check everything is working as it should?
@ReaperSPTN2109 try adjusting the Transcoder quality setting
the background transcoding preset?
thought that didnt work with HW transcoding?
it does with optimizations when using a qsv or nvidia encoder. Does handbreak use hw encoding?
yes handbrake is using nvenc and i have the plex preset set to very slow and i have plex set to use my 2080ti
the reason i was asking is because i would prefer to use plex instead since i can set it to optimize the library and forget all about it so when i add new stuff it gets automatically done, with handbrake it requires a bit of work and i dont really want to do it with the 14000 files i have
Which settings and to what values?
Firefox does not support HEVC video by default. caniuse.com says it can be enabled.
Edge supports HEVC. HEVC extensions from the Windows store may be required.
This setting:
chrome://flags/#use-angle
I had it set to D3D9 because I needed this for a plugin I use for watching 2.35:1 videos on YouTube on my Ultrawide monitor. The plugin (ultrawidify) is unable to detect and crop the encoded black bars in the YouTube video if it’s left to the default value which is D3D11.
I tried turning on media.wmf.hevc.enabled in Firefox v130 but no luck there still.
I didn’t mess around any more with Edge.
Well it’s dash/mp4 so Plex has to either
- Send the video via different means (e.g.
http/mkv) - Embed the subtitles into the video stream (e.g. CEA-608)
- Embed the subtitles into the DASH container (e.g. ISO/IEC 14496-30)
- Convert the subtitles into a compatible IMSC1 file (e.g. TTML XML)
That’s what I meant by “extra effort” – this will require some work but I think it will be worth it. Although in my particular case MKV should be enough and my TV definitely supports it (tested via USB drive).
It works for 8-bit content only.
Proof:
I was going to say 3/4 in answer to your original query. Unfortunately it’s always going to be the perception of the viewer, much like audio arguments between people with self-proclaimed “golden ears”.
1 Like
@SirMaster you are a hero! That the /dev/dri line got it working for me as well. Definitely crazy that the regular transcoding worked fine before without it.
Also, the cgroup2 allow numbers are going to be somewhat unique to the PCI ID of your GPU, kernel version, and nvidia driver version. For instance for my Quadro RTX4000 it’s 195 and 238. In my experience can change if you add/remove hardware from the host or with kernel or driver updates even. Be on the look out for that if your LXC ever stops working down the road. On my system, the 195 has been constant but the 238 has changed enough times over the years I’ve had this setup, that section of my conf file looks like this:
lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 212:* rwm
lxc.cgroup2.devices.allow: c 226:* rwm
lxc.cgroup2.devices.allow: c 234:* rwm
lxc.cgroup2.devices.allow: c 235:* rwm
lxc.cgroup2.devices.allow: c 236:* rwm
lxc.cgroup2.devices.allow: c 237:* rwm
lxc.cgroup2.devices.allow: c 238:* rwm
lxc.cgroup2.devices.allow: c 240:* rwm
lxc.cgroup2.devices.allow: c 241:* rwm
lxc.cgroup2.devices.allow: c 510:* rwm
I believe 195 and 238 is all I would need right now, but I’ve left the others in there because I’m not worried about the LXC potentially having more access than it needs.
@SirMaster @dpope123 I’m surprised it worked so well without PMS being able to identify the GPU. every playback PMS has to try all the available encoders until it finds one that works, and then it only gives you basic functionality, though with nvidia basic functionality is almost everything. Moving forward there will likely be more and more features that rely on identifying the GPU.
Hey all, I have just updated the download links to a build with the following changes:
- 10 Bit data is no longer truncated on mac
- 10 Bit Data is no longer truncated on Shield
- Note: The shield does not support 10 bit encoding so tone mapping is still required for HDR files
- Tone mapping is applied when the client does not support HDR playback
- Note: there is a bug in the android client where it does not properly inform PMS of a lack of HDR support. This has been addressed but users will need to wait for it to roll out in a future version
- Apollo Lake CPUs do not support 10 bit encoding (just decoding) so we removed support from those devices
- DVR recordings should now be a reasonable size
- Burning in bitmapped subtitles (such as PGS) should only be preformed when encoding to a 10 bit format
- Updates to the target resolution (for the same bitrate) when encoding to HEVC.
- Note: this means the selector on the client will likely be lying to you
I have a couple of non-HEVC bugs to address and then I plan on tacking the issues with DOVI some clients seem to be having
16 Likes
