Gesplittete DVB-Aufnahmen mit ffmpeg reparieren

[Caramon2]

Dafür ist es hervorragend geeignet, wegen seiner (besonderen) RGB Kodierung aber kaum außerhalb dieses Einsatzfeldes einsetzbar.

Ups! Das mit RGB hatte ich vollständig überlesen.

Bzgl. ffmpeg/x264 bin habe ich neulich auch was zu RGB gelesen und nochmal gesucht:

The libx264rgb encoder is the same as libx264, except it accepts packed RGB pixel formats as input instead of YUV.

https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
Zur Kompatibilität kann ich noch nichts sagen.

Zu 'nice' kann man sagen, dass es nicht das Gleiche ist wie das systemd Kommando. Ersteres ist veraltet und u.U. in der Tat nicht mehr wirksam. Letzteres sollte aber Wirkung zeigen.

Auf meinem PC gibt es kein systemd.

In meinen Augen ist systemd der "Cancer", von dem der Ballmer in Bezug auf Linux gesprochen hat.

Es "frisst" sich jedenfalls immer tiefer ins System und hat schon lange "gestreut", was man gerade erst wieder bei der xz-Bsckdoor gesehen hat. - Je komplexter, desto anfälliger:

Preliminary analysis from the aforementioned post shows that the backdoor is designed to exploit openssh when linked against libsystemd (which depends on lzma) to compromise the SSH services. Artix and Arch don't link openssh to liblzma and thus this attack vector is not possible.

