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.
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.
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.
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.
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
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.
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.
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.
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.
Yeah, it was not exactly unexpected. Not sure ATM whether simply increasing the number of allocated buffers ("surfaces") would scale.
The changeset [editor/cache] Recycle buffers for HW accelerated decoding on cache flush (https://github.com/mean00/avidemux2/commit/bfc0a04ac738763a661b331181dd25054dd7efe7) might help to solve the problem, hopefully without adverse effects. Please try a future nightly.
Please try the 190427 VC++ nightly: https://avidemux.org/nightly/vsWin64/
It succeeds with 8 and 10 consecutive b-frames, but fails on 12 consecutive b-frames.
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?
Here's the project script for getting 12 consecutive b-frames.
Thank you.
It is not required to pile up B-frames in order to deplete the pool of free surfaces with DXVA2. Just set the A marker to an I-frame != the first frame of the video, go to a later I-frame and framestep N times (N>24) while staying within the same GOP (i.e. the GOP length should be sufficient), set the B marker there and delete the selection. Rewind to a position before the start of the deletion and try to play the video. The playback stops at the cut point.
Evaluating options for a fix.
For now, the decoding failure should not happen anymore as I've drowned it in resources, allocating up to 40 buffers/surfaces to hold decoded frames. This might result in a failure to use HW accelerated decoding on old PCs with integrated graphics as loading a 1080p video would require ~150 MiB of video memory, going up to ~700 MiB for 4k content.
Please try the 190502 VC++ nightly.
Build 190502 works both on my script and in the situation you described in Reply #16.
Good, I tested the relevant patches with really nasty samples (720p H.264 with 16 ref frames and 16 consecutive B-frames, with the end of a deletion more than 60 frames past a keyframe, other samples 1080p HEVC and 2160p H.264) too. All worked so far on my system with Intel integrated graphics, but it had a plenty of shared memory available.
By the way, why do you use an non-accelerated video output (Qt) while DXVA2 is available? Using DXVA2 output should considerably reduce system load. Is there a problem with this video ouput with your setup?
Which setting in Preferences is this? Is it in the Display tab? I don't remember touching this setting.
Yes, "Display" tab --> Video display: [DXVA2]