v2.7.3 Cutting on non-keyframe leads to incomplete video

[Bugfragged]

While encoding with x264, I cut my video on non-keyframes and tried to save the video, but it only a portion of the footage. I noticed that the incomplete video ends on one of the cut areas, on a B-frame.

[eumagga0x2a]

Have you tried with the latest nightly? Is the issue specific to a particular file? The codec should not matter, it should be enough to play the video after the cuts.

If the issue persists, please compress and attach the admlog.txt from the session when you reproduced it.

[Bugfragged]

I reproduced this bug on the 190421 nightly build. It turns out I was wrong about which frame I'm supposed to cut to reproduce this bug. This time, I cut starting on a P-frame and ending on an I-frame, and this resulted in the saved video being 8 seconds (where I cut the P-frame) rather than 15 like it should be.

[eumagga0x2a]

The encoding stops because the decoding of the source video fails after the switch to the second segment, something I can't reproduce with a random DXVA2-decodable video on my Windows 10 system with the latest nightly with cut points as specified after deleting a portion starting with a P-frame and ending at an I-frame.

This must be specific to this particular source video and/or HW accelerated decoding using DXVA2. Does decoding succeed when you disable HW accelerated decoding? Would it be possible for you to provide it as a sample? Only if it is innocuous enough, of course.

[Bugfragged]

Disabling DXVA2 decoding allowed the video to save properly this time, even when cutting from P-frame to I-framE. Thanks.

Here's the link to the video that I tested on, before cutting: https://drive.google.com/file/d/18CwUjarNvENkEHpuLTSCHShgyi7dODBY/view?usp=sharing

[eumagga0x2a]

Thank you, I can reproduce with DXVA2 enabled using the specified marker A position. The location of marker B doesn't matter, it is also completely unrelated to x264 as encoder.

Choosing a different frame as the start of the deletion allows decoding to succeed. At the first glance, this looks like a highly specific failure within the bundled ffmpeg.

[eumagga0x2a]

I've managed to reproduce the issue with another sample. Again, this happens only with deletion starting at few chosen positions which don't seem to be special in any way.

Will try to look into it.

[eumagga0x2a]

Please try the latest nightly (190422 or later) from https://avidemux.org/nightly/vsWin64/ (VC++ builds) or from https://avidemux.org/nightly/win64/ (MinGW builds). It contains a simple quick & dirty change which should make such situations when we run out of free buffers resulting in decoding failure much less frequent. It is not a full waterproof solution, unfortunately.

[Bugfragged]

On nightly build 190422, I got the number of free buffers to run out by cutting the video multiple times in a way that results in 8 consecutive b-frames, thus causing the video to saved too short. Less than 8 consecutive b-frames still works and doesn't cause the free buffers to run out.

The linked video was originally recorded so that there are at most two consecutive b-frames, and the log from yesterday (build 190421) was when I cut in a way that resulted in 4 consecutive b-frames.

[eumagga0x2a]

Yeah, it was not exactly unexpected. Not sure ATM whether simply increasing the number of allocated buffers ("surfaces") would scale.

[eumagga0x2a]

The changeset [editor/cache] Recycle buffers for HW accelerated decoding on cache flush might help to solve the problem, hopefully without adverse effects. Please try a future nightly.

[eumagga0x2a]

Please try the 190427 VC++ nightly: https://avidemux.org/nightly/vsWin64/

[Bugfragged]

It succeeds with 8 and 10 consecutive b-frames, but fails on 12 consecutive b-frames.

[eumagga0x2a]

While I believe that this is good enough, could you please provide a new project script to facilitate the reproducibility? I assume you used the same sample as before, right?

[Bugfragged]

Here's the project script for getting 12 consecutive b-frames.