AR-Flags bei anamorphem x264-Encoding

sundance.kid

Hallo,

für meine DVD-Encodings benutze ich seit langer Zeit "HandBrake" und kodiere das Video anamorph (MKV-Container). Das funktioniert auch mit allen meinen Playern (PC und WDTV live) ohne Probleme: Die Filme werden im korrekten AR angezeigt.
Jetzt ist allerdings ein weiterer "Player" hinzugekommen: Die MediaPlay-"App" in den Samsung LCD-TVs (getestet mit LE32C579 und LE40C679). Dort werden die MKVs zwar abgespielt; bei anamorph kodierten allerdings stimmt das AR nicht - das Video wird in der codierten Auflösung (also z.B. 720x432) abgespielt. MediaInfo meldet korrekt:

Code

Width                            : 720 pixels
Height                           : 432 pixels
Display aspect ratio             : 2.35:1

Wenn ich nun als Ziel-Container MP4 verwende, wird der Film korrekt entzerrt angezeigt, d.h. der Player kann es offensichtlich, nur wird die AR-Info nicht (korrekt) aus der MKV-Datei ausgelesen.
In Brother John's Encodingwissen steht, dass man das AR-Flag im Container und/oder im Videostream unterbringen kann (besser im Stream).

Daher meine Fragen:
a) Kann man anhand MediaInfo feststellen, woher die AR-Info kommt?
b) Läßt es sich irgendwie bewerkstelligen, dass die AR-Info beim Muxen mit mkvmerge an beiden Positionen abgelegt wird?

Vielen Dank im Voraus...

Selur

zu a.: aus dem Container
zu b.: (hab was im Hinterkopf:) war es nicht so, dass mkvmerge beim Muxen den PAR Wert aus dem Stream entfernt und ihm beim Extrahieren wieder einfügt? Würde sagen: Nein
Selbst wenn der PAR Wert bei mkv files im Videostream als auch im Container vermerkt ist, muss der Fernseher damit noch lange nicht klar kommen,... (z.B. weil er bei mkv Dateien den PAR Wert gar nicht ausliest,... ;))

Cu Selur

Ps.: gehört in den "Alternative A/V-Container und -Formate" Bereich,.. hat ja nichts mit dem Encoding als solches zu tun,..

sundance.kid

Hallo Selur,

Zitat

zu a.: aus dem Container

Das würde voraussetzen, dass deine Vermutung aus b) stimmt.
Zumindest wird das AR mit MediaInfo im Videoabschnitt aufgeführt.

Zitat

Selbst wenn der PAR Wert bei mkv files im Videostream als auch im Container vermerkt ist, muss der Fernseher damit noch lange nicht klar kommen,... (z.B. weil er bei mkv Dateien den PAR Wert gar nicht ausliest,...

Ist durchaus möglich. Aber um das herauszufinden, wollte ich den Test mit dem doppelten Eintrag ja durchführen. Wenn man bei der Implementation der MP4-Container daran gedacht hat, warum sollte es bei MKV vergessen worden sein... Ich hätte halt gerne die MKV-Container weiterhin verwenden wollen, weil hier einfach mehr Möglichkeiten geboten werden.

sundance.kid

Selur

Zitat

Das würde voraussetzen, dass deine Vermutung aus b) stimmt.

Basierte die Aussage eher darauf, dass MediaInfo i.d.R. nur direkt die Containerheader ausliest und nicht die Streams an sich genauer untersucht.

ohne auf den Sourcecode zu gucken lässt sich folgendes beobachten:
1. wenn man mit x264 einen .264 Raw stream erstellt, der mit PAR 1:1 geflaggt ist und ihn analysiert

Code

MediaInfo "--Inform=Video;%PixelAspectRatio%" "d:\Encoding Output\test.264"

erhält man: 1.000
2. wenn man mit mkvmerge den Stream importiert, als mkv speichert und ein Seitenverhältnis von 2.35 angibt

Code

MediaInfo "--Inform=Video;%PixelAspectRatio%" "d:\Encoding Output\test.mkv"

erhält man: 1.292
3. wenn man aus dem mkv File nun den Stream extrahiert und analysiert

Code

MediaInfo "--Inform=Video;%PixelAspectRatio%" "d:\Encoding Output\test_Track1.h264"

erhält man: 1.000
4. wenn man sich nun das mkv file nimmt und es mit MediaInfo --Full analysiert erhält man:

Zitat

Pixel aspect ratio : 1.292 <- Pixel Aspekt Ratio im Container
Original pixel aspect ratio : 1.000 <- Pixel Aspekt Ratio im RAW Stream
Display aspect ratio : 2.349
Display aspect ratio : 2.35:1
Original display aspect ratio : 1.818
Original display aspect ratio : 16:9

