search

google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.7k stars 6.01k forks source link

MKVs from seamless branching blu-rays cause atmos audio drop outs and/or sync loss #10520

Open HurinSteadfast opened 2 years ago

HurinSteadfast commented 2 years ago

ExoPlayer Version

2.18.1

Devices that reproduce the issue

NVIDIA Shield Pro w/ SHIELD Android TV v9.1.0(33.2.0.125)

Devices that do not reproduce the issue

Reproducible in the demo app?

Not tested

Reproduction steps

Expected result

Audio plays back normally.

Actual result

Audio momentarily drops out (goes silent) and then returns out of sync with the video when a "seamless branch" boundary is crossed. Occasionally, the audio merely drops out but remains in sync upon return.

Media

Geogan on the plex forums has provided/extracted a clip that reportedly exhibits the issue: https://forums.plex.tv/t/plex-audio-dropouts-and-sync-issues-with-seamless-branching-on-4k-truehd-atmos-movies/775510/24

Alternatively, the full MKV extracted from 4K UHD Blu-ray of "The Martian" could be used. The audio will drop out and/or go out of sync on the extended edition wherever there is a "seamless branch" between the two versions of the movie. Example glitch is at 36:20 of Extended/Director's Edition where he says "I'm going to need to science the s--t out of this. . ." Which is the glitch provided in Geogan's clip linked above.

Bug Report

Montell-S commented 1 year ago

Just stumbled across this with apocalypse now seamless branch, kodi seems to handle it fine, finding alot of issues on reddit dating back a few years from various movies having this issue, is there any progress on this issue?

Kodi seems to have this fixed, but seeing more reports on this issues for things like plex that use exo player as titles that use seamless branching with 4k atmos continue to grow..

CineMAC-HA commented 1 year ago

any news from this? now I have titles with the same issue.

dastardo commented 1 year ago

It would be great if this could be fixed. It seems all the players on android that support Dolby Vision are based on ExoPlayer, so there is currently no way to play problematic Dolby Vision titles with seamless branching without TrueHD issues.

Using domyd's MLP demuxer does help, but even that cannot fix some 2 in 1 discs for ExoPlayer.

https://github.com/domyd/mlp

VLC plays the problematic files with no issues, but it doesn't support Dolby vision.

rohitjoins commented 1 year ago

@christosts can you please take a look?

dastardo commented 1 year ago

@christosts can you please take a look?

Thanks @rohitjoins, @christosts if you need any help with logs or testing etc, then I'm happy to help

dastardo commented 1 year ago

Just stumbled across this with apocalypse now seamless branch, kodi seems to handle it fine, finding alot of issues on reddit dating back a few years from various movies having this issue, is there any progress on this issue?

Kodi seems to have this fixed, but seeing more reports on this issues for things like plex that use exo player as titles that use seamless branching with 4k atmos continue to grow..

@Montell-S, domyd's MLP demuxer will fix this title, there is a bit of technique to getting it right though. I can share the method I use if you're interested.

https://github.com/domyd/mlp

The latest nightly version of kodi now supports Dolby Vision in MKV, so I use that for the problematic titles.

christosts commented 1 year ago

@Montell-S, domyd's MLP demuxer will fix this title, there is a bit of technique to getting it right though. I can share the method I use if you're interested.

https://github.com/domyd/mlp

The latest nightly version of kodi now supports Dolby Vision in MKV, so I use that for the problematic titles.

