Anamorph: Grundsätzliche Fragen

Es ist nicht wirklich komplizierter, nur verwirrend, wenn man Anhänger der "alten Schule" ist - und für Einsteiger allemal. Ich hab's ja schon früher gesagt: Mich persönlich stört die Verwendung des Begriffs SAR - der ist in der MPEG-Welt eigentlich schon lange vor h.264 definiert worden - und vor allem anders. SAR = Sample Aspect Ratio, ein Screen Aspect Ratio braucht doch eigentlich niemand mehr, wenn er ein DAR hat, das Display Aspect Ratio. Und das PAR - Pixel Aspect Ration - ist ja eigentlich universell.
Na ja, wie auch immer ... der Schaden ist ja bereits angerichtet, jetzt müssen wir auch damit leben. Lustig ist halt, dass dieselben Fehler, die auch schon bei MPEG2/DVD gemacht wurden, jetzt wiederholt werden - nämlich zwei Angaben: Eine im eigentlichen Stream und eine im Container - das kennt man ja bereits von der DVD. Tja, warum einfach, wenn's auch kompliziert geht?
Was jetzt am DAR durch das Cropping der Balken so anders geworden sein soll, will mir aber nicht klar werden, denn für die eigentlichen Film-Pixel ändert sich dadurch doch gar nichts.
Und Auflösungen wie 720x540 sind nun mal nicht sinnvoll und werden es auch nie sein.

Zitat von kika

Mich persönlich stört die Verwendung des Begriffs SAR - der ist in der MPEG-Welt eigentlich schon lange vor h.264 definiert worden - und vor allem anders. SAR = Sample Aspect Ratio, ein Screen Aspect Ratio braucht doch eigentlich niemand mehr

Bringst du da nicht was durcheinander?
Die Abkürzung SAR in x264 steht für Sample Aspect Ratio und ist identisch mit dem PAR. Stören tut mich der Begriff auch. Warum hat man das verdammte Ding nicht einfach PAR genannt?

Zitat

Was jetzt am DAR durch das Cropping der Balken so anders geworden sein soll, will mir aber nicht klar werden

Mit jeder gecroppten Pixelreihe ändert sich das DAR. Es ist also unmöglich zu sagen, hier hast du eine Tabelle mit einer Handvoll Werten, die immer stimmen.
Die DVD umgeht das Problem, indem sie die Auflösung zwingend vorschreibt. Bei MPEG-4 ist das halt nicht mehr der Fall, siehe auch:

Zitat

Und Auflösungen wie 720x540 sind nun mal nicht sinnvoll und werden es auch nie sein.

In der analogen Welt mag das stimmen. In einer volldigitalen Umgebung ist die Auflösung prinzipiell piepegal. Auch mod16 ist erst einmal eine Konvention, damit die Codecs möglichst effizient arbeiten können.

Zitat

Bringst du da nicht was durcheinander?

Ja, war ja auch schon so früh.

Zitat

Mit jeder gecroppten Pixelreihe ändert sich das DAR.

Im Prinzip ja, in der Praxis allerdings... Wir haben doch nach wie vor Standard-Auflösungen wie 4:3, 16:9, 1.85:1 etc. Ob man da jetzt Balken dranhängt oder nicht, ändert doch gegenüber MPEG2 gar nichts - da wird ja meistens auch ohne Balken gearbeitet, die kommen ja dann zum Schluß dran.
Wegen den 540 Zeilen: Nach wie vor sind die meisten TVs - digital oder analog ist wurscht - für PAL und/oder NTSC ausgelegt. Mal ganz davon abgesehen, dass das beim Source-Material ja auch so ist. Und aus 576 Zeilen 540 zu erzeugen, halte ich nicht für sinnvoll. Anders sieht's bei HDTV-Material aus, da passt das Maß schon besser. Über den Sinn, 1080 oder 720 Zeilen zu 540 zu verwursten ließe sich aber auch streiten.

Zitat

Ja, war ja auch schon so früh.

Tatsächlich, früh um 4h noch vorm Rechner! Du bist ja noch verrückter als ich.

Zitat

Ob man da jetzt Balken dranhängt oder nicht, ändert doch gegenüber MPEG2 gar nichts

Warum Balken dranhängen und Bitrate verschwenden, wenn es genausogut ohne geht? Ok, dann haben wir konstanten DAR. Aber konstante und zuverlässige Werte haben wir mit dem PAR doch sowieso.

Zitat

Nach wie vor sind die meisten TVs - digital oder analog ist wurscht - für PAL und/oder NTSC ausgelegt.

