Display of frame number in Avidemux v2.6.x

[Bosanek]

Hello!

I have been using Avidemux v2.5.6 for a long time. One of big reasons why I still have not switched to Avidemux v2.6.x is that it does not display the current frame number in the opened video (it displays only the exact time within video).

I downloaded and tried Avidemux v2.6.8 yesterday, and I see that it still does not display the frame number. Avidemux v2.5.x has that as a standard feature (and it works just fine even for H.264 material).

Why isn't the frame number displayed in Avidemux v2.6.x? Please add that feature, as it is very important when doing slice-editing: cutting parts of the video, splitting, merging, etc. with lossless (direct stream copy) output.

[Ice]

I agree, this is a very important feature and makes adding fades and frame specific cuts in this program a serious pain.
Please add it back in the latest release! I would really appreciate to have frame accurate encoding...

The same as it was before the update, or at least a separate option to skip ahead to any frame in the video. Something similar to other programs (Virtualdub) etc.

[Jan Gruuthuse]

avidemux 2.6.* branch is time based.
avidemux 2.5.* branch is frame based.

[Ice]

2.6 has some important upgrades, but I suppose I can always just switch.

How can I run both without losing the other?

[Bosanek]

I have noticed two very important issues in Avidemux v2.6.8 (and probably in all earlier v2.6.x revisions):


ISSUE #1: Added frames
-------------------------------

1. I load an input MP4 file (with H264 video stream in it) into Avidemux v2.6.8;
2. I select a portion of the recording (both A and B markers are on GOP boundaries);
3. I set input audio to "none";
4. I select "Direct stream copy" for video;
5. I save that portion into an output MP4v1, MP4v2 or MKV file (output format does not matter);

6. I load the output file in Avidemux v2.5.3 and I notice that it has 3 extra frames at the end! In other words, the output file, which was made from the section which was made in step 2, has at its end the three next frames which followed the "B" marker (those frames are outside of the selected zone in the input file)!

I tested the scenario above with at least three input MP4 files. It is repeatable. If I do all of the above with Avidemux v2.5.3, it produces a valid output file (the file does not have any extra frames at the end when compared to the selected zone in the input file).

An exception to this is the case when the "B" marker is at the very end of the input file. In that case, the program behaves exactly like in issue #2 (read below).


ISSUE 2: Missing frames
------------------------------

1. I load an input MP4 file (with H264 video stream in it) into Avidemux v2.6.8;
2. I do NOT select any portions of the file (that means that the entire input file is "selected");
3. I set input audio to "none";
4. I select "Direct stream copy" for video;
5. I save the input file into an output MP4v1, MP4v2 or MKV file (output format does not matter);

6. I load the output file in Avidemux v2.5.3 and I notice that it is missing the last three frames from the  end of the input file!

If I do all this with Avidemux v2.5.3, it produces a valid output file (the output file is not missing any frames from the input file).

I have tested this with multiple input files, and the issues are repeatable.

[Jan Gruuthuse]

You missed the point: avidemux 2.6.* is not frame based editor and as such you don't have total control on the frames issue.
Very basic explanation (as user) 2.6.* uses virtual frames. As a result some represented frames are not usable as start for video cut. Or as end cut for video that needs joining a part after it.
If you find 2.5.3 works best for certain job, I would suggest using that one for these jobs.
I use from time to time  avidemux 2.5.6 alongside 2.6.8. Both are installed on my computer.

[AQUAR]

With Avidemux 2.6 the time reference against a frame is accurate for AVC streams.
With Avidemux 2.5 the time reference against a frame is not accurate for AVC streams.

The relationship between a frame time reference and its frame number is too complicated for AVC streams.
Hence not available in Avidemux 2.6 and probably inaccurate in Avidemux 2.5.

@Bosanek

I select a portion of the recording (both A and B markers are on GOP boundaries);

I tried your process, but I do not see any extra frames added from outside the selected GOP's.
Setting the A and B markers on Idr frames (by using avidemux I frame navigation) defines the selection:
starting with and including the Idr frame at A and ending upto but not including the Idr frame at B.
At least that is the result I got.

[AQUAR]

@ Bosanek
I did lose 3 frames as per issue 2 you mentioned.
We are also getting a .1 sec audio shift and maybe its related!

[Jan Gruuthuse]

How can I run both without losing the other?

They should install alongside, can only confirm this for linux.
2.5.x has avidemux2* names
2.6.x has avidemux3* names

