Keine Keyframes bem Schneiden von DVB-T2 Streams mehr

[sqrt-1764]

Moin,
ich denke ich bin im deutschen Teil des Forums richtig aufgehoben.

Ich habe einen kleinen externen DVB-T2-Receiver, der auch auf USB-Stick aufnehmen kann. Diese Aufnahmen konnte ich bis jetzt problemlos schneiden. (Trimmen an den Keyframes und ansonsten kopieren des Inhalts ohne neu codieren.)
Seit einiger Zeit geht das aber bei einigen Sendern nicht mehr. Da findet Avidemux (2.8.1, Linmux) bei vielen Sendern keine Keyframes mehr und springt weit nach vorne in den Stream um dann nach ein paar Sprüngen am Ende des Streams zu landen. Abspielen der Dateien mit VLC und springen in der Datei mit VLC funktioniert.
Die Sender zdf-neo und 3sat funktionieren noch wie gewohnt, arte, Das Erste und die Dritten zeigen dieses neue Verhalten.
Scheint, als ob die Sender da was am Sendeformat geändert haben?

Finde grad nichts passendes im Netz, daher meine Frage hier.

TIA

[eumagga0x2a]

2.8.1 ist steinalt, bitte mit dem aktuellen 2.8.2 nightly (appImage für Linux ab etwa Ubuntu 20.04.x und neuer) testen, vorher ggf. die von älteren Avidemux-Versionen generierten idx2-Indexdateien löschen. Falls das Problem auch darin besteht, bitte ein oder mehrere kleinere, unveränderte MPEG-TS Samples, wie vom Receiver aufgenommen, mittels WeTransfer, Mega, Dropbox oder Google Drive bereitstellen.

[sqrt-1764]

Moin, sorry für die Verzögerung. Defaultmäßig ist die Benachrichtigung nicht eingeschaltet und da ich auch andere Sachen um die Ohren hatte ...

Zur Version:
Ihr solltet dann mal Eure Verteilungsstrategie überdenken. Sowohl über "mein" Linux-Repository als auch über die üblichen Downloadseiten (z.B. heise, computerbild, chip) wird aktuell die 2.8.1 verteilt. Otto-Normaluser muss also davon ausgehen, dass das die offzielle aktuelle Version ist.
Sucht man nach avidemux Download, dann bekommt man auf der avidemux.org Seite erstmal nur die 2.6.0 angeboten - noch viel älter. Von Nightlys lasse ich normalerweise die Finger - ich will stabile Versionen und nicht cutting edge, denn ich will ja nur Standardaufgaben machen.

Aber wie dem auch sei, hab mir die Nightly Version 2.8.2 vom 31.5.2024 runter geladen und damit getestet - gleiches Ergebnis. (Im Info-Dialog wird da nur 2.8.2 angezeigt, aber von der Download Seite her ist zu erwarten, dass es eine Menge an 2.8.2 Versionen gibt - das sollte da ebenfalls angezeigt werden, denke ich - oder muss man dann jeweils die UUID mit übermitteln? Nur sollte die dann per Cut & Paste kopierbar sein - so was tippt man nicht gerne freiwillig ab).

Zu den gewünschten Beispieldaten:
Hier ein aktueller Schnipsel von arte. Diese .ts Datei kommt direkt von meinem Receiver und konnte bisher problemlos geschnitten werden. Firmware-Updates am Receiver gab es nicht.

https://drive.google.com/file/d/1rQWvbq529n4uhMX31urcsQu-YfWhRALg/view?usp=sharing

Sind jetzt nur etwas mehr als 2 Minuten.
Auffällig ist, dass es am Anfang 2 Keyframes gibt und dann nichts mehr. Schon die liegen aber recht weit auseinander.
Nach den ersten paar Keyframes kommt dann aber immer ein riesen Sprung irgendwo in die Mitte der .ts Datei und dann noch ein oder zwei weitere Keyframes bis man dann am Ende der Datei ist. In einer Datei liegt der nächste Keyframe bei 22 Minuten, in einer anderen bei 1 Stunde 28 Minuten, ...
Will jetzt nicht so lange Dateien hoch laden - reicht der Schnipsel für den Anfang?
Bin einigermaßen vom Fach. Wenn man mir sagt was ich tun muss, kann ich durchaus auch lokale Analyse hier fahren und die Ergebnisse posten ...

HTH
ML

[eumagga0x2a]

