@hsousa, today’s build 8.39 (8915) introduces video playback stutter on media with TrueHD audio if the AppleTV’s Match Content ➜ Framerate is disabled on AppleTV 4K A1842. When the match content is enabled, playback looks smooth, but audio sync drifts.
Using an AC3 compatibility track will remove the playback stutter and I am not seeing the issue with files that do not have TrueHD audio tracks.
To note, the TrueHD content is direct playing and not transcoding to FLAC in this version.
EDIT: May have jumped the gun here. After further testing, it’s not all files with TrueHD tracks causing a stutter, just my latest few with DV HDR and TrueHD. But older files with DV HDR and TrueHD aren’t showing the same issue. I’m going to re-digitize these files and report back.
Confirmed, this was an issue with my files. Re-digitizing corrected the issue with the new files and I’m able to Direct Play TrueHD content on DV HDR files without the stutter or lag with both Match Content on or off.
8.39 (8915) also looks to support multichannel Spatial Audio for AirPods Pro when playing back TrueHD, EAC, and DTS-HD on iOS 18 (haven’t tested 17). iOS audio no longer shows Stereo or Spatialized Stereo. Also iOS is direct playing TrueHD audio and not transcoding.
That’s very interesting, what made you think it was a previous MakeMKV run that could be the issue? This opens a huge can of worms, like have we all been chasing HD digital ghosts?
My initial playback tests were with my most recently added UHD files, two used TrueHD audio tracks and two were DTS-HD MA. The TrueHD files had the stutter on them where there DTS did not.
With previous betas, I’d been using a different UHD film with DV and TrueHD that I had previously digitized. It had been fine, but I believe audio was still transcoding from TrueHD to FLAC on playback at that point. To be consistent with testing, I ran that file on today’s release, and it direct played the TrueHD track without issue. That caused me to test a few more older files with DV and TrueHD, and all played back fine on the latest build.
So I went back and re-digitized the two newest files with TrueHD and lo and behold, they played back correctly. Also, even though the content was exactly the same, the file size was about 10 megabytes larger on the corrected files. So something must have happened with the original rips.
Running quite smooth here.
SDR staying in SDR.
Subtitles doing right.
TrueHD seemingly direct into LPCM seems like a nice upgrade!
The audio sync is the closest out of the box I’ve seen it yet, and my test system is fairly complex being ATV > Denon > TV.
Still, if I needed to adjust the audio, I could not with the offset adjuster, seems stuck at 0?
Have been testing the new version on AppleTV 2022, Sony A80, Sony DN-1080 Atmos Setup and wired ethernet connection to my server.
BDRemux Playback: Seems to be smooth and didn’t experience any issues Container: mkv HDR/DV: TV was detecting DV signal. Audio: FLAC, and didn’t find any issues with that.
4k HEVC + EAC3 Audio Playback: I used to have issues with these files before in the current public release where video playback is choppy, but this experimental player completely resolved those. There seems to be slight delay in audio though on this Container: mkv HDR/DV: None. This was a plain 4k video Audio: My receiver is still showing this as PCM instead of Atmos, so I am assuming this is not handled/fixed yet?
Suggestions/Bugs:
Can we highlight that experimental player is being used in Technical Details section? I had to enable debug information to confirm experimental player was being used.
I can confirm that SDR content that previously triggered HDR is now played correctly as SDR. However, when playing back an HDR/DV file (my LG OLED enters Dolby Vision mode) at Maximum Quality (Direct Play), the scene is very dark. If i tell it to “Convert Automatically” it shows as being transcoded from HDR to SDR (in Tautulli) and the picture is the correct brightness level.
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, Profile 7.6, dvhe.07.06, BL+EL+RPU, no metadata compression, Blu-ray compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 55 min
Bit rate : 77.6 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.390
Stream size : 62.4 GiB (83%)
Title : English
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 877 cd/m2
Maximum Frame-Average Light Level : 180 cd/m2
Original source medium : Blu-ray
Here’s a sample taken within the same timecode as the screenshots above: sample-dv.mkv
My understanding is the ATV-Plex app does not support DV, and certainly not the profile7 you linked, very few streaming widgets support that. It’s just not used for streaming content, it’s almost entirely out of the scope of plex/appletv/streaming widgets. Scroll back up to my old chart and see the row for Profile7, Dolby=pain. Apple Player Update Beta Testing - #446
Your TV is saying DV due to some headers leaking through but not the actual DV data. So it’s stuck with HDR10 static metadata, and your LG OLED, at least historically has very low brightness, so it’s matching say 1000nit in the brightest part of movie, down to 400nit max, and scaling everything proportionally below that.
The HDR-SDR example is because SDR is just uniformly bright with less contrast.
That may be true but I can confirm that using the non-beta with that file results in the normal brightness whether it direct plays or transcodes. The beta with direct play has lowered brightness as shown in the screenshot.
Having said that, I have tried another file which was HDR only and it was being incorrectly reported as DV to my TV and colors are incorrect/washed out due to that
