Geht mit ffmpeg, das blöde ist nur, dass es auf der Box fast genauso lange dauert, wie die Aufnahme abzuspielen; wenn du es aber nachts laufen lassen willst, könnte es funktionieren.

ffmpeg liegt auf dem Feed, der einfachste Aufruf wäre

ffmpeg -i "<Aufnahme-File.ts>" -v error -f null -

Man kann das in ein Python-Script verpacken, welches deine Aufnahmen scannt. Mit dem Parameter -progress kannst du dir dann auch noch die Stelle ausgeben lassen, wieweit ffmpeg gerade ist oder wo im File der Fehler passiert (wenn eine Aufnahme beendet wird, hat der allerletzte Frame sehr oft Fehler).

Hallo zusammen,

ich komme aus der VDR Welt und hatte bisher meine Aufzeichnungen vor dem Scheiden und Archivieren automatisiert auf Fehler überprüft und dieses recht alte Thema gefunden.

Ich würde gerne folgendes erreichen:
1) automatischer Scan einer Aufnahme im Hintergrund, nachdem sie auf der VU abgeschlossen ist
2) Anzeige der Fehler möglichst direkt in der Aufnahmeliste der VU

Eine Möglichkeiten zur Prüfung der TS Files ist die oben beschriebene Nutzung von ffmpeg (lässt sich ja einfach nachinstallieren) - allerdings erschien mir das etwas Übertrieben. Und die Ausgabe war für mich nicht so einfach zu interpretieren.

Eine weitere Möglichkeit erschien mir das Portieren des kleinen Tools "vdr-checkts" von Tobias Grimm auf die VU.

Das Tool habe ich somit geringfügig angepasst und es läuft jetzt auf meinen VUs mit normalen TS Files.

Ich habe mal verglichen, wie es mit der Geschwindigkeit auf einer VU und der CPU Last beim Check ausschaut:

Die Testdatei ist ca. 10G groß.

checkts:
top-Ausgabe :
Bei checkts:
%Cpu(s): 3.9 us, 2.6 sy, 0.0 ni, 70.9 id, 21.8 wa, 0.2 hi, 0.5 si, 0.0 st
KiB Mem : 567572 total, 7116 free, 193228 used, 367228 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 350572 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12457 root 20 0 2972 816 732 D 10.3 0.1 0:06.37 checkts




ffmpeg:
top-Ausgabe:

%Cpu(s): 15.2 us, 3.5 sy, 0.0 ni, 71.9 id, 7.9 wa, 0.7 hi, 0.7 si, 0.0 st
KiB Mem : 567572 total, 6372 free, 222324 used, 338876 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 321468 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14365 root 20 0 59876 39504 9728 R 63.9 7.0 0:03.51 ffmpeg


Es zwar etwa die gleiche Zeit zur Prüfung benötigt (Limitierung scheint hier der Festplattenzugriff) allerdings benötigt ffmpeg erwartungsgemäß deutlich mehr Ressourcen.
Die Ausgabe von checkts ist für mich außerdem einfacher zu deuten.

Gibt es eine einfache Möglichkeit einen Script nach Fertigstellung einer Aufnahme auf der VU zu starten?
Wie kann ich die Anzahl der gefundenen Fehler zur Anzeige bringen? - Aktuell fällt mir Umbenennen der Aufnahme, Erzeugung einer neuen Datei oder Patchen der Meta-Daten ein.
Kann man das Aufnahmemenu so konfigurieren, dass z.B. ein Spalte mit den Fehlern angezeigt wird?
Gibt es ggf. die Möglichkeit mit Tags in einer meta Datei zu Arbeiten?

Ich würde mich über Vorschläge zur weiteren Umsetzung / Verbesserung freuen - man könnte dann ggf. auch das checkts noch etwas modifizieren...

Ich hänge die von mir geänderte Version vom "vdr-checkts" an (bin für ARM und AMD64 und src)

Was mich interessieren würde: finden ffmpeg und dein Tool dieselben Fehler?

Das Tool nach Ende einer Aufnahme automatisch laufen zu lassen: gibt ein paar Möglichkeiten:
- als Plugin, das auf das Ende einer Aufnahme reagiert: Script nach Aufnahme
- als Shell-Script im entsprechenden System-Event in /etc/enigma2/events/ - Informationen zu den Updates VTi 14.0.X

Zur Anzeige bringen: vielleicht möglich als Skin-Part und einem Converter; bin mir aber nicht sicher, ob du da bei der MovieList dazwischen kommst. Bei EMC sollte es möglich sein, notfalls musst du da den Code für dich anpassen.

