Display of frame number in Avidemux v2.6.x

[AQUAR]

With issue 2, I simply tested by copying/remuxing everything (ie without setting the A and B markers).
No decoding takes place in a "simple " remux, referencing is not taking place and hence you would expect all the frames to be there.

But in doing so the last 3 frames are missing (ie approx .1 sec).
Perhaps its co-incidental that audio is also shifted by approx .1 sec (as mentioned previously by zak).

With issue 1, you also are doing a "simple" remux if doing Iframe to Iframe with closed GOPs.
And cutting at any other frame type we know gives orphaned frames (unless recoding of course).
But what happens when cutting segments at GOP boundaries when these are open GOP (do we get extra frames!)?
AVC also has Idr frames and cutting on those should be fine (it's what avidemux does).

Anyway, it was just a bit of curious postulating at enduser level.
And in the scheme of things these are just tiny "flaws" IMHO.

[Jan Gruuthuse]

It is more complex:

IDR-frames

IDR frames are: An IDR frame is what has been traditionally known as an I frame. An IDR frame, just like an I frame in MPEG-1/2 and MPEG-4 ASP, starts with a clean slate, and all subsequent frames will make reference to the IDR frame and subsequent frames. Non IDR I frames should be rare, but since they cannot be ruled out, enforcing a minimal IDR interval can help improve compression in some high motion scenes. In H.264/AVC you can also have I frames inside a GOP, which are not seekable, since the long time references introduced in H.264/AVC could result in a P frame after the I frame to reference a P frame before the I frame.

Max IDR-keyframe interval indicates the maximum distance between two IDR frames. Similarly, Min IDR-keyframe interval indicates the minimum distance between two IDR frames.

notice the bolded intriguing part.

source:
http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264#idr-frames
additional frame info: http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264#frame

[AQUAR]

Thats for sure.
Luckily avidemux seeks only to the Idr frames if the video is compressed with AVC (with I frame navigation!).

The OP did mention putting the B marker on an I frame but probably meant Idr frame.
Hence the nature of the response.

[Bosanek]

I am glad to see that you people have really made interest in these issues. Yes, I was always referring to IDR frames (I suppose that those are the frames that Avidemux always jumps to when using UP and DOWN keys on the keyboard?).

I would be more than happy to provide you with any source video materials which you need. We could share them through Dropbox maybe?

I have some source videos from my Gopro Hero 1 camera (fixed GOP length at 60 frames, around 8 Mb/s), and from my GoPro Hero 3+ Silver camera (fixed GOP length at 32 frames, around 14 Mb/s).

Just say which footage you want, and of what length.

[Bosanek]

Here are two source files from GoPro Hero 1 camera:

https://dl.dropboxusercontent.com/u/45323798/Test1.mp4
https://dl.dropboxusercontent.com/u/45323798/Test2.mp4

Since I have no short/small files directly from the camera (all footage is at least several minutes long), i loaded one of those original camera files in Avidemux v2.5.3, made two relatively short "A-B" selections on GOP boundaries (by UP and DOWN keyboard keys), and saved each selection as one of these two test MP4 files. Processing was "direct stream copy", of course.

[AQUAR]

@ Bosanek

I think your observations (issue 1 and issue 2) are probably the result of the complexity involved in editing h.264 streams and comparing results using two different editing approaches (avidemux 2.5 and 2.6).
That doesn't mean you observation of extra frames is incorrect. But as to the why and significance of them, that is a ?.

Most avidemux endusers don't have an in depth understanding of these aspects.
Probably only Mean (the developer of avidemux)  knows h.264 and his creations with that level of expertise.

I suspect the why is too complex and of little interest but a few endusers.
Significance might be addressed?

Did DL the Test1.pm4 just out of curiousity and do have two "NOOB" observations:
First thing to note was that the video doesn't start at an Idr frame (so avidemux 2.5 has an AVC problem cutting on Idr frames?).
Second is that Mediainfo shows M=3 N=15 for GOP formatting, but the interval between Idr frames is 60 for this video.

I think that means its a long GOP - probably open GOP and has refresher I frames (seen as P frames!) in between.
So - extra editing complications with an already difficult to edit compressed format.

It would be nice to know if these extra frames are the result of the avidemux "time based" model wrt:
a) some H.264 strategies used and b) are they an unwanted side effect or are they neccesary for proper decoding of all frames up to the end of the video.

[Jan Gruuthuse]

You can avoid these small issues if you don't use stream copy for video, but re encode the video. Selecting markers [ A] [B ] is not required with up/down arrow keys in this case. And you have some more control of the edit. Disadvantage: time consuming as this process is quite slow, average 150 fps instead of 1800 fps for SD video. Depending available processing power cpu/gpu.

[AQUAR]

I kind off have the opposite view viz, these issues are too small to consider taking the recoding route.

On balance:
Some cutting limitations, maybe a few extra/fewer frames and a fast result.
Versus.
Recoding lossy compression with inevitable quality loss, frame accurate cutting and slow result.

If you have to recode to another compression standard anyway then the choice is already made.

I think lots of people on this forum report issues with too much drama, and have unreachable expectations.
It's the same on other forums I participate in.