staging.inyokaproject.org

Ich verwende Avidemux zum Schneiden von Filmen (Werbung entfernen) von heruntergeladenen Dateien ab teleboy.ch. Das hat alles bestens funktioniert. Ab letzter Woche hängt Avidemux. Ab einer gewissen Stelle (unterschiedlich bei verschiedenen Filmen) stoppt die Wiedergabe. Mit dem Regler nach vorne verschieben geht, jedoch bleibt das letzte Bild erhalten. Und beim erneuten Starten ab einer Position nach der Abbruchstelle, springt die Wiedergabe zurück vor diese Stelle und bricht danach wieder an derselben Stelle ab. Die Datei kann über andere Player (VLC, Mediaplayer am TV) fehlerfrei abgespielt werden, inkl. Vorspulen. Ich habe auch unterschiedliche Dateien versucht zu schneiden, alte und neuere, und das ist bei allen nicht mehr möglich weiter als ca. 1:40:00 bis 2:00:00 weiter abzuspielen oder weiter zu springen. Und wie geschrieben, letzten Sonntag hat das noch alles funktioniert. Und ich bin mir Sicher, dass ich nichts geändert habe. Die Systemressourcen sind nicht ausgelastet: RAM 4 GB von 32 GB verwendet, CPU ist auf < 10%. Avidemux Version: 2.7.4 Videoformat:

Merkwürdig...

Schon ~/.avidemux* gelöscht?

Falls das nix hilft: normalerweise rate ich nicht dazu, aber idF ist es einen Versuch wert: reinstallieren. Ja, ich weiß 😉

Also volles Programm mit purge, autoremove, update, upgrade, install.

Du nutzt das PPA?

Hallo Pepre

Das Löschen von ~/.avidemux* hat nicht geholfen und auch das Entfernen und neu Installieren nicht. Und ja, ich nutze das PPA. Also leider kein Erfolg. Jetzt habe ich nochmal andere (noch ältere Downloads) genommen und das funktioniert es. So wie es aussieht, haben die Dateien ab teleboy.ch ab einem gewissen Zeitpunkt ein für Avidemux ungültiges Format erhalten. Jetzt muss ich wohl auf die Suche, wie ich die Dateiformate von mp4 auf ihre Gültigkeit prüfen kann.

Danke und schönen Tag

Was für einen Container verwendet denn der Teleboy? mkv, avi, ts, mp4?

Und was ist da drin? Kuck mal mit

ffmpeg -i $inputfile

nach. Stell die Ausgabe hier ein, dann wissen wir mehr.

Du könntest die betroffenen Dateien einfach mal mit ffmpeg umpacken:

ffmpeg -i $inputfile -c copy out.mkv

Dann wüsstest du zumindest schon mal, ob da der Container (Zeitmarken zB) Probleme macht, den Teleboy ausliefert. Falls das kopieren schon scheitert, dann bitte die Ausgabe hier einstellen.

Hallo Pepre

Du bist richtig schnell. Cool. Der Output ist

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  configuration: --prefix=/usr --extra-version=0ubuntu0.18.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2020-03-21_22_30_TV24_Lethal-Weapon-2-Brennpunkt-L_A_.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42isomiso2iso5dashavc1mp41
  Duration: 02:34:36.02, start: 0.000000, bitrate: 5072 kb/s
    Stream #0:0(deu): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 4805 kb/s, 50 fps, 50 tbr, 1k tbn, 100 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
    Stream #0:2(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s
    Metadata:
      handler_name    : SoundHandler

Und wenn ich die Datei in mkv umwandle, kann ich sie auf Avidemux öffnen und auch an jede beliebige Stelle springen. Einzig wenn ich das dann schneide und als mp4 wieder ausgeben möchte, (VideoCodec MPEG4 AVC (x264)), dann dauert das jetzt sehr lange. Hier geschätzte 1H 20 Min. und die CPU (4 Kerne) geht auf 100%. Nicht gerade schön. Ich werde mal bei Teleboy nachfragen, denn ich habe da eine Vermutung. In der Schweiz wurde letztes Jahr etwas mit dem Urheberrecht verändert und Werbung darf nicht mehr automatisch übersprungen werden können. Ev. hat das damit zu tun. Danke erst mal. Ev. hast Du noch einen Tipp, wie ich das Konvertieren etwas schneller hinkriege. Ich werde meine Erkenntnisse hier einpflegen.

Schönen Sonntag

dr-feelgood schrieb:

Der Output ist

1 2 3 4 5

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2020-03-21_22_30_TV24_Lethal-Weapon-2-Brennpunkt-L_A_.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp42isomiso2iso5dashavc1mp41

Es ist also Dash (fragmentierter mp4 Container). Versagt das bislang letzte hochgeladene AppImage (200318) von Avidemux ebenso? –> https://avidemux.org/nightly/appImage4/

Falls ja, bitte das AppImage, ausführbar gemacht, im Terminal ausführen und die Ausgabe in eine Datei (hier: admlog.txt) umleiten

1

./avidemuxUniversal_amd64_200318_71.app > ~/admlog.txt 2>&1