Based on the same analysis, the execution of openssh under systemd is a prerequisite for the backdoor to activate and given the additional distance of Artix to systemd (aren't we glad?), the exploit shouldn't affect any running Artix system.

Ich habe mein System auch unter der Haube lieber einfach und übersichtlich. - Wie mein Vater gerne sagte: Was man nicht hat, geht nicht kaputt.

Aber auf einer ext. SSD habe ich eine LMDE-Testinstallation (hat letzten Monat den Kernel 6.7 bekommen). Damit kann ich das mal ausprobieren und mit dem Livesystems (6.1-LTS) vergleichen. Das AppImage funktioniert ja auch dort.

Nachtrag:

Ich habe mir mal die Manpage angesehen und würde das:

systemd-run --user --pty --quiet -d -p IOWeight=10 -p CPUWeight=idle -p CPUSchedulingPolicy=idle

so zusammenfassen:

systemd-run --user -tqd -pCPU{Weight,SchedulingPolicy}=idle

Da sich "IOWeight=10" nicht mit den anderen "-p" kombinieren lässt und die Laufwerkszugriffe beim Videoencoding sowieso nicht relevant sind, lasse ich es weg.

Normalerweise sollte das funktionieren. Solche Zusammenfassungen habe ich schon bei LinuxMint 18.x genutzt, um es nach einer Neuinstallation großmaßstäblich auszumisten: s. hier

 

[Caramon2]

@Uridium : Die systemd-Priorität verhält sich genauso:

Ich habe beim LMDE 6 (mit Kernel 6.7) zuerst das AppImage normal per Dateiverwaltung gestartet und eine HD-Aufnahme recoden lassen. Etwas später (um beide anhand der CPU-Zeit auseinander halten zu können) habe ich die 2. Instanz mit der systemd-Befehlszeile gestartet, um die selbe HD-Aufnahme mit der selben "kontrastarmes"-Voreinstellung zu recoden:

systemd-run --user --pty --quiet -d -p IOWeight=10 -p CPUWeight=idle -p CPUSchedulingPolicy=idle ./avidemux281.appimage

Alleine nutzte das normal gestartete AVIdemux 780-790% CPU-Last (AMD FX-8350 mit deaktiviertem TurboCore), also blieben 10-20% idle, aber statt nur die zu nutzen (was idle-Priorität bedeuten würde und wie ich es gerne hätte: eben wie früher bei Windows), wird die Rechenzeit nahezu gleichmäßig auf beide verteilt (die Prioritätsanzeige des Gnome-Systemmonitors basiert auf den nice-Wert):

Es bleibt zwar immer etwas unterhalb dem anderen (300-380% habe ich gesehen - wobei es keinen Unterschied machte, welches ich zuerst gestartet hatte), aber alles andere als die vorgegebene idle-Priorität.

Btw:

Die ext-SSD:

Die verschlüsselte Home gehört zu "Artix-eSSD" = Die 1:1 Kopie meines Produktivsystems, damit ich überall meine gewohnte Umgebung und Tools habe, wenn jemand Probleme hat.

Die Homepartition habe ich nach hinten gesetzt, da ich die SSD auch an alten BIOS-PCs nutze, die nur innerhalb der ersten 128 GiB booten können.

Die anderen beiden sind Testinstallationen.

 

[Uridium]

Appimage könnte dazwischen funken.

Schauen, ob der scheduler gesetzt wurde:
$ sudo ps axo uname,cmd,cls,ni,pri,rtprio

Bzw. ob es grundsätzlich funktioniert:
$ systemd-run --user --pty --quiet --property=CPUSchedulingPolicy=idle chrt -p 0
pid 540's current scheduling policy: SCHED_IDLE
pid 540's current scheduling priority: 0

 

[Caramon2]

Werde ich nächstes Mal testen.

Ich werde es dann auch mit dem p7zip-Bench gegentesten, da das ja kein AppImage ist:

"7z b 99 -md22" damit es lange genug läuft und nicht ständig die Wörterbuchgröße wechselt.

Nachtrag:

Da du in dem Skript lanczos nutzt, wollte ich dir noch schreiben, dass spline die gleiche Qualität liefert, aber deutlich schneller ist, hatte es aber vergessen.

Selbst im direkten Einzelbildvergleich per Win+Tab gibt es höchstens minimale Unterschiede. Weder besser noch schlechter, nur anders.

Deshalb nutze ich Spline auch bei der MPV-Konfiguration neulich.

 

[Uridium]

aber statt nur die zu nutzen (was idle-Priorität bedeuten würde und wie ich es gerne hätte: eben wie früher bei Windows), wird die Rechenzeit nahezu gleichmäßig auf beide verteilt

So richtig dufte läuft das in der Tat nicht. 'autogroups' will ich jetzt nicht unbedingt abschalten. Von 'sched_idle' und systemd-run als cgroups Manager hatte ich mehr erwartet. Das Einzige, was merklich anspricht, ist 'CPUQuota', also hardlimit (100%=1 Kern, vermutlich).

$ time -p systemd-run --user --pty -d -p CPUQuota="200%" ffmpeg -y -f lavfi -i colorspectrum=duration=60:size=1280x720:rate=30 /tmp/file01.mp4

 

[Caramon2]

So richtig dufte läuft das in der Tat nicht. 'autogroups' will ich jetzt nicht unbedingt abschalten.

chithanh hatte auch diesen reddit-Thread verlinkt, aber bevor ich mich da in Ruhe einlesen konnte, war dieser Streik und der Thread gesperrt, so dass ich dann drüber weg gekommen bin.

Inzwischen ist mir das nicht mehr so wichtig, da der Kernel das viel besser macht und selbst 10-20 parallel encodenden Videos (kommt gelegentlich mal vor) stören nicht mehr gravierend.

Außerdem habe ich gestern endlich (ENDLICH! (ENDLICH!!!)) herausgefunden, wie man AVIdemux im Terminal nutzt: Ich habe über viele Jahre immer mal wieder gesucht, bin aber irgendwie nie darauf gestoßen, oder habe es irgendwie übersehen, oder was auch immer. - Und "avidemux3_cli --help" bringt einen überhaupt nicht weiter, weil das ungeheuer viel Mist raushaut, schlimmer noch als die MS-AGB bei der Installation von Windows: s. A. (als "code" war mir das zu viel…)

Dabei ist das so einfach, wenn man weiß wie es geht, da man per "--run" einfach die Konfigurationen der GUI-Version nutzen kann:

avidemux3_cli --load input.ts --run delogo.py --run konfig.py --save output.mkv > /dev/null

">/dev/null", da da das Ding auch dabei so ungeheuer viel raushaut, dass man sowieso nichts erkennen kann und es sogar das encoding verlangsamt.

Passend kamen diese Nacht alle 7 Folgen von "Raumpatrouille" (war vor meiner Zeit - ich kenne nur Bruchstücke) und das in einer überraschend guten Qualität, damit werde ich das gleich testen:

(li/re entferne ich 152 Pixel, so dass das "one" noch ganz drauf ist: da es bis in den schwarzen Rand reicht, kann man DeLogo leider nicht vernünftig nutzen)​

 

[Caramon2]

Von 'sched_idle' und systemd-run als cgroups Manager hatte ich mehr erwartet.

Ich habe es eben mit dem 7zip-Bench vergleichen, da funktionierte das ziemlich gut: Wenn der normal gestartete gerade voll benchte (leider ziemlich kurze Intervalle), bekam der geidlete nur noch 8% (von 800%) CPU-Last.

Beide normal gestartet und einen per nice auf niedrigste Priorität gesetzt, ging die CPU-Last zwar auch bis auf 11 % runter, aber deutlich später und kürzer: Durchschnittlich hat der schätzungsweise noch an die 100% (von 800%) bekommen. - Dto. bei Artix-Runit (Kernel 6.9).

Btw:

Bzgl. Screencapturerecoding habe ich gerade ein 1 Min./492 kiB FullHD-Video geposted ("kontrastreiches"-Voreinstellung, q30, max. 1000 Frames/GOP): Wie man von einer OPAL-verschlüsselten SSD bootet.

 

[Uridium]

Artix-Runit (Kernel 6.9).

Was sagt:

$ cat /proc/sys/kernel/sched_autogroup_enabled

Wie man von einer OPAL-verschlüsselten SSD bootet.

Wird im Fx/Desktop nur als Anhang angezeigt (kein Player). Die Handy HW-Decoder nehmen das auch nicht (grau). Keine Keyframes (wahrscheinlich deshalb, kein >>FFWD). YUV420 (RGB>YUV>RGB). Die 4:2:0 Matrix sieht man sofort, z.B. an der artix url (cyan auf schwarz).

 

[Caramon2]

Was sagt:

$ cat /proc/sys/kernel/sched_autogroup_enabled

Ich hatte das bei beiden nicht geändert, aber bei LMDE (in der VM) ist es deaktiviert:

Das liegt nicht an der VM: Artix zeigt auch dort "1", egal ob Kernel 6.9 oder 6.6-LTS (ich habe beide installiert: den LTS als Backup, falls es mal mit einer ganz neuen Kernelversion Probleme gibt).

Wird im Fx/Desktop nur als Anhang angezeigt (kein Player). Die Handy HW-Decoder nehmen das auch nicht (grau). Keine Keyframes (wahrscheinlich deshalb, kein >>FFWD). YUV420 (RGB>YUV>RGB). Die 4:2:0 Matrix sieht man sofort, z.B. an der artix url (cyan auf schwarz).

Bei der Qualität kam es mir darauf an, es so stark wie möglich zu komprimieren, ohne dass störende Artefakte auftreten: Es soll nicht perfekt sein, sondern man soll nur alles gut erkennen können.

Bei mir auf dem PC (Opera) ist es genauso und es gibt nicht mal eine DL-Möglichkeit. Wenn ich es anklicke, öffnet sich ein schwarzer Tab mit einem "toten" Player und es gibt auch dort keine Möglichkeit es runterzuladen:

Das lokale Video lässt sich mit Hardwaredecoding abspielen:

Es hat I-Frames: Gleich den ersten und einen nach 40 Sek. (eben 1000 Frame GOPs bei 25 fps)

Beim Handy (Opera) wird es als Video angezeigt und lässt sich normal abspielen.

Das blöde ist, dass man hier kein mkv anhängen darf:

Angeblich (ich hatte extra gefragt) weil mkv alle möglichen Codecs enthalten kann und deshalb ggfs. nicht von allen abspielbar ist. - mp4 wäre viel kompatibler…

Ich habe nochmal 0x0.st genutzt. Du kannst es ja mal vergleichen:

wget -c https://0x0.st/Xb2o.mp4/OPALencypted.mp4

Wenn ich den Link im Browser ausführe, habe ich wieder obigen "toten" Player: Der ist offenbar von Opera und das liegt vermutlich daran, dass ich die "opera-ffmpeg-codecs" installiert habe: Schon wegen meiner Internetverbindung sehe ich keine online-Videos und will erst recht nicht, dass sie sogar automatisch starten.

…

Nö, auch mit installierten "opera-ffmpeg-codecs" bleibt der Payer "tot" (egal ob CB oder 0x0.st): Den Browser hatte ich extra neu gestartet.

Wenn ich es als mkv hochlade und den Link mit Operaöffne (die codecs sind noch installiert), wird dieser Player gar nicht erst geöffnet, sondern es gleich heruntergeladen:

https://0x0.st/Xb2N.mkv/OPALencypted.mkv

Btw:

Jetzt habe ich auch verstanden, wie dort das "umbenennen" funktioniert: Gar nicht.

Man hängt stattdessen an den Originallink einfach den Namen an, unter dem es heruntergeladen werden soll.

 

[Uridium]

'mediainfo' zeigt 'keyint=1000‘. Das ist wahrscheinlich viel zu heftig für kleine ASICs. Wobei 'mediainfo' immer noch 'High@L4' anzeigt, was die Kompatibilität eigentlich gewährleisten sollte.

$ ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 OPALencypted.mp4 | awk -F',' '/K/ {print $1}'
0.080000
40.080000

Zwei Keyframes. Da die B und P Frames von den I-Frames abhängig sind, in beide Richtungen, wird das wahrscheinlich enorm Speicher benötigen.

 

[Caramon2]

1000 Frames/GOP sind das Maximum, was man bei AVIdemux einstellen kann, weshalb ich davon ausgehe, dass das zulässig ist.

Da nicht mal meine Satreceiver damit Probleme haben (nur der Bildsuchlauf wird dann ziemlich lahm), hatte ich nicht gedacht, dass das irgendwo ein Problem sein könnte. Beim normalen abspielen sollte es nicht mal etwas ausmachen, da ja immer nur die Unterschiede zum jeweils nächste Frame decodet werden müssen.

Ich hänge mal ein paar Test-Videos an (werde ich in einigen Tagen wieder löschen): Mit q40 recodet und mit 1000, 500 und 250 Frames/GOP (=Standard). Letzteres dafür auch noch als v1: Die anderen habe ich in "MP4v2" gespeichert.

Ich habe bisher immer "v2" genutzt (wenn ich MP4 nutzen musste), da "neuer=besser" - Macht das überhaupt einen Unterschied?

Edit:

Bei mir sind alle vier Anhänge grau, bei allen vier gibt es den "toten" Player und eine Download-Option gibt es auch nirgends. - MP4 ist ja sowas von kompatibel…

Edit:

Auf dem Handy (Poco M3 mit inzwischen Android 12) funktioniert dagegen alle vier Videos problemlos.

Und wenn ich sie herunterlade, auch local. - Wobei der Player beim scrollen nur die I-Frames anspringt: Also beim 1000er nur den Anfang und 40s.

 

[Uridium]

Das v1 funktioniert. Besser und neuer ist v2 (entgegen dem Namen wohl nicht). Nur eine gänzlich andere library.
https://avidemux.org/smif/index.php?topic=18515.0
Ich glaube, den gleichen Fehler habe ich auch schon mal gemacht.

 

[Caramon2]

Ich hatte das Gegenteil vermutet: Da MP4 ziemlich restriktiv ist (sozusagen das Windows der Videocontainer), wäre v2 eine Erweiterung.

Da bei meinem PC auch das v1 nicht funktioniert, werde ich es später noch mit meiner LMDE-Testinstallation versuchen: Dort habe ich Gnome-Web (epidingsbums) installiert.

 

[Caramon2]

@Uridium : Ich wollte einen Rundumschlag machen:

Test-1000.mkv, Test-1000.raw, Test-1000.ts, Test-1000.m2ts, Test-1000v1.mp4, Test-1000.mov, Test-1000.avi

Leider wurde außer dem .mp4 nur noch das .mov angenommen: Teste die bitte noch.

Als ich das AVI speichern wollte, meckerte AVIdemux:

Ich habe alle obigen Videos als .7z angehängt: Da alle den selben Videostream nutzen, ließen sie sich auf 9% komprimieren.

Das .raw ist davon das einzige, das MPV nicht mag:

Failed to recognize file format.
Exiting... (Errors when loading file)

Der Gnome-Web (43.1) beim ansonsten standardmäßig installierten LMDE 6 hatte übrigens mit keinem der oben angehängten Videos Probleme (Vorschau und abspielen) und auch das https://0x0.st/Xb2o.mp4/OPALencypted.mp4 hat er anstandslos abgespielt.

Das hat mich überrascht, da der ansonsten die meisten Probleme macht: Ich habe ihn dort nur installiert, weil er von allen verfügbaren Browsern am wenigsten Platz brauche und ich einen Browser habe, falls ich mit der LMDE-Testinstallation doch mal was im Internet nachsehen will. - Ich glaube, das war eben sogar die Premiere.

 

[Uridium]

Von den Test-1000.7z funktioniert keines auf dem Handy, bzw. nur mit sw-decoder. Von den Videos einen Post zuvor geht nur das Test-250v1.mp4.

 

[Caramon2]

Von den Test-1000.7z funktioniert keines auf dem Handy, bzw. nur mit sw-decoder.

Mein Handy kann davon nur mit den *ts und dem .raw nichts anfangen. Alle anderen spiel es flüssig ab. - Ob hw/sw ich nicht nicht sagen, da ich nicht weiß, woran ich das erkennen kann.

Von den Videos einen Post zuvor geht nur das Test-250v1.mp4.

Also nicht mal das Test-1000v1.mp4?

Würdest du das bitte genauer aufstellen?

Also für PC und Handy jeweils OS+Browser+Relevantes: Welche Vorschaubilder gezeigt und welche Videos wirklich abgespielt werden können.

Es geht dabei ausschließlich um die Videos von Post #51. Das Test-1000.7z spielt keine Rolle mehr.

Ich möchte mich an CB wenden, da dort etwas nicht passt:

Weil Gnome-Web (LMDE 6) mit keinem der Vorschaubilder und Videos Probleme hat, habe ich es dort auch mit Opera versucht und anschließend auch noch mit Google-Chome.

Opera und Web habe ich als Beispiel nebeneinander geöffnet: s. Anhang


LMDE 6, Kernel 6.7, alle Browser in ihrer Standardkonfiguration:

Gnome-Web mit AD-Blocker: Alle Vorschaubilder werden gezeigt und alle Videos werden problemlos abgespielt.

Opera mit auf CB deaktivierten AD-Blocker *): Alle Vorschaubilder sind grau und bei allen Videos öffnet sich nur der "tote" Player: s. o.
*) der AD-Blocker macht aber keinen Unterschied

