Postproduktion allgemein Forum



Codec: Filmausgabe in Sondergrößen



Fragen rund um die Nachbearbeitung, Videoschnitt, Export, etc. (div. Software)
Antworten
ruessel
Beiträge: 10103

Codec: Filmausgabe in Sondergrößen

Beitrag von ruessel »

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?


Gruss vom Ruessel



Frank Glencairn
Beiträge: 26130

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von Frank Glencairn »

Kommt drauf an ....

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.
Sapere aude - de omnibus dubitandum



ruessel
Beiträge: 10103

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von ruessel »

Bist Du sicher?

Habe mal die KI gefragt:
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.
Gruss vom Ruessel



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

Es ist ja die Frage, was "arbeitet effizienter" alles bedeutet. Kann auch der Stromverbrauch sein.
Auswirkungen aufs Ergebnis dürfte es jedenfalls nicht haben.



Frank Glencairn
Beiträge: 26130

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von Frank Glencairn »

Ich nehme an, das bezieht siech auf die Kompressions Effizienz.

@Rüssel - das ist nur mein letzter Wissensstand, kann aber gut sein, daß das schon überholt ist.
Sapere aude - de omnibus dubitandum



ruessel
Beiträge: 10103

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von ruessel »

@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........

h.264 hier: https://shopdelta.eu/h-264-image-coding ... id734.html
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.
Gruss vom Ruessel



cantsin
Beiträge: 15641

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von cantsin »

Hier gibt's ein Paper zu dem Thema:
https://www.researchgate.net/figure/The ... _220845531

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.



ruessel
Beiträge: 10103

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von ruessel »

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.
Gruss vom Ruessel



TheBubble
Beiträge: 1998

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von TheBubble »

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.



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

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
Beiträge: 1998

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von TheBubble »

Man sollte auch nichts bemerken. Nur arbeitet der Codec dann nicht mehr maximal effizient (auf die Kompression bezogen).



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

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).
?



pillepalle
Beiträge: 9866

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von pillepalle »

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
Bescheidenheit ist die höchste Form der Arroganz.



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

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.



cantsin
Beiträge: 15641

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von cantsin »

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?



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

cantsin hat geschrieben: ↑So 19 Jan, 2025 17:19
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.

Siehe u.a. hier: https://encodingwissen.de/codecs/x264/technik/



prime
Beiträge: 1539

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von prime »

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
Beiträge: 15641

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von cantsin »

prime hat geschrieben: ↑So 19 Jan, 2025 20:32
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?!?



prime
Beiträge: 1539

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von prime »

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.



dienstag_01
Beiträge: 14234

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von dienstag_01 »

"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."

Aus Encodingwissen: https://encodingwissen.de/hintergrund/v ... floesungen



TheBubble
Beiträge: 1998

Re: Codec: Filmausgabe in Sondergrößen

Beitrag von TheBubble »

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.



 Aktuelle Beiträge [alle Foren]
 
» Nikon stellt RED Kameras mit Z-Mount vor: V-RAPTOR-X und KOMODO-X Z Mount
von MrMeeseeks - Di 0:43
» Was schaust Du gerade?
von Jörg - Mo 22:52
» Kamera/-system, geeignet für mobile Livestreams?
von TomStg - Mo 22:12
» Planck 1TB / 2TB - kleinste SSD für Smartphone-Filmer?
von cantsin - Mo 22:11
» Atomos Ninja und Shogun mit HDMI RAW Unterstützung für noch mehr Kameras
von iasi - Mo 21:41
» ARRI ALEXA 265 - 65mm-Filmproduktion jetzt kompakter und leichter
von iasi - Mo 15:37
» Nikon Z50 II - Sensor-Bildqualität, Rolling Shutter und Debayering unter der Lupe
von cantsin - Mo 11:54
» Viltrox bringt 25mm/1.7 APS-C Budget-Objektiv
von cantsin - Mo 11:16
» Das Kinojahr 2024 in Zahlen & Fakten
von pillepalle - Mo 3:18
» Deutsche Kinemathek zeigt 60-80er Jahre Kultfilme kostenlos online
von thsbln - So 23:04
» Speicherkarten für HC-X2E
von Jur - So 17:07
» BADEN GEHEN | Making Of + Teaser
von Clemens Schiesko - So 17:00
» DJI stellt am Dienstag und Donnerstag Neues vor
von slashCAM - So 15:04
» Netflix macht Scanline dicht
von 7River - So 13:11
» Front-Monitoring auf der Basis eines Teleprompters
von Kino - So 12:44
» Was hast Du zuletzt gekauft?
von 7River - So 6:53
» Licht how to:
von roki100 - So 0:45
» Linsen (Vintage, Anamorphic & Co.)
von roki100 - So 0:40
» Hilfe benötigt: Externe Audio-Handles in DaVinci Resolve beibehalten?
von vago - Sa 19:11
» >Der LED Licht Thread<
von Darth Schneider - Sa 15:13
» Asus Zenbook DUO OLED ab sofort mit neuem Intel Core Ultra i9
von slashCAM - Sa 14:45
» Das erste KI-Bild bekommt Copyright Schutz
von Rick SSon - Sa 12:59
» A guide to cinematic film
von roki100 - Sa 10:58
» Licht für Foto/Filmstudio
von Rockcrusher - Fr 22:18
» Aputure Storm XT52
von macaw - Fr 18:34
» Erster Gerichtsbeschluss verneint Fair Use bei Urheberrechtsverletzung
von slashCAM - Fr 17:21
» AI-Diskussionsthread - Pro/Kontra?
von ruessel - Fr 17:08
» Erstes videooptimiertes NIKKOR Z 28-135mm f/4 PZ vorgestellt
von cantsin - Fr 16:54
» Nvidia Geforce RTX 5090 - Die beste Grafikkarte für Blackmagic DaVinci Resolve
von cantsin - Fr 16:12
» „Generatives Erweitern“ in Adobe Premiere Pro - wie man fehlende Frames herbeizaubern kann
von antonknoblach - Fr 13:33
» Autodesk Flame h265 import
von xteve - Fr 12:57
» Suche Betacam SP dvw-a500p
von Reämara - Fr 12:51
» Cinemagic Verfahren - Weltraumschiff MR-1 gibt keine Antwort
von ruessel - Fr 11:43
» AI mit "unakzeptablen Risiken" in der EU jetzt verboten
von DKPost - Fr 10:42
» Video übertragen
von morkovka - Do 22:36