Einfluss von Pixelverhältnis auf Bildformat bzw. Seitenverhältnis ?

[DonaldFaQ]

x264 mit x265 zu vergleichen ist wie Äpfel mit Birnen vergleichen, x265 nutzt komplett andere Alghorythmen, die Codecs sind wesentlich unterschiedlicher als es der Name vermuten lässt und beide haben ihre Stärken und Schwächen.

 

[BatemanP.]

Völlig egal, was zählt ist gleiche Qualität und 50% weniger Filesize!1 aber die unseriösen x265-Encodes mit 10Mbit bei 1080p kennen wir ja alle.

 

[JellyfinPlex]

x264 mit x265 zu vergleichen ist wie Äpfel mit Birnen vergleichen, x265 nutzt komplett andere Alghorythmen, die Codecs sind wesentlich unterschiedlicher als es der Name vermuten lässt und beide haben ihre Stärken und Schwächen.

Sagen wir einfach nichts mehr ist besser

 

[BatemanP.]

Ich bin noch auf zwei Threads auf Doom9 gestoßen ( Klick und Klick ) die sich mit dem Thema beschäftigten. Dabei hat mir ein kurz und knappes Posting besser verständlich gemacht, was MrOrange im Kern mit seinen Beiträgen ausdrücken wollte.

Cropping a film from a BD with an AR of 2.35:1 results in a video-alone 1080p encode that is approximately 20% smaller in file size than one that isn't cropped.

Begründung:

The borders don't take any bits, the difference is that CRF's frame complexity metric takes into account the overall complexity of the frame--which is lower when you have large chunks of the frame that are completely black. Lower complexity ---> lower quantizer ---> higher bitrate.

Zusammenfassend gesagt ist eine teilweise bis zu 20% kleine Endgröße mit x264 bei gleichen Encodingsettings beim gecroppten Encode erwartbar, jedoch "false positiv". Beim Bild ohne Letterbox erkennt der Encoder eine höhere Komplexität und schätzt(?) vergibt(?) höhere QP-Werte. Dadurch wird stärker komprimiert und die Bitrate fällt geringer aus.

Somit hat Cropping tatsächlich keinerlei Vorteile. Selbst der Geschwindigkeitvorteil beim Encoden/Decoden dürfte nur marginal sein.

 

[DonaldFaQ]

Die schwatten Balken sind teil des vorliegenden Bildes und von Frame zu frame gleichbeibend. Bedeutet, bei 2.35:1 sind gut 1/5 des gesamten Bildes durchgehend bei allen Frames an gleicher Position "einfach schwarz". Der Encoder berechnet diese Bildanteile einfach mit und haut deswegen andere QP Werte aus (umso weniger Änderungen von Frame zu Frame umso mehr komprimiert er). Darum habe ich weiter oben geschrieben, um das zu umgehen das Bild via Avisynth croppen und am Ende mit AddBorders einfach wieder die schwarzen Balken "dranheften". Der Encoder setzt dementsprechen die QP Werte so, dass er nur die reinen "realen" Bildinfos verarbeitet und als Ausgabe hast trotzdem ein 16:9 Bild.

 

[JellyfinPlex]

Die schwatten Balken sind teil des vorliegenden Bildes und von Frame zu frame gleichbeibend. Bedeutet, bei 2.35:1 sind gut 1/5 des gesamten Bildes durchgehend bei allen Frames an gleicher Position "einfach schwarz". Der Encoder berechnet diese Bildanteile einfach mit und haut deswegen andere QP Werte aus (umso weniger Änderungen von Frame zu Frame umso mehr komprimiert er). Darum habe ich weiter oben geschrieben, um das zu umgehen das Bild via Avisynth croppen und am Ende mit AddBorders einfach wieder die schwarzen Balken "dranheften". Der Encoder setzt dementsprechen die QP Werte so, dass er nur die reinen "realen" Bildinfos verarbeitet und als Ausgabe hast trotzdem ein 16:9 Bild.

Die Schwarzen Balken macht der TV Automatisch wieder dran kenne keinen der es nicht macht

 

[DonaldFaQ]

Das ist richtig, gibt aber Szenarien wo man mit Balken kodieren will:

- Der Encode soll BluRay Standard haben.
- In den Encode sollen PGS Untertitel
- In den Encode soll ein EL gemixt werden

nur um paar Beispiele mal zu listen.

 

[JellyfinPlex]

Das ist richtig, gibt aber Szenarien wo man mit Balken kodieren will:

- Der Encode soll BluRay Standard haben.
- In den Encode sollen PGS Untertitel
- In den Encode soll ein EL gemixt werden

nur um paar Beispiele mal zu listen.

Das stimmt schon aber 99 Prozent der PGS untertitel sind aber nicht mehr im Schwarzen bereich sondern im bild

Aber mit den anderen hast du schon recht aber ich kenne fast keine gruppe die nicht bei encoden croppt ^^

 

[DonaldFaQ]

Einige Player (u.a. mein KODI der bei CoreELEC werkelt) stellen die PGS Untertitel bei cropped Material falsch dar. Da hängen dann Untertitel die so gesetzt sind, das sie genau ÜBER dem schwarzen Balken sein sollten dann mittig im Bild, weil der die Pixel dann vom gecroppten Bild abrechnet. Gibt allerdings Media Player die das richtig handeln können.

 

[JellyfinPlex]

Einige Player (u.a. mein KODI der bei CoreELEC werkelt) stellen die PGS Untertitel bei cropped Material falsch dar. Da hängen dann Untertitel die so gesetzt sind, das sie genau ÜBER dem schwarzen Balken sein sollten dann mittig im Bild, weil der die Pixel dann vom gecroppten Bild abrechnet. Gibt allerdings Media Player die das richtig handeln können.

Stimmt schon aber wenn die Gruppen Croppen machen sie nicht die PGS die bleiben dann auf 1080

 

[DonaldFaQ]

Die sind immer auf 1080px, auch bei UHD Content. Das ist wie gesagt ein Player Problem, in den PGS sind Pixel hinterlegt an welcher Position der UT sein soll, "intelligente" Player checken das bei Cropped Content und positionieren sie richtig, "dumme" Player wie der Kodi setzen diese Positionen an das reelle Bild und der UT klebt mittig im Bild.^^