www.makemkv.com

Hello Mike Admin,

There is a long problem and discussion going on for months now on both PLEX forum and Google Exoplayers Github regarding a serious problem with audio dropouts occurring while playing MKVs produced with MakeMKV on NVidia Shield PLEX media player directly to AVRs.

I think its been narrowed to some sort of audio switch occurring at seamless branch points within the stream causing AVRs to mute audio for a second or two and then continue movie with completely out of sync audio track, which makes these movies unwatchable from MKV rips from disc. Examples are The Martian Extended 4k which happens in one place and M3gan Bluray which happens many times during movie so is a good example.

I wonder would you have any insight into the possible cause and or fix for problem and could help google fix their Exoplayer or point them to possible fix?

https://forums.plex.tv/t/plex-audio-dro ... /775510/96

https://github.com/google/ExoPlayer/issues/10520

Thank you for posting this geogan!

The crux of this issue is that Google's exoplayer team considers this an issue of "bad media." They say that their code is unlikely to be at fault "because that's the level at which ExoPlayer is handling these files - we basically unwrap the media container and feed the samples inside down into a decoder."

Rightly or wrongly, they don't see other players not suffering from this problem to be indicative of exoplayer having an issue. Rather, they seem to believe that other players have merely worked around a formatting/media issue. And they are unwilling to do that themselves.

They will, however, accept a patch to exoplayer that accomplishes this.

So. . . as I wrote elsewhere, for the best MKV playback device for home theaters, we're stuck at in impasse until either someone fixes the way these files are being formed, demonstrates beyond doubt that the files are not malformed, or submits code that fixes the issue regardless of whether the files are malformed.

We're essentially coming, hat in hand, to you, Mike, asking if you can help us with any part of this puzzle. Is there any chance that MakeMKV could play a role in extracting these TrueHD samples differently (I hesitate to say "better"), or would you be able to determine empirically/authoritatively that there is no issue with the TrueHD samples coming from MakeMKV so that we could then convince the exoplayer team to re-evaluate?

Thank you for your time and any consideration you can give this issue!

Best Regards,

Hurin

"We're essentially coming, hat in hand, to you, Mike, asking if you can help us with any part of this puzzle. Is there any chance that MakeMKV could play a role in extracting these TrueHD samples differently (I hesitate to say "better"), or would you be able to determine empirically/authoritatively that there is no issue with the TrueHD samples coming from MakeMKV so that we could then convince the exoplayer team to re-evaluate?"

This.

"We're essentially coming, hat in hand, to you, Mike, asking if you can help us with any part of this puzzle. Is there any chance that MakeMKV could play a role in extracting these TrueHD samples differently (I hesitate to say "better"), or would you be able to determine empirically/authoritatively that there is no issue with the TrueHD samples coming from MakeMKV so that we could then convince the exoplayer team to re-evaluate?"

This^2

If it would help here's some of the feedback from eac3to on a problematic seamless branching MKV with Atmos

MKV, 1 video track, 1 audio track, 2:23:40, 24p /1.001
1: h265/HEVC, English, 2160p24 /1.001 (16:9), 10 bits
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
a02 Extracting audio track number 2...
a02 Decoding with libav/ffmpeg...
a02 Writing WAV...
a02 Creating file "X:\MEDIA8\Movies\BLURAY\The Natural (1984)\The Natural (1984)-thd.mkv_2eng.wav"...
[truehd @ 03242b60] Lossless check failed - expected 00, calculated f5.
process: 1%
process: 2%
process: 3%
process: 4%
process: 5%
process: 6%
process: 7%
process: 8%
process: 9%
process: 10%
process: 11%
process: 12%
process: 13%
process: 14%
[truehd @ 03242b60] Lossless check failed - expected 00, calculated 08.
process: 15%
process: 16%
process: 17%
process: 18%
[truehd @ 03242b60] Lossless check failed - expected 00, calculated 3c.
process: 19%

Rudy 4K: seamless branched, has audio sync issue with Atmos on Plex with Shield

Fair warning, I'm writing here from a position of complete ignorance about the details of how ATMOS is encoded, but perhaps you could contact the person who apparently wrote the way AV sync issues in TrueHD streams are handled as of MakeMKV 1.15.4.

https://github.com/domyd/mlp

Maybe as an object based audio format detecting which chunk to drop by treating the data as audio samples isn't correct and that is resulting in the audio issues you are experiencing.

Again, total ignorance here. Just thought I'd possibly facilitate communication here as I encountered that site exploring whether or not I should be concerned about MakeMKV's AV sync warnings which I recently encountered.

https://forum.makemkv.com/forum/viewtopic.php?f=1&t=23347&p=98706#p98706

^ There are some comments from Mike about how things work in MakeMKV.

Thanks for that link. What a mess, and I'm referring to the standards requiring all that complexity. Makes me curious what officially licensed blu ray players do. Do they let the audio just drift out of sync over time or do they drop packets as well? With the description mentioning sync frames wouldn't it be nice if one could just ignore the apparent loss of sync because the sync frames would realign the data and the player would just drop the extraneous audio samples to get back in sync? (Yeah right.)

I'm guessing there's nothing here the author of MakeMKV hasn't already considered, but just in case it could help I'll write some quick thoughts as a new set of eyes. It does seem that the dropped packets are causing checksum errors from the eac3to output above and a quick glance at the dolby atmos parser showing they do use 16 bit checksums on the metadata. Should these checksums be taken into account when dropping packets? Like only drop entire checksummed regions not partial? Or recompute the checksum so it is correct for the shortened stream? (That doesn't sound so safe if the checksum is protecting metadata and not audio content.) Or if only part of the stream (the metadata) is checksummed never dropping a packet in those regions.

Just spitballing.