Danke für die MPEG-TS-Datei zum Testen. Avidemux verliert Keyframes hier: wenn in MPEG-TS neben "recovery points" in üblichen Open-GOP-Streams auch echte IDR zu finden sind, ignoriert Avidemux die recovery points. "Recovery points" eignen sich jedoch einwandfrei zur Navigation (aber sehr eingeschränkt zum Schneiden).

Das ist sehr alter Code, ein Quirk aus längst vergangenen Tagen, ich hatte diese Stelle in meinen lokalen Builds sowieso auskommentiert gehabt. Werde sie demnächst offiziell entfernen.

Im Info-Dialog wird da nur 2.8.2 angezeigt

Git-Revision fehlt (meistens) in MSVC-kompilierten Builds ("vsWin64") bedingt durch die Art und Weise wie der Maintainer sie erstellt. Cross-Builds ("win64") sollten diese Angabe im "About"-Dialog haben.

Nightlies sind im Fall von Avidemux 99% der Zeit stabiler als Releases. "Instabil" sind sie im Sinne von möglichen Änderungen der Interfaces. Natürlich können Distributionen damit nicht arbeiten.

Otto-Normaluser muss also davon ausgehen, dass das die offzielle aktuelle Version ist.

Ja, das wird er tun, ich habe keine Ressourcen, das zu ändern. Der Release steckt fest im Zeitmangel und im alten OpenGL-Code, der mit aktuellen Qt6 Versionen nicht mehr kompatibel ist (OpenGL ist in Avidemux die einzige hardwarebeschleunigte Videoausgabe unter macOS und somit Pflicht-Feature, solange Avidemux keine bessere Alternative bekommt).

[sqrt-1764]

Danke für die MPEG-TS-Datei zum Testen.

Bitte, bitte - ist ja in eigenem Interesse. ;-)
Ich gehe mal davon aus, dass die anderen Sender das selbe Problem haben. Das Verhalten beim Schneiden ist jedenfalls das selbe. Oder soll ich noch Schnipsel von den anderen Sendern machen?
Das aktuelle Beispiel auf GDrive kann ich jetzt in die Tonne treten?

Das ist sehr alter Code, ein Quirk aus längst vergangenen Tagen, ich hatte diese Stelle in meinen lokalen Builds sowieso auskommentiert gehabt. Werde sie demnächst offiziell entfernen.

... das heisst, dass die App demnächst gefixt ist? Schön zu hören. ;-)
Wie erfahre ich, in welcher Version der Fix dann drin sein wird? Sagt hier dann jemand Bescheid?

Benachrichtigungen scheinen hier im Forum nicht richtig zu funktionieren? Hab jedenfalls wieder keine bekommen gehabt. Eime ungefähre Zeitangabe wäre daher praktisch.

Wenigstens die Download-Seite sollte aktualisiert werden. Ein Hinweis dass (im Moment?) die Nightlies die beste Option sind, währe dort hilfreich. Diese Änderung sollte doch kein großer Aufwand sein?

Git-Revision fehlt (meistens) in MSVC-kompilierten Builds ("vsWin64") bedingt durch die Art und Weise wie der Maintainer sie erstellt. Cross-Builds ("win64") sollten diese Angabe im "About"-Dialog haben.

... ich bin allerdings unter Linux unterwegs (hatte AppImage4Buster genommen - klang mir mangels Doku die passendste Version). win64 wird da für mich wohl nicht zutreffen. ;-)

Bin jetzt nicht in den Code eingestiegen - dazu bin ich etwas weit weg vom Thema. Ist nur 'ne Anregung, denn im Support Fall ist die genaue Version ja manchmal durchaus interessant.
In den Code-Projekten in denen ich unterwegs war, konnte man solche Informationen mehr oder weniger automatisiert in den Code bekommen.

Nightlies sind im Fall von Avidemux 99% der Zeit stabiler als Releases. "Instabil" sind sie im Sinne von möglichen Änderungen der Interfaces. Natürlich können Distributionen damit nicht arbeiten.

OK, wenn man's weiß ...
Ist natürlich doof, dass so die automatischen Updates nicht funktionieren. Hab mich so an den Komfort gewöhnt.

Der Release steckt fest im Zeitmangel und im alten OpenGL-Code, der mit aktuellen Qt6 Versionen nicht mehr kompatibel ist (OpenGL ist in Avidemux die einzige hardwarebeschleunigte Videoausgabe unter macOS und somit Pflicht-Feature, solange Avidemux keine bessere Alternative bekommt).