Google-Chrome: Alle Vorschaubilder werden gezeigt, alle MP4-Videos werden problemlos abgespielt und beim .mov startet stattdessen der Downlkoad.

Dabei spielt es in keinen Fall eine Rolle, ob ich im Willkommens-Assi die Multimedia-Codecs installiert habe, oder nicht. - Da ich die noch nie gebraucht habe, installiere ich die normalerweise nicht.


Poco M3 64 GB, Android 12:
(damals aus dem Wintersale)

Opera mit aktivierter Komprimierung (deaktivieren ändert aber nichts): Einige der Vorschaubilder (immer mal andere) werden angezeigt und der Rest bleibt grau, aber trotzdem lassen sich alle MP4-Videos abspielen, nur beim .mov startet der Download.

Manchmal "verschluckt" sich Opera aber, dann sind alle Vorschaubilder grau und ich bekomme dann bei allen einen "toten" Player, wie beim Desktop-Opera.

 

[Uridium]

Ich kann den Fehler nicht nachstellen, egal wie ich mit ffmpeg kodiere (10 bframes, GOP=1000, etc).
Auch ein remultiplexen (-c copy) der 250.mp4 (mp42) in den normalen MP4 Container (mp41) repariert das nicht. ffprobe zeigt bei allen Files 'Truncated VUI' (Video Usability Information), außer bei 250v1.mp4 (was funktioniert). Da würde ich ansetzen (anders encoden). Keine Ahnung, wie Du das kodiert hast (AviDemux?), aber offenbar ist der h264 Stream nicht ganz sauber und irritiert einige Player/Browser/etc.