Ok, ok. Ich geb's ja zu, ich bin in der Hinsicht befangen, weil ich keinen Fernseher besitze und es mir dementsprechend ziemlich Wurscht ist, was am besten für TV-Wiedergabe ist.

Zitat

Und aus 576 Zeilen 540 zu erzeugen, halte ich nicht für sinnvoll.

Ack. Deswegen habe ich oben gemeint: "prinzipiell piepegal". Auch wenn der codierte Film nie auf einem Fernseher spielt, ist gerade 720x540 blödsinnig.
1. Weil 540 nicht mod16 ist.
2. Weil der Unterschied zu 576 gering ist und mit 576 das temporale Rauschen des Resizings wegfällt.
Im Endeffekt dürfte 576 die bessere Qualität ergeben. Einziger Nachteil, der mir spontan einfällt, ist die SAP-Wiedergabe. Wie üblich ist es denn, dass ein DivX-fähiger SAP eine 720x576-AVI zu korrektem 4:3 strecken kann?

Zitat

Wie üblich ist es denn, dass ein DivX-fähiger SAP eine 720x576-AVI zu korrektem 4:3 strecken kann?

Tja, wohl eher sehr unüblich - deshalb habe ich auch keinen. Wenn die das mal perfekt können, schlage ich zu, vorher nicht.

Zitat

Ok, ok. Ich geb's ja zu, ich bin in der Hinsicht befangen, weil ich keinen Fernseher besitze und es mir dementsprechend ziemlich Wurscht ist, was am besten für TV-Wiedergabe ist.

Nun, ich habe einen, sogar einen HD-ready-LCDer, und der mag's nicht besonders, wenn ich ihm 540 bzw. 544 Zeilen vorsetze. Weder, wenn ich ihn per DVI direkt an den PC anschließe, noch, wenn ich den S-Video-Ausgang benutze. Material mit 576 Zeilen sieht da immer besser aus.

Zitat

Warum Balken dranhängen und Bitrate verschwenden, wenn es genausogut ohne geht? Ok, dann haben wir konstanten DAR. Aber konstante und zuverlässige Werte haben wir mit dem PAR doch sowieso.

