Anamorph: Grundsätzliche Fragen

Ich gehe mal davon aus, dass du eine DVD als Quelle hast. Dann ist 16:9 als SAR auf jeden Fall falsch, denn 16:9 ist das Display AR (DAR) incl. schwarzer Balken. x264's SAR meint aber das Pixel AR (PAR).

Das hier sind die richtigen Zahlen:

für digitale Wiedergabe am Computer
               PAL     NTSC
non-anamorph   12/11   10/11
anamorph       16/11   40/33


für analoge Wiedergabe am Fernseher
               PAL      NTSC
non-anamorph   128/117  72/79
anamorph       512/351  96/79

Da es nur ein AR-Flag gibt, musst du dich entscheiden, welches Wiedergabemedium du hauptsächlich nutzt. Die Abweichungen sind allerdings gering: für eine anamorphe PAL-DVD z.B. 1,4545 und 1,4586. Das kann man vernachlässigen.
Die üblicheren Werte sind die digitalen, die auch im ITU-R BT.601-Standard stehen. XviD richtet sich bei seinen Standard-PARs z.B. danach.

2,35:1 spielt bei der DVD übrigens keine Rolle. Alle Widescreen Formate sind anamorph (sinnvolles Authoring vorausgesetzt) und unterscheiden sich nur durch die Größe der schwarzen Balken. Das PAR ist bei allen gleich, egal ob 1.78, 1.85, 2.35 etc. Und es verändert sich durchs Cropping auch nicht.

Wenn dir bei mod16 noch Ränder bleiben, hilft oft der FillMargins-Filter weiter. Meistens handelt es sich ja nur um 1-2 schwarze Pixelreihen. Und die kann der Filter bestens übertünchen.

hm, mit Fillmargins hatte ich in meinen Tests (schon eine Weile her) immer üble unscharfe Ränder.

Werde das aber nochmal probieren und auch letterbox.

Zitat von Brother John

2,35:1 spielt bei der DVD übrigens keine Rolle. Alle Widescreen Formate sind anamorph (sinnvolles Authoring vorausgesetzt) und unterscheiden sich nur durch die Größe der schwarzen Balken. Das PAR ist bei allen gleich, egal ob 1.78, 1.85, 2.35 etc. Und es verändert sich durchs Cropping auch nicht.

@ Deinorius
Genau das habe ich versucht dir beizubringen (ich kann sowas eben nich so gut erklären wir Brother John)
Deswegen reicht es völlig aus zu croppen und dann in xvid die entspreche "Pixel Aspect Ratio" zu wählen -> (4:3 PAL , 4:3 NTSC, 16:9 PAL, 16:9 NTSC)

@Brother_John
Danke für die Zahlen, aber die sind mir ehrlich gesagt wurscht. Ich komprimiere derzeit nur mit x264 und natürlich mit DVDs als Quellen.
Ich hab selber noch ein paar Tests gemacht. Derzeit hab ich Mononoke Hime gerippt. Gebe ich 16:9 bei x264 ein, passt die AR (Vergleich mit der DVD auf Laptop). Insofern passt es damit.
Was mich nur noch interessieren würde ist, ob ich für letterboxed DVDs eher 2,35 oder 2,33 eingeben sollte. Oder bin ich vielleicht zu pingelig?

Zitat von Brother John

2,35:1 spielt bei der DVD übrigens keine Rolle.

Auf der DVD sicher nicht, aber was geht mich das an? Ich mach nur Sicherungskopien mit x264 und Matroska.

Zitat von Deinorius