Unten bei '250v1.mp4' kommt keine Fehlermeldung und er springt sofort zum nächsten (500.mp4).

$ for f in *.*; do echo -e "\033[1;35m$f\033[0m"; ffprobe -v warning "$f"; done
1000.mov
[h264 @ 0x5a37d4630d80] Truncated VUI (0)
    Last message repeated 1 times
[h264 @ 0x5a37d466e9c0] Truncated VUI (0)
1000.mp4
[h264 @ 0x56283c144d80] Truncated VUI (0)
    Last message repeated 1 times
[h264 @ 0x56283c179500] Truncated VUI (0)
1000v1.mp4
[h264 @ 0x56b90d313d80] Truncated VUI (0)
    Last message repeated 1 times
[h264 @ 0x56b90d351900] Truncated VUI (0)
250.mp4
[h264 @ 0x56703e1e4dc0] Truncated VUI (0)
    Last message repeated 1 times
[h264 @ 0x56703e219580] Truncated VUI (0)
250v1.mp4
500.mp4
[h264 @ 0x5a5ad4725dc0] Truncated VUI (0)
    Last message repeated 1 times
[h264 @ 0x5a5ad475a540] Truncated VUI (0)

 

[Caramon2]

Keine Ahnung, wie Du das kodiert hast (AviDemux?),

