Corrupted frame handling

[scratch404]

Hello.

Finally, I can reproduce the bug, which has long been ruining my life 

avidemux v2.7.4. windows 7 x64.

H264/mp4 1 minute 83Mb sample - https://mega.nz/#!UiJl0QrZ!8yPWpV1yApfJRb_5n8zBi-kbTAoqfcaDAhx6Gc9uO3E

At 18 second there is corrupted frame. Playback skips this frame and reencoding with lower bitrate works fine, no any problems. But situation changes if I do cut after 18 second (for example from 40 to 42 second) - then playback at 18 second JUMPS to 40 second! And when I'm trying to reencode the file with lower bitrate video freezes after 18 second (there is only audio), and continues only after 40 second (see reencoded.mp4 17Mb https://mega.nz/#!UqY3DKQY!jKmja1YG2qT_qtYKrMMT0yVapmL19Xn-lqZcXKCilxE)

Could you please fix this bug it's really driving me crazy 

Btw version 2.5.6 works correct in this situation - no any jumps while playback and reencoding works fine, just 1 frame dropped, not a big problem.

BR, Egor

[eumagga0x2a]

The behavior of Avidemux you complain about (skipping to the next keyframe if consecutive decoding has hopelessly failed) is actually a workaround to allow re-encoding of IDR-less H.264 streams (almost all DVB broadsts nowadays) cut at keyframes with POC (picture order count) going back. This workaround does exactly the right thing in that context, but admittedly it is not nice in a case when the next keyframe is that far ahead.

So, this is generally not a bug and once the decoder is unable to decode, there is nothing we can do – and there is no way back to FFmpeg 0.9 used in Avidemux 2.5.6 from FFmpeg 4.1.4 Avidemux uses now.

Nevertheless, I'll look at the sample once I get a decent bandwidth to download it.

edit: Finally got the sample, issue confirmed, fix upcoming.

[eumagga0x2a]

It was just the opposite from what I was initially thinking: the issue was a regression from [editor] Try to continue from the next keyframe if decoding fails which did not take into account that maxPts is set to the expected value only if the current segment is also the last segment of the video. Deleting a portion of video after the broken frame (but not up to the end of video) resulted in maxPts remaning equal zero and thus the check to ensure that we don't leave the current segment failing so that we switched to the next segment i.e. to the end of the cut in your steps to reproduce.

Should be fixed by [editor] Fix next keyframe discarded and instead switched to the next segment on persistent decoding failure when the current segment is not the last one, thank you for your report.

[eumagga0x2a]

Fresh nightly builds (190904) for Windows with the fix included have been uploaded.

VC++ 64 bits off the git master
MinGW 64 bits off the git master
MinGW 32 bits off the legacy compatibility branch.

[scratch404]

IT FIXED! It will save a lot of my time and nerves! Now avidemux is absolutely perfect for me! Thank you very much!

[eumagga0x2a]

You're welcome, I'm sorry for inconvenience.

In the future, please don't hesitate to report spotted regressions right away.