I took a look at the tool and also related discussions at the mentioned plex/reddit forum, plus the kodi code fixes. I'm not an expert on blu-ray, and please correct me if I'm wrong, but my understanding that existing tools the convert blu-ray to MKVs copy the audio from the disc on the mkv, including the overlapping audio frames at branch boundaries (as described in https://github.com/domyd/mlp). Therefore, the resulting mkv file has overlapping audio frames. If that is so, this is an issue that we'd classify as "malformed media" rather than a spec-compliant piece of media, and we don't plan to alter the player to address this.

Please do let me know if my understanding about the root cause of the problem is different.

GhostM121 commented 1 year ago

@christosts Someone with more technical knowledge would need to help explain it,, but this is a disappointing result. These are commercial media discs, xbox's, blu ray discs players all need to handle this type of seamless branching audio. As mentioned the title you quoted from someone else was not a great solution considering it plays fine in kodi without using some obscure third party demuxer, and again plays fine in a commercial player.

We are seeing alot of these issues pop up in plex forums and people complaining about stuttering audio falling out of sync and not knowing what causes it. Only a few went down the rabbit hole and ended up here. If we cant get a solution many of us will have to stop using plex and exo player which would be disappointing and moving to a branch like kodi.

icbaker commented 1 year ago

These are commercial media discs, xbox's, blu ray discs players all need to handle this type of seamless branching audio.

From ExoPlayer's perspective this is irrelevant. We are only concerned with the MKV you're asking us to play, not where it was originally converted from. If the MKV is not valid, then the issue should be reported to the owners of the tool that produced it.

GhostM121 commented 1 year ago

@icbaker they have, players have had issues with these discs and offered fixes through firmware updates.

I think this is becoming clear exo player is not going to address this, many of us with plex will have to talk to them or find other options.

HurinSteadfast commented 1 year ago

Hello christosts,

With respect, I don't think that's an accurate evaluation of this issue.

You cite https://github.com/domyd/mlp as describing the phenomenon. Perhaps because it has been claimed that the application there "fixes" a problematic title? Yet the author of that application states that "MakeMKV 1.15.4 and newer uses the same method for joining TrueHD streams, and should produce flawless TrueHD streams as well." The vast majority of the people experiencing this issue are using MakeMKV to generate the affected MKV files.

HurinSteadfast commented 1 year ago

These are commercial media discs, xbox's, blu ray discs players all need to handle this type of seamless branching audio.

From ExoPlayer's perspective this is irrelevant. We are only concerned with the MKV you're asking us to play, not where it was originally converted from. If the MKV is not valid, then the issue should be reported to the owners of the tool that produced it.

Yet, according to what chrisosts posted, he hasn't played any MKV files or analyzed them himself. Rather, he has inferred, from reading about what a tool someone suggested does, that the issue with all cited MKVs must be (that they are "malformed" despite the most popular tool for generating them conforming to what has just been cited as best practice). And based upon that, closed the ticket.

There has been no indication that exoplayer contributors have investigated the issue beyond doing some reading last night, after letting the report languish for months. And now. . . ticket closed.

geogan commented 1 year ago

I don't know if anyone is going to bother reading this at all now since this ticket is closed, and I don't really know what to say to you, or whether it is your code that is wrong or MKV file format that is wrong somehow (but if the file format is wrong then why does it play back perfectly in all other players including PC based players without audio problems?)

As HurinSteadfast said on PLEX forum:

"While I hate to let plex off the hook for this, I think I have determined that this is an issue with the exoplayer (by Google) embedded in the Plex client rather than a problem with the Plex client or code itself.

Why? Well, I tried jellyfin to work around this issue, and found that the exact same issue at the exact same place occurred in The Martian (and some other movies I have). However, jellyfin allows you to change the embedded player from exoplayer to libVLC. . . and upon trying libVLC, the problem disappears.

So, since both jellyfin and plex use exoplayer, and both are affected (yet jellyfin ceases to be affected when exoplayer is disabled), I believe that indicates Google’s exoplayer is likely the culprit.

"

I have got this problem on multiple discs now and latest and worst I have found is the Extended Cut of M3gan on Bluray. My post on PLEX details it and also shows the MakeMKV log which it generates while reading the disc to produce the MKV

https://forums.plex.tv/t/plex-audio-dropouts-and-sync-issues-with-seamless-branching-on-4k-truehd-atmos-movies/775510/84?u=geogan

If you need me to send you the entire original M3gan MKV file to attempt playback and test / investigate I can - the audio dropouts occur at least 10 times throughout movie after the first one about 35 minutes in (when she kills dog)

HurinSteadfast commented 1 year ago

Please note that the ticket has been re-opened. So, let's all stay chill. :)

dastardo commented 1 year ago

@geogan try DGDemux, if that doesn't work, then I have another method that will work.

https://www.rationalqm.us/dgdemux/binaries/DGDemux_1.0.0.67.zip

geogan commented 1 year ago

@geogan try DGDemux, if that doesn't work, then I have another method that will work.

https://www.rationalqm.us/dgdemux/binaries/DGDemux_1.0.0.67.zip

This program only extracts and de-muxxes from original full disc image copies (ie exact Bluray/4K disc images with entire original structure).

This is not what we are getting from MakeMKV - that already does all that job of extracting/muxxing from original file structure on disc and producing a final muxed MKV file with just the video/audio track and subtitles only.

So no use here. We are not really looking for alternate Bluray ripping program solutions here. This is just confusing things.

Are you saying Exoplayer uses some buggy demuxer? (domyd's MLP demuxer)?

dastardo commented 1 year ago

@geogan, it's pretty simple to drop the output from DGDemux into MKVToolNix to produce your MKV.

MakeMKV uses domyd's MLP demuxer but it does have issues. I use a slightly different method and it works 99% of the time, but ExoPlayer does need fixing, because it doesn't happen with any other players.

geogan commented 1 year ago

@geogan, it's pretty simple to drop the output from DGDemux into MKVToolNix to produce your MKV.

MakeMKV uses domyd's MLP demuxer but it does have issues. I use a slightly different method and it works 99% of the time, but ExoPlayer does need fixing, because it doesn't happen with any other players.

Yes but DGDemux only works with full disc decrypted disc images, which is not what we have here. You are basically suggesting a complete alternative to MakeMKV. I don't have any interest in re-ripping using alternate complicated methods (yes I do know and have MKVToolNix for other uses for years).

OK, so MakeMKV uses domyd's MLP demuxer, right.

Well there is definitely a problem somewhere between this MLP demuxer (which MakeMKV apparently uses) and Exoplayer reading what it produces.

I'll just repeat what I said on PLEX here in case its not read by devs:

But anyway I just tried playing back the M3gan MKV locally on my Windows 10 PC from the server on some local players…

KMPlayer 2021.02.23.57 Using LAV Filters 0.70.2.0

SMPlayer 22.7.0 rev10091 Using MPV 0.34.0

VLC Player 3.0.18 Vetinari

Windows Media Player 12.0.19041.2788

All were able to get past the first problem point at dog attack around 35mins without audio dropouts. The only program that went out of sync a bit was Windows Media Player when I tried to seek up to just before problem, but when I went back to start and then seeked to a bit further back there was no problem.

dastardo commented 1 year ago

@geogan, unless you can find a player that can deal with the output from MakeMKV, then you have no choice but to re-rip. It's not complicated.

HurinSteadfast commented 1 year ago

@dastardo, as you just put it, "unless we can find a player that can deal with the output from MakeMKV". . . Kodi was apparently modified so that it can play back the cited mkvs without issue (which I intend to test with renewed urgency).

Is it your contention that there is no issue with exoplayer and that the fault lies entirely in "malformed" MKVs? If so, fair enough, nobody can stop you from making that case. However, I'm not sure it's possible, from (y)our vantage point, to determine which demuxer/transcoder/ripper is doing things correctly vs which ones are simply doing things in such a way that it doesn't happen to trigger this unfortunate behavior in exoplayer.

If that is not your contention, and you allow for the possibility that exoplayer needs to be improved so that it can play back MKVs ripped from seamless branching blu-rays without issue, may I kindly invite you to join us on the Plex forums where I'm sure many of us would welcome any guides you would like to post to help us work around the issue (ie., rip our blu-rays in such a way that does not trigger this issue) while the investigation over here continues.

It doesn't seem like this is the proper venue to work around the issue on a disc-by-disc basis using multiple different de/remuxers. And I'm not sure it's helpful in determining whether the issue is with exoplayer itself or with media that we're told has been demonstrably mangled.

geogan commented 1 year ago

@geogan, unless you can find a player that can deal with the output from MakeMKV, then you have no choice but to re-rip. It's not complicated.

Well I did just list four players above which can deal with the output from MakeMKV... but I presume you mean on NVidia Shield or that PLEX on Shield can use instead of Exoplayer

dastardo commented 1 year ago

@HurinSteadfast The issue is with ExoPlayer, but there are some problematic discs. The best example of this is the 2 in 1 UHD of Resident Evil: Apocolypse. domyd does give a good description of what his demuxing tool does. He does explain in quite a lot of detail at https://github.com/domyd/mlp The problem is, it needs more development, but I don't think he's working on it anymore.

@geogan try the Resident Evil: Apocalypse 2 in 1 UHD. The only way I can get it to play without dropouts and going out of sync is to demux the audio with DGDemux and then play with Kodi.

HurinSteadfast commented 1 year ago

@HurinSteadfast The issue is with ExoPlayer, but

. . . Let me stop you there. ;)

This is a bug report I filed with the intent of getting exoplayer fixed. I appreciate that you're trying to help. But, unfortunately, I think you're likely muddying the waters. Already, it seems apparent that the exoplayer devs seized upon some of the information you provided (the FAQ at mlp) and interpreted it as evidence that there is no issue with exoplayer. Thankfully, they seem to have now been convinced otherwise and have re-opened the ticket.

Again, there are better, more visible venues for helping individual users work past issues with individual discs. While I have no authority to tell you that you shouldn't be posting these things here, I hope you will consider that perhaps doing so isn't helpful for the purpose of this ticket.

dastardo commented 1 year ago

@HurinSteadfast The issue is with ExoPlayer. I'm offering a workaround, but if you're not interested, then enjoy your dropouts and out of sync audio :-)