Hatte ich geschrieben:

Meine "kontrastreiches"-Voreinstellung für AVIdemux (Kurzanleitung befindet sich im 7z), auf q30 und 1000 Frames/GOP geändert, mit der AppImage-Version encodet.

aber offenbar ist der h264 Stream nicht ganz sauber und irritiert einige Player/Browser/etc.

Genau darum geht es doch:

Bei welchen OS, Browser und Einstellungen tritt das bei dir auf und in welcher Form? - Eine einfach Aufstellung wie ich in #56.

Wie soll ich das gegentesten, wenn ich nicht weiß womit?

 

[Uridium]

Teste deine Videos mit ffprobe auf 'Truncated VUI', wie in dem Beispiel oben. Ändere die Encodereinstellungen bis der Fehler verschwindet.

Solange der Stream defekt ist, sind Fehler beim Abspielen irrelevant.

 

[Caramon2]

Teste deine Videos mit ffprobe auf 'Truncated VUI', wie in dem Beispiel oben. Ändere die Encodereinstellungen bis der Fehler verschwindet.

@1st: Die alten Anhänge habe ich gelöscht, da nicht mehr relevant.

Da meine Test-Videos vom bereits "kaputten" OPALencypted.mp4 (MP4v2) mit q40 (vorhin hatte ich versehentlich q30 geschrieben, da ich Screenrecords normalerweise damit recode) recodet, hatte ich gedacht, daher käme das und auch den AB 282 "Nightly" hatte ich in Verdacht, aber das konnte ich nicht reproduzieren:

