Server Version#: 1.23.3.4707
Player Version#: 4.57.4
Hello,
currently it is needed to uncheck “Disable video stream transcoding” to play H264 10 bit in browsers even though plex does no transcoding and plays the file just fine.
My plex Server is not fast enough to handle a single transcoding attempt without killing plex for CPU and RAM load, so it is crucial to keep “Disable video stream transcoding” enabled. But I still want to be able to play H264 in browsers.
This is to me a bug since transmuxing is in plex no transcoding or else playing h264 8 bit in browser should fail too.
You can already play h264 10-bit without needing to modify the profile. Keep in mind Chrome only supports this for mp4. If your file is mkv, that wont’ work.
That is nice to know, but I don’t understand it, mp4 and mkv are just containers and no codecs and because DASH is used, the container shouldn’t matter at all because the client will never see it?
DASH is not used when direct playing a file. The container also matters.
I grabbed that file and it has 16 ref frames. That is out of spec and why it isn’t direct playing. These may or may not work, but Plex can’t detect when it doesn’t so anything above 8 is not allowed.
(Everything about anime encodes seems designed as an obstacle for playback. I don’t understand that community at all.)
@anon18523487, is that a hardcoded limit on reference frames? Or is it linked to Level?
Level 5.1 allows a crazy number (16!) of reference frames for 1920x1080 video.
But lower Levels can exceed 8 at moderate resolutions, too. I have a few SDTV and 720P shows encoded with 9 and 10 frames. They’re not particularly exotic encodes.
There is a formula based on the exact parameters of the video. However, on average, a max of 8 ref frames for 1080p h264 video is right.
I wouldn’t say it’s only the anime community. As ripping and encoding videos have become easier, the knowledge of what it actually does has been diluted and most people just pick from defaults and presets. I’ve seen files that are 720p, h264, 2 Mbps, 16 ref frames, level 5.2, 12-bit HDR. This is just overkill for this type of file.
Sure, because encoders don’t apply this limit, when they should. Instead users are allowed to set the value themselves. Some devices don’t care, they’ll just try playing the file anyways. It may work, it may not. If it fails, it will fail hard and could lead to device crashes. Plex can’t prevent a crash should it happen, but we do try to avoid it by setting a ref frames limit.
No, but just because everybody is wrong, doesn’t make it right.
Painfully accurate. They always seem to be the ones to push quality levels and adopt features before anybody else (MKVs, ASS\SSA, x264, 10bit, etc). I think it’s the fact fansubs were pretty much exclusively computer playback only for so long (I was swapping VHS tapes long before trying to watch .ra files with subtitles on my TV somehow).
Also accurate. As technical functions become easier to manage the why gets lost and the how remains. I don’t need to know why my car works, just need to know how to work it.
Sorry for the tangent here - but it’s an interesting topic so I’m watching.
You might not be able to. Some things are hard coded into the app. Some clients will make the decision themselves if a file can be played or not. The profile is only used to determine what to transcode to. I can’t remember if Web works this way or not. I’ll have to get back to you.
Ok thanks for that. I understand why you did introduce limits, but on the other hand I would not understand why you would hardcode them. The decoder of browsers get from time to time updated, so there is a need to adapt that. For example they decode x264 very slow encoded files fine and that up to level 5.2, maybe even more but I first have to create test file to test 6.1 and 6.2.
Ugh. I wanted to say “encoders generate conforming files!”. And they do by default … unless they’re told not to. It’s easier to foot-shoot than I thought.
Handbrake does get it right. It uses Level as a maximum, and automatically conforms ref to comply. If a too-high ref is given, it’s automatically reduced.
FFmpeg and x264 and x265 are reasonable by default, and the appropriate Level is automatically detected. But if level is provided, it isn’t used as a constraint, it’s just passed to the output file. So it’s easy to generate nonconforming files.
My point was that 16 ref frames isn’t wrong - it’s perfectly valid for the L5.2 example given here. I have a number of conforming files with 10+ ref frames.
BUTTTTTT I don’t think that’s the issue here anyway.
Jun 24, 2021 18:05:39.000 [0x80b0bcd00] DEBUG - [Transcode] Test Mkv - video.bitDepth limitation applies: 10 > 8
@Big, try removing this entire section. Works for me.
<VideoCodec name="h264">
<Limitations>
<!-- Chrome does playback h264 10 bit so allow that -->
<UpperBound name="video.bitDepth" value="10" />
</Limitations>
</VideoCodec>
I did restart and i see that my profile is not used anymore because else it would stream flac instead of transcoding that to aac.
I can provide logs of that session if that helps?
In which log file did you find that so i can look at that myself?
Thank you Volts
I copied your config and it does work, it seems like I have something in the config file that I provided which doesn’t get parsed right because with that it doesn’t work.
