Fetaure request: remove Audio delay if Audio reencoding is done

[BobDig]

I have the following problem. I made two parts of one youtube video. Later I decided to merge these by appending. But whatever I do, the endfile will have async audio (later) because those two videos have different delays according to MediaInfo to begin with.

So wouldn't it be possible to insert "silence" or cut the audio at the beginning in general, whenever I do re-encode the audio to have all delays to be removed? Or at least an easy box to tick for that it it isn't done be default?

[eumagga0x2a]

Loss of A/V sync for appended source videos when video stream contains B-frames is a known bug.

As you re-encode anyway, I wonder whether deleting a small selection (just a few frames) across the boundary might help. If this doesn't help, I'd suggest the following procedure: re-encode each of the videos with B-frames disabled, save each separately in copy mode (this removes B-frame delay and related audio delay), then append as usual. This should minimize the loss of sync.

[eumagga0x2a]

By the way, is it the same topic just with a better explanation of the problem as https://avidemux.org/smif/index.php/topic,19190.msg89408.html ?

[BobDig]

I will try that and report back. I thought it might be a more general problem, that appending files with different audio delays would never work. Let's see.

[BobDig]

By the way, is it the same topic just with a better explanation of the problem as https://avidemux.org/smif/index.php/topic,19190.msg89408.html ?

No, it is not. In that thread, there was no appending involved, just cutting one file.

[eumagga0x2a]

Good, but please understand that only 2.7.6 or later builds are supported (else we will repeatedly have to deal with numerous issues which have been solved on the long way from 2.7.5 to the current state of development). Of course, tests with older versions are necessary to identify regressions so they can be fixed.

[BobDig]

I wonder whether deleting a small selection (just a few frames) across the boundary might help. If this doesn't help, I'd suggest the following procedure: re-encode each of the videos with B-frames disabled, save each separately in copy mode (this removes B-frame delay and related audio delay), then append as usual. This should minimize the loss of sync.

Ok, so tried both and it didn't work. The async in the later part stayed...

I am not sure if this disables b-frames...

I think that this problem (appending files with different delays) is old as hell and is not related to any recent changes, but to be honest, I am still using 2.7.5 because of reasons.

[eumagga0x2a]

Yes, this setting disables B-frames. Did you ensure the resulting file had first frame PTS equal zero? This is achieved by re-saving in copy mode (re-encoding keeps the B-frame delay of the source).

You could try to remux the source files in copy mode to MKV* as there is a MP4-specific part in audio delay calculation.

2.7.5 is really unsupported, there were tons of fixes in all parts of the application involved since then. The reasons need to be identified and diagnosed else the next release (or rather 2.7.8 ) will carry on the issues which bother you but not me.

*) You really need at least 2.7.6 for that, fps calculation was incorrect in most cases in earlier versions.

[eumagga0x2a]

Just noticed that you use HEVC. In this case you should use the latest nightly in order to have this fix included and always remember to disable Open GOP when the result should be editable without damaged frames at cut points in copy mode.

[eumagga0x2a]

I have to return to the topic, especially to my claim

Loss of A/V sync for appended source videos when video stream contains B-frames is a known bug.

as it was reported a while ago (I wish I could find that topic...). I tried the following steps:

1. Load a H.264 video (30000/1001 fps) with B-frames and 2 frames B-frame delay (66 ms) and AAC audio track allowing very precise sync control

2. Append in onto itself, save in copy mode

3. Repeat step 1

4. Set audio delay to e.g. +500 ms (I tried both +500 and -500) and save the video in copy mode

5. Reset audio delay to zero

6. Repeat step 1

7. Append the result of step 4

8. Save in copy mode

Actual results: impeccable sync both in the first and in the second part in the output from step 2, the audio offset matches the configuration in the second part of the output after step 8 = works as it should.

What am I missing?