Dolby TrueHD passthrough - modified mpv build

Plex Players Desktop Players
,
41

It’s in our ffmpeg build and we don’t have a public repo for this. We do have a source tarball at https://downloads.plex.tv/ffmpeg-source/plex-media-server-ffmpeg-gpl-2427c1679fd.tar.gz and you can find the relevant code by searching for resolve_hosts in libavformat/tcp.c. This is how the app tells FFmpeg how to resolve certain names to IP addresses.

2 Likes
42

I’m not getting a DNS resolution for 192-168-178-4.33a5a84e513f43afa47653c41086db36.plex.direct, so I guess that leads to the post gbooker02 made.

I’ve now added

192.168.178.4 192-168-178-4.33a5a84e513f43afa47653c41086db36.plex.direct

to my local HOSTS file and lo and behold, playback is working now with the modified mpv-2.dll.
Thanks to both of you! I hope this will fix my sound drop issues.

43

While you got it working by brute force, I’d investigate what causes the DNS resolution to fail as there is a rather serious error somewhere on your setup.

1 Like
44

If this is a server in the local network, then it is quite likely caused by “DNS rebinding protection” as mentioned above. https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/

1 Like
45

Thanks, now that I know what I had to look for, I was able to fix it. I had to add plex.direct to the DNS rebind protection exclusion list on my router and now it also works without the local HOSTS entry.

1 Like
46

New build, this time its also a testing build including commits that were originally reverted
(+ mpv debug and mpv.exe):

Name: mpv-dev-x86_64-v3-20221226-git-cb15bc4-old-truehd-spdifenc+commits.zip
Size: 142799680 Bytes (136 MiB)
CRC32: EEB3050E
CRC64: FEF4F305F416721E
SHA256: a0ccc0745180f6b66dc31a8f4d1aaf123bb77da54ca1b0f1f884d7cbe960da32
SHA1: 238887b3958abd4a35082ad74cc02b7642b88a0a
BLAKE2sp: d656bbb74d8cf3d9a5224a336990331a22c926d12edc751d5b410c05640660f0
MD5: 341f4bfeae8b8a46f5dffaaf93db4552

This time the build includes:

=> I have to correct myself regarding the first testing build post, where I said that only the commits

are reverted.

Commit

is also reverted, because it makes changes to the aforementioned and reverted code.

Experience:
While using the new testing build I could not find any issues. Dolby TrueHD, AC3/EAC3/DTS/DTS-HD HRA/DTS-HD MA worked as with my initially published modified build. So I guess only these three commits need to be reverted, I will do so in the coming days.

I also had some time to test an upstream ffmpeg/mpv version with my LG TV, that luckily also supports Dolby TrueHD and to my surprise, it did not showed the issue. (Would also explain why you @gbooker02 are not seeing this one with your setup) Skipping inside the file did not broke audio playback like seen with my AVR. Also, a movie with seamless branching worked almost (you could hear some crackling when hitting the spot where those files were merged) fine. Whereas it would immediately break with my AVR.
Have a look at this thread => Dolby Atmos Track drops out with v74.1, but not with v73.1 · Issue #282 · Nevcairiel/LAVFilters · GitHub for the exact same issue with a seamless branching file. (I also used Baywatch to verify this)
The modified build also worked fine in this regard with the LG Tv.

So this sounds like we have a new “DTS-HD HRA only works on some setups” situation again… (DTS-HD HRA 7.1 Audio Not Working)

2 Likes
47

@ChuckPa Is this also a reason affecting what we were talking about?

48

I cannot speak to MPV specifics or Windows (I wash or I break them).
sorry. I’m strictly Linux here.

TrueHD broke with 1.30.0
I’ve given all the info to the Transcoder Team .

If TrueHD is required, use PMS 1.29.2 in the interim

1 Like
49

Hey Mitzch,

I’ve uploaded a blu-ray rip of Guardians of the Galaxy Volume 2. At 18:27 or so in the movie (~27 seconds into the small clip attached here, right as Nebula starts to fly out of the exploding space ship), your modified mpv-2.dll file completely halts playback for me in Plex. Plex’s vanilla mpv-2 build plays it smoothly. Interestingly, VLC garbles the audio at that point, which I have not encountered before when comparing the two players.

For science, your build did fix a very minor but reproducible audio hitch at the very beginning of Doctor Strange using the vanilla mpv file (this hitch occurs 7 seconds in to test clip, right before the first cymbal crash), but created this problem that rendered your mpv unusable in GOTG. VLC gets through the Doctor Strange clip without any issues, fwiw.