Man muss ja keine Balken dranhängen. Aber bis man bei MPEG2 die Balken dranhängt, sollte es eigentlich keinen Unterschied machen, ob man nun für h.264 oder für MPEG2 rechnet - die Sache mit den Playern mal außen vor gelassen. Der Bereich der Filmpixel ist doch eigentlich identisch.
Meiner Meinung nach sollte man die Auflösungen im gesamten MPEG4-Bereich ähnlich restriktiv handhaben wie bei MPEG2 bzw. wie bei DVD. MPEG2 selbst kommt ja auch ohne Balken aus, benötigt also auch nur MOD16.
Aber mal so nebenbei bemerkt (mit h.264 kenn' ich mich nur rudimentär aus): Müsste bei h.264 nicht eigentlich auch MOD8 völlig ausreichen?

Die ganze AR-Thematik hängt wirklich nicht an der MPEG-Version. Dem Encoder ist es reichlich egal, ob er ein verzerrtes Bild vorgesetzt bekommt oder nicht.
Theoretisch kommen alle modernen MPEG-4-Encoder mit jeder Auflösung zurecht, nur arbeiten sie bei mod16 am effizientesten, weil ein Macroblock 16x16 Pixel groß ist. Davon abgesehen hat der YV12-Farbraum Einschränkungen, das war mod2 iirc.
Wenn man nach RGB32 konvertiert, verbietet rein theoretisch nichts so Sachen wie 689x387, auch wenn das praktisch extremster Dummfug ist.

Bei den Auflösungen haben wir doch inzwischen eine ähnliche Situation wie bei MPEG-2/DVD. BluRay/HD-DVD/Digi-TV und auch die DVD definieren ein paar wenige Standardauflösungen und MPEG-4 an sich hat kaum Restriktionen. Ich bin damit ganz zufrieden.

Eine andere Frage. Warum sind eigentlich die 576 so extrem wichtig. Wäre es für einen TV nicht ähnlich einfach, balkenlose z.B. 432 gefüttert zu bekommen und die vertikal zu zentrieren?

Zitat

Eine andere Frage. Warum sind eigentlich die 576 so extrem wichtig. Wäre es für einen TV nicht ähnlich einfach, balkenlose z.B. 432 gefüttert zu bekommen und die vertikal zu zentrieren?

Eigentlich schon, ist die Standard-Vorgehensweise bei letterboxed.
Aber mal davon abgesehen, dass ich von letterboxed nichts halte - 432 IST letterboxed - muss man das den Scalern aber auch explizit sagen. Und die gehen eigentlich immer von PAL oder NTSC aus, also von 576 oder 480 Zeilen. Da spielen auch andere Dinge mit rein, z.B. WSS-Signaling. Dummerweise machen das weder alle Player noch alle TVs korrekt, und bei HDMI/DVI wird's dann ganz kompliziert. Da gibt's etliche TVs, die via HDMI ausschließlich 4:3 oder 16:9 anamorph korrekt anzeigen können, letterboxed wird dann grundsätzlich entweder als eine Art Fenster (und somit klein) oder verzerrt dargestellt. Deshalb gibt es für mich eigentlich nur noch zwei Auflösungen: 4:3 und 16:9 anamorph - bei letzterem ist dann völlig wurscht, ob das 16:9, 1.85:1, 2.35:1 oder was auch immer ist. Hauptsache, es wurde korrekt anamorph encodiert und auch so gekennzeichnet (Flags).
Eine Ausnahme sind HDTV-Streams, da die grundsätzlich mit PAR 1:1 arbeiten. Selbst die horizontal anamorphen Formate wie z.B. 1440x1080 lassen sich aber einfach umrechnen, da HDTV immer 16:9 ist - bei DVB auch durchaus trotz h.264 mit schwarzen Balken, wenn das Format nicht exakt 16:9, sondern eben 1.85:1 oder 2.35:1 ist.
So sind die existierenden Standards nun mal gesetzt, ob's gefällt oder nicht, Encodierung mit schwarzen Balken ist auch bei modernen Formaten nicht ungewöhnlich, sondern eher der Standard.

Zitat von Brother John

Theoretisch kommen alle modernen MPEG-4-Encoder mit jeder Auflösung zurecht, nur arbeiten sie bei mod16 am effizientesten, weil ein Macroblock 16x16 Pixel groß ist.

Beziehst du dich auch auf AVC? Ich hab das zwar noch nie ganz gerafft, aber ich dachte, bei AVC (x264) sei das nicht mehr so, der würde auf 4x4 irgendwie rechnen

Hallo,

zu mod16 siehe auch hier.

Gruß

akapuma

Wäre es denn eigentlich möglich, x264 (z.B. mit einem Patch) durch eine manuelle Eingabe beizubringen, der soll z.B. von Vertikal-Pixel oben 1 bis V-P72 und von V-P 504 bis V-P 576 einfach nur schwarz komprimieren, damit man damit extrem an Bitrate sparen und dennoch anamorph komprimieren kann?

Wäre von der Effizienz her die beste Lösung, aber auch möglich? Es ist ja nur eine Frage des Encoders, wie er die Bitrate verteilt. Hauptsache, der Decoder kann es lesen.

Zitat von Bumsfalara

Beziehst du dich auch auf AVC? Ich hab das zwar noch nie ganz gerafft, aber ich dachte, bei AVC (x264) sei das nicht mehr so, der würde auf 4x4 irgendwie rechnen

Ein Macroblock ist auch bei AVC 16x16 Pixel groß. Die Standardtransformation arbeitet zwar auf 4x4 Pixeln.
Der Encoder kann aber für die MC und Intra Prediction Modi zwischen 16x16 und kleineren Untereinheiten (8x8,8x4,4x8,4x4) umschalten.
Und im High Profile gibt es noch die 8x8 Transformation, die in den Farbkomponenten wegen dem subsampling 16x16 Pixel abdeckt.

Zitat von Deinorius

Wäre es denn eigentlich möglich, x264 (z.B. mit einem Patch) durch eine manuelle Eingabe beizubringen, der soll z.B. von Vertikal-Pixel oben 1 bis V-P72 und von V-P 504 bis V-P 576 einfach nur schwarz komprimieren, damit man damit extrem an Bitrate sparen und dennoch anamorph komprimieren kann?

Wäre von der Effizienz her die beste Lösung, aber auch möglich? Es ist ja nur eine Frage des Encoders, wie er die Bitrate verteilt. Hauptsache, der Decoder kann es lesen.

Die einfachste Möglichkeit ist, die schwarzen Balken oben und unten mit avisynth anzupappen, der Encoder wird die skippen, bzw. fallen die dank CABAC auf wenige Bits zusammen. Da ist nicht viel zu sparen.

Also mit AddBorders bzw. Letterbox. Das ist eine Möglichkeit, die ich mit AVC und Constant Quality testen werde. Mal sehen, was dabei rauskommt.

Zitat von Kopernikus

der Encoder wird die [schwarzen Balken] skippen, bzw. fallen die dank CABAC auf wenige Bits zusammen. Da ist nicht viel zu sparen.

Weiß nicht mehr, wer das mal erklärt hat. Jedenfalls dachte ich bisher immer, dass das eigentlich Bits fressende nicht der Balken an sich, sondern der scharfe Übergang zum tatsächlichen Bild ist. Und dass dieses Problem nur dann nicht besteht, wenn der Übergang genau auf eine Macroblockgrenze fällt.
Ist das tatsächlich so und wäre es dann für AVC nicht Macroblock- sondern Partitionsgrenze?

Und ich muss mich korrigieren. Hab diese verquere 689x387 kurz getestet. Ein AVS-Script ist zwar so möglich, nur das Encoding klappt nicht. XviD braucht mod2 und x264 mod4.

Zitat

Und dass dieses Problem nur dann nicht besteht, wenn der Übergang genau auf eine Macroblockgrenze fällt.

Das ist sogar schon bei MPEG1/2 so, sollte also auch bei AVC so sein.

Zitat

Weiß nicht mehr, wer das mal erklärt hat. Jedenfalls dachte ich bisher immer, dass das eigentlich Bits fressende nicht der Balken an sich, sondern der scharfe Übergang zum tatsächlichen Bild ist. Und dass dieses Problem nur dann nicht besteht, wenn der Übergang genau auf eine Macroblockgrenze fällt.
Ist das tatsächlich so und wäre es dann für AVC nicht Macroblock- sondern Partitionsgrenze?

Die Submakroblöcke helfen, Ringing zu vermeiden aber verschwenden mvs.

Zitat

Und ich muss mich korrigieren. Hab diese verquere 689x387 kurz getestet. Ein AVS-Script ist zwar so möglich, nur das Encoding klappt nicht. XviD braucht mod2 und x264 mod4.

YUY2 und YV12 müssen immer mod2 sein, wegen dem Chroma Subsampling

Was diesen immer wiederkehrenden PAR Kram angeht.
Um es auf den Punkt zu bringen:
Damit nicht alles im Chaos endet kann man ohne Probleme den Sinn der Klassischen PARs auch bei mpeg4 anwenden. Wie Kika es sagte, man nenne mir einen Grund, warum man das ändern soll? Im doom9 wird Teilweise die Theorie verbreitet, dass die TV PAR eigentlich keinen rechten Sinn ergibt und man dann beim Encoding auf generic PAR gehen sollte, warum? Da müsste ich ja -->dazwischen<-- interpolieren.
NUR! Die individuelle DAR/PAR bei avi's wird imho nur bei Videolan, Mplayer (und einem Dshow Player mit speziellen Splittern? oder Bitstreamhandling) beinahe korrekt angezeigt.
Videolan und Mplayer nutzen ebenso eine "Generic" par von 768/720 beim entzerren von 4:3 Content --> Falsch.

Jetzt wird zudem Hingegangen und jeder kocht sein eigenes Süppchen, da wird lecker hingegangen und mit generic PAR beim Behandeln von original DVDs (mpeg2) gerechnet. Der eine Macht PAR, der andere DAR und am Ende sind alle wirr. Es war ja schon für viele Irreführend, dass bei mpeg2 es ein 4:3 und ein 16:9 "Ausdruck" gab, obwohl kein klares 4:3 oder 16:9 bei rauskommt.
Dann hat man wenigstens den Begriff anamorph manifestiert, denn der machts eher einleuchtend.

Wenn man eine DVD Source z.B. mit 720x576 "non-anamorph" hat, dann braucht man lediglich die schw. Balken via Mod16 wegcroppen NIX resizen und mit PAR/SAR von 128/117 zu enkodieren. Das wäre eine 100% identische Pixel Aspect weiterleitung an den Encoder und dessen Flag-Erstellung.
Die bezeichnung "DAR" ist sehr tricky, da man nie weiss, wie es der mpeg4 Encoder/Decoder umsetzt. PAR steht für ein klares Pixelaspect-Ratio woraus sich eine DAR ergibt.

Bei anamorph sourcen kann man hier ebenfalls mit der bekannten TV PAR arbeiten und diese in die Kalkulation übernehmen.

128 __4 __512
--- * --- = --- = 1,45869:1 = anamorph PAR/SAR
117 __3 __351

geht man also hin und nimmt einen anamorphen mpg2 stream einer DVD, dann auch hier --> Ränder weg-croppen, so dass am ende MOD16 bei rauskommt, im Encoder bei SAR 512/351 eingeben und enkodieren.
Da wird nix vorher interpoliert. Wennd denn nachher wieder was falsches im Player erscheint, dann hat der Enkoder da was falsch gesetzt oder der decoder (system/player) kocht da sein eigenes Süppchen.

Der Knaller ist vor allem dann bei den mpeg4 SAPs angesagt. Denn die scheinen meistens eh nix mit ner anderen PAR als 1:1 anfangen zu können und da wäre der klare Vorteil vom anamorph encoding dahin, selbst ein re-encoding der lossless Spitzenklasse würde bei PAR 1:1 am TV mit mehr Unschärfe enden.

Du sprichst mir aus der Seele!
Da wird extra MPEG4 benutzt - welche Variante auch immer - und der einzige Vorteil, der sich daraus ergibt ist, dass man kleinere Dateien erhält. Dass man gleichzeitig einen Teil der erreichbaren Qualität sofort wieder wegwirft, indem man auf Maße resized - oder überhaupt resized - scheint kaum jemanden zu interessieren.
Und die SAPs, tja, da müsste man mal die Entwickler fragen. Aber die Antwort ist ja eh klar. Die haben sich an den existierenden Videos orientiert, und die hatten nun mal alle PAR 1:1.

Und was diese generic PAR Theorie betrifft - ich weiß ja nicht, wie's andere TVs machen, mein LCD zeigt von einem 720er MPEG2-Bild jedenfalls ziemlich exakt 702 Pixel, keinen mehr, keinen weniger.

Zitat von Kika

Und was diese generic PAR Theorie betrifft - ich weiß ja nicht, wie's andere TVs machen, mein LCD zeigt von einem 720er MPEG2-Bild jedenfalls ziemlich exakt 702 Pixel, keinen mehr, keinen weniger.

Wie hast du den angeschlossen?

Zitat

Da wird extra MPEG4 benutzt - welche Variante auch immer - und der einzige Vorteil, der sich daraus ergibt ist, dass man kleinere Dateien erhält. Dass man gleichzeitig einen Teil der erreichbaren Qualität sofort wieder wegwirft, indem man auf Maße resized - oder überhaupt resized - scheint kaum jemanden zu interessieren.

Ich mache mich jetzt bestimmt unbeliebt, aber die mpeg4 quality-ahead theorie war bei 90% der ganzen mpeg4 kodiererei eh von Anfang an eine Milchmädchenrechnung.
Bei NTSC machts Sinn. 720x480 ist hier eh ein interpolations-Tod-Punkt er nacher am TV kompensiert wird.
Aber non-PAR 1:1 enkodieren im Falle von PAL war für mich eh immer eine Art der Kompression bei erhalten maximaler Details auf späterer gleicher Widergabegröße. Geh ich hin und enkodiere "richtig" PAR 1:1 für die Beamer etc. Wiedergabe ist das dann was anderes. 720x576 auf 720x576 croppen, auf 1024x576 resizen filtern, h264 enkodieren, ab via HTPC an den Beamer der 1024x768 beherrscht, wie auch immer nur eben dann nicht via S-Video oder Scart.

Zitat

Wie hast du den angeschlossen?

S-Video, RGB, Component (Scart und echter Component) sowie HDMI - welches Schweinderl hätten's denn gern?
Bei HDMI hält er sich nicht dran, da zeigt er den Stream as is, bei allen anderen Verbindungs-Möglichkeiten macht er aber bei 702 Pixeln dicht - immer.
Übrigens sieht das bei manchen DVDs völlig sch... aus, wenn man HDMI benutzt (Balken etc.), Component ist da besser. Es sei denn, ich benutze den HDTV-Component-Mode, dann benimmt er sich auch da wie bei HDMI.

Was das Resizen für einen bestimmten Zweck betrifft: Ja, das klappt, kann ich bestätigen, aber was, wenn sich der Zweck - sprich das Wiedergabe-Gerät - mal ändert? Dann sitzt man bei Non-Standards wieder im Regen.

Zitat

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).

Sollte ohne irgendetwas manuell einzustellen alles automatisch richtig erkannt werden.

Zitat

Was mir nicht einleuchtet ist, dass StaxRip nicht das exakte 16:11 verwendet.

Weil StaxRip denn Wert grundsätzlich anhand des DAR's berechnet, hab so kompakten und einfachen Quelltext der auch für Auflösungen wie 480x576 funktioniert. Bei einem aktuellen build sollte man 48:33 bekommen was exakt 16:11 entspricht.