First 7 frames are the same

[avadotclothing]

I've been using Avidemux for 2+ weeks now, everything worked fine until now.

Now all of a sudden, every video I modify using Avidemux has 7 frames at the beginning that are all an exact copy of the first frame; then the video proceeds as normal.

Anyone know how to fix this? ¯\_( ❛ - ❛ )_/¯

EDIT:

Output format: MP4 Muxer
Video Output: Mpeg4 AVC (x264)

[eumagga0x2a]

First of all, please verify that the issue persists with the latest nightly build

Native builds compiled with Microsoft Visual Studio on Windows: https://avidemux.org/nightly/vsWin64/
Builds cross-compiled with MinGW on Linux: https://avidemux.org/nightly/win64/

If it does, please compress (gzip, zip or 7z) and attach to your reply admlog.txt located at %localappdata%\avidemux resulting from an Avidemux session which produced such a strange output file.

[avadotclothing]

Thanks for responding! 

Had an older version of Avidemux. After reading your post, I've installed 'nightly build' Avidemux_2.7.5 VC++ 64bits 200215. Same issue, but now instead of 7 identical frames, there are only 3. And if I play around with some settings, I can reduce this number to 2, which is one step away from what I need.

Attached is the .zip archive with admlog.txt of the faulty session and two additional admlog.txt files of other faulty sessions.

Tried different source videos. Same thing everywhere.

[eumagga0x2a]

The source videos you re-encode look very special (in other words, broken) for me, the issue with identical frames might be due to decoding failures. If the content is innocuous enough, could you please provide one of such files as a sample? If the internal libavcodec is unable to decode the video cleanly, the encoder can't really do much.

[avadotclothing]

Yeah. I thought that this might be a problem somewhere in my hardware/software and not in Avidemux.

I made a simple test: an ultra-simple 10-frame video that I made out of nothing in Sony Vegas. It came out wrong: it had an eleventh frame - all green.

The other video is from the web. It seems to be fine. But after Avidemux it has those duplicated frames at the start of the video.


Can't upload the videos to this forum - it says the files are too large. So here're links to my Google Drive:

https://drive.google.com/file/d/1U0c7SPMDA5R8tPWSUUG_hK44OGaRJO4v
https://drive.google.com/file/d/1uOeHlMH822bdR4vlObNNdOIMTmFY8v0l


Thank you for your help so far!

Should I be doing diagnostics on 'decoding' stuff?

[eumagga0x2a]

I made a simple test: an ultra-simple 10-frame video that I made out of nothing in Sony Vegas. It came out wrong: it had an eleventh frame - all green.

Thank you for the samples.

The 11th frame indeed exists and is empty. If Sony Vegas produced this video, well, then it is buggy 
Setting the B marker in Avidemux to the last real frame which is frame 10 and re-encoding the sample works fine for me, no irregularities, no duplicated frames at the start.

The other video is from the web. It seems to be fine. But after Avidemux it has those duplicated frames at the start of the video.

I loaded it in Avidemux and re-encoded it with x264 (the version of libx264 on my Linux system is currently 157) – cannot reproduce the issue you describe. No duplicated frames at the start of the video.

[avadotclothing]

In the words of a character from True Detective series: "You're speaking riddles to me, white man"...  🤭

Really. Encode. Decode. libx264. B marker. -- you might as well be speaking Xhosa But I'll try to read up on it sometime this week.

I'll try doing the same video encoding/decoding? on a different laptop. And I'll reinstall my video drivers on this laptop.

Thank you for the help, eumagga0x2a

[eumagga0x2a]

I'll try doing the same video encoding/decoding? on a different laptop. And I'll reinstall my video drivers on this laptop.

I don't think any of these steps can make any difference.

Do you see duplicated frames when you load a re-encoded video in Avidemux? Or does it happen only with some third-party application? If the latter, the application might be unable to deal with non-zero presentation timestamp of the first frame.