After 5th sept.: appending mp4 files may generate artefacts

[me444]

winx64, using the winx54 nightlies:

when appending some mp4 file slices, i encounter artefacts in the result file
(at the position where the pieces had been combined). The artefacts are visible nearly one second.

I saw that using the x64 nightly as of sept. 13.
Testing back, the version from sept 05 was still ok.

What did change?
Normally those vids are containg AVC / AAC.

[eumagga0x2a]

Please provide sample videos which result in the first intra of the second sample lost when appended.

What did change?

The way how a segment is created from a reference video, see [editor] Create a new segment with start time in ref = pts of the first frame + add padding when truncating video to keep the frame matching the A marker. Highly experimental, makes all videos "start at zero" from users' POV. The goal was to avoid writing ugly hacks to deal with very short segments without a single video frame in them.

[me444]

Hello eumagga0x2a,

thanks for your attention!

a) Searching around for some suitable test case, i now  created a simple one, but i cannot attach it here
   (attachment 192 kb  max, that is a real challenge). Any other way, pm/email etc.?

b) Would it be possible to option this experimental stuff out? I use ADM cutting and appending
   over a long time with basically none problems and maybe have no other chance
   than to the use the old version for an undetermined time, unless it gets really fixed.

[eumagga0x2a]

Please use WeTransfer or similar service and provide a link to the file(s). The video should not be sensitive or problematic anyway ;-)

Actually, nightly builds are for development purposes. I didn't encounter problems with my videos, so I went ahead for a field test. If issues get found and can't be solved reasonably soon within the current release cycle, ADM_ZERO_OFFSET gets flipped for the release (or the whole change gets reverted if problems turn out to be fundamental).

[me444]

Sounds good, but, hm, how to get aware when a decision was taken?
Should i better wait until the next release change (2.8?) ?

About the upload, here we go:
http://www.filedropper.com/testcase_1

[eumagga0x2a]

Thank you very much for the testcase, this is again a classical "DTS is going back" issue, the first intra is not lost at the appending step, it gets lost while saving in copy mode.

how to get aware when a decision was taken?

Follow https://github.com/mean00/avidemux2/commits/master.

Should i better wait until the next release change (2.8?) ?

The next one will be 2.7.1.

If you wait, bugs will make it happily into release. Thank you for testing nightlies.

[me444]

Yep, i'll keep close to it.
Appreciating your good work!

[eumagga0x2a]

The direct cause of the DTS collision leading to a dropped keyframe is an irregularity (duplicated or going back PTS) at the last frame of samples. I wonder, which program was used to generate the videos?

Saving each video separately in copy mode first, resulting in the frame with duplicate or going back PTS (there are no B-frames here!) being dropped, then appending the videos works around the issue for now.

[me444]

Thank you eumagga0x2a for the information!
Sources for the vids where i observed the behaviour are different. Also when having cutted the pieces
using ADM before. But, previously i was able to append them without problems.

So, it is fine for me to wait for a final solution, but hopefully it tolerates the missing B-frames and appends such vids just as before without additional restrictions.

[eumagga0x2a]

There are no B-frames missing. The last frame, which is a P-frame, has an invalid presentation timestamp, leading to a collision. You can always replicate the error with an older Avidemux build by deleting the chunk of video from the first frame of the appended video to the next intra and trying to save the result in copy mode.

Anyway, I've disabled the automatic creation of segments with start time in reference equal the first frame PTS (i.e. videos always looking as if they would start at zero). This will ensure that no DTS collisions are possible at the segment boundary with an appended video.

[me444]

Thanks again  eumagga0x2a, and sorry for my slight misunderstanding!
So i tried the nightly win x64 as of today (sept. 19th) and found that this indeed appears to fix the problem.
I have no longer so much (temporary) test files around, but checking the test case i did send you,
the result files are even bit identical to those generated with the version from sept. 05th.
Really great!