Test MPEG-4 kodeků: úvod do problematiky
16.1.2008, Radek Jahoda, recenze
Na internetu lze najít testů kodeků jako šafránů. I my zde máme v podstatě jen jediný, konkrétně MPEG-2 kodeků, který je již ale více jak čtyři roky starý. Je tedy na čase podívat se na zoubek dnešním kodekům a především těm moderním. Jak je to vlastně s těmi prohlášeními různých společností, že jejich kodek je o X procent lepší než jiný nebo předchozí verze? Kdybychom jim měli věřit, tak je dnes jeden snímek videa zkomprimován do jediného bitu. Ale kde je pravda?
Kapitoly článku:
- Test MPEG-4 kodeků: úvod do problematiky
- Co se měří
- Co a jak budeme měřit
Naše metodika měření bude ještě malinko odlišná. Budeme měřit hned tři hodnoty. První hodnota bude aritmetický průměr rozdílu všech bodů, tedy něco podobného jako MSE při výpočtu PSNR. Jediný rozdíl je absence mocniny a její nahrazení absolutní hodnotou. Tato hodnota je lepší pro grafické srovnání kodeků mezi sebou, hodnota nula znamená, že jsou oba obrázky/videa identické. Porovnání tedy bude vždy stylem "menší je lepší". Oproti tomu PSNR funguje naopak - čím větší, tím lepší.
Druhá měřená hodnota bude pouze z maximálních rozdílových hodnot. Z každého snímku se tedy bude brát pouze maximální hodnota, která nám řekne, jak moc kodek chybuje při kompresi - celý snímek může být ideální, ale v jednom místě může být taková chyba, že to bude mít vliv na vizuální kvalitu.
Příklad: rozdíl původního a komprimovaného obrazu
Jak jsme si už řekli, podobnost snímků ještě neznamená kvalitu. Důležité je také zachování detailů a textur obrazu. Jistě jste si všimli, že kodeky často obraz vyhlazují, aby dosáhly lepšího subjektivního dojmu, při vzájemném porovnání s originálem ale vidíme značný rozdíl. Proto je do celkového hodnocení nutné zahrnout i tuto stránku věci. Důvod odstranění detailů je v tom, že většina kodeků provádí v blocích 8x8 bodů diskrétní kosinovou transformaci, což je převod do frekvenční oblasti. Například jednolitá plocha po převedení do frekvenční oblasti zabere pouze jeden byte místo 256. Čím více detailů, tím více hodnot DCT koeficientů, maximálně je jich opět 256. V rámci šetření místa (tedy bitrate) kodek odfiltruje vyšší frekvence po DCT. Dojde tedy ke ztrátě detailů a vznikají známe bloky v obraze o velikosti 8x8 bodů. Navíc dochází k tzv. kvantizaci, tedy snížení počtu možných hodnot (barev), kterou může DCT koeficient nabývat. Místo maxima 256 hodnot dojde k omezení, což je další důvod k tvorbě nežádoucích bloků. Tyto bloky jsou ale na straně dekodéru filtrovány, mluvíme o postprocessingu. Výsledkem pak je, že blokování je zcela nebo zčásti odfiltrováno, ale detaily se navždy ztratily. Proto budeme provádět ještě další měření.
To spočívá ve výpočtu DCT. Nejprve vypočteme DCT původního obrazu, poté DCT zkomprimovaného a odečteme počet nenulových koeficientů. Zjistíme tak počet ztacených koeficientů - ztrátu detailů. Díky postprocessingu se ale může stát, že v komprimovaném videu nějaké koeficienty přibudou. To je také špatně. Dokonce se může stát, že některé původní zmizí a jiné přibudou a na výsledku to nepoznáme. Ideální by bylo porovnat všechny koeficienty podobně jako při výpočtu PSNR.
Velikost jednotlivých snímků videa, červeně I-snímky
Původně jsem to také tak zamýšlel, ale nakonec se mi nepodařilo toto realizovat. Důvodů je víc a nebudu je tady podrobně rozebírat, protože jde o programátorské oříšky. Snažil jsem se vytvořit DirectShow filtr se dvěma vstupy, který by vše počítal, což se ale nakonec zcela nepodařilo. Rozpracovaný projekt ale není uzavřen a jistě ho v budoucnu dokončím, pouze to bude trvat déle, než jsem očekával. Je to také jeden z důvodů, proč jsem nepočítal hodnotu SSIM. Nakonec to skončilo u DirectShow filtru, který analyzuje jen jedno video, spočítá průměrné DCT a hodnoty histogramu obrázku a také zjistí přesně bitrate videa a velikosti jednotlivých snímků. Toto se provede jak s původním obrázkem, tak i s komprimovaným a navíc s rozdílovým. Z výsledků se vypočte vše potřebné.
Existuje program Quality Studio, který se snaží provádět porovnání dvou videí, ale ten se ukázal jako ne příliš použitelný, protože padal stejně často, jako přezrálé švestky. Navíc nepočítá DCT a k němu nejsou zdrojové kódy, takže jakékoliv úpravy nebyly možné. Další možností je použití AviSynth skriptování. Zde existuje i plugin na výpočet SSIM, musel by se k němu ale ještě napsat frontend a DCT také není realizováno. Nakonec vyhrálo vylepšení mého programu APL2000, který slouží pro přehrávání videa, ale zvládá i statistiku bitrate. Zbývalo dopsat "jen" analýzu obrazu, výpočet DCT a výstup hodnot. Nakonec došlo i na program pro automatické generování grafů a průměrných hodnot. Toto vše zabralo asi tři měsíce práce.
Postup byl tedy následující. Nejprve jsem analyzoval originální video a uložil jeho výsledky (použije se pouze DCT). Poté analyzoval každé video, čímž zjistil bitrate a DCT. Poté odečetl originální a komprimované video a z něj vypočetl průměrnou a maximální chybu. Tyto kroky bylo nutné dělat ručně, což opět značně prodlužuje celé měření.
Průběh počtu DCT koeficientů, modře průměr, červeně maximum
Výsledkem budou vždy tři grafy pro jednotlivý kodek s porovnáním hodnot u různých bitrate, čímž zjistíme, jak se zlepšuje kvalita s rostoucím bitrate a odkdy již nemá cenu bitrate zvyšovat. Další tři grafy budou pro každý bitrate porovnání jednotlivých kodeků. Graf bude závislost v čase a pak výsledná průměrná hodnota. Nezapomeneme ani na bitrate v čase.
Tato metodika se bude v budoucnosti vylepšovat. Cílem je zmíněný výpočet všeho najednou a tím i možnost skriptování. Výpočetní čas tolik nebolí, ale čekat vždy hodinu na dokončení výpočtu a poté vše zadávat stále dokola...
Příště už se podíváme na konkrétní výsledky jednotlivých kodeků.
Druhá měřená hodnota bude pouze z maximálních rozdílových hodnot. Z každého snímku se tedy bude brát pouze maximální hodnota, která nám řekne, jak moc kodek chybuje při kompresi - celý snímek může být ideální, ale v jednom místě může být taková chyba, že to bude mít vliv na vizuální kvalitu.
Příklad: rozdíl původního a komprimovaného obrazu
Jak jsme si už řekli, podobnost snímků ještě neznamená kvalitu. Důležité je také zachování detailů a textur obrazu. Jistě jste si všimli, že kodeky často obraz vyhlazují, aby dosáhly lepšího subjektivního dojmu, při vzájemném porovnání s originálem ale vidíme značný rozdíl. Proto je do celkového hodnocení nutné zahrnout i tuto stránku věci. Důvod odstranění detailů je v tom, že většina kodeků provádí v blocích 8x8 bodů diskrétní kosinovou transformaci, což je převod do frekvenční oblasti. Například jednolitá plocha po převedení do frekvenční oblasti zabere pouze jeden byte místo 256. Čím více detailů, tím více hodnot DCT koeficientů, maximálně je jich opět 256. V rámci šetření místa (tedy bitrate) kodek odfiltruje vyšší frekvence po DCT. Dojde tedy ke ztrátě detailů a vznikají známe bloky v obraze o velikosti 8x8 bodů. Navíc dochází k tzv. kvantizaci, tedy snížení počtu možných hodnot (barev), kterou může DCT koeficient nabývat. Místo maxima 256 hodnot dojde k omezení, což je další důvod k tvorbě nežádoucích bloků. Tyto bloky jsou ale na straně dekodéru filtrovány, mluvíme o postprocessingu. Výsledkem pak je, že blokování je zcela nebo zčásti odfiltrováno, ale detaily se navždy ztratily. Proto budeme provádět ještě další měření.
To spočívá ve výpočtu DCT. Nejprve vypočteme DCT původního obrazu, poté DCT zkomprimovaného a odečteme počet nenulových koeficientů. Zjistíme tak počet ztacených koeficientů - ztrátu detailů. Díky postprocessingu se ale může stát, že v komprimovaném videu nějaké koeficienty přibudou. To je také špatně. Dokonce se může stát, že některé původní zmizí a jiné přibudou a na výsledku to nepoznáme. Ideální by bylo porovnat všechny koeficienty podobně jako při výpočtu PSNR.
Velikost jednotlivých snímků videa, červeně I-snímky
Původně jsem to také tak zamýšlel, ale nakonec se mi nepodařilo toto realizovat. Důvodů je víc a nebudu je tady podrobně rozebírat, protože jde o programátorské oříšky. Snažil jsem se vytvořit DirectShow filtr se dvěma vstupy, který by vše počítal, což se ale nakonec zcela nepodařilo. Rozpracovaný projekt ale není uzavřen a jistě ho v budoucnu dokončím, pouze to bude trvat déle, než jsem očekával. Je to také jeden z důvodů, proč jsem nepočítal hodnotu SSIM. Nakonec to skončilo u DirectShow filtru, který analyzuje jen jedno video, spočítá průměrné DCT a hodnoty histogramu obrázku a také zjistí přesně bitrate videa a velikosti jednotlivých snímků. Toto se provede jak s původním obrázkem, tak i s komprimovaným a navíc s rozdílovým. Z výsledků se vypočte vše potřebné.
Existuje program Quality Studio, který se snaží provádět porovnání dvou videí, ale ten se ukázal jako ne příliš použitelný, protože padal stejně často, jako přezrálé švestky. Navíc nepočítá DCT a k němu nejsou zdrojové kódy, takže jakékoliv úpravy nebyly možné. Další možností je použití AviSynth skriptování. Zde existuje i plugin na výpočet SSIM, musel by se k němu ale ještě napsat frontend a DCT také není realizováno. Nakonec vyhrálo vylepšení mého programu APL2000, který slouží pro přehrávání videa, ale zvládá i statistiku bitrate. Zbývalo dopsat "jen" analýzu obrazu, výpočet DCT a výstup hodnot. Nakonec došlo i na program pro automatické generování grafů a průměrných hodnot. Toto vše zabralo asi tři měsíce práce.
Postup byl tedy následující. Nejprve jsem analyzoval originální video a uložil jeho výsledky (použije se pouze DCT). Poté analyzoval každé video, čímž zjistil bitrate a DCT. Poté odečetl originální a komprimované video a z něj vypočetl průměrnou a maximální chybu. Tyto kroky bylo nutné dělat ručně, což opět značně prodlužuje celé měření.
Průběh počtu DCT koeficientů, modře průměr, červeně maximum
Výsledkem budou vždy tři grafy pro jednotlivý kodek s porovnáním hodnot u různých bitrate, čímž zjistíme, jak se zlepšuje kvalita s rostoucím bitrate a odkdy již nemá cenu bitrate zvyšovat. Další tři grafy budou pro každý bitrate porovnání jednotlivých kodeků. Graf bude závislost v čase a pak výsledná průměrná hodnota. Nezapomeneme ani na bitrate v čase.
Tato metodika se bude v budoucnosti vylepšovat. Cílem je zmíněný výpočet všeho najednou a tím i možnost skriptování. Výpočetní čas tolik nebolí, ale čekat vždy hodinu na dokončení výpočtu a poté vše zadávat stále dokola...
Příště už se podíváme na konkrétní výsledky jednotlivých kodeků.