Ich habe aufgezeichnet, wie ich es mit beiden ADs als MP4v1 recodet habe und es kam zu keinen Truncated VUI.

Anschließend habe ich die Aufzeichnung mit q30 recodet und auch das war i. O.

Ich habe alle drei Videos und den Screenshot nach dem letzten angehängt: Da es bei keinem ffprobe warnings gibt, müssten alle abspielbar sein.

Edit: Mit dem MP4v2 produzieren dagegen beide ADs Truncated VUI: Unabhängig von der GOP-Größe.

Solange der Stream defekt ist, sind Fehler beim Abspielen irrelevant.

Wobei ich mich frage, was ein Browser (welcher auch immer das ist) taugt, der bei online-Videos offenbar kein Bisschen Fehlertolerant ist: Als würde es niemals Störungen in der Übertragung geben können.

Opera ist dagegen konsequent und spielt gar keins ab.

Wobei es da offenbar an fehlender h264-Unterstützung liegt: Bei LMDE6 gibt es nicht mal ein mit "opera-ffmpeg-codecs" vergleichbares Paket zum nachinstallieren.

Jedenfalls kann es die "kaputten" Videos auch nicht abspielen, wenn ich es in mein Drive (das übrigens auch keine Probleme mit denen hat) hochgeladen habe: Test-1000.mp4 (=v2), Test-1000v1.mp4

Sowohl Google-Chrome, als auch Gnome-Web, spielen sie dagegen problemlos ab.