Avidemux 2.6.10: wrong start keyframe when saving selection

[ericzutter]

Steps to reproduce the problem :
1. Download video http://www.mp4point.com/downloads/4fc4391f33c9.mp4 (size = 12 MB, MP4 file with codecs AVC+AAC)
2. Start Avidemux 2.6.10 64 bits on Windows 7
3. Open video 4fc4391f33c9.mp4
4. Video Ouput and Audio Output contains the default value "Copy"
5. Choose MP4 Muxer as output format
6. Click 9x times on button "double right arrow" (= next keyframe)
7. Click on button "A" (= begin part of selection)
8. Set the end part of the selection not on a keyframe
9. Save the video
10. Play the video with a videoplayer (example: Media Player Classic)
11. The first keyframe of the selection is not the same as the first keyframe of the saved video. When saving a selection some keyframes are ignored.

Avidemux 2.6.8v2 64 bits on Windows 7 doesn't have this problem.

[Jan Gruuthuse]

Issue confirmed on Ubuntu 14.04.3 (amd-64)
Seems to be starting @ I-FRM 15.015 (previous I-FRM) instead of 17.017.

Other observation: on I-FRM 17.017
- select next keyframe (KB 'up arrow' or click "double right arrow") = I-FRM 19.019
- select previous keyframe (KB 'down arrow' or click "double left arrow")
-- avidemux jumps back 2 I-FRM 's @ 15.015 instead of 1 I-FRM @ 17.017

same issue with mp4v2 and mkv.
creating with Mpeg TS Muxer creates no playable video content, only audio plays.

[Jan Gruuthuse]

more observations:
re-encoding the same fragment with Mpeg4 AVC seems to producing the correct content (@ first sight) in any of above mentioned containers.
Perhaps something non conventional in that kind/type of video? Video source Web based origin?

[mean]

It might be it rewinds to the previous IDR

[eric10301]

Wow, now that the forum is open for registration I can finally add to this bug thread. Every since 2.6.9, avidemux has been unreliable using the copy function and selecting key frames. I just tested 2.6.11 and the bug is alive and well.

[AQUAR]

Have a look at this explanation about AVC special I frames (called IDR frames).
http://www.streaminglearningcenter.com/articles/everything-you-ever-wanted-to-know-about-idr-frames-but-were-afraid-to-ask.html

Mean is saying that ADM is rewinding from the I-FRM cut point to the preceding IDR frame.
I suppose that starting a copy at a non IDR type I-FRM, might cause decoding issues for the first few frames in the copy result (orphan references to reconstruct some "virtual frame").

If so ADM is actually safeguarding your copy process.
Maybe Mean can elaborate a little bit more for us Noobs.

[eric10301]

Have a look at this explanation about AVC special I frames (called IDR frames).
http://www.streaminglearningcenter.com/articles/everything-you-ever-wanted-to-know-about-idr-frames-but-were-afraid-to-ask.html

Mean is saying that ADM is rewinding from the I-FRM cut point to the preceding IDR frame.
I suppose that starting a copy at a non IDR type I-FRM, might cause decoding issues for the first few frames in the copy result (orphan references to reconstruct some "virtual frame").

If so ADM is actually safeguarding your copy process.
Maybe Mean can elaborate a little bit more for us Noobs.

Good read, I'm by no means an expert in any of this but in my test with 2.6.9+ I've had it shift back from what was almost certainly an IDR I-Frame to a previous I-Frame that was almost certainly not an IDR I-Frame. Like for instance, I would assume when a movie cuts from one scene to completely different one, it begins with an IDR I-Frame. Now, if you have one long scene that is say, 10 seconds without any sort of shift in perspective/cuts, there may be be a couple standard I-Frames in the middle without them being IDR Frame because there is no need to completely refresh the picture. Assuming this is correct, AVD is in fact ignoring the selected IDR I-frame, for whatever reason, and going back to a standard I-Frame.

[AQUAR]

The problem is exactly that - most of us end users are not expert in the complexities involved with codecs, containers and video editing.
I understand your logic and the perfectly reasonable assertion that emanates from that.
But there is probably a whole lot of other complicated things involved at the selected cut point in an editing program like ADM.
On an end users forum you rarely get technical details of "why it might be so" (answers tend to just lead to more questions!).

Note: I understand that I frames are complete frames that do not require bits from other frames - virtual frames before and after can reference them. Your interpretation suggests that they are incomplete frames, viz "because there is no need to completely refresh the picture" - that seems wrong to me).

If mean (the author) has the time and inclination, he might give some more insight or confirm there is an issue.
Otherwise we have to be happy with the status quo in ADM behaviour and any explanation given for it. 

Anyway, its good to point out these observations in case ADM can be improved.

[mean]

Fixed, it was a bad copy paste in the keyframe searching code
Win64 build in progress (~ 15mn)

[AQUAR]

Thanks Mean for the feedback.

The open registration has breathed a bit of new life in the forum.

[eric10301]

Fixed, it was a bad copy paste in the keyframe searching code
Win64 build in progress (~ 15mn)

Thanks!

[eric10301]

I tried the 01-13 nightly build and it worked on a cut that had previously failed but then I tried it on another cut, it did not cut on the correct I-Frame.