@Brother_John
Danke für die Zahlen, aber die sind mir ehrlich gesagt wurscht. Ich komprimiere derzeit nur mit x264 und natürlich mit DVDs als Quellen.
Ich hab selber noch ein paar Tests gemacht. Derzeit hab ich Mononoke Hime gerippt. Gebe ich 16:9 bei x264 ein, passt die AR (Vergleich mit der DVD auf Laptop). Insofern passt es damit.
Was mich nur noch interessieren würde ist, ob ich für letterboxed DVDs eher 2,35 oder 2,33 eingeben sollte. Oder bin ich vielleicht zu pingelig?
Auf der DVD sicher nicht, aber was geht mich das an? Ich mach nur Sicherungskopien mit x264 und Matroska.

2.41

Wenn du die Datei aufm PC wiedergibts, musst du 2.41 eingeben. Das passt fast exakt.

2,41... ok, werd ich mal testen. Danke für die Antwort. Genau das wollte ich ja wissen.

Irgendwo ist hier der Wurm drin. Lass mich dein Vorgehen mal nachvollziehen:

- Quelle DVD. PAL oder NTSC, ist egal.
- Du croppst die schwarzen Balken (also z.B. auf 720x432 für PAL).
- Du verwendest KEIN Resizing.
- Du stellst x264s SAR auf 16:9.

Soweit richtig? Dann:

- x264 CLI oder VDub?
- mkvmerge fürs Muxing?
- Stellst du dort das AR ein?

Die Zahlen in den Tabellen stimmen[1]. Für eine DVD-Quelle ohne Resizing ein anderes PAR einzustellen ist definitiv immer falsch. Ich kann's mir nur so erklären, dass entweder
- x264 schlau genug ist, das falsche PAR zu korrigieren, oder
- das richtige AR im Matroska-Contrainer steht und das beim Abspielen verwendet wird.

[1] Im Standard stehen geringfügig andere Werte, da dort mal überarbeitet wurde. Die aus der Tabelle sind allerdings nahezu identisch, sind deutlich schönere Brüche und werden allgemein verwendet.

Bumsfalara
Um 2,41 ist üblicherweise das DAR nach ITU. x264 verlangt aber das PAR.

- Quelle DVD. PAL oder NTSC, ist egal. Jo.
- Du croppst die schwarzen Balken (also z.B. auf 720x432 für PAL). Jo.
- Du verwendest KEIN Resizing. Jo.
- Du stellst x264s SAR auf 16:9.
.....Also beim croppen mit 432 werd ich wohl eher 2,41:1 verwenden. Bei z.B. 704x560 nehm ich dann 16:9.
- x264 CLI oder VDub?
.....CLI mit MeGUI oder StaxRip
- mkvmerge fürs Muxing?
.....So ist es.
- Stellst du dort das AR ein?
.....Ist nur bei x264 nötig. Z.B. 704x560, dann steht in den Matroska Infos 16/9 (obwohl mir der Weg 996x560 lieber ist). Bei StaxRip (muss ja wegen Audio nochmal muxen) steht dann am Ende 996x560 nachträglich.

- x264 schlau genug ist, das falsche PAR zu korrigieren, oder
.....Gut möglich.
- das richtige AR im Matroska-Contrainer steht und das beim Abspielen verwendet wird.
.....Wenn ich jetzt mit MeGUI direkt ein Video komprimiere, dann steht 16/9 drin und das AR ist korrekt. Wenn ich .mp4 nehme, kommt das Gleiche heraus.

Zitat

Um 2,41 ist üblicherweise das DAR nach ITU. x264 verlangt aber das PAR.

Kommt mir aber eher wie DAR vor.

Zitat von Brother John

Bumsfalara
Um 2,41 ist üblicherweise das DAR nach ITU. x264 verlangt aber das PAR.

Ja, aber 2.41 kannst du in x264 sowieso nicht angeben.
Ich dachte, er wollte diese Zahlen in mkvmerge GUI angeben, kam für mich zumindest im Text so rüber.

Wenn ich das richtig verstehe arbeitet Deinorus identisch zu meiner Methode. Allerdings las ich das PAR in x264 einfach komplett weg, weil es bisher noch absolut NIE gestimmt hat was ich da angegeben habe. Und ich hab da schon sehr viel Verglichen, saß mit nem Metermaß vorm Monitor.