GhostM121 commented 1 year ago

@HurinSteadfast The issue is with ExoPlayer. I'm offering a workaround, but if you're not interested, then enjoy your dropouts and out of sync audio :-)

This is a bug report forum, I dont think you need to get defensive, a work around is suited more for the plex forum or other end user support forums. But this is muddying the waters here.

As for my work around currently its to use another player other then exo (plex) such as kodi, or vlc.

GhostM121 commented 1 year ago

Incase that went to everyone's email as big report forum, I am on my phone with auto correct. That should say "bug report".

HurinSteadfast commented 1 year ago

@HurinSteadfast The issue is with ExoPlayer. I'm offering a workaround, but if you're not interested, then enjoy your dropouts and out of sync audio :-)

Correct. In this context, I am not interested.

Over on the Plex forums? Where the people actually affected would actually see and appreciate your helpful information and be able to follow up with you in a format conducive to conversation and tutorials? That'd be great!

icbaker commented 1 year ago

We were able to reproduce the problematic behaviour on an Nvidia Shield using the clip provided in the original comment (thanks!).

However this thread seems to authoritatively state that Dolby TrueHD Atmos audio is not supported in MKV containers:

mkv containers are not supported

Given that, I'm afraid we don't plan to spend any more time on this issue. ExoPlayer generally aims to support spec-compliant media, but we don't follow the same philosophy as VLC (which generally tries to play everything, even that media which lies outside official spec support). This enables the ExoPlayer code to remain simpler and easier to reason about (since it's all justified with reference to a particular spec). ExoPlayer does occasionally introduce workarounds for spec-noncompliance problems that affect a significant fraction of the ecosystem, but I believe this issue does not meet that bar.

