XViD mit 1:1 Auflösung - Eierköpfe

Zitat von BillGehts

Mit großer Wahrscheinlichkeit hat hippoth aber das falsche AR im mkv Container gesetzt. Der infachste Weg das zu testen wäre das AR Flag im Codec zu setzen und nicht im mkv Container

Ich denke nicht, daß ich das falsche Flag gesetzt habe, denn wenn ich alles croppe, dann stimmt das Bild ja auch.
Aber Du hast Recht, setzte ich das Flag (Pixel Aspect Ratio) im Codec bleibt mir das richtige Seitenverhältnis erhalten, aber ich habe die schwarzen Balken die mir ja doch ganz schön die Bitrate verschwenden.
Ich brauche in dem Fall dann kein Flag mehr im MKV.

Was soll ich denn nun tun?

1. Bill´s Methode: Pixel Aspect Ratio Flag im Codec mit schwarzen Rändern, also ohne croppen rechts & links?

2. Bill´s Methode: Pixel Aspect Ratio Flag im Codec ohne schwarze Ränder, also croppen rechts & links, was aber wohl dazu führen wird das Bildverhältnis wieder zu verhauen?

3. Croppen und das Flag im MKV Container setzen, wobei ein ganzes Stück gezoomt wird??


An sich sehe ich an Bill´s Variante keinen Vorteil! ...gibts da einen?

Um ehrlich zu sein, verstehe ich es auch nicht ganz, warum bei dem einen das Bild o.k. ist und bei dem anderen auch nicht...ich könnt mir selber in den Arsch beißen, daß ich das nach so langer Zeit immer noch verhaue bzw. mir nicht einleuchtet / ich mir das nicht merken kann!

1. Also, wenn Du das Pixel AR Flag im Codec setzt, sieht es korrekt aus ? Im Prinzip wäre Dein Problem damit schon gelöst.

Das 2. nicht funktioniert habe ich ja schon befürchtet.

Das 3. nicht funktioniert liegt am falschen AR, Du setzt im Container das Picture AR und nicht das Pixel AR. Leider kenne ich mich mit mkv nicht aus, vielleicht gibt es aber eine Möglichkeit statt Picture- Pixel AR zu setzen. Es muß auf jeden Fall eine Möglichkeit geben das Pixel AR im mkv Container zu setzen, andernfalls könnte in diesem Container kein gecropptes Videomaterial eingebunden werden. Das Ergebnis wäre immer das von Dir beschriebene Phänomen.

Die beste Methode ist auf jeden Fall das korrekte AR im mkv Container zu setzen, meine Methode mit dem AR Flag im Codec hat keinen Vorteil und war nur zu Testzwecken gedacht.

hippoth,

ich habe mir noch einmal Dein Eingangsposting durchgelesen, indem Du schreibst, dass das komplett gecroppte File keinen AR Fehler aufweist.

Wenn das so ist, dann hat Ligh natürlich Recht und Du hast im mkv Container das Pixel AR korrekt gesetzt !!!

Dass Du einen AR Fehler bekommst wenn Du nur oben croppst ist auch klar, Du setzt in diesem Fall eine Pixel AR auf das gesamte Bild mit Seitenrändern. GK kann natürlich keinen AR Fehler erkennen, da Du ihm die Quelle mit Seitenrändern vorsetzt. Das Ergebnis ist dann ein Film mit falschem AR.

Richtig ist also was Ligh geschrieben hat und ich revidiere meine Aussage:

Croppen aller Seitenränder + 1:1 im GK setzen + AR im Container setzen.

--> Bill

Die 3. Methode funktioniert doch einwandfrei! Nur, daß hier das Bild gezoomt wird was ich eigentlich nicht so als tragisch sehe.

Die 1. Methode scheidet für mich wegen den schwarzen Balken und der verschwendeten Bitrate aus

Im MKV kann man soweit ich das beurteilen kann nur das Picture Aspect Ratio setzen (wird dort allerdings Display Aspect Ratio genannt was vermutlich das gleiche ist?) Ich habe in ein Matroska Container bisher natürlich nur gecropptes Material gestopft.

Warum denkst du ist Methode 3 schlecht...wegen dem Zoom?


[edit]

oho...hier überschneiden sich zwei Antworten!
Aber alles klar :daumen:

Danke für Eure Hilfe!!

[/edit]

Ich verstehe die Problematik anscheinend immer noch nicht...

Wenn im Codec das selbe Pixel-Seitenverhältnis eingestellt wird wie im MPEG2-Video von DVD (also 16:9), und in GordianKnot entsprechend 1:1, und nach dem Croppen an allen Rändern (horizontal und vertikal) möglichst nicht mehr - oder so wenig wie möglich - resized wird (GK-Einstellung ungefähr wie bei 3., bloß möglichst um 100% bleiben), dann sollte ebenfalls ein ordentliches Bild herauskommen wie bei 4.
__

P.S.: ffdshow-20040325.exe - ffdshow-changelog.txt: siehe 22.3.

(Jetzt antworte ich schon auf gelöschte Antworten... Trotzdem:)

Ja, ich meine schon den Zoom: Wenn auf DVD eine Breite von 720 Pixeln war, und du schneidest links und rechts je 32 Pixel weg (nur unwesentlich mehr als vom AutoCrop gefunden), komme ich auf 656 Pixel Breite; das gleiche klappt oben und unten: Je 32 Pixel weg von 576 Zeilen, bleiben 512. Das passt jeweils exakt auf die Modulo-Werte von 16 bzw. 32, und schon kannst du die Resize-Zeile im AVS komplett auskommentieren.

Zitat von LigH

(Jetzt antworte ich schon auf gelöschte Antworten... Trotzdem:)

Ja, ich meine schon den Zoom: Wenn auf DVD eine Breite von 720 Pixeln war, und du schneidest links und rechts je 32 Pixel weg (nur unwesentlich mehr als vom AutoCrop gefunden), komme ich auf 656 Pixel Breite; das gleiche klappt oben und unten: Je 32 Pixel weg von 576 Zeilen, bleiben 512. Das passt jeweils exakt auf die Modulo-Werte von 16 bzw. 32, und schon kannst du die Resize-Zeile im AVS komplett auskommentieren.

ja ich mach ja auch kein Resize...aber das Bild wird trotzdem gezoomt
oder worauf willst du hinaus?

Zitat von LigH

(Jetzt antworte ich schon auf gelöschte Antworten... Trotzdem:)

ja sorry...ich dachte das war Blödsinn was ich da geschrieben habe...war ja auch schnell wieder draußen! ...SORRY nochmal!

Wenn im AviSynth-Skript kein "*Resize()" mehr aktiv ist, dann wird auch beim Konvertieren nicht gezoomt. Höchstens beim Anzeigen - und da sowohl anamorph zum Erreichen des Seitenverhältnisses, als auch beidseitig zum Ausfüllen des Monitors bei Vollbild-Darstellung.

Mir ging es nur darum, dass du nach dem Croppen den Größenregler in GK nicht noch mal auf 720 Pixel hättest hochziehen sollen, sondern auf die Breite nach dem Croppen (da unten stellt man nämlich die Ziel-Bildfläche ein, in meinem Beispiel also 656x512); aber egal: Weil du Resizing dann im Script deaktivierst, spielt das nun auch keine Rolle mehr, da sind die 109% absolut ignorierbar - die hätten sich nur ausgewirkt, wenn Resize im Script aktiv geblieben wäre.

Neueste ffdshow-Version von athos: ffdshow-20040329.exe; enthält einige Bugfixes, die mit ruckelndem Video zu tun haben.