Also 16:9 passt zumindest, wenn ich das in x264 angebe.
2,41 kann ich erst später testen, wenn ich so eine DVD zur Hand hab und mehr Speicher (ext.HDD hatte einen Datencrash :().

@ Deinorius
reden wir spanisch oder was ?
ist so schwer zu verstehen ?
warum willst du uns nicht glauben ?
16:11 in x264 ist das einzig richtige für 16:9 material
ausserdem übernimmt mkvmerge das AR Flag automatisch

Guckst du hier
http://forum.doom9.org/showthread.php?t=100519
und die kennen sich auch gut aus

Ich verstehe sehr wohl, aber du vergisst eine Tatsache.

MeGUI, x264 Rev 485, CoreAVC, ZoomPlayer oder MPC (egal), VMR9 oder Overlay Mixer (egal), .mp4 oder .mkv (egal)
Gebe ich vorm Komprimeren 16:9 ein, wird alles korrekt angezeigt.
Gebe ich vorm Komprimieren 16:11 ein, wird das Video falsch angezeigt.

Es ist eigentlich egal, was nun richtig ist, ob nun x264 diese Option übernimmt, oder Matroska den AR Flag übernimmt. Wenn ich 16:9 eingebe, passt alles, bei 16:11 eben nicht.
Was soll ich sonst dazu sagen, außer dass für mich nur die Eingabe 16:9 relevant ist. Und das ist auch schon alles.

Am Ende haben wir beide recht.

Wenn ich mir aber nun vorstellen, dass auch andere so komprimieren, sie aber glauben, dass man 16:11 eingeben muss, will ich mir dann vorstellen, wie bei denen das Bild dann aussieht.

Wenn du den Matroska Container nimmst, dann würde ich lieber "Display width/height" nehmen...das ist dann fast noch exakter.

x264 selbst verlangt das PAR. Hier war 16:9 falsch, ist falsch und bleibt auch falsch. MKVMerge dagegen arbeitet mit dem DAR. Hier ist 16:9 richtig für eine anamorphe DVD, die keine schwarzen Balken enthält und damit echtes 16:9 (1,78:1) ist. In diesem Fall sind also auch die 996x560 korrekt.
Sobald du croppen musst, ist 16:9 wieder falsch, weil das Bild dann kein echtes 16:9 mehr ist. Der DAR gibt ja nur das korrekte Abspiel-Verhältnis Bildbreite zu Bildhöhe an, was sich mit jedem gecroppten Pixel verändert.
Mit dem PAR hast du solche Probleme nicht, weil der nur die Form eines einzelnen Pixels angibt. Und die ändert sich nur beim Resizing, nicht beim Cropping.

Weitere Tatsachen:
- Die XviD- und x264-Encoder setzen das PAR-Flag im MPEG-4-Stream.
- MKVMerge setzt das DAR-Flag im Container.
- Wenn du beim Muxen nichts angibst, übernimmt MKVMerge automatisch das MPEG-4-Flag. Zumindest die GUI tut das. Habs mit mkvmerge.exe pur noch nie versucht.
- Welches der beiden Flags beim Abspielen angewendet wird, hängt vom Decoder ab.
- Playerkonfig kann auch noch mit reinspielen.

Bei so vielen Möglichkeiten kann es durchaus vorkommen, dass sich verschiedene falsche Einstellungen gegenseitig kompensieren und zum Schluss doch etwas Sinnvolles herauskommt.
Warum kümmerst du dich überhaupt um das AR? MeGUI bietet doch afair beim AVS erstellen gleich die Möglichkeit, ein anamorphes Bild automatisch zu berücksichtigen.

Zitat von Bumsfalara

Ich dachte, er wollte diese Zahlen in mkvmerge GUI angeben, kam für mich zumindest im Text so rüber.

Sorry, dann hab ich dich missverstanden.

Zitat von kurt

mit Fillmargins hatte ich in meinen Tests (schon eine Weile her) immer üble unscharfe Ränder.

Hoppla, kurt, dich hab ich fast übersehen.
Übertreiben sollte man es mit FillMargins wirklich nicht. Aber meistens geht es nur um 1-2 Pixelreihen, um die größere mod16-Auflösung zu erhalten. Und dafür funktioniert es imo bestens.

Zitat von Deinorius

Ich verstehe sehr wohl, aber du vergisst eine Tatsache.

MeGUI, x264 Rev 485, CoreAVC, ZoomPlayer oder MPC (egal), VMR9 oder Overlay Mixer (egal), .mp4 oder .mkv (egal)
Gebe ich vorm Komprimeren 16:9 ein, wird alles korrekt angezeigt.
Gebe ich vorm Komprimieren 16:11 ein, wird das Video falsch angezeigt.

Es ist eigentlich egal, was nun richtig ist, ob nun x264 diese Option übernimmt, oder Matroska den AR Flag übernimmt. Wenn ich 16:9 eingebe, passt alles, bei 16:11 eben nicht.
Was soll ich sonst dazu sagen, außer dass für mich nur die Eingabe 16:9 relevant ist. Und das ist auch schon alles.

Am Ende haben wir beide recht.

Wenn ich mir aber nun vorstellen, dass auch andere so komprimieren, sie aber glauben, dass man 16:11 eingeben muss, will ich mir dann vorstellen, wie bei denen das Bild dann aussieht.

willst du damit sagen
das wenn du in x264 16:11 als SAR eingibst und in mkvmerge nichts verstellst sondern einfach nur in mkv muxt
das dann das AR nicht passt?

dass kann nicht sein

ffdshow konfig für richtige wiedergabe
[Blockierte Grafik: http://img108.imageshack.us/img108/66/ffdshowanamorphicoverlaysettin.png]

Brother John
Ich hab jetzt auch mit dem Kommandozeilenprogramm ein paar Videos erstellt. Dabei ist herausgekommen, egal welcher Container, wenn ich 16:9 eingebe ist das AR falsch, wenn ich 16:11 eingebe, passt alles.
Der Fehler muss wohl also eher bei MeGUI liegen. Ich hab derzeit noch 2116, also noch ziemlich neu. Die Neueste ist derzeit 2118.
StaxRip macht es da nicht besser. Der musste dann auch noch 146:100 hinzufügen, was am Ende (zusammen mit 16:9) dann komplett falsch war (müsste es aber mal mit dem Hotfix probieren).

Ich hab jetzt auch mal die x264 SAR und DAR Verhältnisse mal mit der Quelle verglichen. Dabei hatte ich mit der DAR Methode einen kleinere Fehler von 1,34 %, während SAR einen Fehler von 1,57 % machte. Eigentlich sollte der Fehler bei SAR doch gar nicht erst so hoch sein, oder?

Mr. Brown
Ist aber so. Aber wie schon gerade gesagt. Muss wohl ein MeGUI Bug sein. Direkt mit x264 kommt das nicht.
Ich nutze CoreAVC, aber bei ffdshow (gleiche Einstellungen) kommt das selbe.

Das MeGUI-Problem kann ich bestätigen, allerdings mit einer noch etwas älteren Version. Der setzt in der x264-Konfig tatsächlich 16:9 anstatt 16:11 ein. Wenn du das korrigierst, sollte sonst aber alles automatisch richtig ablaufen.

146:100 passt schon. Runtergebrochen gibt das 1,46:1, was exakt 16/11 auf zwei Nachkommastellen gerundet entspricht. Dieser Wert darf natürlich nur als PAR in der Konfig auftauchen. In MKVMerge wäre er tatsächlich komplett fehl am Platz. Was mir nicht einleuchtet ist, dass StaxRip nicht das exakte 16:11 verwendet.

Über die kleinen Abweichungen mach dir keine Gedanken. Die kommen zustande, weil Software-DVD-Player i.d.R. nach den analogen Zahlen resizen und du fürs Encoding die digitalen nimmst. Außerdem hat ein Bildschirm eben nur ganze Pixel, was zu Rundungsfehlern führt. Die anamorphe PAL-DVD müsste horizontal mathematisch exakt auf 720 x (16/11) = 1047,272727... Pixel gestreckt werden. Und den Bildschirm, der Pixel nur zum Teil ansprechen kann, den will ich sehen!

Zitat von Brother John

Die anamorphe PAL-DVD müsste horizontal mathematisch exakt auf 720 x (16/11) = 1047,272727... Pixel gestreckt werden. Und den Bildschirm, der Pixel nur zum Teil ansprechen kann, den will ich sehen!

Ich auch. Super zum Interpolieren.

Ich werd dann wohl die MeGUI-Entwickler auf den Bug aufmerksam machen, aber wäre der nicht schon früher aufgefallen? Ich frag mich besonders, wo genau der Fehler liegt. Schießlich führt MeGUI einfach nur die CLI aus.

... wobei sich mir bei all dem hier gelesenen die Frage stellt, warum das bei x264 / MKV so völlig unnötig kompliziert ist. Auch die neuen Container- und Kompressionsformate ändern ja nichts an den Bildstandards, und dort haben sich die Werte, wie sie nach CCIR / ITU benutzt werden, völlig bewährt. Selbst im "alten" MPEG2-Format kann man prinzipiell mit den wenigen Angaben auskommen, die dort definiert sind, auch dann, wenn man die Balken weglässt. Man hat sich nur eben drauf geeinigt, das man IMMER 576 bzw. 480 Zeilen haben muss. Lässt man das mit den Balken mal außer acht - was hat dagegen gesprochen, diese Maße - und NR diese Maße, auch bei x264 / MKV zu benutzen? Doch bitte nicht nur der Umstand, dass PC-Monitore nur PAR 1:1 beherrschen. (und nein, ich werde mich NIE an die SAR-Angaben gewöhnen - PAR und DAR haben früher gereicht und reichen heute auch noch).

Warum das Thema für so große Verwirrung sorgt, liegt imo daran, dass es für MPEG-4 lange Zeit keine Decoder-AR-Unterstützung gab und deshalb 1:1 die einzige Möglichkeit war. Für uns MPEG-4-Jungs ist ein verzerrtes Bild in der endgültigen Datei ein ganz neues Konzept und es braucht ein bisschen Zeit, bis sich jeder damit angefreundet und sich der beste Workflow etabliert hat.

Prinzipell ist es ganz einfach. Passendes PAR (= SAR) im Encoder setzen und fertig ... Dumm gelaufen für die DivX-Fans :D. Dann hat man das AR-Flag im MPEG-4-Stream stehen, wo es imo primär hingehört. Schließlich ist das ein Wert, der absolut eindeutig zu den zentralen Eigenschaften des Videostreams gehört.
Deswegen sehe ich das AR-Flag im Container nur als zusätzliches Feature und würde auch immer davon abraten, ausschließlich das Container-Flag zu verwenden.

Man könnte das Thema hierauf reduzieren: "In den MPEG-4-Stream gehört der korrekte PAR-Wert. Ein sinnvoller Decoder hat den anständig auszulesen und umzusetzen. Alles weitere sind Zusatzfeatures, auf die man sich nicht verlassen darf."
Komplizierter als die MPEG-2/DVD-Situation ist das nicht wirklich, oder?

Vom DAR sollten wir uns verabschieden. Denn da mit MPEG-4 wg. Cropping die flexible Auflösung Einzug erhalten hat, ist das DAR einfach unpraktisch zu handhaben geworden.