Nur Cropping – intern trotzdem IMMER „Resize“?

Tag zusammen!

Da ist mir jetzt eben so ein verwegener Gedanke gekommen, wobei ich allerdings denke, dass der gar nicht mal so verwegen ist.

Fragen an die Codec-Experten ...
... dabei spielt es im Prinzip keine Rolle, von welchem Codec (DivX, XviD etc) die Rede ist:

Beispiel:
Das Quell-Video hat eine Bild-Pixel-Auflösung von 720x576 – „klassisch“ (PAL) also.
Egal ob ich nun die Mod16-Regel beim Cropping der schwarzen Balken nicht einhalte oder vielleicht doch „codec-friendly! die Mod16-Regel beim Cropping beachte, so komme ich z.B. NUR durch das Cropping auf eine neue Bild-Pixel-Auflösung von 720x336.

Dass NUR durch das Cropping die Sache ZUFÄLLIG „codec-friendly“ ist, spielt für mich zunächst keine Rolle, jedenfalls wollte ich ja von vorne herein keinen RESIZE-Filter verwenden. Zudem setzte ich knallhart nicht mal ein AR-Flag – z.B. ganz nach dem Motto „der Zoom Player bügelt mir schon das >richtige< AR hin.

Nun die geistreichen (Anfänger-)Fragen:

1) Allein durch den Umstand, dass sich durch das Cropping nicht nur das DAR des Video-Bildes geändert hat (von 1,25:1 zu 2,14:1), sondern auch das FAR von 720x576 zu nunmehr 720x336 - findet dann bei der Kompression INTERN dennoch ein „Resize“ samt allem Drum und Dran statt, obwohl ich direkt keinen Resize-Filter beauftrage?
Richtig oder falsch?

2.) Falls 1) richtig, dann findet INTERN ebenso auch eine Neu-Skalierung + Interpolation der Bild-Pixel statt, was grob heißt, es bleibt beim Encoden so oder so nie ein Mosaik-Steinchen auf dem anderen, denn das Video-(Raster-)Bild wir ja ohnehin komplett in seine Einzelteile zerlegt, und in einem (neuen) Bitmap-Raster (Bild-Pixel-Raster) intern neu zusammengewürfelt, bzw. neu „aufgelöst“.
Richtig oder falsch?

3.) Falls 2) u. 3) richtig, dann hätte ich unter Umständen so oder so IMMER Bildrauschen im Video-Clip, und mit einem RESIZE-Filter gebe ich dem Codec ledglich manuell bekannt - nachdem er ohnehin vor hat „die Karten neu zu mischen“, er solle dabei z.b. meinen Wunsch berücksichtigen, dass unterm Strich eine Bild-Auflösung von z.B. 720x304 rauskommen soll.
Richtig oder falsch?

4.) Ich ignoriere auch noch z.B. das „harte Kanten“-Problem, und sage dem Codec, dass die Auflösung gleich wie das Quell-Video sein soll. Falls 1) u. 2) u. 3) richtig sind, werden vom Codec auch in diesem Fall die Karten SO ODER SO „neu gemischt“ – nur dass er hierbei vielleicht mehr zu tun bekommt, da ja mehr Pixel zu bearbeiten sind, und auch die „harte Kante“ - wenn schon - dann sauber erhalten bleiben soll. Jedenfalls, der Codec macht in diesem Falls aus 720x576 rechteckigen Pixel lediglich 720x576 quadratisch Pixel. Schrumpft somit ohnehin ganz konkret die Video-Auflösung etwas.
Richtig oder falsch?

Im Klartext:
Egal was und wie ich was mache, beim Encoden bleibt ohnehin NIE ein Stein auf dem anderen, und dabei spielt es auch keine Rolle mehr, ob ich z.B. eine Resize-Filter verwende oder nicht – heißt, Gefahr zum „Bildrauschen“ laufe ich so oder so. Also würd's keine Rolle spielen, ob ich gleich nen Resize-Filter nehme oder keinen verwende.
Richtig oder falsch?

