x264 anamorph

Zitat

ich benutze MeGUI zum Encoden (x264). Muss man da etwas einstellen, wenn man anamorph encoden will oder wird das AR ausschließlich im Kontainer angegeben?

Jo, AR wird im Kontainer angegeben. Man braucht nix extra in MeGui einzustellen.

Zitat

Und zu Auflösung: reicht mod4 für Breite und Höhe bei x264?

Naja da wird die Kompression etwas leiden...
Aber mal sehen was die Expterten sagen

@ nexus: du kannst für pal material auch einfach --sar 16:11 unter custom commandline eintragen (---> Flag im Bitstream), dann kommt die richtige AR am Ende raus....

mkvtoolnix übernimmt dann automatisch die richtigen Werte, wenn es nach Matroska gehen soll.

Zitat von nexustheoriginal

Hi Leuts,

ich benutze MeGUI zum Encoden (x264). Muss man da etwas einstellen, wenn man anamorph encoden will oder wird das AR ausschließlich im Kontainer angegeben?

Wie schon geschrieben, du solltest bei PAL Material in 16:9 Auflösung entweder zur Kommandozeile "--sar 16:11" oder "--sar 512:351" hinzufügen.
Flags in Containern mögen zwar schön und gut sein, allerdings ist es so wesentlich einfacher.

Zitat von nexustheoriginal

Und zu Auflösung: reicht mod4 für Breite und Höhe bei x264?

http://forum.gleitz.info/showthread.php?t=32031
--> Das am besten mal ganz durchlesen.

Mod16 wenn du rezised ist immer noch am besten. Falls du die Auflösung beibehalten willst und nur croppst, solltest du bei x264 schauen, dass du alle schwarzen Ränder wegcroppst. Egal, ob am Ende mod1, mod2, mod4 etc bei herauskommt. x264 rechnet das intern um.

Filter wie Fillmargins oder Addborders behindern x264. Das rechnet das intern wesentlich besser, da x264 im Falle von mod2 auflösungen oder ähnlichem selbstständig schwarze Ränder dranrechnet, die allerdings beim decoding Vorgang nicht angezeigt werden.

Wenn schon Mod16 oder Mod8, dann ohne schwarze Ränder. Alles andere wäre schlechter als ein mod4 oder mod2.

nö, 16:11

es wird wie bei xvid's PAR das croppen miteinbezogen...

Bsp:

PAL DVD Auflösung: 720x576 --> croppen Mod16: 716x432 --> in XviD PAR 16:9 auswählen und es wird der Wert 16:11 im Bitstream als Flag gesetzt. Es wird die korrekte AR am Ausgabegerät angezeigt.

Wenn du stattdessen einen DAR Wert setzen willst, musst du richtig rechnen, dass die gecroppten Werte auch berücksichtigt werden. Beim PAR Wert ist das inklusive...

Genauso beim SAR - Wert für x264...

Der SAR Wert von x264 ist nichts anderes als das PAR, leider nur anders ausgedrückt.

Am besten mal das durchlesen, das ganze ist einfach viel zu kompliziert, als dass man es schnell mal erklären könnte:

http://encodingwissen.brother-john.net/spezial/itur-bt601.html

Bei 4:3 müsste es dann 12:11 ergeben... http://seemoredigital.net/03_Video_Only_…hic_encode.html

Zitat von nexustheoriginal

128/117 = 1,0940
12/11 = 1,0909

-> Passt

Habe es mit "--sar 128:117" getestet, siehe Screenshots (links original, rechts encode. capture ist 704x576, 1:1 wäre das dann 768x576).

Danke Jungs, endlich hab ich das mal richtig kapiert.

Och, dass man es richtig verstanden hat denkt jeder alle 2 Wochen, doch dann kommt wieder ne neue Fragestellung

Najaaa, eigentlich gibt es 12 Möglichkeiten:

- 4 Stück exakt nach ITU,
- 4 Stück vereinfacht nach ITU,
- 4 Stück generisch = ITU ignoriert.

Bei Captures kann es auch noch eine Ecke komplizierter werden. Scheint mit solchen Scherzen wie halber hor. Auflösung zusammenzuhängen.

x264 erwartet mindestens Mod4-Auflösungen. Ganz freie Wahl geht schonmal deshalb nicht, weil YV12 hor. mod4 und vertikal mod2 haben muss. Kopernikus hat aber vor kurzem in einem anderen Thread mal erklärt, dass erst Mod8 "günstig" wäre. Und richtig perfekt und ganz ohne Effizienzverlust natürlich nur Mod16.