Edit: auf dem MacBook benutze ich das angehängte Script als Wrapper für ffpmeg -v error - da werden dann nur Fehler angezeigt.
Edit 2: ich probiere dein Tool auch mal auf meinem MacBook. Vielen Dank schon mal für das Tool.

checkts findet definitiv nicht alle Fehler, die z.B. ffmpeg finden würde, allerdings langt es für mich um zu entscheiden, welche Aufzeichnung geschnitten werden sollte und welche nicht...

lt. Kommentar im Code: Right now, only continuity errors are reported

Bedeutet: Es werden mit hoher Wahrscheinlichkeit Fehler gemeldet, wenn es z.B. Empfangsstörungen gab...

Und das Tool hat den Vorteil, dass es extrem viel schneller ist als ffmpeg. Schön wäre, wenn noch die Timestamps der gefundenen Fehler angezeigt werden - ffmpeg findet sehr oft die Fehler in den ersten und letzten paar Frames.

Ich habe das checkts Tool etwas erweitert.

Es gibt zei neue Optionen, die es erlauben die Anzahl der gefundenen Fehler als ein Tag an das Ende der TS Datei zu schreiben.
Der Sinn liegt darin, dass ein File bei erneutem checken dann nur noch den Tag liest und die Anzahl der Fehler zurückmeldet.

Beim default Aufruf wird nichts geschrieben
checkts TS-File

Es werden Tags erzeugt, wenn der Aufruf um -t ergänzt wird. (Mir ist bisher nichts negatives aufgefallen, wenn Files getaggt wurden...)
checkts -t TS-File

Soll eine erneute Prüfung trotz existierendem Tag durchgeführt werden:
checkts -f TS-File oder checkts -f -t TS-File

rdamas schrieb:

Schön wäre, wenn noch die Timestamps der gefundenen Fehler angezeigt werden

Stimme dem zu, habe aber bisher noch keinen simplen Weg dazu gefunden...

Es werden auch bisher nur Continuity errors erkannt (für mich reicht das aber fast immer)

p-body schrieb:

habe aber bisher noch keinen simplen Weg dazu gefunden...

oder in der cuts Datei hinterlegen…
oder zusätzlich auf dem stdout mit Newline getrennt ausgeben

p-body schrieb:

Stimme dem zu, habe aber bisher noch keinen simplen Weg dazu gefunden...

Sorry habe mich falsch ausgedrückt - aktuell kenne ich keinen Weg einfach an die Timestamps aus dem TS-Stream zu kommen - die Ausgabe in cuts oder cmd-line könnte man dann vermutlich einfach wie vorgeschlagen realisieren

Ja, das geht wohl auch nicht, ohne dass du die Pakete im Payload wenigstens teilweise dekodierst.

Ich habe noch einen anderen Parser gefunden, der das teilweise macht: GitHub - mikecancilla/mpts_parser: MPEG2 Transport Stream Parser to XML und nur wenig langsamer ist. Der hat immerhin einen MPEG2 und einen H264 Parser mit an Bord. Das Programm muss ein wenig angepasst werden, bevor es unter Linux läuft, das ist aber straight forward.

Ich habe noch etwas an dem checkts Tool gebastelt.

Aktueller Stand ist, dass das Tool erkannte Fehler in einem definierten Zeitraum zusammenfassen und einen entspr. Zeitbereich ausgeben kann.

Das schaut dann als Debug-Ausgabe bei mir aktuell etwa so aus

Ich noch unsicher ob bzw. wie eine Ausgabe der Schnittmarken bei "checkts" erfolgen sollte.

Aktuell könnte man recht einfach eine neue ts.cuts erzeugen, die dann die Zeitstempel der Fehler als "Mark" einträgt. (In / Out erscheint mir nicht so sinnig - oder?)

Gibt es noch andere Kenner in der cuts, welche man nutzen könnte um die Marken von den "normalen" Marken zu unterscheiden? (Bekannt sind mir: In / Out / Mark / Last)

Kann man den Marken auch Bezeichner geben?

Ich würde es durchaus für sinnvoll erachten, den fehlerhaften Frame mit einem OUT davor und einem IN danach zu markieren. Im CutlistEditor könnte man dann die unmittelbare Aufeinanderfolge von IN und OUT als Fehlerindikator sehen (und eventuell auch gleich zum Rausschneiden lassen).

Die Bezeichner sind im CutlistEditor definiert. Für einen neuen Bezeichner bräuchte man auch eine neue Marker-Nummer. Alles grösser als 3 wird aber in den Standardprogrammen wieder gelöscht bzw. bricht die Bearbeitung der .cuts-Datei bei einem solchen Marker ab (auch nachfolgende 'normale' Marker sind dann weg).