Kann das geschriebene mangels Detailkenntnissen im Projekt jetzt nicht vollständig verstehen.
Hab im Github Repository mal auf die Branches und Tags geschaut. Die Struktur dort sieht anders aus, als ich erwartet hätte. Finde da z.B. keinen 2.8.2 Tag, der da doch inzwischen eigentlich sein müßte?
Alte gewachsene Strukturen? Verstehe, dass so was wenn, dann nicht so einfach glatt zu ziehen ist.
Wäre das mit dem automatischen(?) Update der Distributionen nciht einfacher, wenn es da eine "saubere" Git-Struktur gibt? Dann könnten die automatisch erzeugten Binaries automatisch abgeholt werden, sobald eine neue "offizielle" Version erschienen ist.
Aber OK - ich rede über Dinge, von denen ich keine wirkliche Ahnung habe. Hab noch nie Anwendungen unter Linux in Repositories veröffentlichen müssen ... ;-)

So, der Haken bei "Notify me of replies" ist jetzt definitiv gesetzt. Mal sehen, ob jetzt eine Benachrichtigung kommt.

TIA
ML

[eumagga0x2a]

Das aktuelle Beispiel auf GDrive kann ich jetzt in die Tonne treten?

Ja, danke nochmals. Vorerst keine weiteren Samples notwendig.

... das heisst, dass die App demnächst gefixt ist?

Davon gehe ich aus.

Wie erfahre ich, in welcher Version der Fix dann drin sein wird? Sagt hier dann jemand Bescheid?

In einer künftigen

Ich poste normalerweise den Link zum Commit im Thread wo das entsprechende Problem gemeldet wurde. Wenn schon Avidemux keinen Bugtracker hat, dann wenigstens das.

Eime ungefähre Zeitangabe wäre daher praktisch.

Jetzt ist erst mal FFmpeg upgrade dran, dann Indexierung von MKV, beigetragen von szlldm und in der Liste der Pull Requests schmorend, einpflegen.

Wenigstens die Download-Seite sollte aktualisiert werden. Ein Hinweis dass (im Moment?) die Nightlies die beste Option sind, währe dort hilfreich. Diese Änderung sollte doch kein großer Aufwand sein?

Vermutlich ist sie mit keinem großen Aufwand verbunden, bloß habe ich mit der Website und der ganzen Infrastruktur nichts zu tun.

ich bin allerdings unter Linux unterwegs

Das vereinfacht die Sache enorm, ist es doch ein Leichtes, unter Linux selbst Avidemux zu kompilieren. Deaktiviere den entsprechenden Abschnitt in avidemux_plugins/ADM_demuxers/MpegTS/ADM_ts.cpp von Zeile 187 bis hin zur Zeile mit return-Statement durch

Code Select Expand

#if 0
(hier steht der Code, den der Präprozessor unsichtbar für den Compiler machen soll)
#endif
und kompiliere Avidemux.

hatte AppImage4Buster genommen - klang mir mangels Doku die passendste Version

Richtig, und dort wird im "About"-Dialog die Git-Revision einwandfrei angezeigt.

Hab im Github Repository mal auf die Branches und Tags geschaut. Die Struktur dort sieht anders aus, als ich erwartet hätte. Finde da z.B. keinen 2.8.2 Tag, der da doch inzwischen eigentlich sein müßte?

Der Tag wird gesetzt, wenn die Version 2.8.2 freigegeben werden kann (dann wird die Version voraussichtlich auf 2.8.3 erhöht).

[sqrt-1764]

Wenigstens die Download-Seite sollte aktualisiert werden. Ein Hinweis dass (im Moment?) die Nightlies die beste Option sind, währe dort hilfreich. Diese Änderung sollte doch kein großer Aufwand sein?

Vermutlich ist sie mit keinem großen Aufwand verbunden, bloß habe ich mit der Website und der ganzen Infrastruktur nichts zu tun.

Ich kenne Eure interne Projektstruktur ja nicht, aber es hört sich so an, als bestünde da Optimierungspotential. ;-)

ich bin allerdings unter Linux unterwegs

Das vereinfacht die Sache enorm, ist es doch ein Leichtes, unter Linux selbst Avidemux zu kompilieren. Deaktiviere den entsprechenden Abschnitt in avidemux_plugins/ADM_demuxers/MpegTS/ADM_ts.cpp von Zeile 187 bis hin zur Zeile mit return-Statement durch

Code Select Expand

#if 0
(hier steht der Code, den der Präprozessor unsichtbar für den Compiler machen soll)
#endif
und kompiliere Avidemux.

