Avidemux Forum

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.

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.

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.

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

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

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.

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.

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).

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

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.