VMS 16 Crash mit .m2ts files

nepomuk schrieb am 06.03.2019 um 18:18 Uhr

VMS 16 crashed (keine Rückmeldung, not responding…) regelmässig beim Versuch, .m2ts files, die z.B. von ffmpeg erzeugt wurden) einzulesen. Jeder player (HW, SW, streaming zu TV) öffnet und spielt diese Files problemlos und ruckelfrei. (Falls das File durch VMS über lange Zeit indexiert wird o.ä, sollte VMS dies zumindest anzeigen).

Meine Frage:
Welche Formate / Container akzeptiert VMS 16 überhaupt? Die Dokumentation sagt dazu wenig, oder habe ich da etwas völlig übersehen?

Verstehe nicht, wieso andere SW mit diesen Files problemlos umgehen kann, ausser eben VMS 16 Platinum. Ähnliches gilt übrigens auch für DVD Architekt, auch mit dem neuesten Build 100.

Kommentare

Marco. schrieb am 06.03.2019 um 18:26 Uhr

Kannst du das FFmpeg-Script, mit dem du zu M2TS transcodiert hast, zur Verfügung stellen? Dann könnte ich es hier genauer unter die Lupe nehmen.

nepomuk schrieb am 06.03.2019 um 20:28 Uhr

Hallo Marco

Danke, dass du da mal reinschaust. Anbei 2 scripts. Die Encodierung läuft sowohl für CPU als auch für GPU (8x schneller) problemlos.

Script für CPU:
ffmpeg.exe -i "C:\input.M2T" -map 0:0 -map 0:1 -c:a ac3 -ab 640k -metadata:s:a:0 language=deu -disposition:a:0 default -async 1 -c:v libx264 -crf 18 -maxrate 40000k -bufsize 30000k -r 24000/1001 -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -bsf:v h264_mp4toannexb -profile:v high -preset medium -level 41 -partitions partb8x8+partp4x4+partp8x8+parti8x8 -aq-mode 1 -b-pyramid 1 -nal-hrd vbr -bluray-compat 1 -psy 1 -weightb 1 -8x8dct 1 -fast-pskip 1 -direct-pred 1 -coder ac -trellis 1 -me_method hex -flags +loop -mbd rd -sc_threshold 40 -keyint_min 24 -g 24 -qmin 1 -qmax 51 -qdiff 4 -f mpegts -mpegts_m2ts_mode 1 -slices 4 -f mpegts -sn -y "output.M2TS"

Script für GPU:
ffmpeg.exe -hwaccel cuvid -i "input.M2T" -map 0:0 -map 0:1 -c:a ac3 -ab 640k -metadata:s:a:0 language=deu -disposition:a:0 default -async 1 -c:v h264_nvenc -b:v 9000k -maxrate 18000k -bufsize 18000k -r 24000/1001 -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -bsf:v h264_mp4toannexb -level 41 -coder ac -trellis 1 -me_method hex -subq 7 -me_range 16 -bf 1 -b_strategy 1 -flags +cgop -mbd rd -sc_threshold 40 -keyint_min 24 -g 24 -qmin 1 -qmax 51 -f mpegts -mpegts_m2ts_mode 1 -slices 4 -f mpegts -sn -preset bd -cq 25 -bluray-compat 1 -y "output.M2TS"

 

Marco. schrieb am 06.03.2019 um 21:09 Uhr

Das GPU-Script kann ich leider nicht verwenden, da spuckt FFmpeg nur Fehlermeldungen aus.

Beim Clip, der mit dem CPU-Script transcodiert wird, kann ich den Crash (bzw. vielmehr einen Freeze) sowohl mit Movie Studio16 als auch mit Vegas Pro 16 reproduzieren, sobald ich den Clip im Explorer anklicke, selbst mit Sony Vegas Pro 13.

Allerdings ist das nicht generell ein Problem mit M2TS-Clips, denn andere Clips dieser Art, die von Kameraaufnahmen stammen, funktionieren bei mir in Movie Studio und Vegas Pro problemlos. Da muss wohl irgendeine Encoding-Eigenschaft dazwischenfunken.

Ich werde es mir mal genauer ansehen und einen Bugreport dazu senden.

