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

Started by me444, September 14, 2017, 10:40:34 AM

Previous topic - Next topic

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.

Quote from: me444 on September 14, 2017, 10:40:34 AM
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.

Quote from: me444 on September 14, 2017, 02:21:16 PM
how to get aware when a decision was taken?

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

QuoteShould 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


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!