Dolby Atmos Track drops out with v74.1, but not with v73.1

[wowdeathbringer]

I just realized, that LAV Filters v74.1 drops out on a Dolby Atmos track, that plays fine with LAV Filters v73.1. I can reproduce this, I had v74.1 installed, reverted back to v73.1 and than re-installed v74.1. I cut a demo mkv file, you have any place I can upload it to for you? (duration 2:30 ~570MB) There're 2 drop outs in it, one at the beginning, which is rather short. And one bigger against the end. In both cases the audio drops out first, and than a second or so later the video stutters.

My setup: HTPC (Win 10, Radeon RX 480), Anthem MRX 720 A/V-Receiver

[Nevcairiel]

I don't have any official place to share files. But something like https://mega.nz/ should work

[wowdeathbringer]

OK, I sent you the link via eMail.

[wowdeathbringer]

So I tried to watch the movie with v73.1, and I encountered another problem. At some time about half way through the movie, the sound was completely dropped. The AVR still showed Dolby Atmos was coming in, but there was no sound at all. Pausing/unpausing and rewinding did not help, I had to switch audiotracks to get it to work again (or restart the movie). It is reproducable, but only when watching the movie from start, when I skip forward to a scene a few minutes before the original drop of audio, it just rolls by flawlessly. Is there a logging function in LAV I could somehow activate, to get some information out of it for you to look at? That said, I am positive that I already watched the movie some time last year without any problems, probably with v68.1. I downloaded v71.0 and give that a try in the next days, because that's the version prior to the first changes for Dolby Atmos according to the changelog.

[Nevcairiel]

All earlier versions have issues with some Atmos tracks, specifically if the bandwidth is very high, like on UltraHD Blu-ray discs. Thats why there were changes in the first place. It doesn't really help me to test with older versions.

[wowdeathbringer]

OK, how can I help? Should I try v74.1 again to see if it drops the sound completely at some point?

Here's the info for this track that MediaInfo outputs: Audio #1 ID/String : 2 Format/String : MLP FBA 16-ch Format/Info : Meridian Lossless Packing FBA with 16-channel presentation Format_Commercial_IfAny : Dolby TrueHD with Dolby Atmos CodecID : A_TRUEHD Duration/String : 2 h 1 min BitRate_Mode/String : Variable BitRate/String : 4 685 kb/s BitRate_Maximum/String : 7 380 kb/s Channel(s)/String : 8 channels ChannelLayout : L R C LFE Ls Rs Lb Rb SamplingRate/String : 48.0 kHz FrameRate/String : 1 200.000 FPS (40 SPF) Compression_Mode/String : Lossless StreamSize/String : 3.97 GiB (15%) Language/String : English Default/String : Yes Forced/String : No Number of dynamic objects : 11 Bed channel count : 1 channel Bed channel configuration : LFE

[cmichaelhk]

Same problem here and similar HTPC Windows 10 & RX480 & yamaha AVR, anyway that I can help?

[chros73]

