English
Deutsch
PolskiH.264 oder H.265 für Video: Dateigröße, Bildähnlichkeit und Kodierzeit im Vergleich
Management Summary
Videokompression verringert den Platzbedarf von Aufnahmen bei Speicherung und Übertragung. H.264, H.265 und AV1 bieten unterschiedliche Möglichkeiten, Dateigröße, Bilddetails und benötigte Rechenzeit auszubalancieren. Die Nachprüfung von achtzehn Testdateien zeigt, warum kein Format eine feste Ersparnis garantiert: Material und Einstellungen bestimmen das Ergebnis. Bei Kameraarchiven und anderen Videosammlungen zählen zusätzlich die Wiedergabemöglichkeiten. Erneutes Komprimieren älterer Aufnahmen kann Platz sparen, kostet aber Zeit und möglicherweise Details.
Inhalt
Ein Codecname legt keine feste Speicherersparnis fest. Encoderimplementierung, Einstellungen, Ausgangsmaterial und Qualitätsmaßstab wirken zusammen. Ein erhaltenes Experiment mit H.264, H.265 und AV1 ist gerade deshalb hilfreich, weil die Dateien die Grenzen einer einfachen Prozentangabe zeigen.
Ein Encoder ist die Software oder Hardware, die das komprimierte Video erzeugt. Ein Preset legt den Kompromiss zwischen Rechenaufwand und Kompressionseffizienz fest. CRF steuert die Qualität innerhalb eines Encoders; gleiche Zahlen bei verschiedenen Encodern versprechen keine gleichen Ergebnisse.
Was im Archiv vorhanden ist
Das Experiment vom 2. September 2026 enthält zwei jeweils sechs Sekunden lange Y4M-Quellen mit 1280 × 720 Pixeln, 25 Bildern pro Sekunde und YUV 4:2:0 sowie achtzehn MP4-Kodierungen. Eine Quelle verbindet einen unbewegten fotografischen Hintergrund mit einem bewegten Quadrat. Die andere ist ein künstliches bewegtes Testbild. Das sind konstruierte Testszenen, keine repräsentative Stichprobe von Überwachungsaufnahmen.
Das protokollierte Skript verwendet libx264 und libx265 mit veryfast sowie libsvtav1 mit Preset 8. Die CRF-Werte betragen 20, 26 und 32 für x264/x265 und 30, 40 und 50 für SVT-AV1. Diese Einstellungen bilden keine gleichwertigen Aufwands- oder Qualitätsskalen. Bei x265 ist veryfast die dritte Stufe vom schnellsten Ende aus, nicht die zweite.
Was die Nachprüfung bestätigt
Alle achtzehn gespeicherten Dateigrößen stimmen mit dem historischen Protokoll überein. Die erneute Dekodierung jeder Ausgabe gegen ihre erhaltene Quelle reproduzierte die SSIM-Werte mit weniger als 0,000002 Abweichung. Auch Quellbilder wurden angesehen. Die Kodierzeiten wurden nicht neu gemessen; die folgenden Zeitangaben bleiben historische Beobachtungen aus dem Protokoll.
| Szene | Encoder / CRF | Größe (kB) | SSIM | Zeit (s) |
|---|---|---|---|---|
| Ruhig | libx264 / 26 | 173,935 | 0,969647 | 7,4 |
| Ruhig | libx265 / 26 | 216,020 | 0,983188 | 48,4 |
| Ruhig | libsvtav1 / 40 | 281,820 | 0,993602 | 61,2 |
| Bewegt | libx264 / 26 | 1273,821 | 0,990624 | 14,3 |
| Bewegt | libx265 / 26 | 1843,236 | 0,993767 | 93,9 |
| Bewegt | libsvtav1 / 40 | 1028,964 | 0,991210 | 178,1 |
Die Tabelle zeigt ausgewählte tatsächliche Ausgaben, keine auf gleiche Qualität normierten Dateien. Dezimale kB entsprechen 1.000 Byte. Die Größen enthalten den MP4-Containeraufwand. Aus den Zeilen folgt keine allgemeine Rangliste der Codecstandards.
SSIM misst Ähnlichkeit, nicht identische Wahrnehmung
SSIM beschreibt strukturelle Ähnlichkeit zu einer Referenz. Gleiche Durchschnittswerte beweisen weder identische wahrgenommene Qualität noch gleich gute Erkennbarkeit kleiner Details. Die x265-Dokumentation weist darauf hin, dass wahrnehmungsbezogene Optimierungen Messwerte zugunsten der Darstellung verschieben können, und empfiehlt für SSIM-Vergleiche eine passende Abstimmung. Der erhaltene Befehl enthält diese Abstimmung nicht.
Bei der ruhigen Quelle reicht x264 von SSIM 0,940944 bis 0,986467, x265 von 0,965353 bis 0,992410 und AV1 von 0,987918 bis 0,997030. Über alle drei gibt es keinen gemeinsamen gemessenen Bereich. Die AV1-Datei mit 179,212 kB hat einen höheren SSIM als die x264-Datei mit 300,607 kB. Exakt gleiche Qualität ist damit aber nicht belegt.
Bei der bewegten Quelle überschneiden sich die Messbereiche. Interpolation schätzt einen Zwischenwert aus vorhandenen Messpunkten. Mit den drei Stichproben lässt sich so die Dateigröße bei einem gewählten SSIM-Wert schätzen, sofern der Zielwert innerhalb des gemessenen Bereichs liegt und das Verfahren genannt wird. Die Schätzung ist keine tatsächlich kodierte Datei. Lineare Interpolation in Byte kann andere Ergebnisse liefern als eine Rechnung mit logarithmischer Bitrate. Ein Wahrnehmungsvergleich braucht zusätzliche Belege.
Kein Lauf belegt Echtzeitkodierung
Die historischen Zeiten betragen 7,4 bis 17,1 Sekunden für x264, 41,4 bis 149,6 für x265 und 61,2 bis 180,7 für AV1, jeweils für sechs Sekunden Material. Jeder protokollierte Lauf dauerte länger als das Ausgangsvideo. Die Voreinstellungen als nachweislich echtzeitfähig zu bezeichnen, widerspricht diesen Beobachtungen.
Ein Dateikodiertest prüft zudem keine vollständige Kameraverarbeitung. Aufnahme, Pufferung, Verzögerung, Ton und Dauerlast brauchen eigene Prüfungen. Gleiche Presetnamen bedeuten keinen gleichen Rechenaufwand. Ein Hardwareencoder garantiert weder eine bestimmte Ersparnis noch Unterstützung für jede Auflösung und Bildrate.
Was die früheren Prozentwerte tragen
Die früheren zwölf Prozent Ersparnis und achtzehn Prozent Mehrbedarf beruhen auf ausgewählten Vergleichen und geschätzten Punkten mit angeglichenem Messwert. Die Dateien tragen eine engere Aussage: Größe und SSIM ändern sich mit Encoder und Einstellung, und die geprüften Softwareläufe hielten Echtzeit nicht ein. Daraus folgt weder ein alleiniger Einfluss der Geschwindigkeitsstufe noch ein allgemein geringerer Effizienzverlust von AV1 bei hohem Tempo.
Auch die vorgeschlagene Bewegungsgrenze von 13,8 Prozent setzt voraus, dass beliebige Tagesaufnahmen eine lineare Mischung dieser beiden Szenen bilden. Szenenwechsel, Gruppierung der Einzelbilder (GOP-Struktur), Rauschen und Bitratensteuerung können diese Annahme verletzen. Eine Planungsgrenze für Kameras entsteht daraus nicht.
Eine brauchbare Speicherentscheidung
Ein Praxisvergleich benötigt repräsentatives Material, konkrete Encoderversionen und Einstellungen, wiederholte Zeitmessungen, Qualitätsbewertung und die tatsächlichen Wiedergabeanforderungen. Bei gemessener durchschnittlicher Gesamtbitrate von 1 Mbit/s entstehen rund 10,8 dezimale GB pro Tag Daueraufnahme vor Dateisystemaufwand. Der Codecname allein liefert diese Bitrate nicht.
Spätere Umkodierung kann manche Archive verkleinern, benötigt aber Rechenarbeit. Beim erneuten Komprimieren können weitere Bilddetails verloren gehen. Ob ein ganzer Bestand umkodiert werden kann, hängt von Rechenkapazität und Zeitvorgabe ab. Die historischen AV1-Läufe zeigen hohen Aufwand auf dem damaligen Aufbau, kein allgemeines Verbot.
Fragen und Antworten
Warum lassen sich gleiche CRF-Werte bei x264 und x265 nicht gleichsetzen?
Weil CRF nur innerhalb eines Encoders eine Qualitätsstufe beschreibt. Schon die Standardwerte unterscheiden sich: 23 bei x264, 28 bei x265. Ein Vergleich zweier Encoder braucht deshalb mehrere Einstellungen je Encoder und einen gemeinsamen Qualitätsmaßstab, wie es das Experiment mit drei CRF-Werten und SSIM versucht.
Wie viel Speicher braucht ein Monat Daueraufnahme mit mehreren Kameras?
Bei gemessenen 1 Mbit/s je Kamera entstehen rund 10,8 GB pro Tag. Mit angenommenen vier Kameras und 30 Tagen ergibt das 4 × 30 × 10,8 GB = 1.296 GB, also knapp 1,3 TB, dezimal gerechnet und vor Dateisystemaufwand.
Die Rechnung steht und fällt mit der gemessenen Durchschnittsbitrate. Bei variabler Bitrate steigt sie mit Bewegung und Rauschen, häufig in Nachtaufnahmen; eine Messung über einen ganzen Tag mit Tag- und Nachtphase ist deshalb aussagekräftiger als ein kurzer Ausschnitt. Ein Puffer für Spitzen gehört in jede Planung.
Lohnt es sich, ein bestehendes H.264-Archiv nach H.265 umzukodieren?
Das kann nur eine Messung am eigenen Material entscheiden; drei Punkte sprechen für Vorsicht.
- Rechenaufwand. In den historischen Läufen brauchte x265 für sechs Sekunden Material 41,4 bis 149,6 Sekunden, also rund das 7- bis 25-Fache der Laufzeit. Auf jenem Aufbau und mit jenen Einstellungen hätte ein einziger Tag solchen Materials einer Kamera bei gleichem Tempo etwa 7 bis 25 Tage Rechenzeit gebraucht. Andere Hardware, Hardwareencoder oder schnellere Presets ändern das, liefern aber auch andere Größen und eine andere Qualität.
- Qualitätsverlust. Das Archiv ist bereits verlustbehaftet komprimiert. Eine zweite Kodierung kann weitere Bilddetails entfernen.
- Wiedergabe und Nachweis. Nicht jedes Abspielgerät und nicht jeder Browser gibt H.265 wieder. Und wird Material als Nachweis gebraucht, ändert das Umkodieren die Datei; Prüfsummen des Originals passen danach nicht mehr.
Ein Probelauf mit einem repräsentativen Ausschnitt, gemessener Größe, Laufzeit und Qualität zeigt, ob sich der Aufwand lohnt.
Ist der Unterschied zwischen SSIM 0,990 und 0,995 klein?
Nicht unbedingt. Nahe 1 drängen sich die Werte zusammen; deshalb wird SSIM oft zusätzlich in Dezibel angegeben, als −10 · log10(1 − SSIM). Aus 0,990 werden so 20 dB, aus 0,995 rund 23 dB: Der Abstand zu 1 hat sich halbiert. Ob der Unterschied sichtbar ist, zeigt der Mittelwert trotzdem nicht, denn er kann kleine, aber wichtige Details verdecken.
Quellen
Passend dazu
