anamorphes Encoding

zu Display und Picture Aspect Ratio:
http://www.3ivx.com/support/par.html
http://www.uwasa.fi/~f76998/video/conversion/

Muss gestehen den 2ten Link hab ich vor Ewigkeiten mal genau durchgearbeitet, hab aber davon nix mehr im Kopf.
=> wenn wer ne nette kleine Zusammenfassung zu Display und Pixel Aspect Ratio schreibt würde ich die gerne ins 'Wissenswertes rund um Xvid/3ivx' übernehmen

Cu Selur

ps.: wenn ich mich recht entsinne hat 'der Karl' auch mal was zu Pixel und Display Ratio geschreiben gehabt und der ist eventuell noch fit darin

Gute Besserung an den Hasen; Karl meinte auch er guckt mal, wenn er nächste Woche Zeit findet schreibt er uns auch was dazu

Cu Selur

Hier ist noch ne kleine PAR/DAR Hilfe von bobo.

Zitat von Brother John

XviD-AR: Picture-AR auf den richtigen Wert setzen. Der lässt sich am leichtesten rausfinden, indem man GKs Input-PAR auf (je nachdem) 16:9/4:3 stellt und unter »crop (before resize)« den Wert neben »Aspect Ratio....« abliest.

Ich stelle im XviD-Codec dazu nix ein...das bleibt wie es ist (steht auf 4:3 PAL)...bei jedem Film!
Da es auch keinen Einfluß auf´s Encoden nimmt.
Ich stelle in MKVToolnix dann immer "Display width/height" ...das ist exakter als "Aspect ratio" (hat mal jemand hier erwähnt). "Display width/height" ergibt sich aus dem übrig gebliebenen Rest nach dem Croppen...ich zitiere mal dazu tedgo

Zitat von tedgo

Zitat von tedgo

Croppe IMMER links und rechts zusammen 16 Pixel (wegen dem Overscan-Bereich), dann croppst Du oben und unten immer so, dass sich die verbleibende Auflösung mindestens durch 4 oder besser noch durch 16 teilen lässt.
Anschließend, beim Muxen mit mkvtoolnix (bei Display width/height) oder AVIMux, gibst Du folgende Werte ein:
bei 16:9/2,35:1 = 1024 * die nach dem Croppen verbliebene vertikale Auflösung
bei 4:3 = 768 * die nach dem Croppen verbliebene vertikale Auflösung.

Croppst Du links und rechts nicht, dann musst Du folgende Werte eingeben:
bei 16:9/2,35:1 = 1048 * die nach dem Croppen verbliebene vertikale Auflösung
bei 4:3 = 784 * die nach dem Croppen verbliebene vertikale Auflösung.
(Diese Zahlen sind nicht 100%ig genau, passen aber recht gut)

So bekommst Du Filme, die den korrekten AR behalten und bei 4:3 im Besten Falle das ganze Bild ausfüllen.

Alles anzeigen

Die Werte sind recht schlüssig, da anmorphes Material hat ein PAR (Pixel AR) von 1.459 bzw. 1,455555555556 auch 1,4545454545 (reine Rundungssache) hat. Rechnest du 704*1,454545454545 (alo wenn du gecroppt hast) ergibt das 1024 x "verbliebene vertikale Auflösung"

Alle Klarheiten beseitigt? Ich weiss, das ist manchmal echt ein schwieriges Thema bei dem man schnell auf dem Schlauch stehen kann (ging mir auch schon so). Ich versuch manchmal nicht großartig drüber nachzudenken, da ich es dann immer verkompliziere

...wobei sich die Angaben allerdings zunächst nur auf die Wiedergabe am PC beziehen, denn dafür ist ja MKV wie gemacht!

Für Standalones sollte der AR allerdings so berechnet werden, wie für DVDs, da die Filme sonst zu breit geraten (so wurde es mir zumindest nach einer Anfrage im englischen Doom9-Board von SeeMoreDigital erklärt und ich vertraue ihm da mal ).
Also gilt z. B. für den MP4-Container - obwohl auch für MPEG4 eigentlich 16:9 PAL PAR (16/11) richtig ist (und darauf beziehen sich die obigen Berechnungen) - ein AR von 16:9 (Custom PAR 64/45), wenn die erstellten Filme für Standalones gedacht sind.

So ich denke, jetzt ist die Verwirrung komplett

Na da können wir ja auch mal gespannt sein wie die Zensonic Z500 Series-SAP´s den Matroska Container interpretieren werden. Chaos!

