v2.6 Ignoring the [A marker

[Ceyarrecks]

Excuse me Please:

I am having difficulty with the v2.6 of Avidemux on a win7pro64 system.
I am attempting to pull "commercials" off of a .mp4 file, I set A to time 00:00:12.800 to get rid of the preceding bits, then at 00:06:02.333, just before the next annoyance.
While the Save As works fine, and creates a smaller file (which I guess I will be appending all of the upcoming edits back into one file) I find that the first part of the original file remains, as though A may have been set, but was ignored and started at 00:00.

Does this make sense?
Or did I miss some crucial, albeit non-intuitive detail(s)?

if I may ask, is there a step by step guide (which I have yet to be able to find) that details how I can slice up a video for only the parts desired, discarding the rest?

Thank you kindly for the assistance.
CAH

[Jan Gruuthuse]

avidemux small how to videos
check this video: Fast Edit with Copy Mode

[Ceyarrecks]

ah!
so if I understand, what lies between A & B is what is being removed.
which would also allow for the removal of leading commercials that start at 00:00, is my understanding correct?

[eumagga0x2a]

Leaving A at zero, setting B at the first keyframe after the end of the leading commercials and hitting "Del" should work (try this first), but might fail to produce a cleanly playable video due to a not yet understood bug, which results in the first keyframe after the cut being lost. To avoid this, set the marker A to the first keyframe of the video instead, which is often not equal zero.

I assume you use at least the latest release 2.6.15.

[Ceyarrecks]

yes, being recently downloaded and installed, v2.6.15 is resident.
Thank you for the assistance.

[Ceyarrecks]

...the first keyframe of the video instead...

So I may thoroughly understand, what exactly is the first keyframe?

and yeah, found that bug, when after the deletion of A-B, the time slider resets itself to the 00:00 second. (any way to leave it at its last position until after the recompiling of the whole?)

[eumagga0x2a]

...the first keyframe of the video instead...

So I may thoroughly understand, what exactly is the first keyframe?

Well, it is just what it is called ââ,¬â€œ the first complete picture, the one which doesn't need any other frames to be decoded. Subsequent frames until the next keyframe contain only differential information which can't be decoded correctly without the information contained in the first keyframe. A keyframe means also that no later frame may reference anything before this keyframe.

If a video doesn't start with a keyframe, the first GOP (group of pictures), which may last depending on codec from ~0.5s to 20s and longer, can't be decoded. Some video players will skip this broken GOP, some will choke on it, some will display garbage till the next keyframe.

and yeah, found that bug, when after the deletion of A-B, the time slider resets itself to the 00:00 second.

No, this is not a bug at all and not the bug I was talking about. The bug is that the keyframe at B gets lost sometimes if A was left at zero.

(any way to leave it at its last position until after the recompiling of the whole?)

The slider will retain its last position if you move it after the A-B span prior to deleting.

[Ceyarrecks]

thank you again for the input.
I found less problems by letting A start at 00:00.33, though sometimes, on deletions later in the video, Avidemux would seem to rewind the time slider to 00:00, then issue a few errors and crash with the OK button; however, relaunching Avidemux would acknowledge the crash and offer to recover, doing so allowed me to successfully edit the rest of the vid.
Had to save as .mkv as opposed to maintaining the original .mp4, but MPC-HC plays them just as well, so all is good, as I was able to get rid of the annoying "commercials"

[eumagga0x2a]

If you haven't deleted the source video yet and are able to reproduce the crash, would you please attach a compressed admlog.txt (Avidemux log file) from the session that led to the crash?

If the audio codec is not AAC but anything else like AC3, you can't use the MP4 muxer. The choice is either MP4v2 for mp3/ac3 or MKV for almost everything.

[fish]

Leaving A at zero, setting B at the first keyframe after the end of the leading commercials and hitting "Del" should work (try this first), but might fail to produce a cleanly playable video due to a not yet understood bug, which results in the first keyframe after the cut being lost. To avoid this, set the marker A to the first keyframe of the video instead, which is often not equal zero.

I assume you use at least the latest release 2.6.15.

Thank goodness someone has finally stated this is a bug, I have experienced sections of black video from the first I-Frame to the second I-Frame, where the video then begins playing. There is also a case (which may or may not be regarded as nit picking  ) with DVB-T HD where, as far as I can see, moving to an I-Frame, goes to a frame two frames after the real I-Frame. This can easily be seen by moving to an I-Frame closest to a scene change, then moving three frames back and the scene will then change. It could maybe be argued that maybe the I-frame is sometimes not on the scene change but I think in that case, it is impossible that every I-Frame would be exactly two frames after a scene change, every time.
I have also noticed that some mp4's previously edited a while ago with Avidemux, now play as all black. A quick fix I have found is to import them into 'Machete'
and export them without any changes. This is not a quick plug for 'Machete by the way, it is a much less responsive editor than Avidemux and will drive you mad because of this, if you have already used Avidemux. It does fix this annoying problem though.
I have yet to try Avidemux v2.6.16 and as the changes include, "Fixed keyframe detection",  this may be already old news as I type.

[Jan Gruuthuse]

No one yet, uploaded a source video (1 minute/ 50 - 100 MB) with this behaviour! Developer(s) need to be able to reproduce this event!

... but might fail to produce a cleanly playable video due to a not yet understood bug, which results in the first keyframe after the cut being lost. ...

ps.:Upload use a free dropbox account, https://www.wetransfer.com/, mega or similar webservice (free public access, without registration to download your uploaded video) thank you.

[eumagga0x2a]

Is the DVB recoding with keyframe misdetection interlaced? If yes, this is an unrelated, known issue though.

[fish]

There is a complication that I have noticed with DVB-T HD in that MBAFF encoding is quite often used, which as you may know uses both progressive and interlaced blocks in the same frame. I don't know whether this would be classed as interlaced/progressive or whether there is a third classification which might cause a problem for editors. I will check on the field type in future, to see if it affects the output, as it seems to vary according to the type of content being broadcast. Movies are usually progressive but most native and live content now broadcast by 1080p terrestrial HD channels uses MBAFF encoding.
The mp4's the play as black are all progressive.

[fish]

I did a few tests to clear up a query earlier in this thread. A few years ago, when editing DVB-T HD files wjth Avidemux, moving to I-Frames put the play head right on a scene change. Recently moving to an I-Frame in DVB-T HD files now puts the play head two frames further on.
So to check whether my memory was on the blink, I first installed Avidemux v2.6.8 and edited some recent DVB-T HD files. I found that Avidemux v2.6.8 behaved exactly like Avidemux v2.6.18. I then tried some old DVB-T HD files from 3 years ago. They edited as I remembered, ie moving to I-Frames put the play head right on a scene change using both Avidemux versions.
Conclusion, I'm not going senile yet but it is not Avidemux that has caused the change. So it is either the hardware I'm using, the related software or the broadcast files have changed (not likely).
I think I need some new hardware, this old USB stick was intended for use with a laptop.

[rojavid]

...the first keyframe of the video instead...

So I may thoroughly understand, what exactly is the first keyframe?

Well, it is just what it is called ââ,¬â€œ the first complete picture, the one which doesn't need any other frames to be decoded. Subsequent frames until the next keyframe contain only differential information which can't be decoded correctly without the information contained in the first keyframe. A keyframe means also that no later frame may reference anything before this keyframe.

If a video doesn't start with a keyframe, the first GOP (group of pictures), which may last depending on codec from ~0.5s to 20s and longer, can't be decoded. Some video players will skip this broken GOP, some will choke on it, some will display garbage till the next keyframe.

Thanks - till now I had no idea that was the functionality of a keyframe - thought it was just a marker and was wondering why AviDemux would not let us edit between two keyframes and say it may be corrupt.

But then again, I noticed that in many videos, there are significantly different scenes in the intra frames - but I am forced to cut on keyframes by the editor.