Da ich nicht in einen Codec reingucken kann, auch seine Vorgehensweise bzw. sein Arbeitsweise NICHT genau kenne, sind obige Fragen doch irgendwie berechtigt – oder?
Es sei denn, ich hab das irgendwo bei "Häufig gestellte Fragen" übersehen - dann sorry ...

Jedenfalls,
besten Dank im Voraus für Aufklärung + vielleicht kurze Hinweise!

Zitat von Redfox

1) Falsch. Die Abspielsoftware führt die Größenänderung gemäß des DAR/PAR durch, NICHT der Encoder.

Hi - und danke!
Aus deiner Antwort, die eigentlich nur richtig sein kann, kann ich also schlussfolgern, dass NUR beim Einsatz eines Resize-Filters "kein Stein auf dem anderen bleibt". Richtig?
Heißt also, Cropping alleine bewirkt KEIN gesamtes "Resize", bei welchem ALLE Bild-Pixel dann (quadratisch) umgeformt werden - richtig?
Und dass dabei (resize), sobald dieser mal eingesetzt wird, in der Tat kein einziges Bild-Pixel mehr am anderen bleibt (also ALLE Bildpixel neu angeordnet/interpoliert/skaliert wird), ist doch richtig - oder?

Das wäre noch gut zu wissen, wie das konkret läuft, denn dann wäre soweit alles klar.
-------------
Nachtrag:
Ooops, das kann aber doch nicht stimmen was du sagst - zumindest, kommt darauf an:
Hab grad geguckt: Der Xvid-Codec ist IMMER voreingestellt für quadratische Pixel (shape of a pixel). Heißt also, selbst wenn ich NUR croppe, macht er alles QUADRATISCHE Pixel bei meinem Ausgabe-Video. Der Software-Player (z.B. Zoom Player), würde im Fall 1) lediglich für die Entzerrung des auf quadratischen Pixeln bestehenden Videos sorgen. Er würde also nur das FAR richtig stellen, nicht aber das PAR (das kann der so gesehen gar nicht) - falls ich nicht irre...

Danke selur!
O.k. dann war ich soweit auf der richtigen Fährte.

Ob nun DivX oder Xvid (arbeite mit Xvid) - FRAGE:
Egal welchen MPEG4-Codec ich zum Encoden verwende, und ich belasse die Standard-Einstellung (Square), und ob ich nun den Resize-Filter verwende oder nicht, und wenn ich beim Input-Material "RECHTECKIGE" Pixel habe, das Bild also verzerrt ist, so macht der Codec daraus schlicht und ergreifend "QUADRATISCHE" Pixel beim Output-Video. Gut. O.k.

Und wenn er das tut, und ob dann nun bicubic oder Lanczos etc als Filter für die interpol., der Codec bzw. Filter lässt dann keinen "Stein" (Bild-Pixel) auf dem anderen. Damit meine ich, JEDES einzelne Bild-Pixel ("Bitmap") des Video-Bildes (in welcher Form er das konkret codiert interessiert mich gar nicht) wird jedenfalls vom Codec "bearbeitet". Und zwar JEDES, auch das Mitten im Zentrum des Video-Bildes, es bleibt also nichts am Fleck wie es beim Input-Video mal war - besonders dann (aber eigentlich egal), wenn ich die ursprüngliche Bildauflösung (egal welche) z.b. stark verkleinere.

Ich würde mich schon über ein klares JA! oder NEIN! freuen ...
========
Danke MegaDeath.

Zitat von MegaDeath

Was für ein wirr
quadratische Pixel dann wird die Auflösung natürlich umgerechnet.