DamianEdwards commented 1 year ago

That comment on the referenced thread seems to be referring to a specific player (Dolby Reference Player), not that MKV is unofficially unsupported as a container format that happens to be holding TrueHD content.

HurinSteadfast commented 1 year ago

@DamianEdwards

Indeed! That seems to be a reference to the reference player and what it is capable of playing. That does not preclude other players being able to handle additional containers. And, furthermore, aren't there actual specs and design documents that could be cited rather than random forum posts by Dolby employees?

It's disheartening that, twice now, the exoplayer teams seems to be reflexively latching onto any utterance found across the internet that could plausibly (or even implausibly) give them an excuse to declare this to be "not their problem" or "not worth fixing."

If exoplayer continues to refuse to fix this issue, there will be a lot of NVIDIA Shield devices up on eBay and/or in ewaste piles. Its audio-handling capability and status as the best Plex home theater playback device is the only reason many of us own one.

HurinSteadfast commented 1 year ago

@icbaker Would you please explain why the container type is relevant to this problem? Your are citing a forum post where a Dolby rep states that their Dolby Reference Player is not intended to play MKV files. Heck, he even casts shade at mp4 files as well.

That is not the same as stating (much less "authoritatively") that "Dolby TrueHD Atmos audio is not supported in MKV containers."

The fact that Dolby TrueHD Atmos tracks playback fine when they're not derived from seamlessly branched Blu-Rays, playback mostly fine but then get glitchy in the affected MKVs, and that other media players play them back fine regardless of source, all these would seem to belie the contention that "Dolby TrueHD Atmos audio is not supported in MKV containers."