Nachtrag:
Also zumindest ist es eine der Encoding-Einträge, die die Datei für Movie Studio/Vegas Pro untauglich macht. Wenn ich das Script stark vereinfache und einige Einträge lösche, funktioniert die Datei. Ich versuche noch rauszufinden, welcher Eintrag oder welche Einträge es sind, die das Problem verursachen.

nepomuk schrieb am 06.03.2019 um 22:56 Uhr

Schon mal gut zu wissen, dass du das Problem nachvollziehen kannst. Wie es scheint, hab ich das Fuder mit den encoding Parametern etwas überladen. Die sollten zwar alle "compliant" sein, aber eben …. Vielleicht gibt es Probleme mit b-Pyramids. Ich werde auch selber mal etwas zurückstecken.

Die GPU Variante können wir ruhig mal zurückstellen. Funktioniert so nur mit NVidia Grafikkarte, und gewisse Parameter sind vermutlich nicht anwendbar. In der Regel führen diese zu einer Warnung in ffmpeg und werden einfach ignoriert. Das Encoding funktioniert dann trotzdem.

Marco. schrieb am 06.03.2019 um 23:42 Uhr

Ich bin leider nur einen winzigen Schritt weitergekommen. Wenn ich folgende Einträge im CPU-Script lösche, kann ich im Explorer von Vegas Pro und Movie Studio die Clips schonmal anklicken, ohne dass die Programme einfrieren. Ich kann die Clips auch in die Timeline ablegen. Aber wenn ich dann versuche sie abzuspielen, stürzen die Programme mit Fehlermeldung ab (auch wenn die GPU-Beschleunigung unter Optionen/Präferenzen/Video deaktiviert ist). Gelöscht habe ich bisher:

-b-pyramid 1
-bluray-compat 1 
-keyint_min 24 
-g 24 
-qmin 1 
-qmax 51 
-qdiff 4

nepomuk schrieb am 06.03.2019 um 23:57 Uhr

Ja, ich bin auch nicht schlauer geworden. Ich beginne an FFmpeg zu zweifeln.... MediaInfo zeigt am Schluss einen ungewöhnlichen Eintrag, der mit "Menu" beginnt.
Allerdings wundert mich dann wieder, warum sich die Files mit anderer (nicht VEGAS) Video Software und Playern öffnen und abspielen lassen. Merkwürdig.

Marco. schrieb am 07.03.2019 um 00:24 Uhr

Ich denke, ich habe es.

Ich habe aus dem Script (zusätzlich zu den oben gelisteten Einträgen) zunächst den Eintrag "-nal-hrd vbr" gelöscht. Meines Wissens tut der nichts weiter, als den Bitratenmodus zu erzwingen, was aber im CRF-Modus nicht nötig oder sogar kontraproduktiv sein sollte (weil das unter CRF eigentlich immer eine automatisch optimierte VBR sein sollte). Eigentlich kannte ich den Eintrag bisher sogar nur als "-nal-hrd cbr", um also eine konstante Bitrate zu erzwingen.

Außerdem habe ich die Einträge "-maxrate 40000k" und "-bufsize 30000k" gelöscht, weil die meiner Meinung nach ebenfalls durch den CRF-Modus automatisch optimal gesteuert sein sollten. In der Praxis wird vermutlich ein HD 24p-Clip als H.264 mit CRF 18 codiert selten die 40 Mbit/s sprengen.

Mein Script sieht jetzt also so aus (ich nutze es grundsätzlich immer in der Drag&Drop-Variante, damit ich nicht wegen Input und Output die Dateien einzeln anpassen muss):

@echo off
:next
if "%~1"=="" goto done
ffmpeg.exe -i "%~1" -map 0:0 -map 0:1 -c:a ac3 -ab 640k -metadata:s:a:0 language=deu -disposition:a:0 default -async 1 -c:v libx264 -crf 18 -r 24000/1001 -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -bsf:v h264_mp4toannexb -profile:v high -preset medium -level 41 -partitions partb8x8+partp4x4+partp8x8+parti8x8 -aq-mode 1 -psy 1 -weightb 1 -8x8dct 1 -fast-pskip 1 -direct-pred 1 -coder ac -trellis 1 -me_method hex -flags +loop -mbd rd -sc_threshold 40 -f mpegts -mpegts_m2ts_mode 1 -slices 4 -sn -y "%~1_new.M2TS"
shift
goto next
:done
exit

 

