3D-Parameter in Metadaten setzen

Hallo machzwei, heute möchte einmal auf Deine wiederholten Vorschläge bezüglich der Vergleichsvideos eingehen. Da mir nicht ganz klar ist, was genau Du damit meinst, muß ich mal etwas ausholen:

Zum Vergleich benötigt man einen (oder mehrere) Vergleichskriterien und einen Änderungsparameter, gegenüber dem man den Vergleich durchführen kann.

Man könnte z.B. die Performance verschiedener Codecs vergleichen und als Maßstab für die Performance die bei konstanter Videoqualität benötigte Dateigröße verwenden. Aber obwohl es sicherlich nicht einfach ist, so einen Vergleich objektiv durchzuführen, denn "Videoqualität" läßt sich nur ganz schwer objektiv messen, dürfte das Ergebnis zumindest grob bekannt sein: Ganz vorne sollte der H265 (HEVC/AV1) Encoder liegen und ich wüßte nicht, welcher andere Encoder diesen Platz 1 streitig machen sollte. Auf den Plätzen dahinter dürften sich dann dicht gedrängt alle MP4-Derivate tummeln, also auch der von mir immer wieder erwähnte H264/X264-Encoder.

Aber ist denn diese Performance (häufig auch als quality per bitrate bezeichnet) für unsere Anwendungen überhaupt relevant? Ich denke: eher nicht, denn wir streamen unsere Videos nicht, sondern spielen sie in der Regel von einem Datenträger ab und ob die Videodatei dann 20% größer oder 20% kleiner wird, ist dann eigentlich nebensächlich.

Performance ist auch nicht das einzige Kriterium, das für uns wichtig ist, der Codec sollte zumindest beim Decodieren Hardwareunterstützung durch die Grafikkarte ermöglichen, er sollte eine breite Konfigurationsmöglichkeit anbieten (konstante Bitrate, variable Bitrate ...) und er muß eine hohe Akzeptanz zeigen bei aktuellen Hardwareplayern (Smartphone, 3D-TV, ...). Der X264 ist in all diesen Punkten ein idealer Allrounder und wenn wir als 3D-Autoren auch noch frame-packing Flags benutzen wollen, sogar die einzige Alternative. Aus diesem Grund habe ich 2014 im Cosima-Complete Paket den bis dahin verwendeten WMV3-Encoder duch den X264-Encoder ersetzt und empfehle diesen auch zur Anwendung bei den DGS-Kongressen. Ich sehe deshalb aktuell keinen Bedarf an Vergleichen verschiedener Video-Codecs.

Wir könnten also im nächsten Schritt für den jetzt als ausgewählt angenommenen X264 Encoder die Qualität in Abhängigkeit der Bitrate vergleichen wollen. Allerdings macht die (ausschließliche) Forderung nach einer möglichst hohen Videoqualität keinen Sinn, da folgender monotoner Zusammenhang gilt: je höher die Bitrate, desto höher ist die Qualität und ohne weitere Randbedingung würden wir bei der Forderung nach einer möglichst hohen Videoqualität bei einem uncodierten Video landen.

Wenn Videos vom PC abgespielt werden, gibt es abhängig von dessen Leistungsfähigkeit eine maximale Bitrate, die man für eine flüssige und ruckelfreie Wiedergabe der Videos nicht überschreiten darf. An dieser Stelle halte ich tatsächlich Performancetests für wichtig und notwendig, diese können aber immer nur für eine bestimmte Hardware gelten. Die DGS bietet auf ihren Kongressen seit 2007 digitale Projektionen an und seit dieser Zeit werden auch umfangreiche Performancetests auf der jeweils aktuellen DGS-Hardware durchgeführt. Die momentane Empfehlung (und damit verbundene Garantie einer ruckelfreien Wiedergabe) beträgt für den X264-Encoder und für ein SBS-HD-Video 20MBit/s. Bei diesen Performancetests wird der Framejitter des Anzeigezeitpunktes der Einzelframes gemessen. Da das Ergebnis dieser Tests bei jeder Hardware anders ausfällt (und bei 3D-TVs gar nicht objektiv durchgeführt werden kann), sehe ich auch hier keinen Ansatzpunkt für einen breiter angelegten Vergleichstest bezüglich der Videoqualität.

Um nicht falsch verstanden zu werden: Ich halte Vergleichstests für sehr lehrreich und kann nur dazu ermuntern, das einmal mit der eigenen Hardware durchzuexerzieren. Grundsätzlich gilt ja: Bitrate so hoch wie möglich, aber eben so niedrig wie nötig. Da das "so niedrig wie nötig" aber von der Hardware abhängig ist, kann das Ziel von solchen Test immer nur sein, diese Grenze für eine bestimmte Hardware zu ermitteln.




 