Und das war's, was ich eigentlich wissen wollte.
Heißt also, sobald z.B. dem Xvid gesagt wird, er soll es Standard (square) machen, dann wird IMMER umgerechnet - egal welche Auflösung ich neu wähle oder sie belassen würde - sofern hier natürlich die ganze Zeit von DVD-Quell-Material (MPEG-2-Streams) die Rede ist, und von meiner Seite auch ist.

Selur:
ehm, du hast das mit Encoder u. Filter wohl so bei mir verstanden, dass diese beiden für mich dasselbe sind. Dass das 2 Paar Schuhe sind, das weiß ich. Was ich aber nicht genau weiß, und wie sollte ich auch, ist dessen konkrete (zumind. grobe) vorgehensweise, und eben welchen Einfluss es dann auf dieses oder jenes hat. Eben z.b., wenn alles umgerechnet werden muss, interpoliert werden muss, wird halt nicht immer zum besten Ergebnis or gar zu Fehlern führen - so in die Richtung meine ich das.

Puh, hm, mal versuchen das Pferd von hinten aufzuzäumen …

Selur, @didee, Brother John – mir ist schon schon klar, dass ihr kein Anfänger seid, und ich bin schon froh, wenn ich so inetwa 10 – 15 Jahren mal so einigermaßen mit euch mithalten kann. Hilft aber nix, die Postings hier sind nur mehr reinstes Wirr Warr für einen Anfänger …