Tja, bei Matroska ist das aber absolut kein Problem:

Einfach die Dateien noch mal brennen, Rohlinge kosten ja fast nix mehr
Vorher aber einfach per Rechtsklick den AR von z. B. 1024*X auf 1002*X ändern, falls die Schauspieler an Fresssucht zu leiden scheinen
(Natürlich muss dazu "Matroska Properties" installiert sein)

Bei MP4 gestaltet sich eine nachträgliche Änderung etwas schwieriger.
Zwar gibt es für AVC in MP4 den ARChanger, aber für gewöhnliches ASP muss man das Video erst demuxen, dann durch MPEGModifier jagen und dann wieder in die MP4 muxen...
Hach ich sag dir, meine Versuche mit MP4 sind ganz schön nervenaufreibend

hippoth
Ach übrigens:
Wenn Du in XviD den Pixel Aspect Ratio auf 16:9 PAL einstellst, bekommst Du das selbe Ergebnis wie in meinen obigen Angaben, denn MKVToolnix übernimmt den in XviD gesetzten PAR seit einiger Zeit.

Nochmal zur PAR: Bobos PDF nach würde das ja bedeuten:

Bei einer anamorphen PAL-DVD-Quelle 64:45 als Pixel-AR stimmt immer (oder doch nicht 64:45? Siehe ganz unten). Egal welche der anamorphen Encoding-Methoden aus meinem Posting oben man verwendet. Denn die Form der Pixel bleibt ja bei allen Methoden gleich. In XviD Pixel-AR "16:9 PAL" einzustellen müsste also immer hinhauen. Analog sollte es mit "4:3 PAL" für nicht-anamorphe PAL-DVD-Quellen funktionieren.
Kurz angetestet: scheint tatsächlich genau so zu sein. Damit hat die Pixel-AR natürlich deutliche Vorteile, weil man nur aufpassen muss, was DGIndex über die Quell-DVD sagt. Genau das stellt man dann als PAR wieder ein. Keine Berechnungen und unzählige wenn-dann mehr = weniger Fehlermöglichkeiten.

Jetzt stellt sich mir Matroska-Fan natürlich die Frage: Unterstützt der Matroskacontainer Pixel-AR? Wenn ich mir mkvmerge (die GUI) so anschaue, kann ich da nur Display-AR angeben, richtig? hippoth? Notfalls ließe sich aber auf das zusätzlich AR-Flag im Container auch verzichten.

Was mir am Rand aufgefallen ist:
Mal wieder der "ITU-R BT.601"-Standard, und zwar beim AR ändern per MPEG4Modifier. Wenn ich PAR "16:9 PAL" nehme entspricht das der mit ITU berechneten DAR. Wenn ich manuell die 64:45 einsetze, entspricht das DAR ohne ITU. Muss ich mal testen, ob das XviD genauso handhabt.

tedgo, diese zu breiten Filme am Standalone, könnte das mit ITU zusammenhängen? Sollte demnach vielleicht ITU für reine PC-Wiedergabe an bleiben, für TV-Wiedergabe dagegen aus?

Der Pixel Aspect Ratio hat immer dann Vorteile, wenn man croppt. Denn egal wie man croppt: Die Pixel werden immer korrekt nach Vorgabe gedehnt.

Würde man croppen und einen DAR einstellen, z. B. 16:9, dann würde das ganze nach dem Croppen übriggebliebene Bild verzerrt, denn die ursprüngliche Auflösung des Bildes wird ja im Ganzen verändert (hoffentlich war das klar verständlich, ich habe manchmal selbst Probleme, mich zu verstehen ).

Der Matroska-Container (oder besser MKVToolnix) übernimmt auch den XviD-PAR, und übernimmt die korrekte Entzerrung unter "Display width/height".
Croppt man z. B. auf 704*432 und setzt in XviD einen 16:9 PAL PAR, dann übernimmt MKVToolnix diesen PAR als 1024:432, einen in XviD gesetzten Custom PAR von 64:45 in 1001:432 (kleine Rundungstoleranz, denn besser wäre 1002:432).

Übrigens:
"Display width/height" ist bei MKVToolnix (mkvmerge) deshalb korrekter, weil man hier eine benutzerdefinierte Auflösung angeben kann, also praktisch einen "simulierten PAR" , während man bei "Aspect Ratio" nur einen DAR eingeben kann, der dann das gesamte Bild auf diesen AR entzerrt. Das ist bei gecropptem Material aber alles andere als ideal...

Und XviD handelt es genauso wie MPEGModifier.