Ich habe mal testweise eingebaut, Out - In Marken zu setzen.
Mir persönlich gefällt das allerdings nicht so gut als wenn einfach nur Marken gesetzt werden. Die Marken lassen sich bei mir dann auch im normalen Player nutzen um schnell an einen potentiellen Fehler zu springen damit man diesen "begutachten" kann. Der Cutlist-Editor muss dann nicht geöffnet werden.

Ich nutze den CutlistEditor der VU allerdings auch nicht wirklich, da mir das Schnittfester meines alten VDR noch immer besser gefällt (vielleicht ist der CutlistEditor aber auch nur zu ungewohnt für mich und ich müsste ihm mal wieder eine Chance geben)...

Ich werde also noch Optionen einbauen um optional "OUT-IN-Cuts" und/oder "MARKs" in der ts.cuts auszugeben.

Ist ggf. auch eine Ausgabe der gefundenen Fehler als JSON-String sinnvoll?

Hier eine neue Testversion von "checkts"

Neu:
- Es können Timestamps der Fehler ausgegeben werden
- Fehler können per "MARK" in der cuts eingetragen werden
- Fehler können per CUT-Out und CUT-IN in die Schnittliste aufgenommen werden
- alte Marken können optional entfernt werden. (der LAST-Marker bleibt erhalten)
- Fehler können über einen definierbaren Zeitraum zusammengefasst werden




checkts "MyRecording.ts" -p -d 2 -e (Mindestzeit zwischen 2 Fehlern = 2 Sekunden ; Ausführung mit Statusanzeige ; nach dem Scan Ausgabe der erweiterten Infos)
checkts "MyRecording.ts" -D -M -p -e (Mindestzeit zwischen 2 Fehlern = default (5Sekunden) ; Ausführung mit Statusanzeige - nach dem Scan wird die .cuts geleert und Marker bei Start- und Ende der Fehler Markierung eingetragen - Ausgabe der erweiterten Infos)

checkts "MyRecording.ts" -D -C -p -e (Mindestzeit zwischen 2 Fehlern = default (5Sekunden) ; Ausführung mit Statusanzeige - nach dem Scan wird die .cuts geleert und Cut-Out Marker bei Start und Cut-IN bei Ende der Fehler Markierung eingetragen - Ausgabe der erweiterten Infos)

Falls die Aufnahme bereits einen Tag mit der Anzahl der Fehler enthält, wird nur die Anzahl der Fehler ausgegeben, da der Tag keine Zeitinformationen beinhaltet.
In diesem Fall kann ein erneutes Scann mit "-f" erzwungen werden

Fehlerbereinigte Version von "checkts"

Neu:
Neue Option -E schreibt die Fehlerdteils, wenn Fehler in der TS Datei erkannt wurden, in eine Textdatei mit der Endung .err

Bugfix: Programm lieft in eine Endlosschleife, wenn Fehler "Syncbyte fehlt" erkannt wurde.

Fehlerbereinigte Version von "checkts" (V0.7)

Bugfix: Die Positionen der erkannten Fehler wurden aus der optionalen .err Datei (Option -E) gelöscht, wenn das TS-File schon getaggt war und somit das TS-File nicht neu geprüft wurde.

Fehlerbereinigte Version von "checkts" (V0.8)

Unnötige Abhängigkeiten entfernt
meine VU meldete bei mir beim Start von checkts0.7 :
checkts: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by checkts)

Dann hast du (oder jemand anderes) das Tool gegen eine neuere libstdc++ übersetzt. Dieses Versions-Symbol gehört zur GCC-Release 5.1.0. Der wurde übrigens Ende April 2015 veröffentlicht. Der beim bauen von VTi benutzte GCC ist immer noch 4.9.2 (von Ende Oktober 2014, also ebenfalls steinalt).

@rdamas ich kompiliere für ARM aktuell einfach auf meinem Raspi - nachdem ich die mit der V0.7 neu eingefügten Abhängigkeiten wieder entfernt hatte läuft das so erzeugte Binärfile auch wieder auf der VU... (wenigstens bei meinen Kisten)

Wir hatten uns ja schon mal vor einiger Zeit unterhalten, wie man am Einfachsten für die VU und das VTI-Image kompiliert - zum Schluss hatte bei mir ein einfaches "make" auf einem Raspberry recht gut funktioniert...

Falls jemand einen einfachen Weg kennt, eine Buildumgebung für das aktuelle VTI-Image zu erzeugen würde ich das gerne mal aufsetzen...