The fact is, Dolby TrueHD Atmos works fine within MKVs on all payers but exoplayer. And it's hard to believe that the forum post cited would compel you to consider this a feature rather than a bug.

dastardo commented 1 year ago

@icbaker, it's nothing to do with the container. Remux your test file into ts or m2ts and it will be even worse, but they will play fine in other players.

@HurinSteadfast, MP4 doesn't support TrueHD.

HurinSteadfast commented 1 year ago

@dastardo, which is why I found the cited Dolby rep saying. . . "Using them inside of mp4 container is not a very often scenario." . . . so strange/amusing.

icbaker commented 1 year ago

@HurinSteadfast

And, furthermore, aren't there actual specs and design documents that could be cited rather than random forum posts by Dolby employees?

Please link to such a spec describing how Dolby TrueHD Atmos should be muxed into an MKV container - I didn't find anything after some searching.

HurinSteadfast commented 1 year ago

@icbaker I can't find any official specs or documents from Dolby either, as a layperson, describing how to mux Dolby TrueHD Atmos _into any containers_. Perhaps, as a dev, you can. But in any case, I fail to see the point because a lack of evidence is not evidence of lack.

We know MKV containers can work with Dolby TrueHD, flawlessly. Thousands of people mux Dolby TrueHD into their MKVs daily for playback on their home theater devices. Only exoplayer has trouble with some of them (MKVs derived from seamlessly branched blu-rays).

I hope you will change your mind about your interpretation of an ambiguous forum post by a Dolby rep. While I can appreciate your desire to keep exoplayer "clean" and not modify it to play media that is not "spec-compliant," we have yet to see any compelling evidence that there is any problem with MKV containers that would render them non-"spec-compliant."

The number of affected blu-rays is already large (and it is growing). It would be a shame if exoplayer were consigned to a permanent status as an inferior player that will never play those movies back correctly on the best home theater playback device (nvidia shield) for the most popular home theater media player (Plex). Our only hope then would be that Plex would abandon exoplayer.

I regret that the tone of this thread has grown contentious. But I hope you can appreciate that, from our perspective as users (who are helpless to fix this ourselves), all efforts evident from here seems to have been directed at rationalizing why this readily evident issue should not be fixed. Shouldn't it be demonstrated conclusively that MKV containers are materially non-compliant in some way before it is asserted/assumed that exoplayer is therefore faultless and the issue can be ignored?

And, finally, thank you for taking the time to test and reproduce the issue! That does represent progress! I hope you will reconsider your interpretation of the dolby rep's forum post and help us get this issue resolved.

Thanks!

dastardo commented 1 year ago

@icbaker, do you accept m2ts is a suitable container for TrueHD? If so, remux your test file into m2ts and check the results. You will get the same issues as you do with the MKV file. It's nothing to do with the container.

HurinSteadfast commented 1 year ago

@icbaker Hi! I note that the ticket remains open. Is there a chance that your appraisal will be reevaluated? Please do try what dastardo suggests immediately above. Whether an MKV container is used or not, the issue persists. Thank you!

HurinSteadfast commented 1 year ago

Hooked up my kid's XBox Series X to my home theater receiver in audio passthrough mode, installed Plex on the XBox, and. . . TrueHD/Atmos plays back flawless via MKV files served from the Plex server. Yet another player that does not have this issue.

@icbaker, with respect, please reconsider your opinion that this has something to do with MKV containers. Its only basis appears to be that one post by a Dolby rep stating that their player application won't play MKV files. That's not the same thing as stating that Dolby Atmos won't work in MKV files. And there is lots of circumstantial evidence and examples of other players handling TrueHD/atmos within MKV containers absolutely flawlessly.

Please, there are many people heavily invested in Plex, their Blu-rays, and their home theater that they envisioned being able to playback their files without issue on the Shield. Which is the only device currently out there that will do audio passthrough and playback Dolby Vision without issue (XBox won't do Dolby Vision reliably).

Again, with respect. exoplayer should be able to play back TrueHD/Atmos from within MKV conatiners, like every other player in its class. It is so close, there's just this glitch that is within your power to fix.

Thank you for your time and patience!

tresnugget commented 1 year ago

@geogan try DGDemux, if that doesn't work, then I have another method that will work.

https://www.rationalqm.us/dgdemux/binaries/DGDemux_1.0.0.67.zip

I tried this with F9 and no luck.

icbaker commented 1 year ago

Just to recap my current understanding (and clarify some things that people seem confused about above):

Given these points, if there is a problem in ExoPlayer, it's unclear how we should find it (since there's no spec explaining the technical details of how ExoPlayer should handle these files).

