Davinci Resolve (formáty videa)

20.10.2020 02:03 | Přečteno: 2037× | Linux | poslední úprava: 20.10.2020 14:06

Obecněji o souborech sloužící k ukládání videa, audia, ... atd.

Digitální záznam obrazu a zvuku můžeme chápat jako určitý způsob ukládání informací o snímaném obrazu a zvuku do souboru. Můžeme si představit diskrétní záznam obrazu a zvuku jako posloupnost vzorků barev jednotlivých bodů obrazu a úrovní signálu zvuku (přičemž bitová hloubka pro barevné složky a zvukový signál určuje jemnost rozlišitelné škály). Aspect Ratio představuje poměr stran obrazu, rozlišení pak množství bodů zaznamených v horizontálním a vertikálním směru, u zvuku vzorkovací frekvenci signálu. Množství zaznamených snímků/sekundu obrazu pak určuje tzv. framerate (fps .. Frames Per second). U klasických filmů 24p typicky ~24 Frame Per Second snímaných progresivně(vcelku). Svět TV nás naopak desítky let obdařoval 50i(případně 60i), obrazu snímaného a vysílaného prokládaně (interlaced).

Na straně jednoduchosti, objemnosti a bezeztrátovosti je to například historický .AVI(formát RGB24 uncompressed) na druhé straně komplexnosti, úspornosti a ztrátovosti je tu .mp4(formát AV1). Jelikož bezeztrátový způsob ukládání obrazu a zvuku vyžaduje velký objem dat, přišly ke slovu kompresní algoritmy (zprvu ty bezeztrátové RLE,LZW jež plně zachovaly originální digitální informaci). Tyto metody však narazily na své limity (omezená úspěšnost komprese, omezená kapacita datových nosičů) a tak přišly na řadu ztrátové algoritmy komprese obrazu a zvuku jež stavěly na omezených schopnostech lidského zraku a sluchu vnímat rozdíly (obzvlášť u měnícího se obrazu videa).

Z těch nejrozšířejnějších ztrátových formátů zmiňme například MPEG-1 (ten spíše nenašel než našel uplatnění ve standardu VideoCD), MPEG-2 (DVD, pozemní DVB-T a satelitní vysílání DVB-S), MPEG-4 Part2 (na alternativní scéně s jeho implementacemi DivX/Xvid), MPEG-4 Part10(alias MPEG-4 AVC/H.264) v Blu-Ray,DVB-T/T2/S2,YT, MPEG-H Part 2 (alias HEVC/H.265) v např. UHD Blu-ray,Netflix 4K. Jak je vidět z příkladů použití tyto formáty byly především určeny pro šíření finálního obsahu k divákovi éterem/médii/Internetem. Hlavní měřítkem pro jejich vývoj byl nejspíš poměr kvalita/bitrate což vedlo k využití technik jako je například mezisnímková predikce a řady dalších. Velmi zjednodušeně řečeno u tohoto typu souborů(streamů) se předpokládá, že budou přehrávány ve směru času a k tomu, aby se zcela zobrazil N-tý snímek je u nich zapotřebí interpretovat minimálně relevatní data souboru(streamu) od nejstaršího vztaženého snímku.

A nyní si představme časovou osu v NLE, na kterou je vložen tento typ souboru a my se s ukazatelem na timeline snažíme přesunout v čase zpět v očekávání, že budeme schopni pozici plynule nastavit na jakýkoli ze snímků (nikoli jen na ty, které jsou si ve streamu datově soběstačné). Předpokládám, že při snaze o postavení na libovolný snímek ukazatelem časové osy se musí dekódovat růžně velká část souboru (podle závislostí daného snímku). Bohužel takovýto typ souborů produkuje řada DF a asi i SF. Jedno z řešení může být za cenu větších objemů dat využití u formátu H.264 tzv. All-I (tj. záznamu produkujícího jen úplné snímky). Scrubbing timeline je pak plynulý (dekódování jednotlivých snímků má podobnou pracnost). Je otázkou nakolik je případná nedostupnost All-I u DF dána vyššími HW nároky proti IPB a nakolik jde o pouhé cenové škálování produktů.

