Missing frames at end of video.

[fish]

I was noticing that when I removed frames at the start of a video clip, I then lost 6 frames from the end. If I removed frames from the middle of the same clip I lost no frames on the end. So to make it easy to test what I was seeing, I created a 2000 frame video slug encoded with a standard preset in Handbrake (Super HQ 1080p changed to 25fps constant).
Sure enough it is pretty obvious, when I go to the I Frame 500 and remove those first 500 frames in copy mode, I lose 6 frames from the end of the video. If I remove frames from the middle 750 to 1250, I lose no frames from the end. That is exactly what I have seen in video from various sources. I will post a link and others can confirm or not the behaviour.

https://we.tl/eCDVD4F7V7

[Jan Gruuthuse]

You did not tell what version of avidemux you use?
2.6.xx or 2.7.0 and the commit? if nightly, see Avidemux Menu: Help: About
like:
Avidemux v2.7.0
(171226_33c75a20c29-fflibs 3.3.5)

Avidemux 2.7.0 commit 33c75a2

[fish]

I'm using v2.7.0, the last general billed release and Win7 64bit sp1, not any of the nightly releases. Either way what you will see, will either be what I see or not, regardless of which version. Have you tried it on your version, it is a very basic one or two edit comparison?

[Jan Gruuthuse]

There could be an issue with the test video? it does not end on I-FRM (02).
- The last I-FRM (02) frame is 1750 (00:01:10.080) avidemux time index
- The video ends on frame 1997 (00:01.19.960) avidemux time index

after cutting the 1st 500 and saved the remaining video with mp4 muxer the
- video ends at B-FRM (02) frame 1991 (01:01:19:16) frame time index in copy mode
- video ends at P-FRM (02) frame 1997 (01:01:19:22) frame time index in Nvidia H264
- video ends at B-FRM (02) frame 1995 (01:01:19.20) frame time index in mpeg4 AVC (x264)

Lets see what the developer(s) findings/conclusions are.

end result of tests:
re-encoded
- x264
- h264 (HW Accel)

1 file 1st500FrameCut.zip, 12.3 MB in total ・ Will be deleted on 2 January, 2018
Download link https://we.tl/YlMsZhmiE5

tested with avidemux 2.7.0 171226-64bit commit 33c75a2 on ubuntu HWE 16.04.3 LTS 64 bit

[eumagga0x2a]

Confirmed in general (less frames get lost depending on the position of the B marker when deleting from the start of the video, also this might me somewhat demuxer related), additionally the last 3 (at least 2) frames cannot be decoded in Avidemux, so they get lost when the video is reencoded. Thank you for the excellent sample.

I can think of the presence of B-frames as the key reason why this happens. Avidemux has to delay the PTS of the first I-frame in this case (the delay is equal nb ref frames * frame increment). When deleting from the start, the first I-frame of the remaining video gets PTS equal zero. This gets corrected on saving video, but probably the total duration doesn't get bumped to account for that.

When deleting a chunk from the middle of the video, the PTS of the first frame is not touched, so no frames (or almost no frames) get lost due to insufficient total duration.

[fish]

There could be an issue with the test video? it does not end on I-FRM (02).
- The last I-FRM (02) frame is 1750 (00:01:10.080) avidemux time index
- The video ends on frame 1997 (00:01.19.960) avidemux time index

I did think I was being a little unkind posting a video with I frames at frames 0,250,...1750 and of course the next one would have been 2000. I simply spat the DNxHD clip out of Media Composer and chose a standard preset from Handbrake. As that preset appears to produce GOP's of 250 I will make another video with an extra frame or a longer test file. They are very simple to make and give a clear and obvious indication of what is happening frame wise. I'm guessing the missing 6 frames are something to do with p and b frames. The audio was included simply to produce as typical a file as possible.
I will post a longer file later with an I frame ending and another without an I Frame ending for comparison. If you have any ideas for what settings to use for an ideal test file please make a suggestion, they are quite small files.

[eumagga0x2a]

The sample is good enough, nothing more needed. It is pretty clear what is going on here. No time estimate for the fix possible though.

[fish]

Just to tidy things up, here is a file of 3001 frames encoded with the same settings but of course the extra frame becomes an I Frame. Using the same edits, removing the first 500 to the I Frame now loses just 2 frames on the end, instead of 6 and Avidemux will display all the frames to the end. It's just something to be wary of and maybe requires a tail of frames to be left on specific edits of certain files.

https://we.tl/MOPndKfyvi

[eumagga0x2a]

Should be fixed for copy mode by [streamCopy] Bump video duration if we delay the first frame so that last frames don't fall off the cliff. This doesn't touch the issue with last frames not decoded and thus missing when the video is reencoded.

Thank you for your report.

[Jan Gruuthuse]

confirmed, saves now up to the frame 1997 (01:01:19:22)

[eumagga0x2a]

Did you check it with Avidemux? Then you see the other bug (Avidemux fails to decode the last 2 or maybe 3 frames). You should use something like mpv which doesn't suffer from this problem instead.

On my system, mpv shows 1999 as the last frame.

[Jan Gruuthuse]

Yes, VLC plays up to frame 1999.

Loaded into avidemux
- it only shows frame 1997
- bottom left: [ Time:] [00:00:59:960] / 00:01:00.041

tested with avidemux 2.7.0 171227-64bit commit 8340bab on ubuntu HWE 16.04.3 LTS 64 bit

[Jan Gruuthuse]

It is not a common error made when using counters: We count 1 to 10, computer logic counts 0 to 9?
Hard to find these mistakes, especially when combined with indexed matrix.
Could be a reason: calculation error of frames left to play. time index does show there is something beyond last frame showed.

[eumagga0x2a]

It is not a<n un>common error made when using counters: We count 1 to 10, computer logic counts 0 to 9?

That is true, the frame showing 1999 is actually frame #2000 and really the last one.

We have 2 ref frames in this h264 video, so the decoder delay is 2 frames. It looks like Avidemux doesn't try to retrieve the last decoded frames from the decoder, it stops once the demuxer sends the last compressed frame. Due to the decoder delay, we've got 1999-2=1997 out of the decoder at this moment.

[fish]

It is not a common error made when using counters: We count 1 to 10, computer logic counts 0 to 9?
Hard to find these mistakes, especially when combined with indexed matrix.
Could be a reason: calculation error of frames left to play. time index does show there is something beyond last frame showed.

I could start the count at 1 if it is causing confusion, First frame as 0 is the way digital video is timed, based on the fact that in an NLE the frame being displayed in the record viewer is to the right of the play head on the timeline. So obviously when 0 time has elapsed the play head is at 0 and the first frame is being displayed, when in this case 1/25 sec has elapsed the second frame is displayed and so on.