In conclusion, I'm happy to leave this issue open, but we have no plans to investigate the problem further or work on this (since it seems to me that the problem is generally under-specified due to the lack of spec). We would accept a high quality PR fixing the issue along with an explanation of the problem in ExoPlayer's logic that it is fixing.

HurinSteadfast commented 1 year ago

@icbaker Thank you for taking the time to clarify your position. I much appreciate it.

I now better understand that, if there is a problem with exoplayer, it most likely exists in the code where it "unwraps and feeds" the sample to the decoder.

While I understand that other players doing this without issue is not necessarily evidence that exoplayer "unwraps and feeds" improperly, I hope it is appreciated that, circumstantially, their doing so at least raises some questions.

It appears we're at an 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.

Again, thank you for your time.

geogan commented 1 year ago

Hi @icbaker thanks for update. Just FYI in case you didn't see this comment by FlaTechNole21 on PLEX forum post:

"If you convert a muxed seamless-branched TrueHD track in ffmpeg, you’ll get warnings at the branch points that it’s not lossless at those frames. This sounds like a possible cause of the player mishandling lossless pass-through."

This to me gives the best clue as to the cause. There must be something continually being transmitted in the stream, or some command or sequence, which indicates to the player what the current stream format is.

And when the player ie the physical AVR in case of direct bit-streaming to the device from Shield, sees a different audio data format to what it is currently playing, it normally mutes the sound for a second or two while changing internal power relays etc and updates front LCD display to switch eg from Dolby Surround to Dolby Atmos

If these seamless branch TrueHD tracks contains extra extremely quick format changes in middle of track at branch points (warnings at the branch points that it’s not lossless at those frames) it would explain the AVRs behavior while playing.

So I'm not sure if you know exactly what commands are being sent, or if you actually parse the stream at all or just bit-stream it blindly, but I would check around these problem branch points for some sort of "audio format change" command which causes it to switch from lossless to a lossy format, and suppress or remove them from stream and see what that does. This does depend on knowledge of the actual bit-stream data format though and commands within it.

It may be some problem with the way the TrueHD stream was read from disc and "corrected" by MakeMKV while it reads it - it does give warnings about audio skew errors and adding/removing frames to correct while it reads disc so maybe it adds in erroneous audio format in middle for a single or a few frames while doing this. No idea why or how other players manage to handle this though.

Another idea would be to get in contact with author "Mike" from MakeMKV himself - he is fairly expert on all this... maybe he could find the problem - he definitely knows the format and how to handle it... maybe its a bug in his code that needs fixing while he produces the TrueHD track in the MKV container. I have created a post about it here: https://forum.makemkv.com/forum/viewtopic.php?f=6&t=31140&p=136697#p136697

dastardo commented 1 year ago

@geogan MakeMKV has been using domyd's TrueHD demuxer since 1.15.4.

MakeMKV was not very good at TrueHD seamless branching, so I think that's why Mike integrated domyd's TrueHD demuxer.

https://github.com/domyd/mlp

geogan commented 1 year ago

Interesting FAQ there on the domyd github about removing the duplicate end frame. But I doubt that is anything to do with our problem. But interesting he mentions this "major sync" thing...

"we can cut the very last TrueHD frame off a stream without consequences. The reason for that is that the start of every stream always has what's called a major sync. Major syncs are basically restart points for the decoder, where any issues introduced by previous audio data are no longer relevant"

Maybe that's the thing that is switching audio format at branch point and should be fixed to have correct lossless format in it?

Also, I used MakeMKV v1.17.3 to rip the M3gan Bluray and that is still completely riddled with at least 10 audio dropouts/out of sync continuations... so the switch to this better demuxer doesn't appear to have fixed or affected problem.

dastardo commented 1 year ago

