English
Deutsch
PolskiH.264 czy H.265 do wideo: porównanie rozmiaru, podobieństwa obrazu i czasu kodowania
Management Summary
Kompresja wideo ogranicza miejsce potrzebne do przechowywania i przesyłania nagrań. H.264, H.265 i AV1 oferują różne kompromisy między wielkością pliku, szczegółowością obrazu i czasem obliczeń. Ponowna ocena osiemnastu plików pokazuje, dlaczego żaden format nie gwarantuje stałej oszczędności: wynik zależy od materiału i ustawień. W archiwach kamer i innych zbiorach ważna jest także możliwość odtwarzania. Ponowne kompresowanie starszych nagrań może oszczędzić miejsce, ale wymaga czasu i może usuwać szczegóły.
Spis treści
Nazwa kodeka nie wyznacza stałej oszczędności miejsca. Znaczenie mają implementacja kodera, ustawienia, materiał źródłowy i kryterium jakości. Zachowany eksperyment z H.264, H.265 i AV1 jest użyteczny właśnie dlatego, że pliki pokazują granice prostego procentowego twierdzenia.
Koder to oprogramowanie lub sprzęt tworzący skompresowane wideo. Preset ustala kompromis między nakładem obliczeń a efektywnością kompresji. CRF steruje jakością w obrębie kodera; jednakowe liczby w różnych koderach nie zapewniają jednakowych wyników.
Co zawiera archiwum
Eksperyment z 2 września 2026 obejmuje dwie sześciosekundowe referencje Y4M o rozdzielczości 1280 × 720, 25 klatkach na sekundę i YUV 4:2:0 oraz osiemnaście plików MP4. Jedna scena łączy nieruchome tło fotograficzne z poruszającym się kwadratem. Druga jest syntetycznym ruchomym obrazem testowym. To skonstruowane sceny, a nie reprezentatywna próba nagrań monitoringu.
Zapisany skrypt używa libx264 i libx265 z veryfast oraz libsvtav1 z presetem 8. Wartości CRF to 20, 26 i 32 dla x264/x265 oraz 30, 40 i 50 dla SVT-AV1. Ustawienia nie są równoważnymi skalami nakładu ani jakości. W x265 veryfast jest trzecim presetem od najszybszego, nie drugim.
Co potwierdziła ponowna kontrola
Rozmiary wszystkich osiemnastu zapisanych plików zgadzają się z historycznym logiem. Ponowne dekodowanie każdej wersji względem zachowanej referencji odtworzyło wartości SSIM z odchyleniem poniżej 0,000002. Obejrzano także klatki źródłowe. Czasów kodowania nie mierzono ponownie; podane czasy pozostają historycznymi obserwacjami.
| Scena | Koder / CRF | Rozmiar (kB) | SSIM | Czas (s) |
|---|---|---|---|---|
| Spokojna | libx264 / 26 | 173,935 | 0,969647 | 7,4 |
| Spokojna | libx265 / 26 | 216,020 | 0,983188 | 48,4 |
| Spokojna | libsvtav1 / 40 | 281,820 | 0,993602 | 61,2 |
| Ruchoma | libx264 / 26 | 1273,821 | 0,990624 | 14,3 |
| Ruchoma | libx265 / 26 | 1843,236 | 0,993767 | 93,9 |
| Ruchoma | libsvtav1 / 40 | 1028,964 | 0,991210 | 178,1 |
Tabela pokazuje wybrane rzeczywiste wyniki, a nie pliki znormalizowane do równej jakości. Dziesiętne kB oznaczają 1000 bajtów. Rozmiary obejmują narzut kontenera MP4. Wiersze nie tworzą ogólnego rankingu standardów kodeków.
SSIM mierzy podobieństwo, nie identyczny wygląd
SSIM opisuje podobieństwo strukturalne do referencji. Równe średnie wyniki nie dowodzą identycznej jakości postrzeganej ani jednakowej widoczności drobnych szczegółów. Dokumentacja x265 wskazuje, że optymalizacje percepcyjne mogą poświęcać wynik metryki na rzecz wyglądu, i zaleca odpowiednie strojenie przy porównaniach SSIM. Zachowane polecenie nie zawiera tego strojenia.
Dla spokojnego źródła x264 obejmuje SSIM 0,940944–0,986467, x265 0,965353–0,992410, a AV1 0,987918–0,997030. Nie istnieje wspólny zmierzony przedział wszystkich trzech. Plik AV1 o rozmiarze 179,212 kB ma wyższy SSIM niż plik x264 o rozmiarze 300,607 kB, ale nie dowodzi to dokładnie równej jakości.
Dla ruchomego źródła zakresy się pokrywają. Interpolacja szacuje wartość pośrednią na podstawie zmierzonych punktów. Trzy próbki pozwalają w ten sposób oszacować rozmiar przy wybranym wyniku SSIM, jeśli cel mieści się w zmierzonym zakresie, a metoda jest podana. Oszacowanie nie jest faktycznie zakodowanym plikiem. Interpolacja liniowa bajtów może różnić się od interpolacji logarytmu bitrate. Porównanie percepcyjne wymaga dodatkowych dowodów.
Żaden przebieg nie wykazał kodowania w czasie rzeczywistym
Historyczne czasy wynoszą 7,4–17,1 sekundy dla x264, 41,4–149,6 dla x265 i 61,2–180,7 dla AV1, zawsze dla sześciu sekund materiału. Każdy zapisany przebieg trwał dłużej niż źródło. Nazywanie ustawień potwierdzonymi presetami czasu rzeczywistego przeczy tym obserwacjom.
Test kodowania pliku nie sprawdza też całego toru kamery. Przechwytywanie, buforowanie, opóźnienia, dźwięk i długotrwałe obciążenie wymagają osobnych kontroli. Jednakowe nazwy presetów nie oznaczają równego nakładu obliczeń. Koder sprzętowy nie gwarantuje określonej oszczędności ani obsługi każdej rozdzielczości i liczby klatek.
Granice wcześniejszych procentów
Wcześniejsze dwanaście procent oszczędności i osiemnaście procent wzrostu wynikały z wybranych porównań oraz szacowanych punktów o zbliżonej metryce. Pliki uzasadniają węższy wniosek: rozmiar i SSIM zmieniają się wraz z koderem i ustawieniem, a testowane przebiegi programowe nie nadążały w czasie rzeczywistym. Nie dowodzą wyłącznego wpływu presetu ani ogólnie mniejszej utraty efektywności AV1 przy dużej szybkości.
Proponowany próg 13,8% ruchu zakłada ponadto, że dowolne nagranie dobowe jest liniową mieszaniną dwóch scen. Zmiany scen, grupowanie klatek (struktura GOP), szum i sterowanie bitrate mogą naruszać to założenie. Nie jest to próg planowania dla kamer.
Użyteczna decyzja o pamięci
Praktyczne porównanie wymaga reprezentatywnego materiału, konkretnych wersji i ustawień koderów, powtórzonych pomiarów czasu, oceny jakości oraz wymagań odtwarzania. Zmierzony średni całkowity bitrate 1 Mbit/s daje około 10,8 dziesiętnych GB na dobę ciągłego nagrania przed narzutem systemu plików. Sama nazwa kodeka nie wyznacza bitrate.
Późniejsze przekodowanie może zmniejszyć część archiwów, lecz wymaga obliczeń. Ponowna kompresja może usunąć kolejne szczegóły obrazu. Możliwość konwersji całego zbioru zależy od mocy obliczeniowej i terminu. Historyczne przebiegi AV1 pokazują znaczny koszt w tamtej konfiguracji, a nie uniwersalny zakaz.
Pytania i odpowiedzi
Dlaczego tej samej wartości CRF w x264 i x265 nie należy traktować jako równoważnej?
Ponieważ CRF opisuje poziom jakości tylko w obrębie jednego kodera. Różnią się już wartości domyślne: 23 dla x264 i 28 dla x265. Porównanie dwóch koderów wymaga więc kilku ustawień dla każdego z nich i wspólnej miary jakości, co eksperyment próbuje zapewnić trzema wartościami CRF i SSIM.
Ile miejsca potrzeba na miesiąc ciągłego nagrywania z kilku kamer?
Przy zmierzonym bitrate 1 Mbit/s na kamerę powstaje około 10,8 GB na dobę. Przy założonych czterech kamerach i 30 dniach daje to 4 × 30 × 10,8 GB = 1296 GB, czyli niecałe 1,3 TB w jednostkach dziesiętnych i przed narzutem systemu plików.
Rachunek zależy w całości od zmierzonego średniego bitrate. Przy zmiennym bitrate rośnie on wraz z ruchem i szumem, często w nagraniach nocnych, dlatego pomiar obejmujący całą dobę z fazą dzienną i nocną mówi więcej niż krótki fragment. Każdy plan potrzebuje zapasu na szczyty.
Czy opłaca się przekodować istniejące archiwum H.264 do H.265?
Rozstrzygnąć to może tylko pomiar na własnym materiale; trzy kwestie przemawiają za ostrożnością.
- Nakład obliczeń. W historycznych przebiegach x265 potrzebował od 41,4 do 149,6 sekundy na sześć sekund materiału, czyli mniej więcej od 7 do 25 razy dłużej, niż trwa nagranie. W tamtej konfiguracji i przy tych ustawieniach jedna doba takiego materiału z jednej kamery wymagałaby przy tym samym tempie około 7 do 25 dni obliczeń. Inny sprzęt, kodery sprzętowe lub szybsze presety to zmieniają, ale dają też inne rozmiary i inną jakość.
- Utrata jakości. Archiwum jest już skompresowane stratnie. Ponowne kodowanie może usunąć kolejne szczegóły obrazu.
- Odtwarzanie i dowody. Nie każde urządzenie i nie każda przeglądarka odtwarza H.265. Jeśli nagranie ma służyć jako dowód, przekodowanie zmienia plik; sumy kontrolne oryginału przestają wtedy pasować.
Próbny przebieg na reprezentatywnym fragmencie, ze zmierzonym rozmiarem, czasem i jakością, pokazuje, czy nakład się opłaca.
Czy różnica między SSIM 0,990 a 0,995 jest mała?
Niekoniecznie. W pobliżu 1 wartości się zagęszczają, dlatego SSIM często podaje się dodatkowo w decybelach jako −10 · log10(1 − SSIM). W tym ujęciu 0,990 odpowiada 20 dB, a 0,995 około 23 dB: odległość od 1 zmalała o połowę. Średnia i tak nie pokazuje, czy różnica jest widoczna, bo może ukrywać małe, ale ważne szczegóły.
Źródła
Powiązane artykuły