nepomuk schrieb am 07.03.2019 um 00:36 Uhr

Ich werde das morgen mal so probieren. Die -maxrate und -bufsize parameter müsste man allerdings setzen können auch im CRF modus, sonst kann es bei Blu-ray zu Bufferproblemen kommen (Unterlauf / Ueberlauf) oder Bitratenspitzen, was u.U. bereits beim Disk Erstellen (Stichwort Buffer Verifier) Probleme macht oder beim Playback (Stottern oder Abbruch). Dies wurde bei der x264 Entwicklung viel diskutiert.

Marco. schrieb am 07.03.2019 um 00:50 Uhr

Das mag sein, aber du brauchst diese Parameter doch nicht, wenn die Clips zur Bearbeitung ins Schnittprogramm gehen. Da wird am Ende ja eh neu codiert. Anders ausgedrückt: Die Clips sollten zunächst nicht Blu-ray-optimiert, sondern schnittoptimiert sein.

Marco. schrieb am 07.03.2019 um 09:58 Uhr

Also das oben zitierte Script funktioniert zwar soweit, ich knie aber immer noch über diverse andere Parameter, die für mich in diesem (ursprünglichen) Script nicht schlüssig sind.

So taucht beispielsweise "f mpegts" doppelt auf (das hatte ich in meiner Variante schon korrigiert). Dann wird am Ende "-sn" verwendet, was nichts anderes tun sollte, als das Lesen von Untertiteln zu unterdrücken. Aber am Anfang wird schon durch die verwendeten Mapping-Parameter das Lesen von Untertiteln unterdrückt. Und summa summarum widerspechen meiner Meinung nach etliche Parameter der Verwendung des CRF-Modus. der dadurch derart limitiert wird, dass er mir fast nutzlos erscheint.

Für die Verwendung der Clips in einer Schnittsoftware wäre womöglich eine starke Entschlackung nicht von Nachteil. Und ich würde dafür nicht das M2TS-Dateisystem, sondern schlicht MP4 benutzen, was unter anderem den Vorteil hat, dass Movie Studio dazu eine modernere Decoding-DLL benutzt.

nepomuk schrieb am 07.03.2019 um 10:00 Uhr

Ich habe deinen Script versucht. Sowohl VMS16 als auch DVDA frieren weiterhin sofort ein. Ich verwende ffmpeg v4.1.1 64 bit (static, stable) von Zeranoe.

Ich versuche, den Script noch weiter zu vereinfachen (keine B-frames usw.), verstehe allerdings nicht, warum nur die VEGAS Produkte mit den Files nicht zurechtkommen...…...

 

nepomuk schrieb am 07.03.2019 um 10:07 Uhr

Du hast recht, es gibt redundante Einträge in meinem ursprünglichen Script. Die hab ich in der Zwischenzeit auch entfernt. Ob die Redundanzen das Problem sind, bezweifle ich allerdings (ist entgegen meiner Erfahrung). Ich raufe mir weiterhin die Haare …. ;-)

Marco. schrieb am 07.03.2019 um 10:54 Uhr

Ich miste da gerade Schritt für Schritt aus. Auch "-metadata:s:a:0", "language=deu" und "-disposition:a:0 default" scheinen mir für die Verwendung in einer Schnittsoftware unnötig.

Und "-async 1" dürfte nur verwendet werden, wenn es bei den Originalclips Probleme mit Bild-Ton-Synchronität gibt.

nepomuk schrieb am 07.03.2019 um 11:00 Uhr

Dieser Script funktioniert bei mir, ohne dass VMS und DVDA gleich einfrieren: keine B-frames. Das ist doch verwunderlich. -maxrate und -bufsize sind noch enthalten, kann ich aber auch noch eliminieren, wenn's daran liegen sollte.