So wie ich es mitgeteilt bekommen habe, ist es tatsächlich besser für SAs den PAR ohne ITU zu nehmen, also z. B. in XviD einen Custom PAR von 64:45.
Für den PC hingegen 16:9 PAL, da die PC-Monitore ja das Bild nicht so in die breite ziehen, wie es am TV der Fall ist.

EDIT:
Das ganze bezog sich jetzt natürlich von den Zahlen her nur auf PAL, für NTSC-Material muss man dementsprechend umdenken!

EDIT2:
(Ergängungen und Rechtschreibung. Sorry, bin halt müde )

Zitat von tedgo

hippoth
Ach übrigens:
Wenn Du in XviD den Pixel Aspect Ratio auf 16:9 PAL einstellst, bekommst Du das selbe Ergebnis wie in meinen obigen Angaben, denn MKVToolnix übernimmt den in XviD gesetzten PAR seit einiger Zeit.

Ja das hab ich schon bemerkt nur wußte ich nicht wie MKVToolnix auf den Wert kommt. Ich habe ich mir darüber dann auch keine Gedanken gemacht. Da ich das immer auf 4:4 stehen hatte mußte ich das bei 16:9 immer korrigieren....jetzt weiss ich auch warum. Prima Hinweis :daumen:

[edit]

Zitat von Brother John

Jetzt stellt sich mir Matroska-Fan natürlich die Frage: Unterstützt der Matroskacontainer Pixel-AR? Wenn ich mir mkvmerge (die GUI) so anschaue, kann ich da nur Display-AR angeben, richtig? hippoth? Notfalls ließe sich aber auf das zusätzlich AR-Flag im Container auch verzichten.

Siehe dem was tedgo schreibt --> "simulierten PAR"

Ich bin da ehrlich gesagt auch ein wenig überfragt habe habe beim Lesen hier nichts gegenteiliges einzuwerfen.

Für weitere (irreführende) Infos hier mal noch ein paar alte Links:
http://forum.gleitz.info/showthread.php?t=12643
http://forum.gleitz.info/showthread.php?t=12699

[/edit]

Was haltet ihr von folgender Vorgehensweise:
In Gknot croppe ich ganz normal bei 1:1, stell dann auf 16:9 um und notiere den Aspect Ratio Wert vom Cropping Fenster (wobei links der selbe Wert steht wenn ich nicht resize).
Beim Muxen mit mkvtoolnix schreibe ich bei Aspect Ratio den Wert von vorher hinein.
Auf diese Weise wird die Display Aspect Ratio von mkvtoolnix so berechnet, dass die volle vertikale Auflösung erhalten bleibt und nur horizontal geresized wird.
Bei einer 16/9 Quelle komm ich damit ohne croppen auf eine DAR von 1050x576 wenn ich der ITU folge (mach ich auch da nur PC).
Ohne ITU käme ich auf eine DAR von 1024x576.

So kann man es auch machen. Einfacher wäre aber in XviD einfach den PAR auf 16:9 PAL oder 4:3 PAL zu setzen, dann kannst Du dir das notieren sparen

Und nochmal:
Wenn man für den SAP zum Abspielen am TV erstellt, sollte man tatsächlich lieber auf ITU verzichten (ist ja auch irgendwie logischer).

So langsam kommt tatsächlich Sinn in die ganze Angelegenheit.

Die mkvmerge-Automatik hatte ich erst überlesen, sorry. Das klappt ja prima, um ohne zusätzliche Berechnung die AR auch in Matroska zu speichern. Ob das dann rein technisch PAR oder DAR ist: nicht so wichtig, solange das Ergebnis passt.

Genial wäre es, wenn MPEG4Modifier in Zukunft auch AVC und Matroska unterstützen würde. Dann hätten wir (abgesehen von MP4 und dem imo unwichtigen OGM) ein richtiges MPEG4-AR-Allround-Tool. Direkt beim Encoding können ja leider nur XviD und 3ivx eine AR setzen.

ITU ist keine Funktion, sondern eine Norm. (ITU-R BT.601)

Bei 16:9 PAL zum Beispiel wäre demnach die korrekte horizontale Dehnung:
Breite*16/11

Bei 4:3 PAL wäre sie:
Breite*12/11

Das heißt: Eine DVD mit 720*576 würde dann korrekt entzerrt wiedergegeben, wenn die Auflösung wie folgt wäre:

16:9 PAL
720*16/11=1047*576

4:3 PAL
720*12/11=785*576

