Wish for switch-off the automatic seek for I-farmes

[JoKr8833]

Background: Since more than one year the stations of the 1st german TV chain omit most of the I-frame flags in their programs, especially during TV movies.
These recordings can not be cleaned with avidemux at start and end because it seeks automaticly for the next I-frame flag, which can end-up far away later or earlier on the timeline. This behaviour is very detrimental - and un-necessary according to my experiences, if approx. a second of flickering after the start is acceptable.

[eumagga0x2a]

You probably mean DVB-T2 broadcasts (HEVC encoded). I need to double-check check whether the latest known good 2.8.2 nightly which is r241212 from Dec. 12 of 2024 already contains the fix, but please try r241212 instead of whatever older build you are using.

Missing IDR frames in DVB broadcasts are the norm, the bug was Avidemux ignoring keyframes when both IDR ans keyframes were present.

[JoKr8833]

Thaks for the quick answer. 1. You're right, I'm using R 2.8.1 (2022 ?). But nowhere in the WWW I can find R 2.8.2, even not on sourceforge.
2. You're right again, I'm mainly recording DVB-T2 H.265 TV movies. But all emissions of the 2nd german TV chain (also DVB-T2 HEVC) do not have the same problem as before (DVB-T2 since approx. 2018) up to March 2024 also the 1st chain and these recordings can/coud be cleaned in a very short time with avidemux. If you need more information, let me know.

[eumagga0x2a]

You can find official cross-compiled nightlies at https://avidemux.org/nightly/win64/

[JoKr8833]

The 1st test looks successful. More tests tomorrow. But I'm confident. Thank you very much! Greetings from Germany, JK

[JoKr8833]

Unfortunately, my joy yesterday evening was too early. Possible, that it was a mowie from the 2nd chain. A further test today with 2.8.2 r241212 with a recording from last night showed the same bad behaviour as before with 2.8.1. The time between to points avidemux finds is up to 30 minutes.

[eumagga0x2a]

Assuming, you speak of the original MPEG-TS streams: you did delete old *.idx2 index files for these videos, didn't you?

If you did and re-indexing didn't make seek granularity better, please provide the original file(s) (a chunk of about 1 GiB in size should suffice, cut using a content-agnostic tool similar to head or dd on Unix-type operating systems) via WeTransfer (no email address required!), Mega, Dropbox or Google Drive.

If you speak of files already remuxed to other formats, I am not immediately sure how to proceed. Maybe providing such a file as a sample might help either.

[eumagga0x2a]

Moved to the main forum as this is presumably not an issue that has anything to do with user interface (the original request is entirely non-viable).

[JoKr8833]

I'm unable to sent you a test file (1.4 GB complete, as recordet) via WeTransfer without an e-mail-adress. Sorry

[eumagga0x2a]

You are right, WeTransfer has changed their mode of operation recently, unfortunately. Thus forget this service, please. It would be great if you were able to use any of the remaining three known working options though.

[JoKr8833]

Answer to your satement from May 06, 2025, 02:49:29 PM:
I only worked with and tested the original recorded *.ts streams. The files were newly recorded and no old *.idx2 files existed. Video and Audio Codecs were both in Copy mode. Because the recordings in question after cutting (as far as possible) were remuxed to *.ts because in this form they can be re-played more or less normally with MPVnet or VCL. (Recordings from the 2nd TV chain I remux to the the recommended *.mkv.)
I have a small number of original recordings in the remaining space of my System SSD (ca. 1 GB). 

Actually, the smalles one has approx. 1.4 GB, a little bit more than you asked for, but with this you can get a more complete picture then with a cutteted one. Its title is "Die Macht der Frauen" (The Power of Woman).
The total length is 1:49:18. Between start and the begin of the movie (mostly trailers for future emissions) at aprox. 0:04:03 and 0:04:18 are 8 stop points. During the movie at 0:18:59, 0:19:05 and 1:34:49. The next one at 1:36:34 is already after the movie's end and some more trailers follow with shorter distances as at the begin. Accidentially, in this case cutting was very easy at 0:04:03 and at 1:36:34 because they were very close to the begin and the end. But often there are other cases with only 3 of such points over more then 2 hours.
I put it on Mega.nz. The link is

https://mega.nz/file/sdwSnIaZ#_LsRjO9f3Uy1J_fFwhXQlub0bsIyuyEL7JM7F4MYnOI

Hope it works. Let me know what is happening and if you found a solution. JK

[eumagga0x2a]

Thank you, got the sample. An Avidemux Linux build off the latest git shows no issues seeking throughout the movie itself and trailers preceding and following the movie in the stream, it detects 3574 keyframes including 30 IDR frames (a keyframe every 1.85 seconds on average). Saving a part of the stream in copy mode works fine as well.

Could you please try...

1. The latest VC++ nightly from https://avidemux.org/nightly/vsWin64/. It is still not fully functional, but missing bits are irrelevant for the problem you describe. To uninstall it, run the uninstaller in the program directory directly rather than going the usual Windows Settings / Apps path (this is a known upstream bug of the Qt installer framework).

2. Please test whether enabling / disabling hw decoding in Avidemux Preferences has any effect.

As said above, no issues with current code on Linux.