Kurze Frage, gilt es immer noch wie ich es vor 20 Jahren mal gelernt habe: Die Bildausgabe sollte in jeder Abmessung (horizont/vertikal) durch 8 teilbar sein um Artefakte in der Ausgabe zu verhindern?
Bin gerade beim Ultra-Panavision Format mit Bildverhältnis 2,76:1. Umgesetzt auf meiner BMD Pocket 6K, wäre die maximale Aufnahmebreite 6048 Pixel (durch 8 teilbar). Bei 2.76:1 entspricht das vertikal 2191 Pixel (nicht durch 8 teilbar). Ein Pixel mehr (2192) ist wieder durch 8 teilbar..... klar, 1 Pixel mehr merkt keiner, ist aber die magische 8 überhaupt noch bei der Ausgabe aktuell?
H.264: Verlangt, dass Höhe und Breite durch 2 teilbar sind.
MPEG-1 und MPEG-2: erfordern, dass die Breite und Höhe des Videos durch 16 teilbar sind.
x264: arbeitet effizienter mit Bildgrößen, die durch 16 teilbar sind. Wenn die Dimensionen nicht durch 16 teilbar sind, warnt x264, dass die Kompression darunter leiden wird.
Anstelle einer Diskreten Kosinustransformation (DCT) mit 8×8 Pixel großen Blöcken wird eine Integertransformation bei H.264 auf 4×4 Pixel (im High-Profile zusätzlich wählbar bis 8×8 Pixel) großen Blöcken verwendet. Die Entropiekodierung wurde an die veränderte Transformation angepasst.
Es ist ja die Frage, was "arbeitet effizienter" alles bedeutet. Kann auch der Stromverbrauch sein.
Auswirkungen aufs Ergebnis dürfte es jedenfalls nicht haben.
@Rüssel - das ist nur mein letzter Wissensstand, kann aber gut sein, daß das schon überholt ist.
Wäre es nicht schön das genau zu wissen? Zur Jahrtausendwende war ich zur Fortbildung in Hamburg in einer Filmklasse, der Dozent stellte diese These (mit teilbar durch 8) dort damals auf, da hatten wir ja gerade HDV und mpg1 beides glaube ich DCT. Wenn ich Lust habe, google ich mal rum, ob man da was gerade über die neueren Codecs erfährt, poste ich dann hier........
The cosine transform operates at small blocks - (4x4) for luminance samples and (2x2) for chrominance samples for improved adjustment to local image properties.
Also eher durch 4 teilbar um Artefakte zu verhindern.
Der Punkt ist wohl, dass die Kompression je effizienter wird, desto größer die Pixel-Blöcke sind - was ja auch logisch ist, weil das gewissermaßen das spatiale Äquivalent von LogGOP ist, und man bei LongGOP ebenfalls effizienter komprimiert, je mehr Frames in einer GOP stecken. (Und All-I mit seinen "Blöcken"/Gruppen von nur einem Frame maximal ineffizient ist.)
Deshalb kann h265 (im Gegensatz zu h264) auch 64x64 Pixel-Blöcke komprimieren und sind dafür optimierte Videoauflösungen durch 64 ganzzahlig teilbar.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Ich vermute mal, die Blockgröße ist nicht nur beim komprimieren wichtig, sondern auch beim Abspielen, da könnten auch Artefakte entstehen - je nach Qualität und Aufwand des Players.
Der Grund für Einschränkungen bzw. die Empfehlungen liegt an der inneren Vorgehensweise der Codecs, die Pixel in Blöcke zusammenfassen und gemeinsam verarbeiten.
So benutzt z.B. JPEG 8x8 Blöcke, die DCT transformiert werden. Wenn die Bitmap nicht dazu passt, dann muss der Rand mit "Platzhaltern" aufgefüllt werden.
Bei MPEG kommen noch Bewegungsvektoren hinzu, die sich auch auf Blöcke beziehen.
Farbunterabtastung verkompliziert die Sache ebenfalls, denn beispielsweise bei 4:2:0 Unterabtastung fehlt horizontal und vertikal jeweils jeder zweite Zischenwert, es wird aber auch eine Blocktransformation angewendet. Letztlich deckt ein Croma-Block dann bei gleicher Blockgrösse die vierfache Fläche ab.
Ich hab mal zwei Videos getestet, Breite durch 16 teilbar und Breite durch 2 teilbar (also 2 Pixel breiter).
Keine Unterschiede, die auf irgendeine Einschränkung hindeuten würden.
TheBubble hat geschrieben: ↑So 19 Jan, 2025 13:01
Man sollte auch nichts bemerken. Nur arbeitet der Codec dann nicht mehr maximal effizient (auf die Kompression bezogen).
Wenn das Bild in Blöcke unterteilt wird, hätte das doch ohnehin nur Auswirkung auf die paar Blöcke am Bildrand, die dann zu ungeraden Blöcken führen würden.
pillepalle hat geschrieben: ↑So 19 Jan, 2025 13:23
Wenn das Bild in Blöcke unterteilt wird, hätte das doch ohnehin nur Auswirkung auf die paar Blöcke am Bildrand, die dann zu ungeraden Blöcken führen würden.
VG
Wenn die Blockgröße 2x2 Pixel ist und das Video 3 Pixel breit, führt das nicht zu "ungeraden Blöcken" sondern zu einem Fehler. Halbe Blöcke gibt es nicht, das wäre was wie halbe Pixel.
dienstag_01 hat geschrieben: ↑So 19 Jan, 2025 13:03
TheBubble hat geschrieben: ↑So 19 Jan, 2025 13:01
Man sollte auch nichts bemerken. Nur arbeitet der Codec dann nicht mehr maximal effizient (auf die Kompression bezogen).
?
Du müsstest eigentlich bei Deinem Versuch bei dem 2-Pixel-Block-Video entweder eine grössere Datei erhalten haben als bei dem 16-Block-Video, oder die Bildqualität müsste etwas schlechter sein (z.B. wenn Du Einzelframes als PNGs aus den beiden Videos extrahierst und direkt miteinander vergleichst).
EDIT: Wobei ich gerade in einer technischen Dokumentation lese, dass sich beim x264-Encoder die Blockgrösse nicht ändern lässt, sondern immer auf 16x16 steht. Vielleicht bedient der sich irgendwelcher Tricks, um fehlende Randpixel zu emulieren und im Ergebnis unsichtbar zu machen?
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
dienstag_01 hat geschrieben: ↑So 19 Jan, 2025 13:03
?
Du müsstest eigentlich bei Deinem Versuch bei dem 2-Pixel-Block-Video entweder eine grössere Datei erhalten haben als bei dem 16-Block-Video, oder die Bildqualität müsste etwas schlechter sein (z.B. wenn Du Einzelframes als PNGs aus den beiden Videos extrahierst und direkt miteinander vergleichst).
EDIT: Wobei ich gerade in einer technischen Dokumentation lese, dass sich beim x264-Encoder die Blockgrösse nicht ändern lässt, sondern immer auf 16x16 steht. Vielleicht bedient der sich irgendwelcher Tricks, um fehlende Randpixel zu emulieren und im Ergebnis unsichtbar zu machen?
Die Größe und die Qualität liegt eigentlich in dem Rahmen, den man ohne irgendwelche Beschränkungen erwarten würde.
Zum Thema Macroblock: die Macroblöcke werden nochmal in sogennante Partitions aufgeteilt.
cantsin hat geschrieben: ↑So 19 Jan, 2025 17:19Vielleicht bedient der [x264 Encoder] sich irgendwelcher Tricks, um fehlende Randpixel zu emulieren und im Ergebnis unsichtbar zu machen?
Ja so in der Art wird es gemacht (Wiederholung von Zeilen). Endausgabe ist aber immer die ursprüngliche Auflösung, d.h. etwas was zusätzlich hinzugefügt wurde, wird beim Dekodieren wieder entfernt (frame cropping flags). Das ist aber nicht x264 spezifisch sondern ist im H264/AVC Standard enthalten (frame_cropping_flag, frame_crop_left_offset, frame_crop_right_offset etc).
cantsin hat geschrieben: ↑So 19 Jan, 2025 17:19Vielleicht bedient der [x264 Encoder] sich irgendwelcher Tricks, um fehlende Randpixel zu emulieren und im Ergebnis unsichtbar zu machen?
Ja so in der Art wird es gemacht (Wiederholung von Zeilen). Endausgabe ist aber immer die ursprüngliche Auflösung, d.h. etwas was zusätzlich hinzugefügt wurde, wird beim Dekodieren wieder entfernt (frame cropping flags). Das ist aber nicht x264 spezifisch sondern ist im H264/AVC Standard enthalten (frame_cropping_flag, frame_crop_left_offset, frame_crop_right_offset etc).
Was dann aber im Endeffekt bedeutet, dass man Auflösungen frei Schnauze verwenden kann und die Teilbarkeit durch 16 für die Codierungseffizienz keine Realwelt-Bedeutung hat?!?
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
cantsin hat geschrieben: ↑So 19 Jan, 2025 22:10Was dann aber im Endeffekt bedeutet, dass man Auflösungen frei Schnauze verwenden kann und die Teilbarkeit durch 16 für die Codierungseffizienz keine Realwelt-Bedeutung hat?!?
Genauso ist es, wobei mod2 weiterhin gilt. Bei ffmpeg/x264 wird das aber ohnehin erzwungen, sofern man versucht davon abzuweichen.
"Unter dem Strich bedeutet das: Wenn wir beim Cropping eine Mod-16-Auflösung erreichen, ist das nett und optimal. Nicht-Mod-16-Auflösungen sind für H.264-Encodings absolut unbedenklich und für ASP zumindest unkritisch. Bleiben evtl. inkompatible Abspielgeräte, was v.a. bei alten Hardwareplayern vorkommen kann."
dienstag_01 hat geschrieben: ↑So 19 Jan, 2025 13:03
TheBubble hat geschrieben: ↑So 19 Jan, 2025 13:01
Man sollte auch nichts bemerken. Nur arbeitet der Codec dann nicht mehr maximal effizient (auf die Kompression bezogen).
?
Kodiereffizienz bedeutet hier bei gleichbleibender Qualität möglichst wenig Bits pro Pixel (oder Sample) aufzuwenden.
Lass mich das Problem bei der Blockbildung an einem vereinfachten Beispiel erläutern:
Nehmen wir einen fiktionalem Codec an, der nur Helligkeitswerte unterstützt und im Rahmen seiner Arbeitsweise eine Graustufen-Bitmap in 4x4 Blöcke unterteilt. Jeder Block hat dafür Platzhalter für 16 Zahlen. Alle Platzhalter müssen befüllt sein, damit ein Block komprimiert werden kann.
Wenn eine Bitmap mit einer Auflösung, die durch 4 teilbar ist (wie z.B. 4x4, 8x4, 8x8, 12x12, usw.) verwendet wird, dann wird jedes Pixel einem Block zugeordnet. Die Platzhalter aller Blöcke werden hierfür benötigt und mit Pixelwerten gefüllt.
Soll jedoch beispielsweise eine Bitmap mit 7x4 Pixeln komprimiert werden, dann bleiben einige Platzhalter des am Rand liegenden Blocks leer. Der Codec füllt diese zwar mit beliebigen Zahlen auf, denn alle Platzhalter müssen Werte enthalten, aber diese werden bei der späteren Dekodierung wieder verworfen, um auf die ursprüngliche Auflösung zu kommen.
Der Randblock kann zwar nun wie jeder andere Block kodiert werden, aber da er nicht zu 100% mit sinnvollen Nutzdaten gefüllt ist sondern einen Teil Füllwerte enthält, wird die Kodiereffizienz im Allgemeinen Fall sinken.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
