File append broken? win64 build 272

[me444]

It appears that File Append (Ctrl-A)  does no longer work with with win64 build 272 Oct 12.
Adding file1 + file2 + .....  results in file1.
Builld 270 from Oct 7 was still ok.
Seen with MP4 files.

[eumagga0x2a]

I haven't seen any issues when appending videos using builds from the current git at least on Linux. Please attach the admlog.txt originating from a failed attempt to append a video. If the file is too big to attach, compress it first.

There was a small change affecting the behaviour of the GUI when appending between the two nightly builds, but it shouldn't have any negative effect on anything.

[me444]

It should very easy to reproduce on win64 OS using ADM win64 build 272 vs. build 270:
take 2 maybe very smoll MP4 files you can successfully append with build 270 and try the same with build 272.
(the 2 files mentioned here were generated by two cut operations on the same source file).

[eumagga0x2a]

I repeat: please attach admlog.txt. edit: you may search-and-replace any personally identifiable strings in the file prior to attaching it.

[me444]

Ok,  admlog attached

[eumagga0x2a]

Thanks, do you experience any problems with videos consisting of more than just one single GOP? Avidemux can't decode the first 70(!) frames of the appended video, then fails to find a keyframe

Code Select Expand

[seektoTime] Cannot identify the keyframe before 4729 ms

where

Code Select Expand

[seektoTime] Cannot identify the keyframe before 4294967 ms

looks rather strange (~72 minutes).

Are you able to play the full video you are trying to append in Avidemux?

[me444]

Thank you eumagga0x2a for attention!
Sorry to say, i'm only a user and not an expert, so i'm not fully qualified to speak in your terms (GOP ...).
The only i'm sure about is that until oct 7 i could play and do append operations without any problems (none!),
and of course the appended result vids could be played within ADM fine.
I got aware that the last days there happened changes about problems related to clipboard appends,
and i strongly feel that the prob mentioned is related to that.
I would vote that file appends should not be affected by those changes. The previous behaviour was really good,
and now it does not work anymore for me  (did a couple of tests for to verify with several files; via File menu or via Ctrl-A keystroke)
My proposal really would be that you verify that on you win64 box.

[eumagga0x2a]

GOP = group of pictures, a full picture (keyframe) followed by frames which contain mostly changes and cannot be correctly decoded without the first full picture. In h264 the default interval between keyframes is 250 (10 seconds at 25fps), this is why testing with h264 videos shorter than half a minute is rather pointless.

Please provide admlog.txt from a previous nightly build with exactly the same samples and try the current build with other, longer samples. Bugs fixed in editor were quite bad

Appending videos works for me without a hitch, albeit I never tested with samples that short.

My proposal really would be that you verify that on you win64 box.

There is nothing specific to Windows in the issue you describe, but it might help if you provide the samples.

[me444]

Ok, attached the log when using the version from oct 7 on the same test files.

Indeed, it may be the case that somehow file portions to be appended are not so large, in the test case 2,8 MB and 3,5 MB
(normally the files are much more bigger).
But please don't tell me that is is not ok from now on, I'm using ADM since years without any real problems.
But not to be able to process smaller file portions further on would be a real usage killer for me! Please do not!

[eumagga0x2a]

You might have forgotten to add the attachment.

Indeed, it may be the case that somehow file portions to be appended are not so large, in the test case 2,8 MB and 3,5 MB
(normally the files are much more bigger).

Not the size matters (you should be able to append the attached super short video to itself without issues) but the structure.

But please don't tell me that is is not ok from now on, I'm using ADM since years without any real problems.
But not to be able to process smaller file portions further on would be a real usage killer for me! Please do not!

It depends.

[eumagga0x2a]

I've cut a couple of test videos each one GOP long out of a HD mp4 h264 clip and appending works perfectly for me.

Are you aware that the A/B markers don't get reset when appending a video anymore? To save the whole video, you must move the B marker to the end of the video first (press End, then Ctrl+PgDown).

[me444]

I just was going to add the forgotten attachment (added)  when i saw you update ...

OH NO! Of course not! I was NOT aware that i from now on after appending  i should shift the B marker to the end of the file before saving, as previously that was not necessary at all. I simply did not recognized the new behaviour.
Doing so, it works fine just as before.  Very ok so far -- really thanks a lot!!

[eumagga0x2a]

I'm glad we've found the reason. The former behaviour with respect to resetting markers assumed that users work in a strictly linear way (e.g. settings markers first, cutting or trimming second, appending another video third). But what if a user sets the markers first (finding suitable places for markers can be time consuming), then appends another video and wants to return to deleting or copying a chunk of the original video? Why should Avidemux block this way to do things completely? One more point: with the marker B at the end of the first video, you can now actually see where the first video ends and the appended video begins. A small extra step for those who append with intention to save the entire video immediately is a justifiable price IMHO.

[me444]

I understand that reason and it's good.

Initially i did set the markers (begin .. end) explicitely, but once i noticed it was not necessary, over the time i began to miss it by lazyness and got accustomed to. For the same reason the missing awareness with build 272 yet .....
Thanks again for support and advice!

[eumagga0x2a]

FYI: Mean, the author of Avidemux has just committed a patch which automatically resets the markers to the start and the end if they have not been touched by the user prior to appending, thus making both sides happy.