Soweit ich das verstanden habe, ist mod8 deswegen günstiger als noch weiter runter, weil die DCT mit 8x8-Blocks arbeitet. Und dann passen zwischen Original und Encoding wenigstens die DCT-Blocks noch glatt aufeinander. Noch weiter runter, verschiebt sich das. Wenn jetzt im Original Blockartefakte sind (die müssen auch gar nicht so deutlich sichtbar sein), hast du harte Kanten zwischen den Blocks im Original. Natürlich nicht so extrem wie bei schwarzen Balken, aber der Effekt geht in die selbe Richtung. Im Encoding fallen diese Kanten nicht mehr auf die neuen Blockgrenzen und brauchen deshalb mehr Bitrate, weil sie der Encoder nicht von Bilddetails unterscheiden kann.

Mod16: Perfekt
Mod8: Besser als Balken stehen lassen
Mod4: Schlechter als Mod8. Wieviel schlechter und ob immer noch besser als Balken, kommt wohl darauf an, wie blockig die Quelle ist.

Dann ist's halt die Frage nach dem geringeren Übel: Kannst du dir die geringere Encoder-Effizienz gut leisten oder sind ein paar wenige abgeschnitte Pixel vom eigentlichen Bild doch unwichtig.

Die DCT (von MPEG4 ASP) ist 8x8 (luma) bzw 16x16 (chroma) groß, deshalb ist bei ASP mod 16 relativ wichtig. Die Motion Compensation funktioniert mit minimal 8x8 Blöcken.

Die HCT (von H.264) gibt es für luma in 4x4 (standard) und 8x8 (High Profile), bzw. 8x8 und 16x16 für chroma. Die Bewegungskompensation geht bis 4x4 Blocks runter.

zu mod 4:
Dann hätten wir einen mod 2 Chroma kanal, und somit zwei Blöcke, die halb aus echtem Inhalt bestehen und halb aus Edge Extension. Im Luma Kanal haben wir nur ganze Blöcke mit echtem Inhalt bzw. Edge extension.

Da die 4x4 Transformation praktisch nicht ringt und man das im Chroma vermutlich auch nicht sehen würde (es handelt sich ja nichtmal um eine wirklich scharfe kante, sondern um einen übergang zwischen Bild und Edge Extension) ist vermutlich mod4 auch nicht soo schlimm.

Ich glaube (das ist nicht durch Tests irgendeiner Art untermauert, sondern nur ein educated guess), dass mod4 oder mod8 oder mod16 nicht sehr Unterschied macht (zumindest bei x264 nicht). Da haben andere Dinge mehr einfluss.

Hallo,

was ist mit folgenden Weg (den GKnot automatisch macht, wenn man nicht auf die dort bei W-Modul und H-Modul eingestellten Werte (z.B. 16) croppt):

1: genau croppen (geht auf mod2 genau)
2: auf mod16 resizen (z.B mit einem Faktor zwischen 98 und 100%)

Verändert ein Resizer viel, wenn man nur ein ganz kleines bisschen resizt?

Gruß

akapuma

Zitat von akapuma

Hallo,

was ist mit folgenden Weg (den GKnot automatisch macht, wenn man nicht auf die dort bei W-Modul und H-Modul eingestellten Werte (z.B. 16) croppt):

1: genau croppen (geht auf mod2 genau)
2: auf mod16 resizen (z.B mit einem Faktor zwischen 98 und 100%)

Verändert ein Resizer viel, wenn man nur ein ganz kleines bisschen resizt?

Gruß

akapuma

Alles anzeigen

Naja, das ist wieder so ein Kostennutzenfaktor.
Auf jeden Fall gilt: Keine Schwarzen Ränder bei x264.

Muss man einfach mal testen: Ich würde eher ein Mod4 in Kauf nehmen als ein größenverändertes Mod16. x264 hat die Routinen drin um bis auf Mod4 runterzurechnen, also sollte man dem Codec das auch zutrauen.

Hab mal nen kleinen Test mit crf21 und vergleich zwischen Mod16 mit Balken (2 Pixel groß) und Mod4 ohne Balken gemacht: Die Mod16 Version war ungefähr 5% größer, abgerundet.