I have been testing your file for a week or two and have not noticed the Doctor Strange style audio glitch in any other place, so I switched back to the vanilla mpv because I feel the GOTG glitch is “worse.” If there was some way to address the Doctor Strange issue without breaking the GOTG functionality, that would be ideal haha. I have no knowledge of what goes on behind the scenes as far as the actual file goes, but if those two clips prove useful for you, I wanted you to have them.

1 Like
50

Yep, that’s due to the high bitrate that exceeds what the old logic can handle. Above 10 or 11mbit for the truehd track, it breaks. MPV stops (you should be able to skip beyond the spot and playback should resume) whereas VLC would only garble audio as you have described.

It usually happens on the English TrueHD/atmos track on Disney releases as they exceed the 10/11mbit barrier easily.

This is why I opened the FFmpeg bug tracker report °1. (link in the modified mpv build thread).

The new logic handles those parts on GOTG V2 (that’s actually what I have sent the FFmpeg devs - a small snippet from GOTG V2) fine but breaks other things. That’s why I opened the second ffmpeg bug tracker report and yes it would be awesome if we could have both working!

I totally understand this! On my end, however, I only have 1 or 2 files that exceed the 10/11mbit barrier. It’s GOTG V2 and Doctor Strange - it only affects the English atmos track, which I barely use (I´m german and used to hearing the german dubbing) but I got very many other Bluray rips that contain a TrueHD track that would break on my setup with the new/upstream mpv build. Also, I have not seen any german TrueHD track exceeding 8 or 9 Mbit. (somewhere I have read that starting with UHD discs, the truehd track is allowed to go beyond 10+mbit - and only on the UHD disc) So I guess it highly depends on what you have and what you want whether you should use the shipped or my MPV build.

1 Like
51

Thank you for all your work. It has solved my HD audio problems.

Two minor issues I am experiencing. Occasionally, a movie will not start and I have to exit and restart the app, and then it seems to be fine.

Also, it will not start any trailers from Discover or my Watchlist for movies that are not on my local server. It will start trailers from my movie libraries.

Have you seen any of this behavior?

Thanks again!

52

Luckily no! But can you please share your logs, we can probably find the reason there!

53

I think I did this right. It is the log for the Discover trailer failure. A movie not starting is more random and I will grab that as soon as it happens again.

Thanks!

54

Found this in your log =>
Jan 06, 2023 16:42:41.216 [6404] ERROR - [MPVEngine/mpv] ffmpeg: tls: mbedtls_ssl_handshake returned -0x2700

And also did not find the line that should prevent this error. :wink:
You are missing the mpv.conf file with tls-ca-file=C:\Program Files\Plex\Plex HTPC\resources\cacert.pem added.

55

Thanks again. With your help, I found the issue. I had the mpv.conf file contents correct, but I fat-fingered and had an extra dot in the file name, lol

56

New build:

Name: mpv-dev-x86_64-v3-20230114-git-6cdce9e-old-truehd-spdifenc+commits.zip
Size: 142919922 Bytes (136 MiB)
CRC32: 5A6E4351
CRC64: 7325DDE0C761B14C
SHA256: 329422f319fca6f0ebf5fc6102f115886f137fd19e4ed42316fb5b939532a1bf
SHA1: 06a02119b32392ce7507aa5e852d7a68b07363dd
BLAKE2sp: c7882ba0b86eaf42f0a47983f5ab93da9d1b100c24fc4a703ccbe278c99a1acd
MD5: e33212fa25f448df9aae86bd55250490

Finally had time to get used to git cli and I have now reverted the commits that break TrueHD. I hope this time its properly done.

The mpv build also includes:

57

@gbooker02

Is this now correctly done?

58

Yes, that is (assuming that all 3 commits are necessary). Though I must admit taylor5157’s comments above about certain high bitrate audio tracks causing issues is concerning. It makes me wonder if this was the reason for the change you reverted.

59

Looking at the changes some, I’m going to guess at a possible solution. First some assumptions:

  • You state that the old code worked with your problematic files.
  • This code put TrueHD frames at consistent intervals.
  • The new code fails only when it logs Unusual frame timing which is effectively an exception case.
  • In this case, it sets no padding at all between this frame and the previous FFmpeg/spdifenc.c at 36e156bef02566d70cea46cc5e00b3e5d5ed3286 · FFmpeg/FFmpeg · GitHub (padding_remaining = 0;)
  • So, what if the new code is fine but this padding in this one case is just wrong?

So, what if in this scenario, it just set the consistent padding like the old code did? That would be:
padding_remaining = 2560 - ctx->truehd_prev_size;
This may require accounting for a frame size that’s greater than 2560 so perhaps:
padding_remaining = 2560 - ctx->truehd_prev_size % 2560;

60

The new currently upstreamed code has been made to fix the high bitrate issue, with the downside of breaking any truehd track on my side.

I will provide a build for testing shortly (currently compiling)