Dazu kommt immer noch, dass Youtube ein hochgeladenes Video grundsätzlich umcodiert um Speicherplatz zu sparen. Ein Hochladen auf YT um zu Vergleichen ist zwar möglich, aber...

Es macht keinen Sinn, sich Gedanken über den Richtigen Codec zu machen, wenn man eh nach YT hochlädt. Hier sollte das Ausgangsvideo bestmöglich (aber nicht unkomprimiert) sein, damit es zu nicht allzu großen Kompressionsverlusten seitens YT kommt.

Wenn, dann müsste man die Originaldateien vergleichen.

Cosima: 
Ein sehr ausführliche Abhandlung, für die ich leider der falsche Adressat bin, da ich soweit empanzipiert bin, dass ich selbst sehen und das Gesehene selbst beurteilen kann.
Aber die Arbeit kann bestimmt noch nützlich sein.
Ralf 

Hallo,
ich habe die letzten Tage viele (zu viele) Stunden, damit verbracht, das ganze mit ffmpeg nachzuvollziehen.
Direkt mit cmd zu arbeiten ist mir zu umständlich zumal, sich da schnell Schreibfehler einschleichen.
Daher habe ich mir eine GUI (WinFF) besorgt und dort einiges ausprobiert. (Auch Umwandlung von Audio in mp3)
Mein Problem, wenn ich mit Magix in AVI rendere, kann ich entsprechende Vorgaben im Codec (x264) machen.
Hier lautet der Befehl --Frame-packing 4, so wie von Cosima beschrieben,
aber wenn ich mit Magix in mp4 rendere, kann ich diese Vorgaben nicht machen.

Durch Umkonvertierung mit WinFF funktionieren die von Cosimo beschriebenen Befehle nicht.
--Frame-packing 4 für AVI
:frame-packing=4 für mp4

Fündig wurde ich aber auf der Seite des Stereophotomakers
stereo.jpn.org/eng/stphmkr/framepack/index.html
-vcodec libx264 -x264opts "frame-packing=3" (mit Anführungszeichen, Frank hat das aber ohne Anführungszeichen beschrieben).
Das funktioniert auch für mp4.
Es scheint also tatsächlich mehrere Versionen bzw. funktionierende Befehle zu geben.

Zu der Umkonvertiererei.
Eigentlich verschlechtert sich nach jedem konvertieren die Videoqualität. 
Erstaunlich, dass da sogar öfter als einmal hin und her und wieder zurück konvertiert wird.

Da komme ich auch schon mal zu meiner ersten Frage:
Gefühlt gibt es den Kontainer AVI gar nicht mehr, oder wird wohl am seltensten benutzt.
Überall liest man nur von mp4. Das können wohl auch die meisten Geräte lesen.
Ist es da nicht empfehlenswert, gleich in mp4 zu rendern (wenn man auf die direkte Umschaltung nach SD3 verizchten kann)?
Gibt es eine Anwendung, die nicht neu konvertiert, sondern die Daten einfach von einem Container in den anderen packt und man vorher, oder danach nur die entsprechenden Befehle für 3D nachträgt?

Bei dem von Frank beschriebenen Workflow mit XMediaRecode sind bei mir zwei Probleme aufgetaucht.
Beim rendern in AVI mit Magix und x264vfw und lossless wird eine Datei erzeugt, die ich mit dem Windowsplayer nicht abspielen kann.
Ich kann sie aber mit Xmediarecode funktinierend in mp4 umkonvertieren.
Frank ist das bei dir auch so?
Ich habe versucht mich da einzulesen. Da wird geschrieben, dass man bei Rate control auf Single pass -quantizer-based (CQP) einstellen kann und den Wert runtersetzen kann (0) und damit auch verlustfrei gerendert wird.

Das zweite Problem ist das abspeichern der Einstellungen.
Das funktioniert auch, es wird eine .xmr Datei erzeugt. Aber die Einstellung für Frame-packing bleibt beim nächsten Starten wieder auf deaktiviert.
Muss also immer neu eingestellt werden.
Die xmr-Datei kann man mit dem Editor lesen und auch ändern. Aber eine Einstellung für Frame-packing gibt es dort nicht.
Auch ein manueller Eintrag führt zu keinem Ergebnis.

Frank, funktioniert das bei dir? Wenn ja, wie hast Du das gespeichert.

MP3:
Frank: Ich habe auch einen LG LM671. Da funktioniert mp3.
Evtl. müsstest Du da mal im Handbuch nachlesen, ob da bestimmte Voraussetzungen erfüllt sein müssen.
Oder Du lädst dir einfach eine mp3 Audio-Datei auf einen USB-Stick und probierst das mal aus.
Wenn die video-Datei trotzdem nicht gelesen wird, liegt es evtl. auch an den Codeceinstellungen des x264.
(Bei mir dürfen z.B. nicht mehr als 5 reff frames eingestellt werden).

Gruß
Gerd