A bit disappointed that 1.15.3 hasn't removed the erroneous "AV sync" message that precedes the forced subtitles track are empty messages, but that's neither here nor there...
What I am curious about is a bit more detail on how MakeMKV is handling the removal of overlapping frames.
Here's an example log, I've just put a number in front of each line to make it easier to refer to:
1) AV sync issue in stream 1,2 at 0:03:53.024 with duration of 10.208ms : encountered overlapping frame, audio skew is +10.208ms
2) AV sync issue in stream 1,2 at 0:05:32.206 with duration of 6.916ms : encountered overlapping frame, audio skew is +17.125ms
3) AV sync issue in stream 1,2 at 0:05:32.224 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +6.458ms
4) AV sync issue in stream 1,2 at 2:01:29.115 with duration of 9.041ms : encountered overlapping frame, audio skew is +15.5ms
5) AV sync issue in stream 1,2 at 2:01:29.130 with duration of 10.666ms : 1 frame(s) dropped to reduce audio skew to +4.833ms
In line 1 and 2 it encounters overlapping frames and reports the current audio skew.
In line 3 it decides to drop a frame.
In line 4 it encounters another overlapping frame and reports the current skew.
In line 5 it decides to drop another frame.
So I have two questions...
- When it drops a frame in lines 3 and 5, is that an overlapping frame that it's dropping?
- And why not just drop every overlapping frame, and avoid all audio skew? Why wait until line 3 to drop a frame? (This would also save dropping arbitrary frames in lines 3 and 5, if those frames aren't overlapping.)
1.15.3 AV Sync Question
1.15.3 AV Sync Question
Using: ASUS BW-16D1HT 3.00
Re: 1.15.3 AV Sync Question
As there is some relevance, I am cross referencing the following here as well:
viewtopic.php?f=12&t=17597&start=135#p90648
https://github.com/domyd/mlp (scroll down to the FAQ for the great explanation)
Though the above references 1.15.1 (with apparently some fixes made in 1.15.2), apparently it's still an issue in 1.15.3.
viewtopic.php?f=12&t=17597&start=135#p90648
https://github.com/domyd/mlp (scroll down to the FAQ for the great explanation)
Though the above references 1.15.1 (with apparently some fixes made in 1.15.2), apparently it's still an issue in 1.15.3.
Using: ASUS BW-16D1HT 3.00
-
mike admin
- Posts: 4075
- Joined: Wed Nov 26, 2008 2:26 am
- Contact:
Re: 1.15.3 AV Sync Question
It is hard to say without knowing the stream type. Generally, there could be 3 scenarios for audio streams (MakeMKV drops almost nothing else):
1. "Regular" audio codec where all frames are equal - ac3, dts, etc. In this case MakeMKV drops frames immediately to keep skew below 1/2 frame length. Sometimes the gap management engine drops frames one by one, sometimes - few in a row, mostly depends on how many frames are available in a queue when decision for a drop is made.
2. LPCM audio (that includes any transcoding, as audio is first decoded to LPCM and then re-encoded). No frames are dropped, overlapping frames are stitched on a sample level (overlapping samples are dropped, audio silence is inserted on per-sample basis).
3. "Sync frame" audio codecs that have different kind of frames - sync frames followed by a regular frames. One can start playback only starting from a sync frame, which are inserted once every 10-20 frames. TrueHD, MLP and some DTS-HD variants are codecs that use sync frames. In these cases MakeMKV drops frames only at the end of sync sequence, and it evaluates all possible variants across a range of few seconds to find a best frame sequence to drop. Sometimes it is better to drop entire small sequence rather than few frames at the end of another sequence. The "atmos audio drop out bug" was due to the absence of this logic. So for codecs like these, the decision to drop frames could be postponed for as much as about a second.
For all 3 modes the gap engine also has some heuristics - it proactively analyzes upcoming frames and can "move" audio overlap and/or audio gap earlier in time if it would result in a fewer frames being dropped (to mitigate old "noise click on layer switch bug"). Which means that frames could be dropped before the actual frame overlap.
Also it looks at the nature of frame overlap and audio delay - for example if it sees an 20ms audio overlap, then it analyzes following frames, and, if it sees an an audio delay of 20 ms say 5 seconds in future, then it would introduce a 20ms skew instead of dropping the frame and inserting the audio delay ("clicking noise on Japanese DVD bug"). Which means that even the stream has clear overlaps and audio delays, no frames would be dropped.
Hope this helps.
1. "Regular" audio codec where all frames are equal - ac3, dts, etc. In this case MakeMKV drops frames immediately to keep skew below 1/2 frame length. Sometimes the gap management engine drops frames one by one, sometimes - few in a row, mostly depends on how many frames are available in a queue when decision for a drop is made.
2. LPCM audio (that includes any transcoding, as audio is first decoded to LPCM and then re-encoded). No frames are dropped, overlapping frames are stitched on a sample level (overlapping samples are dropped, audio silence is inserted on per-sample basis).
3. "Sync frame" audio codecs that have different kind of frames - sync frames followed by a regular frames. One can start playback only starting from a sync frame, which are inserted once every 10-20 frames. TrueHD, MLP and some DTS-HD variants are codecs that use sync frames. In these cases MakeMKV drops frames only at the end of sync sequence, and it evaluates all possible variants across a range of few seconds to find a best frame sequence to drop. Sometimes it is better to drop entire small sequence rather than few frames at the end of another sequence. The "atmos audio drop out bug" was due to the absence of this logic. So for codecs like these, the decision to drop frames could be postponed for as much as about a second.
For all 3 modes the gap engine also has some heuristics - it proactively analyzes upcoming frames and can "move" audio overlap and/or audio gap earlier in time if it would result in a fewer frames being dropped (to mitigate old "noise click on layer switch bug"). Which means that frames could be dropped before the actual frame overlap.
Also it looks at the nature of frame overlap and audio delay - for example if it sees an 20ms audio overlap, then it analyzes following frames, and, if it sees an an audio delay of 20 ms say 5 seconds in future, then it would introduce a 20ms skew instead of dropping the frame and inserting the audio delay ("clicking noise on Japanese DVD bug"). Which means that even the stream has clear overlaps and audio delays, no frames would be dropped.
Hope this helps.
Re: 1.15.3 AV Sync Question
Here's someone claiming an audible 'pop' in Onwards: viewtopic.php?f=8&t=23553