Aspect Ratio bei DivX-Playern?

"ich glaube die schwarzen Balken fressen da nicht so viel (weiß da einer genauer Bescheid?)."
zumindest bei bei älteren Xvid/Divx versionen war er schon einiges,...
Vorallem da die Ränder meist nie wirklich komplett schwarz sind wenn man sie vorher nicht erst entfernt und dann künstlich wieder hinzufügt.

Zitat von billy

Ich nehme an es handelt sich hier im Original um ein 16:9 Video mit Balken (etwa 1:2,35).

Nicht nur. Es sind die unterschiedlichsten ARs zwischen ca. 1,78:1 und 2,40:1 dabei. Eben das, was nach dem Wegschneiden der Balken jeweils übrig bleibt.

Ich habe mal einen kleinen Test veranstaltet.

Quelle
PAL-DVD, Film-AR 2,35:1, 10.000 Frames, eine recht ruhige Szene.
Links/rechts gab es keine schwarzen Ränder. Die Kanten der Balken oben/unten lagen nicht auf Macroblockgrenzen.

Ziel
VDubMod 1.5.10.1, AVI
XviD 1.1, Single Pass, fester Quant 2, keine B-Frames, Rest Standard

3 Tests: Originalauflösung, nur Cropping, als Referenz Crop & Resize.

AVS-Script

LoadPlugin("C:\Programme\Encoding\DGMPGDec\DGDecode.dll")mpeg2source("E:\Video\test.d2v", idct=0)#crop(0,72,720,432)#LanczosResize(720,304)

Dateigrößen:

Originalaufl. (720x576)  227.762.176 Bytes
Nur Cropping  (720x432)  224.380.928 Bytes
Crop & resize (720x304)  161.396.736 Bytes

Die schwarzen Balken erhöhen die Dateigröße um 1,5% Prozent. Auf 1400 MB hochgerechnet macht das einen Unterschied von ca. 20 MB. Wie sich das letztendlich auf die Qualität auswirkt, lässt sich schlecht sagen. Wenn möglich, würde ich die Balken jedenfalls immer wegschneiden.

Mit Standard-B-Frames wird interessanterweise die 720x432-Version um ca. 4 MB größer als die 720x576.

Etwas offtopic:
Ich habe gelesen, Resizing würde temporales Rauschen hinzufügen. Deswegen könnte man beim anamorphen Encoding ohne Resizing eine größere Auflösung bei im Verhältnis deutlich geringerem Bitratenzuwachs verwenden. Wenn ich mir hier den Unterschied zwischen 720x304 und 720x432 anschaue: Die anamorphe Version hat 42% mehr Pixel (218880 und 311040) und braucht 39% mehr Bitrate. Bin ich falsch informiert, liegt es am Testaufbau oder habe ich einfach zufällig einen »schlechten« Film erwischt?

Nochmal offtopic:
Gibt's eigentlich ein sinnvolles einzelnes deutsches Wort für »Resizing«?

Ein Wort für "Änderung der Bildfläche"... "Größenänderung", "Flächenänderung"? (Hüstel) - Manchmal lohnt sich eine Übersetzung nicht...

"Deswegen könnte man beim anamorphen Encoding ohne Resizing eine größere Auflösung bei im Verhältnis deutlich geringerem Bitratenzuwachs verwenden."
Anamorph encoden sollte man wenn man möglichst viel Qualität/Orignaldaten erhalten will.
Der Grundsatz: Mehr Pixel => mehr Datenrate besteht immer noch.

Für's capturen ist anamorphes encoden interessant, da man eventuell die vertikale Auflösung halbiert (um einfach zu deinterlacen) beim Encoden.

Wenn wer Zeit hat könnte er mal folgende Encodes machen:

1. horz&vertikal gecroppt&resized
2. horz&vertikal gecroppt
3. horz&vertikal gecroppt aber nur vertikal geresized
4. horz&vertikal gecroppt aber nur horizontal geresized
5. horz&vertikal gecroppt und horizontale Auflösung halbiert
6. horz&vertikal gecroppt und vertilale Auflösung halbiert

=>
a. einzelnen Größen bei festem Quantizer 1 oder 2 posten
b. Screenshots posten wie die Bilder beim Decoden aussehen
(per DirectShowSource öffnen und in VD screenshot machen)

Cu Selur

Ps.: "Die schwarzen Balken erhöhen die Dateigröße um 1,5% Prozent"
Kann je nach Quelle auch mehr sein. Hatte schon encodes wo es satte 10% waren. => ich würde immer croppen

Zitat von Selur

Wenn wer Zeit hat könnte er mal folgende Encodes machen

Ich bin eh dabei, fürs Encodingwissen ein anamorphes Kapitel zusammenzuschreiben. Ich will mal nichts fest versprechen, aber ein solcher Test würde mir da ganz gut ins Konzept passen.

Zitat