[AQUAR]

That also applies to the windows versions.
I have 2.5.6 and 2.6.8 installer versions installed on the same system.
And, also on the same system are a few portable nightly revisions in separate folders.

You can run multiple instances of either/both at the same time without issues, except I would not recommend
recoding more than one media file at the same time.
 

[Bosanek]

@Jan Gruuthuse and @AQUAR:

I understand the design differences of Avidemux v2.5.x and v2.6.x regarding frame positioning.

However, the two issues which I described above are definitely real issues. One can view them from the frame perspective (as I do), but you can also view them from the time perspective if you want. The issues are real.

In the bare essence, Avidemux v2.6.8 omits or adds a bit of video material from/to the selected zone of input video when saving the zone through direct stream copy to an output file. You can view that bit as a couple of frames, or as a couple of (dozen) miliseconds.

In essence of issue #1, Avidemux v2.6.8 includes slightly more video material in the output file than it was selected by A-B zone. The added bit is the one after the B marker.
In essence of issue #2, Avidemux v2.6.8 excludes a bit of video material in the output file, compared to the selected A-B zone. The omitted bit is the one just before the B marker.

All A and B markers were set on "Intra frame" ("I-FRM") positions (positions which Avidemux goes to when using the UP and DOWN keyboard buttons). Therefore, there is absolutely no reason for Avidemux to omit or include more video around the I frame on which the B marker is set.

FYI: The input video files are from GroPro Hero 1, and also from Hero3+ Silver cameras.

P.S.:
@AQUAR:

I tried your process, but I do not see any extra frames added from outside the selected GOP's.
Setting the A and B markers on Idr frames (by using avidemux I frame navigation) defines the selection:
starting with and including the Idr frame at A and ending upto but not including the Idr frame at B.
At least that is the result I got.

Was the A marker at the very beginning of the file or somewhere in the middle (but before the B marker of course)? And was the B marker at the very end of the file or somewhere in the middle?

[Ice]

My only concern is the wish to add fades more easily, maybe a sort of dissolve feature?

I am splicing multiple clips together and having to add multiple fade in-outs is a bit tedious.

Any other alternatives?

[AQUAR]

@ Bosanek

Was the A marker at the very beginning of the file or somewhere in the middle (but before the B marker of course)? And was the B marker at the very end of the file or somewhere in the middle?

Selected segment is any random segment a few gops long.
Selected segment was chosen so that the end (B) was on a scene change so as to make it easy to see unwanted material.

A wild guess on Issue1:
Maybe the video has an open GOP structure - meaning virtual frames inside one GOP is referencing frames from adjacent GOPS.
Avidemux 2.6 is not in control of the frame ordering, so the decoder needs to pop out extras up to the referenced frame in the next GOP.
(else it cannot build the virtual frames in the selected GOP). Hence a few extra frames! 
As I said, that is just my wildest guess and probably totally wrong.   

And I agreed with Issue2:   

[Jan Gruuthuse]

My only concern is the wish to add fades more easily, maybe a sort of dissolve feature?

I am splicing multiple clips together and having to add multiple fade in-outs is a bit tedious.

Any other alternatives?

You should not hijack a posting, and created your own for discussion.
There is only the fade filter, applying fade filter involves re-encoding the complete clip/film.
I don't see alternative doing so.

[Jan Gruuthuse]

A wild guess on Issue1:
Maybe the video has an open GOP structure - meaning virtual frames inside one GOP is referencing frames from adjacent GOPS.
Avidemux 2.6 is not in control of the frame ordering, so the decoder needs to pop out extras up to the referenced frame in the next GOP.
(else it cannot build the virtual frames in the selected GOP). Hence a few extra frames! 
As I said, that is just my wildest guess and probably totally wrong.   

And I agreed with Issue2:

@AQUAR, Issue2 is related to Issue1. Virtual frames, relying on previous/future frames, ...

@Bosanek, If you want developer to look at your issues, provide developer with the camera(s) or the original footage produced with the camera.
You have to get out of the mind frame how avidemux should work according to you. Of course the easy way is to blame nasty bugs in avidemux.
Has nothing to do with the used OS, hardware, installed codecs or even user error, ....

Yeah and I've looked for original footage to download, 20 minutes or more. Could not find any, only stuff handled by vimeo or youtube and so no longer original recordings.
Oh and I could no longer find any reference to GoPro Hero 1 on the official GoPro website.

I've done enough ...