Für die Wiedergabe am PC sollte man mit dieser ITU-Norm entzerren, da am Computer-Monitor kein Overscanbereich existiert.

Für die Wiedergabe über einen SAP am TV sollte man hingegen auf ITU verzichten. DVDs sind z. B. auch für diese Art der Wiedergabe konzipiert und berechnen ihre korrekte Entzerrung nach der DAR-Kalkulation:

16:9 PAL
720*64/45=1024*576

4:3 PAL
720*16/15=768*576

Sicherlich ist euch schon mal aufgefallen, dass DVDs deshalb am PC etwas schmaler wirken, als über den DVD Player am TV.
Da das Bild am TV aber etwas breiter dargestellt wird (Teile des Bildes verschwinden links und rechts im Overscanbereich) - denn die Wiedergabe am TV entspricht idR der ITU-Norm - passt der korrekte AR dann wieder.

EDIT: Um diese korrekte Entzerrung mit z. B. XviD zu erreichen, sollte unter "Pixel Aspect Ratio" also "Custom" und entweder X64/Y45 oder X16/Y15 gewählt werden.
(Die Angabe von X und Y bei PAR ist hier unter XviD etwas irreführend, weil man hier den Eindruck bekommen könnte Y stünde für die Breite und X für die Höhe. Tatsächlich steht aber X für den Nenner und Y für den Teiler des Faktors, mit dem die Breite multipliziert wird.
Aber ACHTUNG: Beim "Picture Aspect Ratio" (eigentlich DAR) stehen X für die Breite und Y für die Höhe!)

(Die angegebenen Werte entsprechen den Praxiszahlen am PC, nicht 100%ig der ITU-Norm!)

@BrotherJohn
Ideal wäre es zunächst mal, wenn der MPEGModifier auch OpenDML-AVI unterstützen würde, damit man damit auch Filme >2GB modifizieren kann.
Aber dann würde ich mir schon wünschen, dass er auch MP4 beherrscht. MKV müsste nicht unbedingt sein, denn da lässt es sich ja auch bequem über den Container lösen.

Und rein technisch gesehen ist es tatsächlich egal, wie die AR-Info ermittelt wird (ob nun über PAR -oder DAR-Kalkulation), denn in den MPEG4-Videostream gespeichert wird sie immer als PAR. Hauptsache sie wurde korrekt ermittelt und passt zum Verwendungszweck (also TV oder PC).

Ich weisz nicht, wie Du auf manche Zahlen kommst (aber ich weisz generell nicht, was die Grundlage mancher Aussagen in den Beitraegen dieses Threads sein soll - bin zu faul das aufzuarbeiten, sorry :hm: )

Die korrekte Methode eine anamorphe, nach ITU-R BT.601 PAR gespeicherte PAL DVD fuer den PC Monitor zu endstrecken waere:
720 (bzw. 704) x 128/117 x (1+1/3) oder anders: 720 (bzw. 704) x 512/351

Die korrekte Methode eine nicht anamorphe, nach ITU-R BT.601 PAR gespeicherte PAL DVD fuer den PC Monitor zu endstrecken waere:
720 (bzw. 704) x 128/117

Diese Zahlen sind die praxisgerechten Zahlen für MPEG4, denn im VOL Header von MPEG4-Video können nur zweistellige Werte für Nenner/Teiler gespeichert werden (so habe ich es zumindest in Erinnerung. Oder war das: nur zweistellige Werte kpnnen von den Decodern richtig erkannt werden? Keine Ahnung, muss ich noch mal suchen...).
Deshalb sind die Zahlen auf zwei Stellen auf- bzw. abgerundet.

Aus diesem Grunde ja auch der kleine Zusatz:
Die angegebenen Werte entsprechen den Praxiszahlen am PC, nicht 100%ig der ITU-Norm!

Also wenn man in XviD statt den Pixel AR, den Picture AR aktiviert und auf die Voreinstellung '2,35:1' klickt wird in die Eingabeboxen 235 und 100 geschrieben.

Stimmt, hab's gerade ausprobiert. Dann war das eine irrige Erinnerung

Ich bin auch gerade auf der Suche nach den MPEG4-Specs, denn da stehen die für den MPEG4-Standard vorgesehenen Faktoren drin (und die sind eben nunmal nur an die ITU-Norm angelehnt, passen aber nicht 100%ig mit diesen überein).
Danach passen meine Zahlen jedenfalls. Und da es in diesem Thread auch um XviD-Codierung geht, kann ich nichts falsches an meinen Aussagen entdecken.