admlog.txt dann bitte anonymisieren (den Benutzernamen in den Pfaden konsistent durch einen beliebigen Platzhalter ersetzen), komprimieren und an Antwort anhängen.

Einzig wenn ich das dann schneide und als mp4 wieder ausgeben möchte, (VideoCodec MPEG4 AVC (x264)), dann dauert das jetzt sehr lange. Hier geschätzte 1H 20 Min. und die CPU (4 Kerne) geht auf 100%.

Neukodierung ist natürlich zeitintensiv, sofern man keinen hardwarebeschleunigten Encoder nutzt (solche Encoder wie "Nvidia H264" und "Intel H264" sind zwar sehr schnell, aber für eine hohe Qualität muss man eine miserable Kompressionsrate in Kauf nehmen). Führt das Speichern im Kopiermodus wiederum zu einer nicht durchgängig dekodierbaren Datei?

Nicht gerade schön. Ich werde mal bei Teleboy nachfragen, denn ich habe da eine Vermutung. In der Schweiz wurde letztes Jahr etwas mit dem Urheberrecht verändert und Werbung darf nicht mehr automatisch übersprungen werden können. Ev. hat das damit zu tun.

Wenn die im Stream zwischendurch die Codec-Parameter verändern, kann das Avidemux nicht handhaben. Sowas würde das beobachtete Verhalten gut erklären. admlog.txt wird schon zeigen, was die Sache ist.

Hallo

Danke für den Tipp. Diese Version zeigt die identischen Symptome. Der Ouput sagt nach der Position 01:52:29,237 ein "[lavc] Invalid NAL unit size". Dazu habe ich dann keine weiteren für mich verständliche Informationen gefunden. Vielleicht könnt _Ihr noch etwas dazu sagen? Im Anhang der Output.

Danke und schönen Sonntagabend

dr-feelgood schrieb:

Danke für den Tipp. Diese Version zeigt die identischen Symptome. Der Ouput sagt nach der Position 01:52:29,237 ein "[lavc] Invalid NAL unit size". Dazu habe ich dann keine weiteren für mich verständliche Informationen gefunden.

Ah! The return of the NALUs... 🙄 Gute Güte, ist das lange her...

Ganz vereinfachtes Beispiel: ein Datensatz für ein Bild hat zB 1000 Byte. Die Standard-Paketgröße im Stream ist aber 1200 Byte. Dann kann man die fehlenden 200 Byte mit Nullen auffüllen. Macht zwar keinen Sinn, kann man aber. Wenn nun bei diesem Auffüllen Fehler passieren, wird's doof.

Mein Lösung dazu war: den Originalstream mit ffmpeg zu kopieren, denn ffmpeg schmeißt die NALUs weg:

ffmpeg -i input.mp4 -c copy out.mkv

Sollte funktionieren. Wenn nicht: hier und hier gibt's Genaueres dazu.

Schneiden tust du dann out.mkv. Wenn du dann avidemux anweist, Video und Audio zu kopieren statt zu kodieren geht auch das sehr fix.

Danke für das Log. Demnach ist alles, was Avidemux aus dem Container herausliest und an den Decoder weiterreicht ab einer bestimmten Stelle in der Datei invalid (zum Beispiel, um einige Bytes verschoben), weswegen libavcodec den an ihn übergebenen Puffer, der eigentlich genau einen Access Unit (sprich, Frame) enthalten soll, nicht in NAL Units aufdröseln kann.

Dass auch Audio genauso betroffen ist, lässt ein Problem beim internen Indexieren von fragmentierten mp4 in Avidemux vermuten, sofern

dr-feelgood schrieb:

Und wie geschrieben, letzten Sonntag hat das noch alles funktioniert.

schlicht ein Irrtum ist, falls sich diese Aussage auf eine und dieselbe Datei bezieht.

Wäre es möglich, eine solche Datei als Sample mittels WeTransfer, Mega, Dropbox oder Google Drive zu bekommen, um sich das Problem in echt anzuschauen?

Hallo zusammen

Danke erst mal für die Informationen. Leider kann ich im Moment nicht mehr genau nachvollziehen, welche Dateien ich letzten Sonntag verwendet habe, bzw. denke ich, dass ich "alte" Dateien verwendet habe, welche noch korrekt waren. Deswegen, kann es schon so sein, dass mein Ursprungseintrag zuwenig präzise war. Als Lösung würde ich sonst den Vorschlag von pepre nehmen. Falls eumagga0x2a noch weiter forschen möchte, kann ich so eine Datei gerne wo hochladen und den Link zukommen lassen. Es wäre sicher cool zu erfahren, was denn die Ursache ist. Ich habe teleboy.ch auch schon angeschrieben, um von dort Informationen zu erhalten. Auf jeden Fall habe ich viel gelernt. Danke dafür und schönen Abend

dr-feelgood schrieb:

Falls eumagga0x2a noch weiter forschen möchte, kann ich so eine Datei gerne wo hochladen und den Link zukommen lassen.

Das Interesse sicherlich besteht.