Naštěstí DR a asi i většina dalších velkých NLE umožňuje využít "práce v zastoupení" (Proxy), v případě DR jde o Optimized Media. Umožnuje v rámci nastavení projektu zvolit v jakém formátu/kvalitě/rozlišení se mají připravit náhradní(optimalizovaná) media pro vybrané ze vstupních souborů. Primární účel tohoto postupu asi spočívá v nahrazení výpočetně náročného rozlišení redukovaným (náhledové operace NLE se odehrávají nad menšími objemy dat, při finálním renderu se použije originální materiál), ale s ohledem na výše zmíněné vlastnosti některých vstupních formátů může být zajímavým přínosem i jen samotná změna formátu (i při zachování rozlišení).

Jak bylo zmíněno v předchozích dílech, v prostředí Linuxu je v DR prakticky (finančně) nedostupný encoding ProResu, ale jeho bratři z AVIDu (DNxHD, DNxHR) kupodivu ano a to i v jeho free edici. Vytvoření Optimized Media pro například FullHD(IPB) v plném rozlišení představuje sadu souborů (reprezentující jednotlivé snímky vstupního souboru) o velikosti od stovek KB do jednotek MB (podle zvolené kvality). To při dnešních IO výkonech v sekvenčním čtení nepředstavuje velkou výzvu.

Ziskem je pak plynulé vyhledávání pozice na časové ose samozřejmě vykoupeno kapacitními a časovými nároky na uložení(vytvoření) OptimizedMedia.

Ve free edici DR pro Linux se s tímto H.264/HEVC syndromem vzhledem k chybějící podpoře těchto formátů nesetkáme. Je pro něj nutné při připravit média ve vhodném formátu a zmíněné DNxHD/DNxHR mohou být jedním z nich. Díky podpoře BBC Research se podpora AVID formátů v FFmpegu datuje již k roku 2008. Dosažitelným (až zbytečným s ohledem na pravěpodobně omezený chroma subsampling u zdrojového videa) maximem by mělo být DNxHR 444 10bit (pozor pro UHD cca 10GB/min!).

Profesionální kamery jsou svými formáty orientované na postprodukci, takže u nich bude NLE o hrubé síle CPU/GPU/IO.

Orientační tabulka kapacitních nároků s ohledem na bitrate (přibližně)

1Mbps  450MB/hod
10MBps 4,5GB/hod
100Mbps 45GB/hod
1Gbps  450GB/hod
10Gbps 4,5TB/hod  ... pozn. nedávno uvedená 12K kamera od BMD v kvalitě B-RAW 5:1 při 24p produkuje cca 4,5Gbps(600MB/s) bitrate (kamera umí 12K i v 50p, ale u něj se již musí využít vyšší stupeň komprese B-RAW 8:1)

Pro zjištění formátu a vlastností multimediálních souborů napříč platformami dlouhodobě využívám nástroj MediaInfo, který bývá dostupným i v repozitářích Linux distribucí.

       

Komentáře

[kol-ouch]

Dá se nějak vysledovat rozdíl v kvalitě mezi H264 a 265? Za mě nejsem schopný rozdíl vidět, ale soubory v 265 jsou menší

[PetebLazar]

Obecně asi lze říct, že pro stejný bitrate by se měl obraz v HEVCu více blížit originálu než v H.264 (díky vyspělejšímu algoritmu encodingu).

Teoreticky by asi šlo udělat experiment se zakodovanim originálního videa do obou formátů (za shodného bitrate a dalších parametrů) a následně jejich snímky dekódovat zpět do samostatných snímků a pro oba formáty odečíst dekódovaný snímek vždy od odpovídajícího originálního snímku, čímž by se asi dala matematicky vyjádřit průměrná odlišnost od obsahu originálu. Z hlediska lidského vnímání obrazu by to však nemuselo být průkazné, k některým rozdílům v obraze se člověk může stavět příznivěji (nevnímá je) než k jiným. Asi existuje vědecká kvantifikace hranic(citlivosti) lidského vnímání dynamického obrazu, ale to bude denním chlebem spíše tvůrců těchto algoritmů, než nás jejich uživatelů.

U kompresních nástrojů 7z,zip,lha,gzip,... je hodnocení podstatně jednodušší jelikož výsledek kompresního algoritmu musí vždy odpovídat originálu, takže hodnocení účinnosti komprese je funkcí velikosti vzniklého archivu (samozřejmě v kontextu výpočetních/časových nároků, případně paměťových nároků). Například, kompresní nástroj využívající nejméně zdrojů za nejkratší čas s výslednou nejúčinější kompresí je z daných nástrojů objektivně nejlepším.

[j]

Da, je to pomerne easy. Prakticky staci kdyz si uvedomis, ze abys mel mensi vysledek, musis odstranit vic dat. Tudiz i vysledek (265) musi byt zakonite horsi.