Ich mag es normalerweise nicht, meine Kiste mit Sachen vollzumüllen, die ich selber nicht täglich brauche (will sagen, die ganzen Abhängigkeiten des Projekts). Aber da ich meinen Laptop demnächst sowieso mal frisch aufsetzen will ...
(Würde idealerweise für so was eine dedizierte VM aufsetzen in der ich dann nach Lust und Laune installieren kann. Aber da muß ich gerade noch ein paar Hausaufgaben machen ... ;-) )

Hab also das aktuelle Github-Repository geclont und bin den Anweisungen aus dem Readme gefolgt.
Habe in der angegebenen Datei die Zeilen 187 bis 209 auskommentiert und compiliert.

Mit der daraus gebauten avidemux3_qt5 habe ich dann diverse Dateien von allen problematischen Sendern, die bei mir auf Halde lagen geschnitten und mir die Ergebnisse stichprobenartig überprüft - sieht gut aus.

Der Fix funktioniert von meiner Warte aus.

hatte AppImage4Buster genommen - klang mir mangels Doku die passendste Version

Richtig, und dort wird im "About"-Dialog die Git-Revision einwandfrei angezeigt.

Das ist es, was ich mit "UUID" bezeichnet hatte. Mein Punkt ist, dass diese Information nicht in Textform kopierbar ist. Wenn also jemand nach der Version fragt, müßte ich diese UUID abtippen ...

Hab im Github Repository mal auf die Branches und Tags geschaut. Die Struktur dort sieht anders aus, als ich erwartet hätte. Finde da z.B. keinen 2.8.2 Tag, der da doch inzwischen eigentlich sein müßte?

Der Tag wird gesetzt, wenn die Version 2.8.2 freigegeben werden kann (dann wird die Version voraussichtlich auf 2.8.3 erhöht).

Dann ist also die 2.8.1 immer noch die offiziell aktuelle Version. Dein initialer Kommentar, dass diese Version "steinalt" sei ist dann für den Außenstehenden etwas merkwürdig.

Aber wie dem auch sei: Danke für die Infos, die mein Problem zeitnah gelöst haben.

[sqrt-1764]

... ich vergaß:
Trotz aktivierter Option "benachrichtigen bei Antwort" hab ich keine Mail bekommen.
Auch das sollte mal gefixt werden?

[eumagga0x2a]

... ich vergaß:
Trotz aktivierter Option "benachrichtigen bei Antwort" hab ich keine Mail bekommen.
Auch das sollte mal gefixt werden?

Ich glaube, das Herunterladen von Anhängen geht weiterhin nur wenn HTTP2 deaktivier ist. Dies erlaubt, wenn ich mich nicht irre, nur Firefox. Auch das sollte gefixt werden (nur als Wink mit dem Zaunpfahl, dass ich nicht mehr Einfluss auf die Infrastruktur habe als Du).

[sqrt-1764]

Ich glaube, das Herunterladen von Anhängen geht weiterhin nur wenn HTTP2 deaktivier ist. Dies erlaubt, wenn ich mich nicht irre, nur Firefox. Auch das sollte gefixt werden (nur als Wink mit dem Zaunpfahl, dass ich nicht mehr Einfluss auf die Infrastruktur habe als Du).

Ähem - ich will doch gar nichts runter laden. Ich will 'ne Mail bekommen, wenn hier jemand antwortet, ich kann ja nicht dauernd hier vorbei schauen um das zu prüfen.
Diese Option war (und ist) aktiviert - nur kommen keine Benachrichtigungsmails.
So auch hier wieder. Nur weil ich nochmal vorbei geschaut habe hab ich Deine Antwort bemerkt.

Ich kann gerne einen Fehler melden - wenn Du mir sagst, wo ich das abkippen muss.

[eumagga0x2a]

Ähem - ich will doch gar nichts runter laden.

Es war gedacht als Beispiel einer Fehlfunktion, wofür ein Workaround zu finden eine echte Leistung war. Hier wäre es mit Wollen nicht getan :-)

Ich kann gerne einen Fehler melden - wenn Du mir sagst, wo ich das abkippen muss.

Ich würde es mit dem Administrator versuchen (in Englisch).

[sqrt-1764]

quote author=eumagga0x2a link=msg=96974 date=1718661354]
Ich würde es mit dem Administrator versuchen (in Englisch).
[/quote]
Hab ihm am 23.6. ne Nachricht auf englisch geschrieben. Bisher kein Feedback.
Aber da ich im Moment glücklich bin, hab ich da keinen Leidensdruck. Wäre nur besser für Euer Forum hier, wenn das funktionieren würde ...