domyd's demuxer does have some issues, unfortunately, it looks like he's not developing it anymore. The latest Nexus build of Kodi will playback without any issues if you want Dolby Vision, or you can use VLC if you're not bothered about Dolby Vision.

scarbrtj commented 1 year ago

Not sure if the observations will be helpful but here goes. All these observations are based on known seamless branching "problematic" blu rays (in my case known examples are The Natural, F9, the Martian, BlackHawk Down).

1) DVDFab MKVs produce the same behavior as MakeMKV in Plex Exoplayer on Shield (AV sync issue). 2) DVDFab can mux HEVC and Atmos into MP4. An MP4 produces the Plex Exoplayer on Shield AV sync issue. The behavior is identical to an MKV. 3) One can determine exactly where the AV Sync Issue occurs at the "appending" of two .m2ts files together. If one appends two known "misbehaving" .m2ts files together with MKVToolNix e.g., one can produce the Plex Exoplayer on Shield AV sync issue that way too.

HurinSteadfast commented 1 year ago

Thank you for these contributions here and elsewhere, scarbrtj!

On another note. I found this interesting (maybe I won't be the only one):

I was doing some googling and was surprised to find a lot of reports of "audio dropouts" related to "seamless branching" with TrueHD/Atmos on older blu-ray disc table-top players as well. Around 2014, the industry addressed the issues in their newer batches of disc players and everyone moved on.

https://www.audioholics.com/news/dolby-atmos-old-blu-ray-players https://www.bigpicturebigsound.com/Existing-Blu-ray-Player-Dolby-Atmos-and-DTS-X.shtml

So while it's true, as we've been told, that TrueHD/Atmos is primarily seen on discs (blu-ray), even disc players didn't handle seamless branch transitions correctly for TrueHD/Atmos and needed substantial fixes. Substantial enough to require new hardware (not just firmware) revisions.

scarbrtj commented 1 year ago

Thank you for these contributions here and elsewhere, scarbrtj!

On another note. I found this interesting (maybe I won't be the only one):

I was doing some googling and was surprised to find a lot of reports of "audio dropouts" related to "seamless branching" with TrueHD/Atmos on older blu-ray disc table-top players as well. Around 2014, the industry addressed the issues in their newer batches of disc players and everyone moved on.

https://www.audioholics.com/news/dolby-atmos-old-blu-ray-players https://www.bigpicturebigsound.com/Existing-Blu-ray-Player-Dolby-Atmos-and-DTS-X.shtml

So while it's true, as we've been told, that TrueHD/Atmos is primarily seen on discs (blu-ray), even disc players didn't handle seamless branch transitions correctly for TrueHD/Atmos and needed substantial fixes. Substantial enough to require new hardware (not just firmware) revisions.

Strong bet that somehow the guts of Exoplayer use the playback behavior and/or "code" of the old, pre-seamless branching blu ray players.

This gives hope that Exoplayer could make seamless branching really and truly work imho. There's gotta be a way. Now there just needs to be a will.

GhostM121 commented 1 year ago

If you search this issue on certain blu rays pretty sure alot of hardware players come up even recently on 4k blu rays that had to issue firmware updates to fix this.

I just cant say I agree with the exoplayer devs stance on this. I do know the shield had an issue recently (few years back) where the atmos bitrate (Im going from memory 3 years ago) would go beyond the truehd spec and drop out or the frames were to large, MAT spec was also not well documented. But yet the issue was still fixed..... This occurred on hardware players and software players. There were posts on the shield forum and it eventually got fixed.

I still dont know how this issue is any different. A blu ray is just folders with mt2s files and I think we established that has issues as well. Remuxing into an mkv is beside the point and is not contributing to the issue at all....

Maybe were better off posting on the shield forum like many did with the shield atmos dropout which eventually got attention and resolved (gurardians of the galaxy 2 had a number of dropouts) which was a problem a few years ago. See below link.

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

GhostM121 commented 1 year ago

Btw just for proof this affects hardware players, I believe microsoft fixed it on xbox blu ray players, but the ones we know about like black hawk down microsoft looked into it and as far as I know eventually did fix this bug.

https://answers.microsoft.com/en-us/xbox/forum/all/black-hawk-down-extended-edition-uhd-blu-ray-has/1551d916-3f72-4934-87c5-5b97a2154b2f