A pak uz je to jen otazka bitrate a pripadne rozliseni, pri kterym to jeste vnimas. A v tomhle pripade je ta hranice +- 1080p. Takze pokud pouzijes 265 na neco mensiho, bude vysledek vizualne viditelne horsi, nez 264. Teda za predpokladu, ze budes mit adekvatne mensi vyslednej bitrate = cca 1/2.

Zvednutim bitrate muzes samozrejme zhorseni kompenzovat, ale pak uz zas neusetris nic na velikosti.

I pri 1080 jsou pak vysledky diskutabilni, protoze pokud chces solidni vystup, tak se na 1/2 rozhodne nedostanes, a ve finale jeste zjistis, ze klidne 1/3 velikosti dela audio.

U 4k si pak proste muzes dovolit zahodit mnohem vic dat, aniz by si nekdo vsimnul, coz me vzdycky pobavi prave s honem za rozlisenim, protoze kdyz si pustis "blby" 1080 ... s rekneme 50+ Mbit, tak pochopis, ze zadny 4k ve skutecnosti nepotrebujes, protoze to co ti predlozej bude prave kvuli kompresi a mrzkymu bitrate horsi.

---

Dete s tim guuglem dopice!

[PetebLazar]

Určitě bude rozdíl v kvalitě mezi 25Mbps HEVC 4K z Netflixu a 100Mbps HEVC z Ultra HD Bluray, důležité je, že je tu možnost volby. Ono to není tak, že by ve VoD bylo 4K špatné a FullHD vynikající (i to bude také kompromisní kvality s ohledem na vyhrazený bitrate).

[David Ježek]

Promiň ale máš v tom trošku zmatek. Jen pár opravdu velkých perel... AVI dnes už není ani tak formát ale kontejner. Ano původně to Microsoftí konkurence pro Apple mov, ale už někdy před 25 se na to začala nabalovat podpora komprese pomocí kodeků, Jak správně píšeš o kousek dál. Trošku bych ten popis poupravil.

Každopádně se MP4 je ten problém že si lidé pod tímhle představují jak kontejner .mp4 tak formát videa MPEG-4, což je rodina pod kterou se vejde ... opět jak sám shrnuješ ... DivX/Xvid alias implementace MPEG-4 ASP, H.264/AVC i H.265/HEVC atd atd atd. AV1 s MP4 vysloveně nesouvisí je to jen jeden z podporovaných formátů tohoto kontejneru. Nakrásně můžeš AV1 používat i s mkv či webm.

Jinak pokud se nepletu tak třeba ffmpeg má u H.265 volbu pro lossless encoding, ale nikdy jsem nezkoušel jestli je to opravdu bezztrátové.

[PetebLazar]

Jen pár opravdu velkých perel... AVI dnes už není ani tak formát ale kontejner

V textu není použito slovo formát u .AVI či .mp4, ale v závorce "uvnitř" u RGB_uncompressed/AV1. Ilustrativní použití souborů(kontejnerů) .AVI a .mp4 to mělo pouze umístit na časové ose (pravda asi asociativní jen pro ty co oba konce zažili).

Ano původně to Microsoftí konkurence pro Apple mov, ale už někdy před 25 se na to začala nabalovat podpora komprese pomocí kodeků, Jak správně píšeš o kousek dál.

Kdo byl čí konkurencí nedovedu odhadnout .mov(QuickTime) přišel snad až roky po .avi (Audio Video Interleaved), ale autoři IFF z Electronic Arts zmiňují jako inspiraci pro FourCC Apple. IFF by měl být předlohou pro RIFF(Microsoftu),AIFF(Applu).

Jinak pokud se nepletu tak třeba ffmpeg má u H.265 volbu pro lossless encoding, ale nikdy jsem nezkoušel jestli je to opravdu bezztrátové.

V tomto paperu kde tuto vlastnost posuzovali s ohledem na vhodnost využití pro ukládání lékařských snímků (kde si asi kompresní artefakty kvůli misdiagnostice nemohou dovolit) to srozumitelně popisují (v podstatě bypass řady kroků) s výsledným compress ratio o něco lepším než komprese 7z (s úspěšným bit-match po decodingu). Takže bych tomu lossless věřil. Na druhou stranu pouhých 1:2+ nejspíš limituje využití jen na některé workflow (kapacitní limity).

[David Ježek]

ee, QuickTime (1991) je fakt starší než AVI (1992).