I only had this once with Black Hawk Down (using 74.1, haven't tried out any earlier version), never before and after.

[cmichaelhk]

Yea UHD Black Hawk Down with Atmos got many problem. No sound after seek & suddenly no sound when nornal playback. Set back MPC-BE internal AC3 filter sometime will no sound for half second but after that will back to normal.

[Nevcairiel]

I looked at the provided sample, and LAV behaves up to the specification, and also identical to reference software I have to compare against.

However, there is a huge frametime gap at those two jump points, which leads to LAV (and the reference) to insert a lot of padding, which presumably is the source of the drop out. But the instructions to insert this gap are actually present in the source stream.

If LAV does not obey those gap instructions, then perfectly valid samples fail to play properly, which was fixed in 0.74.

I can only guess that perhaps the ripping software did something wrong here, since seamless branching Blu-ray ripping can be a bit involved, especially with TrueHD.

[chros73]

I can only guess that perhaps the ripping software did something wrong here

Thanks, that's what I thought as well, that's why I haven't commented it as an issue.

[wowdeathbringer]

Ok, I'll try re-ripping and see if I can find the source. I'll let you know what I find.

[wowdeathbringer]

So, I made a completely new backup of the whole disc with MakeMKV, which to my understanding is a 1:1 copy. It has seamless branching, since there's the theatrical cut and the extended version on it. So I checked the stream files (.m2ts) and the dropouts occur exactly at the transition from one stream file to another stream file. But only when I play the playlist for the extended version, not the theatrical cut.

I then checked playback of the disc itself with PowerDVD 12, the extended version played just fine, with bitstreaming. No dropouts. So there seems to be no mastering error on the disc. Next, I took the backup folder made with MakeMKV and turned it into an .iso with ImgBurn. Then I mounted that .iso as a virtual drive and opened it up with PowerDVD 12. Played the extended version, there are no dropouts. So the backup done by MakeMKV seems to be valid too.

Out of curiosity, I turned bitstreaming off for Dolby TrueHD in LAV Filters and played the extended version from the backup folder again, no dropouts. So if there was something wrong with the ripped data, shouldn't it also affect the decoding of the TrueHD stream?

[Aleksoid1978]

Can you give a link for this UHD BD ?

[wowdeathbringer]

Imported it from italy, here's the link: https://www.amazon.it/Baywatch-Blu-Ray-4K-UltraHD/dp/B072FP6TBN/ The discs have the UK ratings printed on them, so I presume the UK-Version have the same discs. The Codes printed on the discs are: BD: EU 147877 BLB UHD: EU 147063 ULB

The UHD and the BD have the same english Atmos audio stream (same size, same dropout problems), my tests yesterday where made with the BD.

[Aleksoid1978]

This version has 01:56:28 | 02:01:23 duration ? What version(theatrical or extended) has dropouts ? Can you give timestamps where dropouts ?

[Nevcairiel]

Thats the problem with seamless branching discs, when there is two variants its hard to unify them properly.

I could possibly fix it when playing directly from the disc or a folder rip with LAV Splitter, but if you do a MKV rip this information is lost, and the MKV ripping tool would need to be responsible to fixing it - which as far as I know, none do.

[wowdeathbringer]

@Aleksoid1978 Yes, ZoomPlayer shows me durations just one second less, but that might just be some rounding issue. I've only tested the beginning of the movie, there it only happens in the extended cut. Don't know if there are any more dropouts, but I guess every transition between stream files is a candidate for a dropout. Timestamps are ~07:44 and ~09:29 of the extended edition. I'm currently only on my Laptop, so I can't reproduce the exact timestamps, sorry. It's right on the following transitions: 00459.m2ts -> 00445.m2ts -> 00460.m2ts

@Nevcairiel If we could get it to work with the folder rip, that would be a step forward, right? I would assume that by fixing it for the folder rip, you could then provide information how a generated MKV from this should look. With that information we could approach the ripping tools, in my case that would be MakeMKV and MKVToolNix, so they can fix it on their end.

[Nevcairiel]

I've found a relatively decent work-around that can detect such breaks in the stream, and reset the state. Give the next nightly builds a try at https://files.1f0.de/lavf/nightly/ (should appear in around ~2 hours from this message, you w ant 0.74.1-20 or newer)

[wowdeathbringer]

Thanks @Nevcairiel, I tried 0.74.1-20, it plays way better/smoother than the 0.74.1, but I still got some hickups. Hopefully I'll find some time to check again the next days, so I can provide you with samples and detailed information.

Just in case @Aleksoid1978 or someone else wants to check too, I've determined the exact timecodes in the extended edition, where a streamfile transition takes place: 00:05:49.264 00:07:44.920 00:09:32.530 00:11:12.337 00:31:33.807 00:32:11.553 01:05:17.703 01:06:34.904 01:11:31.699 01:13:56.260 01:20:36.159 01:21:36.635 01:35:23.168 01:44:00.433 01:44:40.930

[wowdeathbringer]

Just to clarify, the workaround in the nightly, should it be also working with the MKV or just with folder rip? Whereas the folder rip works fine now, the MKV still has some issues, but those are way more subtile than before. Mostly it's just 1 frame repeat happening, sometimes followed by a shorter audio dropout.

[Nevcairiel]

It should definitely affect both, but depending on what the ripping tool did exactly right or wrong, MKVs just differently.

[cmichaelhk]

Just tested 0.74.1-20 with black hawk down It absolutely better than before.

[wowdeathbringer]

So, should I provide some sample MKVs, or is now the time to approach the ripping/muxing tools? If it's the later one, can you give some information that might help those developers to fix their tools?

[MikeChenMM]

Can you please elaborate what is exactly wrong at this point of seamless branching? I do exactly the following:

1. if tracks do not overlap, just join them and leave whatever gap there is (usually 1 video frame)
2. If the tracks do overlap, then cut the stream at the closest SYNC frame and then join them using the case (1)

Is there any other procedure to join 2 MLP streams? can the "delay" metadata be removed?

[Nevcairiel]

TrueHD/MLP have a "timestamp" in their header (byte 3 and 4 in each packet, before the actual header), which needs to be continous. I quoted timestamp because the time refers to when a sample is supposed to be put into the playback buffer, which relates to its size, and not its decoded length.

These buffer timestamps are used to determine how to convert the variable bitrate MLP stream to a constant bitrate MAT stream, for transmission over HDMI, because not every frame gets equal padding (since they might not fit).

When playing a Blu-ray directly, you can see the segment changes and reset the continuity, but once its ripped to MKV, these segment boundaries are lost, which means its impossible to determine if a change in the timestamp simply indicates a bigger MAT frame, or an actual gap.

The only proper work-around I have found is to use the additional "output timing" metadata from the MLP major sync header, and hope that every segment boundary actually has a major sync.

[MikeChenMM]

Thanks for the info! How easy is to calculate and patch these timestamps? If I have a last non-sync frame from a previous segment and a first sync frame from a new segment (segments always do start with a sync), is there a formula/code to patch all following frame timestamps in order to create continuity? Some delta that i can add/substract to all following frames.

[domyd]

I believe I've found a rather banal solution to joining two MLP streams together properly. If there's an overlapping audio frame (and there's only ever at most 1), cut the minor frame duplicate and then just append. Never cut more than 1 TrueHD frame. Perfect A/V sync ensues from simply dealing with duplicate frames, there's nothing else that needs to be done.

I've implemented this in my own demuxer and so far I've had great success on every TrueHD blu-ray I've tested. The README there also contains a write-up of all of my findings regarding this issue.

[wowdeathbringer]

@domyd , thanks for sharing. I'll try your tool on some of my problematic Blu-rays/UHDs. Just out of interest, these kind of overlapping audio frames are specific to TrueHD and no other format (like Dolby Digital (Plus), DTS, ...) has something similar, that would produce faulty audio streams when muxed into a single file?

[wowdeathbringer]

So I've started to replace some of my MKVs from seamless branching discs with the original BDMV folders. For some it works perfectly with LAV v0.74.1-20, but some just won't play properly. What happens there is, that if I start watching the movie from the beginning at some point in the movie audio stuttering will occur, and that point is always the same. But when I skip back or a minute in front of that point, it won't happen. That happens for me on Total Recall (2012) and Monsters University, which both have Dolby TrueHD audio. Whereas Total Recall has 2 different version of the film with different runtimes on it, Monsters University just has different language version with exactly the same runtime. What those 2 discs have in common, they have a lot of segments. Total Recall (Extended Cut) has 61 segments and Monsters University has 81 segments.

Is there somehow a debug mode I could activate in LAV, so it would write a logfile I could send in?