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.
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........@Rüssel - das ist nur mein letzter Wissensstand, kann aber gut sein, daß das schon überholt ist.
Also eher durch 4 teilbar um Artefakte zu verhindern.The cosine transform operates at small blocks - (4x4) for luminance samples and (2x2) for chrominance samples for improved adjustment to local image properties.
?
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.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
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).
Die Größe und die Qualität liegt eigentlich in dem Rahmen, den man ohne irgendwelche Beschränkungen erwarten würde.cantsin hat geschrieben: ↑So 19 Jan, 2025 17:19Du 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?
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?!?prime hat geschrieben: ↑So 19 Jan, 2025 20:32Ja 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).
Genauso ist es, wobei mod2 weiterhin gilt. Bei ffmpeg/x264 wird das aber ohnehin erzwungen, sofern man versucht davon abzuweichen.
Kodiereffizienz bedeutet hier bei gleichbleibender Qualität möglichst wenig Bits pro Pixel (oder Sample) aufzuwenden.