Davon ausgegangen Handbrake macht keinen Unsinn sollte bei deinen Streams aber das 'Pixel aspect ratio' und das 'Original pixel aspect ratio' bei Deinem Stream jedoch identisch sein und sowohl das Pixel Aspect Ratio im Container als auch im Stream selber schon gesetzt sein und das Problem liegt eher an der Firmware von Samsung als an der .mkv Datei

Cu Selur

Ps.:

Zitat

Ich hätte halt gerne die MKV-Container weiterhin verwenden wollen, weil hier einfach mehr Möglichkeiten geboten werden.

Unterstützung für mehr Formate (Untertitel-, Video- und Audioformate). Wäre der einzige Punkt der mir einfällt. Falls die Streams in Deinen mkv Dateien jedoch bereits MP4 kompatibel sind wüsste ich keinen Vorteil von mkv, lasse mich aber gerne eines besseren belehren. (da die meisten Player vermutlich eh nur die Video- und Audioformate in mkv Unterstützen, die eh MP4 kompatibel sind, wären wenn nur die Untertitelformate als Pluspunkt in so einem Fall interessant,...)

Brother John

Zitat von Selur

zu b.: (hab was im Hinterkopf:) war es nicht so, dass mkvmerge beim Muxen den PAR Wert aus dem Stream entfernt und ihm beim Extrahieren wieder einfügt?

Das war mal einige Zeit so, ist aber jetzt auch schon länger wieder anders. Aktuelle MKVMerge lassen das Stream-PAR wie es ist.

Selur

Das passt dann natürlich auch gut zu den 'Testergebnissen' und stützt die Vermutung, dass wenn Handbrake nicht Unsinn macht sowohl im Stream als auch im Container der gleiche PAR Wert stehen sollte und es somit ein Problem der Samsung Firmware ist.

Cu Selur

sundance.kid

Etwas verwirrend, muß ich zugeben.
Aber der gute Brother John hat uns ja bereits vorgewarnt, dass das mit dem anamorphen Encoding nicht gerade einfach ist...

Bei meinem MKV-Testfile (analysiert mit mediainfo --full) ergibt sich folgendes:

Zitat

Width : 720 pixels
Height : 436 pixels
Pixel aspect ratio : 1.422
Display aspect ratio : 2.349
Display aspect ratio : 2.35

Im MP4-Container sieht es dann so aus (ist zwar ein anderes Video, aber identisch erzeugt):

Zitat

Width : 720 pixels
Height : 432 pixels
Pixel aspect ratio : 1.416
Original pixel aspect ratio : 1.415
Display aspect ratio : 2.360
Display aspect ratio : 2.35
Original display aspect ratio : 2.359

Alles anzeigen

D.h. im Fall MKV tauchen bei mir die "Original-..."-Werte gar nicht erst auf.

Sieht wohl so aus, als ob ich für die Samsung-Kiste auf z.B. meine VOBSUB-Untertitel verzichten muss und die MKVs in MP4-Container umverpacken muss.
Gibts dafür ein einfaches Tool, welches nur umpackt und nichts neu kodiert?

sundance.kid

Selur

Zitat

D.h. im Fall MKV tauchen bei mir die "Original-..."-Werte gar nicht erst auf.

Der Original Eintrag macht ja auch nur Sinn, wenn die Einträge sich unterscheiden,...

Zitat

ist zwar ein anderes Video, aber identisch erzeugt

.. und damit ist die Auswertung dann ohne Aussagekraft bzgl. dem mkv-Testfile
Was mich persönlich am 2ten File stört, ist das sich das der PAR im Stream und im Container sich unterscheidet,.. (wobei der Hardwareplayer da vermutlich 'blind' ist und intern 1.422 verwenden wird)

Zitat

Gibts dafür ein einfaches Tool, welches nur umpackt und nichts neu kodiert?

Können die meisten GUIs die auch Reencoden können (MeGUI, Avidemux, Hybrid,..), einfach ist aber vermutlich FastMKV2MP4, da es nicht wirklich mehr kann als Umpacken,..

Cu Selur

akapuma

Zitat von sundance.kid

Bei meinem MKV-Testfile (analysiert mit mediainfo --full) ergibt sich folgendes:

Hmm, da stehen Verhältnisse....

Probier doch mal den Kopfdateneditor von MKVtoolnix. Bei meinen MKV's stehen da keine Verhältnisse, sondern Eingangs- und Aufgangsauflösung (in Pixeln).

Gruß

akapuma

Brother John

Muss auch. Matroska kennt nämlich aus technischer Sicht gar keine Seitenverhältnisse. Es gibt nur Einträge für »display width« und »display height«, womit laut Spec sogar tatsächlich die ideale Abspielauflösung gemeint ist. In der Praxis nutzt jeder die beiden Felder, um das DAR anzugeben.

Jetzt mitmachen!