aber nur vertikal geresized

Genau deswegen die Frage nach einem deutschen Wort. »Geresized« klingt sowas von schrecklich. Ich muss gestehen, dass mir auch nichts Besseres als »aber nur mit vertikaler Größen-/Auflösungsänderung« einfällt.

Zitat

Kann je nach Quelle auch mehr sein. Hatte schon encodes wo es satte 10% waren.

Kannst du dich erinnern, ob das eher »unsaubere« Balken waren?

Zitat von billy

Dein letzter Test: Crop & resize (720x304) ist doch sicher Pixelratio 1:1, Seitenverhältnis des Bildes ~2,37

Genau. Natürlich in eine mod16-Auflösung gequetscht. Ganz exakt wären es gewesen 720x296 und 2.431:1.
Warum du das aber wieder mit Balken in einen 4:3-Rahmen packen willst, verstehe ich nicht. AR 1:1 sollte ein MPEG-4-fähiger Standalone doch sowieso abspielen können. Warum dann nicht gleich bei 720x304 bleiben?

"Ich bin eh dabei, fürs Encodingwissen ein anamorphes Kapitel zusammenzuschreiben."
was kommt da denn so rein ?

billy
Ah, jetzt verstehe ich’s.

Horizontal crop & resize ist schon sinnvoll, denn gerade am Computermonitor sind auch kleine vertikale Balken schon störend. Man gewöhnt sich zwar nach ein paar Minuten dran, aber warum damit leben, wenn es nicht sein muss?
Für deinen speziellen Fall würde ich sie allerdings lassen, denn erstens schluckt die der Fernseher sowieso und zweitens landest du mit Cropping bei ungünstigen 704 hor. Pixeln.

Zitat von Selur

"Ich bin eh dabei, fürs Encodingwissen ein anamorphes Kapitel zusammenzuschreiben."
was kommt da denn so rein ?

Grobe Gliederung:
- Was ist anamorph? Wann/warum ist welche Methode sinnvoll?
- Die versch. Möglichkeiten: Originalauflösung lassen, nur Cropping, Cropping und anamorphes Resizing -> Wie lässt sich das mit GKnot umsetzen?
- Wie speichert man AR-Flags und welche Decoder können welche Art Flagging wieder lesen.
Das sollte das Thema einigermaßen abdecken. Frage dazu am Rande: Gibt’s ein Tool, das für AVC-nicht-in-MP4 das MPEG-4-AR-Flag setzen kann? Das wäre für anamorphe x264-Encodings notwendig. MPEGModifier frisst leider nur ASP-AVIs.

Zitat von billy

Wenn ich eine Bildhöhe von 576 produziere, also Balken einfüge, wird das Video als 4:3 dargestellt (768x576) obwohl es in der Datei als 5:4 vorliegt (720x576). Ich kann also bei obigem Beispiel 20 Zeilen mehr Information unterbringen.
Oder zum Bspl. ein 4:3 Video bei AR 1:1 u. 720 Pixel horizontal wären es vertikal 540 Pixel um es korrekt auf dem Fernseher darzustellen. Wenn ich aber 576 Bildhöhe habe dann stellt mein Player das als 4:3 dar (wie bei ner DVD) als ob es 768x576 wären. Das selbe habe ich auch auf anderen Playern von Arbeitskollegen festgestellt. Es scheint so, daß bei 576 Zeilen eine Umschaltung auf 4:3 erfolgt, oder anders ausgedrückt einfach das Pixelratio verändert wird.

Bist Du dir da wirklich sicher? Bei meinen Tests (die allerdings schon eine ganze Weile her sind) konnte ich das nicht feststellen und ich hatte damals mehrere Player zum Testen.
Ist es nicht so, dass das Bild tatsächlich in 720*576 abgespielt wird und Du nur den Eindruck hast, es würde korrekt entzerrt, weil die "schwarzen Balken" links und rechts lediglich vom Overscan-Bereich des TV's geschluckt werden?
Hast Du mal den Test gemacht, auf eine CD oder DVD einen Filmschnipsel mit 720*540 und den selben Filmschnipsel mit 720*576 aufzuspielen und diese direkt hintereinander zu vergleichen?
So habe ich das damals gemacht und dabei festgestellt, dass die Schauspieler bei 720*576 im Vergleich zu 720*540 etwas schmaler gerieten. Ein Beweis dafür, dass die Player damals nicht korrekt entzerrt haben.
Na ja, vielleicht hat sich ja zwischenzeitlich was getan...

EDIT:
Hat eigentlich schon jemand Erfahrung mit einem "echten" MP4-Player gemacht? Wird da der AR respektiert?

"Frage dazu am Rande: Gibt’s ein Tool, das für AVC-nicht-in-MP4 das MPEG-4-AR-Flag setzen kann? Das wäre für anamorphe x264-Encodings notwendig."
Noch nicht,..