ffmpeg.exe -i "in.M2T" -map 0:0 -map 0:1 -c:a ac3 -disposition:a:0 default -async 1 -c:v libx264 -crf 18 -maxrate 40000k -bufsize 30000k -r 24000/1001 -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -bsf:v h264_mp4toannexb -preset medium -level 41 -partitions partb8x8+partp4x4+partp8x8+parti8x8 -aq-mode 1 -bluray-compat 1 -weightb 0 -8x8dct 1 -fast-pskip 1 -direct-pred 1 -coder ac -trellis 1 -me_method hex -me_range 16 -bf 0 -flags +loop+cgop -mbd rd -sc_threshold 40 -keyint_min 24 -g 24 -qmin 2 -qmax 51 -qdiff 4 -f mpegts -mpegts_m2ts_mode 1 -slices 4 -y "out.M2TS"

Werde noch versuchen, von hier aus wieder "aufzustocken". Etwas unverständlich, warum VEGAS so "wählerisch" ist.

nepomuk schrieb am 07.03.2019 um 11:16 Uhr

Obiges Script mit -nal-hrd vbr wieder zugesetzt (obwohl eventl. unnötig) funktioniert immer noch …..

nepomuk schrieb am 07.03.2019 um 11:31 Uhr

… und mit 2 B-frames: Einfrieren.
Meine vorläufige Schlussfolgerung (richtig oder falsch?): VEGAS akzeptiert max. 1 B-Frame

Das Problem ist dann noch, falls sich zusätzlich noch 1 File mit >1B-Frame im selben Verzeichnis befindet und VEGAS diese Verzeichnis beim Starten öffnet => einfrieren

nepomuk schrieb am 07.03.2019 um 11:42 Uhr

Ich erinnere mich nun an vergangene Diskussionen zum Thema SONY Playstation (ich habe selber keine) und Anzahl B-Frames und B-Pyramiden: Da gab es einige Inkompatibilitäten und Einschränkungen. Verwendet VMS und DVDA immer noch alte Dekoder?

Marco. schrieb am 07.03.2019 um 11:48 Uhr

Also mein Standard-Quellformat ist oft H.264 im MTS-Container mit 2 B-Frames zwischen den P- und I-Frames. Diese Clips laufen in Movie Studio und Vegas Pro seit Jahren problemlos.

Wenn, dann ist es eine Verknüpfung der B-Frames mit anderen Parametern des Scripts.

Aber warum tust du es dir so schwer und versuchst das Script so umfangreich wie möglich zu belassen, anstatt es so einfach und betriebssicher wie möglich zu gestalten? Und warum M2TS als Format zur Bearbeitung?

Marco. schrieb am 07.03.2019 um 12:21 Uhr

Im folgenden Script (wieder als Drag & Drop) ist alles ausgemistet, was mir im CRF-Modus und für die Bearbeitung der Clips redundant erscheint. Außerdem M2TS gegen MP4 getauscht und AC3 gegen das effizientere AAC. Erzeugt je 3 B-Frames und funktioniert bei mir in Vegas Pro und Movie Studio bestens.

@echo off
:next
if "%~1"=="" goto done
ffmpeg.exe -i "%~1" -map 0:0 -map 0:1 -c:a aac -ab 320k -c:v libx264 -crf 18 -r 24000/1001 -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -bsf:v h264_mp4toannexb -profile:v high -preset medium -level 41 -y "%~1_new.mp4"
shift
goto next
:done
exit

 

nepomuk schrieb am 07.03.2019 um 12:24 Uhr

Ja, wenn man nur wüsste, was "so einfach wie möglich" nun tatsächlich ist. Die Dok sagt dazu einfach nichts, und ein Einfrieren spricht auch nicht unbedingt für Qualitätssoftware. Gewisse x264 Parameter erhöhen die Komprimierung respektive die Qualität bei gleicher Zielgrösse.

Was ist nicht gut mit M2TS? M2TS oder MTS kommen zum Beispiel aus Videocams, und die wenigen .mp4 VFR konvertiere ich nach .m2ts CFR. Warum soll ich zuerst alles Umtopfen? Desweiteren versuche ich auch, x-Neucodierungen und Umformatierungen zu vermeiden. Das ist der Qualität nicht unbedingt zuträglich und braucht viel Zeit (mal ganz abgesehen von der Pröbelei; du hast wohl auch sehr viel Zeit aufgewendet).
Ich editiere bei weitem nicht alles mit VMS, sondern möchte Blu-ray kompatible Files direkt mit DVDA authoren - vorausgesetzt, DVDA friert nicht ein.

