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
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
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?
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
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.
Quote from: Jan Gruuthuse on December 26, 2017, 09:45:27 AM
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.
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.
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
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 (https://github.com/mean00/avidemux2/commit/8340bab5031bc24c13c1f9a41cc682ea034d41fb). This doesn't touch the issue with last frames not decoded and thus missing when the video is reencoded.
Thank you for your report.
confirmed, saves now up to the frame 1997 (01:01:19:22)
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.
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
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.
Quote from: Jan Gruuthuse on December 27, 2017, 10:20:21 AM
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.
Quote from: Jan Gruuthuse on December 27, 2017, 10:20:21 AM
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.
It was perfectly fine to start with zero – this is also the way frames are numbered in Avidemux. Meanwhile nightlies containing the fix have been uploaded, you should use them rather than the 2.7.0 release which is really getting long in the tooth.
The issue with last (nb * ref) frames not shown is much more complicated and would likely take more time to fix.
I was wondering how Avidemux handled frames because when I load the sample video, the time indicator in Avidemux shows 80ms/2 frames, even though the viewer displays the first frame. So the timer in this version, when working in 25fps is 80ms/2 frames out. According to the time indicator I should be seeing the 3rd frame in the viewer. The timing display error goes right to the end of the video.
Do you have a link to the nightly you would recomend, I have only used the general release versions up to now. I think I have another issue that I would like opinions on, also concerning a 2 frame discrepancy but I will have to find a way of presenting it to make it as easy to explain as I can. Maybe the latest version will have already fixed it.
http://avidemux.org/nightly/ last is 27 December 2017 win-32 or -64 bit
Quote from: fish on December 29, 2017, 01:17:22 PM
I was wondering how Avidemux handled frames because when I load the sample video, the time indicator in Avidemux shows 80ms/2 frames, even though the viewer displays the first frame. So the timer in this version, when working in 25fps is 80ms/2 frames out. According to the time indicator I should be seeing the 3rd frame in the viewer. The timing display error goes right to the end of the video.
This is not an error. Due to the presence of B-frames the PTS (presentation time stamp) of the first frame is not zero. Avidemux uses uint64_t as data type for PTS and DTS (decode time stamp). It can't go negative. To display the second frame which is a B-frame, the decoder must have decoded 2 frames (nb of ref frames = 2) beforehand.
Some other players use signed long long as data type for time stamps, so DTS can go negative, allowing PTS of the first frame becoming zero despite B-frames in the video.
Thanks for the link. The explanation mostly went straight over my head but from a pragmatic point of view, it's good to know that the timer is working as intended.
Quote from: eumagga0x2a on December 27, 2017, 08:46:54 PM
The issue with last (nb * ref) frames not shown is much more complicated and would likely take more time to fix.
Done (https://github.com/mean00/avidemux2/commit/ade4b2647f5af3886b091feadbd2eecd625250f4), but please wait for nightlies built on Jan. 6 and later. Builds from Jan. 5 are missing a patch (https://github.com/mean00/avidemux2/commit/f307817128595bced7406ab91f62ac40e49073b4) which restores the ability to load images without an already loaded video.