Stichwort Anfänger vs. Profi:
Euch ist doch sicher der Name Avery Lee bekannt, also der Ur-Entwickler von VirtualDub.
Soweit mir bekannt ist, ist VirtualDub schon knapp 10 Jahre „am Markt“. Avery Lee scheint aber auch nach wie vor die „Ur-Version“ von VirtualDub zu hegen und zu pflegen, und er ist auch nach wie vor im „Inoffiziellen VirtualDub-Forum“ recht aktiv. Er selbst hat auch mir schon persönlich dort bei kniffligen Dingen geholfen.
Wie auch immer:
Am Anfang stellte ich mir z.B. die Frage, WIE eigentlich der interne Filter RESIZE von VirtualDub funktioniert. Denn irgendwas „schien da nicht zu stimmen“ - meiner Meinung nach.
Ich hatte also anfangs bei Aspect ratio nämlich immer einfach entweder 16:9 oder 4:3 eingegeben – was so aber nicht wirklich funktioniert …
Ich war dann auf der Suche nach Antworten, und zwar,
WIE der interne VirtualDub-Filter >Resize< eigentlich funktioniert:
[Blockierte Grafik: http://img21.imageshack.us/img21/4540/filterresizegr2.jpg]
Tja, und WER könnte das wohl besser beantworten, als sein Schöpfer selbst – nämlich Avery Lee, denn der interne VirtualDub-Filter, IST ja schließlich sein „Kind“.
Ich wurde also fündig nach der Antwort zu meiner Frage, und fand HIER Folgendes:
Bei den letzten User-Kommentaren ganz unten, hatte letztes Jahr jemand (u.a.) diesbezüglich angefragt (das war nicht ich!) und hat da irgendwas von „PARs“ gefaselt …

Tja, und die Original-Antwort darauf von Avery Lee (Phaeron - 05 12 08 - 04:15) könnt ihr ja dort selbst lesen. Ich hol dazu mal einfach hier sein Posting rein, und werde es einfach mal etwas für’s bessere Verständnis – inkl. in [xxx]-Klammern kleine Ergänzungen von mir - „entzerren“:

Zitat

Er...

First of all, the dialog only accepts frame aspect ratio [FAR], not pixel aspect ratio [PAR]. You can use the resize filter to adjust for changes in PAR as well as it's the same resampling operation either way, but the dialog won't really help you do that as it works in frame aspect [FAR].

The way the current resize filter works is
- that it resamples the image to the size specified in the top half and
- then converts it to the frame size in the bottom half, if they differ.

If you choose 4:3 in the size portion, then you'll get the image stretched to 768x576 with the resampling filter you specify. If you choose 4:3 in the framing options, then you'll get the 720x576 image just copied over with black bars on the side. You can also mix the two to get a blend of both resampling and letterboxing or cropping.

As for the resampling itself, it's the same bog-standard point sampling, bilinear, or bicubic filter kernels you'd find anywhere else. The continuous filter kernel is offset by the desired source offset, sampled according to the positions of the source pixels it overlaps, and then the source pixels are weighted and blended according to the kernel. Phaeron - 05 12 08 - 04:15

Achtet u.a. genau darauf, WIE Avery Lee (und der ist nicht wirklich ein Anfänger!) die Sache mit dem FAR und PAR dabei verklickert!

Jedenfalls, aus diesem Posting wurde ich bisher am meisten schlau, denn GENAU SO läuft das auch! Was ich allerdings damals aber nach wie vor NICHT wusste war, und zwar, was ich nun aber KONKRET beim Feld „Aspect ratio“ eingeben sollte …

Nach Hirn-Einschalten fand ich es schließlich raus:
Dort ist bei verzerrtem MPEG-2-Material (z.B. DVD) schlicht und einfach das richtige DAR der Quelle anzugeben! Und das ist eben NICHT das grundlegende Anzeigen-Verhältnis 16:9 oder 4:3, sondern entweder:
1.33:1 / 1.78:1 / 1,85 / 2.35:1 / 2.40:1 – jedenfalls, das exakte DAR des Originals OHNE etwaige schwarze Balken links/rechts!

Wenn man das Original-DAR des Videos nicht weiß:
DANK Brother John weiß ich es, wie ich es (näherungsweise) ermitteln kann. Denn ich muss ja dazu nur die zur Wiedergabe korrekte horizontale Auflösung berechnen (also als nach PAR nach MPEG-4-Tabelle), und komme so zumindest NÄHERUNGSWEISE an den Wert des Originals. Zumindest weiß ich so, was es ganz KONKRET nur sein kann. Tja, dieses konkrete Original-Video-DAR (z.B. 2,35:1) gebe ich dann wie am Bild oben dargestellt bei Aspect ratio ein – alle Standard-Einstellungen in Xvid blieben (square), und was glaubt man wohl, was als ERGEBNIS rauskommt?

So wie es aussieht (4 versch. Beispiele bis jetzt), ein offenbar EXAKT entzerrtes Video!
Woher ich das wissen will?
Na ganz einfach: Ich verwende den ZoomPlayer, und bei dem z,B. via die [R]-Taste auf der Tastatur, kann ich ja beim ZP verschiedene DARs einstellen. Mein Monitor vor der Nase hat eine Anzeigen-Auflösung von 1024x768. Der Monitor selbst (19Zoll) ist 4:3. Am PC hängt aber noch (via DVI) der 32Zoll LCD-TV dran, welcher wiederum ein 16:9 Verhältnis hat. Meine Grafikkarte muss in dem Fall zwar quasi eine Luftakrobatik machen (Klone-Modus) – ABER: Wenn ich dem ZoomPlayer sage, es soll das DAR der Quelle zeigen („Quelle“), tja, bei beiden Anzeigen-Geräten (4:3 / 16:9) ein völlig entzerrtes u. ganz offenbar korrektes Video-DAR – und das auf Anhieb!

Ergo, es wurde also ein Video produziert, welches „quadratische“ Pixel hat ("changes in PAR as well as it's the same resampling operation either way"), und somit in einer Umgebung mit quadratischen Pixeln auch entzerrt und korrekt dargestellt wird.

Ich hätte z.b. bei obigem Beispiel KEINE Resize-Filter genommen (also anamorph belassen, und OHNE Flag), und hätte dem ZoomPlayer halt dann auf 2,35:1 gestellt – Ergebnis: Na ja, einigermaßen „2,35:1“ – aber nicht wirklich eines.
FAZIT:
Auf oben beschriebene Weise, kommt man offenbar auf das recht „exakte“ DAR wie es sein sollte. Alles andere interessiert somit eigentlich nicht …

Die Frage ist halt noch, WIE läuft das bei anderen Frontends bzw. Resize-Fillter, z.b. StaxRip? Hm, muss ich erstmal testen …

Mag schon sein, dass ich hier vielleicht dem einen oder anderen sicher nix Neues erzähle – für andere vielleicht aber doch.

P.S: ich werde bei Gelegenheit versuchen das Start-Posting hier zu einer kleinen „FAQ“ umzubauen. Also nix weiter wie die Fragen belassen (vielleicht mehr präzisieren) + die „richtigen“ Antworten dazu. Und IHR checkt das halt dann ...

hm, also wundern tut es mich nicht, dass die meisten Leute lieber auf Drag&Drop-Methoden via DivX zurückgreifen. Hat ja schließlich nicht jeder vor wegen ein paar Video-Files zu kompressen gleich ein Informatik-Studium zu betreiben oder die Sache zu einer Lebensaufgabe zu machen .
Eine Sache (Auflösungen/Seitenverhältnisse), die IMHO mehr aufgebauscht wird, als unterm Stich eigentlich notwendig ist. Ein Anfänger will schließlich nur eine paar grundlegende Dinge zu dem Thema wissen wie "welche Seitenverhältnis gibt es (Standard etc), und welche sollten es letzlich sein bzw. worauf gilt es in welchem Fall zu achten." - Mehr will ja Otto-Normalverbraucher nicht wissen. Denn der ganze Rest ist dann meist ohnehin (mehr od. weniger) immer Routine.
Und nein, wüsste nicht irgendwo auch nur 1mm von Haupt-Thema (Cropping/Resize) abgewichen zu sein, denn diese Dinge stehen halt immer im Zusammenhang mit AR/FAR/DAR/PAR. Und somit lassen wir es halt gut sein.
Alles semantisch genug für dich? :ani_lol:

Zitat von Brother John

Genau genommen muss er sich eigtl. gar nicht damit beschäftigen. Die Frontends erkennen das AR bei Standardmaterial recht zuverlässig und rechnen standardmäßig in quadratisch um. Das passt i.d.R. sehr gut zu dem, was der Anfänger haben möchte.

Deine Frage ganz oben war, ob die AR-Optionen in den Encoder-Dialogen zu einem Resizing führen. Deine nächste Frage war nach der Funktionsweise des Resizing-Dialogs in VDub. Ein ziemlich eindeutiger Themenwechsel, findest du nicht …

Danke Brother John! Mit ersten Absatz hast du mir eine wichtige Frage beantwortet. O.k. mit 2. Absatz (abweichen) habt sowohl du und Selur recht. Aber nach dem Posting-Wirr-Warr wollte ich lediglich ein konkretes Beispiel zu einem Fall etwas näher beschreiben. Wie auch immer:
Das wollte ich nämlich schon immer wissen, ob denn mittlerweile nicht Frontends "fähig" sind schon beim Parsen zu erkennen, um welches Material es sich handelt, und demnach dem Anfänger (automatisiert) Vorschläge macht. Die Frage, die sich mir dabei noch stellt, ob das Teil auch dementsprechend auf bestimmte Werte oder die ganze analog/digital-Problematik "getrimmt" ist, und somit die Vorschläge auch ganz gut und brauchbar sind, als wenn man das "zu Fuß" (also manuell anhand Tabellen etc) machen würde.

Also ich hab zwar schon mal StaxRip installiert, muss mich aber erst mal mithilfe deiner Anleitung damit etwas vertrauter machen. Wäre also z.B. StaxRip für mich als Frontend gefragter, damit ich künftig nicht länger jemanden am Nerv gehe muss und mir somit selber einen Gefallen mache?
Dank im Voraus!