Meine Hauptkritik gilt dem Einfrieren - ohne Fehlermeldung. Man steht im Regen ;-)

Marco. schrieb am 07.03.2019 um 13:47 Uhr

»Ich editiere bei weitem nicht alles mit VMS, sondern möchte Blu-ray kompatible Files direkt mit DVDA authoren«

Wenn DVD Architect nicht mit aus Movie Studio (oder Vegas Pro) gerenderten Blu-ray-kompatiblen Dateien gefüttert wird, wird er ohnehin neu kodieren. FFmpeg-codierte Clips wird DVD Architect nicht nativ fürs Preparing übernehmen.

»Gewisse x264 Parameter erhöhen die Komprimierung respektive die Qualität bei gleicher Zielgrösse.«

Ja, das ist für einige einzelne Parameter zutreffend, aber das Zusammenspiel ist in diesem Script nicht stimmig bzw. einige Parameter sind noch immer redundant, weil sie automatisch gesetzt werden würden. Es ist doch meist eine Frage des gesunden Kompromisses, um letztlich zu einem optimalen Gesamtziel zu kommen.
Ich handhabe das daher eher so, dass ich von einem minimalistischen und (für Movie Studio/Vegas Pro) funktionierenden Script ausgehe und dann nur das ergänze, von dem ich mir sicher bin, dass es zu anderen Parametern stimmig bleibt und auch effektiv was bringt.

nepomuk schrieb am 07.03.2019 um 14:41 Uhr

"Wenn DVD Architect nicht mit aus Movie Studio (oder Vegas Pro) gerenderten Blu-ray-kompatiblen Dateien gefüttert wird, wird er ohnehin neu kodieren. FFmpeg-codierte Clips wird DVD Architect nicht nativ übernehmen."

Hmmm….. interessant. Nun akzeptiert aber DVDA die nach meinem letzten Script codierten M2TS files, erklärt sie als kompatibel (grüne Häkchen für video und audio), die explizit keine Neukodierung erfordern. Dazu muss ich allerdings die Parameter -maxrate und -bufsize entsprechend setzen - was auch Sinn macht für Blu-Ray Kompatibilität. Mal sehen, ob trotz alledem neukodiert wird und was dabei rauskommt. Vielleicht krieg ich doch noch alles auf die Reihe.

"Wenn ich damit beispielsweise hochwertige 4k-Aufnahmen zu HD transcodiere, limitiert mir das Script die Datenrate gegenüber dem Standard-CRF-Modus (bei gleichem Faktor) die Datenrate auf weniger als ein Viertel und die Qualität ist deutlich schlechter."

Klar. Für 4k-Aufnahmen muss das Script natürlich angepasst werden. 4k Player haben auch viel höhere maximale Datenraten und grössere Puffer. Bin aber noch nicht bei 4k angelangt.

 

Marco. schrieb am 07.03.2019 um 14:53 Uhr

Es geht da ja nicht ums Generieren von 4k-, sondern HD-Clips, nur eben von hochwertiger Quelle, so dass überhaupt erst hohe Datenraten vonnöten sein sollten. Aber egal womit ich das Script füttere, es werden nie auch nur 10 Mbit/s erreicht, wo beim reinen CRF-Modus schon längst die 30 Mbit/s überschritten werden. Am Level kann es nicht liegen, denn 4.1 High gibt über 60 Mbit/s her. Da stehen sich meiner Meinung nach einfach ein paar Parameter gegenseitig im Weg und schaden dadurch möglicherweise eher als dass sie nützen würden.

Marco. schrieb am 07.03.2019 um 15:17 Uhr

»Nun akzeptiert aber DVDA die nach meinem letzten Script codierten M2TS files, erklärt sie als kompatibel (grüne Häkchen für video und audio), die explizit keine Neukodierung erfordern. Dazu muss ich allerdings die Parameter -maxrate und -bufsize entsprechend setzen - was auch Sinn macht für Blu-Ray Kompatibilität.«

Das wäre Pionierarbeit, denn meines Wissens hat das bisher niemand geschafft. Mir gelingt es allerdings auch nicht (mit deinem Script aus dem Posting von 11:00 Uhr). Da werden Video und Audio in DVD Architect neu codiert und auch schon so angewarnt.