Davinci Resolve (zajištění sekvenční IO průchodnosti)

12.6.2022 21:49 | Přečteno: 1983× | NLE | poslední úprava: 12.6.2022 22:02

Zajištění dostatečné sekvenční IO průchodnosti pro DRS v prostředí Linuxu(Windows).

Jak bylo v předchozích záznamech blogu naznačeno, ne veškerý materiál je ideální pro editaci (nikoli z pohledu kvality obrazu dosažitelné v daném formátu, ale v jeho technické způsobilosti k editaci). Konkrétně mám na mysli záznamy v H.264(HEVC) při využití IPB, kdy snímky streamu mohou být zakódovány vůči obsahu jednoho/více předchozích snímků. To může ovlivnit (více než u záznamu ALL-I, kdy všechny snímky jsou klíčovými) plynulost při scrubbingu záznamu na timeline. Jedním z řešení tohoto nedostatku může být převedení konkrétního záznamu IPB do NLE-friendly formátu např. Avid DNxHR/DNxHD (např. s využitím Optimized Media). K tomu je zapotřebí dostatek prostoru (bezeztrátovější formáty bývají nenasytnějšími) a slušná IO průchodnost storage. Jelikož může jít u hodin záznamu o řadově stovky GB a více, většina dnešních SSD (TLC based a horších) může narazit na limity velikosti své SLC-cache (kdy ukládaná data jsou do určitého objemu zapisována na SSD rychle v režimu pSLC(1bit/cell) a teprve následně zapisována řadičem SSD v pomalejším cílovém tvaru TLC(3bits/cell), QLC(4bits/cell). To způsobuje nezřídka propady v rychlostech zápisu, vedoucí u některých modelů k rychlostem trvalého zápisu za niž by se styděly asi i vnitřní stopy 2,5" 5400rpm HDD.

Na trhu zatím přežívá v comsumer třídě (v enterprise jich asi také moc nebude) poslední mohykán, kterému je pojem SLC-cache naštěstí cizí. Je jím Samsung 970 Pro NVMe 1TB (dostupný i v 512GB variantě), který využívá MLC 2-bit, takže data jsou na SSD zapisována přímo v cílovém tvaru (u TRIMovaného prostoru?). To mu umožnuje, dle výkonu použitého PC dosahovat trvalých rychlostí zápisu cca 2-2,5GB/s přes celou kapacitu. Další výhodou MLC je vyšší životnost (deklarovaných 1200 přepisů pro 1TB model).

Jelikož 1TB kapacity není v oblasti videa zas až tak velkým prostorem, je možné zmíněných SSD zkombinovat více. To by mělo přinést jak vyšší kapacitu, tak vyšší sekvenční rychlosti.

Pokusy se čtyřmi Samsung 970 Pro to aspoň naznačují. Místní zastánci ZFS/Btrfs asi z prokládaného svazku ve Windows a RAID0 v Linuxu nebudou nadšeni, ale připomínám že jde o storage pro umístění dočasných souborů s cílem maximálního výkonu(prostoru). PCčkem je dnes již obstarožní Thr 1950X/X399 (v září snad dovrší 5 let), ale jeho výhodou je možnost bifurkace PCIe 16x 3.0 slotu na režim čtyřikrát 4x3.0. Což v kombinaci s vhodnou PCIe kartou umožnuje osazení čtyř NVMe M.2 bez zabírání slotů M.2 na MB.

Ve Windows 10 nástroj nástroj přímo od BlackMagicDesign ukazuje dosaženou průchodnost v zápisu a čtení.

Benchmarkovací nástroj ATTO ukazuje při větším bloku prakticky teoretický limit zápisu čtyřech SSD (10GB/s).

Fio v Linuxu při iodepth>1 se také dosáhlo rychlosti zápisu 10GB/s (s iodepth=1 okolo 5GB/s). ATTO výše měl queue_depth=4.

Rychlost zápisu v Linuxu na md RAID0 byla okolo 7GB/s (dd .... oflag=direct).

hdparm -t --direct /dev/md0 
Timing O_DIRECT disk reads: 26240 MB in  3.00 seconds = 8746.22 MB/sec (prakticky shodnz jako BMD Disc Speed Test).

Fio v Linuxu při iodepth=4 četlo rychlostí cca 12GB/s.

Pozn. Maximální deklarovaná rychlost čtení jednoho SSD je ~3,5GB/s (jde o SSD NVMe 4x 3.0, kde 4GB/s by měl být jednosměrně strop samotného PCIe). U vysokých rychlostí IO asi bude hrát svou roli i případná (ne)výkonnost PC.

OT: Na screenshotu BlackMagic Disc Speed Test je kromě rychlostí i tabulka rychlostí záznamu (frames/s) pro konktrétní rozlišení/standard záznamu. Předpokládám, že i další pamětníci co kdy v minulosti grabovali analogový video záznam pomocí AverMedia/Pinnacle atd. zamačknou jako já slzu dojetí při výsledku RAID0u 10187 frames/s pro 10bit YUV 4:2:2 NTSC/PAL.        

Komentáře

[Max]

A teď dotaz. Kde máš při své práci úzké hrdlo? Je to na straně storage, nebo CPU, nebo někde jinde?
Zdar Max

[PetebLazar]

Vzhledem k orientaci DRS na GPU si myslim, ze pro vetsinu operaci bude ta tim uzkym hrdlem, ale samozrejme CPU/RAM/storage jsou take dulezitymi (v PudgetSystem benchmarcich DRS (za CAPTCHA) jsou rozdily podle pouziteho CPU pri stejne GPU i vyssi desitky procent).

Zkusil jsem DRS na stanici s 8-channel 512GB RAM (Epyc 7343 16c) s renderovanim do ramdisku (220GB) a pri asi nejjednodussi uloze tj. 8K timeline solid color generator do AVI uncompressed RGB 10bit se dosahlo trvaleho zapisu cca 4GB/s vystupniho streamu. Takze u mne (dosahl jsem na cca 2GB/s) je v teto trivialni uloze asi limitem CPU (ve Windows jsem dosahl na stejnem PC obdobnych vysledku). DRS umoznuje u jednotlivych storage volbu "direct I/O", ktera nemela na vysledny vykon vliv (bottleneck jinde).

Velka rychla storage muze mit prinos napriklad pro ukladani render cache, ktera narocne pasaze vyrendruje a pri nahledu ci finalnim renderu primo pouzije (samozrejme v pripade zmeny, ktera obsah cache invaliduje je nutny jeji opetovny rendering).

Jsem docela zvedav na MACH.2 Multi-Actuator Hard Drives/, zda to snizi nutny pocet HDD pro atakovani 500MB/s+ prenosovych rychlosti pri stale zajimave kapacite. Vypada to, ze uvodni 14TB model se jevi jako dval logicke 7TB HDD.

[Max]

O MACH.2 jsem nevěděl (nebo zapomněl), jsem zvědavý, jak se to bude reálně chovat. Co tak koukám, první zmínky asi v roce 2018 a další před rokem a vypadá to, že to venku ještě není.
Zdar Max

[PetebLazar]

Asi se nekdo u Seagate inspiroval starymi blueprinty po akvizovanem Conneru. U jejich reseni spolupracovaly dve sady hlav nad stejnymi plotnami, takze to melo asi pozitivni dopad na lacence.

[PetebLazar]

Pri zmene chunku md0 na 128KB se rychlost cteni dle hdparm zvysila na 10GB/s.

sudo hdparm -t --direct /dev/md0

/dev/md0:
 Timing O_DIRECT disk reads: 30088 MB in  3.00 seconds = 10029.09 MB/sec

[Max]

Předtím jsi měl 64KB předpokládám?
Zdar Max

[PetebLazar]

Defaultne se /dev/md0 vytvari s chunk size 512KB. Pri chunku 64KB, 256KB, 512KB je vykon dle hdparm nizsi.

[PetebLazar]

V dřívějím dotazu jsem experimentoval s dm-cache ve snaze zajistit transparentni cachování obsahu pomalé storage s uloženými médii(footage). To se chovalo trochu nepredikovatelně, k danému nakonec nebylo navrženo.

Napadl mne trochu jiný přístup. Vytvorit /array_HDD (s dostatkem kapacity), na kterém budou uloženy veškerá neměnící se media (footage). Dale /array_SSD, na kterém budou uloženy v ekvivaletních cestách soubory medií, které jsou využity na timeline posledních(aktivnich) projektů. Jelikož využívám repository DRS ulozene v Postgres databázi mělo by jít o vcelku jednoduchý dotaz přes pár tabulek. Po nakopírování "užívaných" souborů do /array_SSD z /array_HDD by v /array vznikly symbolicke linky primarne na soubory existující v /array_SSD a nasledne pro vsechny ostatni soubory v /array_HDD. V projektech by byly soubory odkazovany vzdy z cesty /array (podle toho kam by konktretni link vedl by soubor byl v NLE sekvencne rychleji/pomaleji dostupny). Aktualizace obsahu /array_SSD by šla provádět na bázi rozdílů seznamů.

[PetebLazar]

Tak to vypada, ze DB repository DRS vyuziva mj. tabulek Sm_Project, Sm2Timeline a Sm2TiItem. Hodnota Sm_Project.LastModTimeInSec (muze byt hodnotou pro stanoveni zivosti Projektu) a Sm2Timeline a na ni navazujici Sm2TiItem.MediaFilePath obsahuje uplnou cestu k souborum pouzitym na timeline (footage atd). Seznam [mp_project.LastModTimeInSec,sm2tiItem.MediaFilePath] seradit podle cerstvosti projektu, odstranit duplicity (soubory vyuzivane ve vice Timeline), seznam souboru zredukovat s ohledem na kapacitu /array_SSD, nakopirovat soubory z redukovaneho seznamu z /array_HDD na /array_SSD, vytvorit na ne sym-linky v /array na /array_SSD, nasledne vytvorit sym-linky v /array na ostatni soubory v /array_HDD.

[PetebLazar]

Tak těch tabulek bylo trochu víc.

select TI."MediaFilePath", SP."ProjectName",SP."LastModTimeInSecs" from public."Sm2TiItem" TI inner join public."Sm2TiTrack" TT ON TT."Sm2TiTrack_id" = TI."Sm2TiTrack_id" inner join public."Sm2Sequence" SS ON SS."Sm2Sequence_id"=TT."Sequence" inner join public."Sm2Timeline" TL on TL."Sm2Timeline_id"=SS."Sm2Timeline_id" inner join public."SM_Project_Sm2Timeline" PT on PT."DbAssociate"=TL."Sm2Timeline_id" inner join public."SM_Project" SP on SP."SM_Project_id"=PT."DbOwner" where TI."MediaFilePath"<>'' order by SP."LastModTimeInSecs" desc;

Vysledkem je seznam souboru pouzitych na Timeline(s) v jednotlivych projektech, nazev projektu a casem posledniho ulozeni daneho projectu (asi sec od 1.1.1970). I pri jednom pouziti souboru na Timeline se mohou vyskytovat dva zaznamy (pro video stream a audio stream souboru).

                   MediaFilePath                   | ProjectName | LastModTimeInSecs 
---------------------------------------------------+-------------+-------------------
 /NVMe/Output/ProRes/2019-11-02_12-13-03_all-I.mp4 | yyyyy       |        1655408593
 /NVMe/Output/ProRes/2019-11-02_12-13-03_all-I.mp4 | yyyyy       |        1655408593
 /NVMe/Output/ProRes/2019-11-02_12-10-46.mp4       | dev         |        1655248122
 /NVMe/Output/ProRes/8k_422_prores.mov             | dev         |        1655248122
 /NVMe/Output/ProRes/2019-11-02_12-10-46.mp4       | dev         |        1655248122
 /NVMe/Output/ProRes/A001_03061457_C005.braw       | dev         |        1655248122
 /NVMe/Output/ProRes/A001_03061457_C005.braw       | dev         |        1655248122
 /NVMe/Output/ProRes/8k_422_prores.mov             | dev         |        1655248122

[PetebLazar]

Vysledkem vyse navrzeneho skriptu je struktura adresaru ve filesystemu /NVMe (puvodni cesta souboru v projektech, v prispevcich vyse pro nazornost obecneji pojmenovany jako /array) obsahujici pouze symbolicke linky vedouci bud do originalni (uplne) storage /array_HDD ci do (podmnoziny) storage /array_SSD (to v pripade pouziti konkretniho souboru z timeline projektu jez nepresahl prostor "cache" filesystemu /array_SSD).

pwd
/NVMe/ProRes
...
lrwxrwxrwx  1 user user    47 čen 19 14:34  dune-trailer-1_h1080p_afx.mov -> /array_SSD/ProRes/dune-trailer-1_h1080p_afx.mov
lrwxrwxrwx  1 user user    43 čen 19 14:34  dune-trailer-1_h1080p.mov -> /array_SSD/ProRes/dune-trailer-1_h1080p.mov
lrwxrwxrwx  1 user user    47 čen 19 14:19  Elysium_trailer_1-4K-HDTN.mp4 -> /array_HDD/ProRes/Elysium_trailer_1-4K-HDTN.mp4
lrwxrwxrwx  1 user user    42 čen 19 14:19  F004C007_190925_MN99.mxf -> /array_HDD/ProRes/F004C007_190925_MN99.mxf
lrwxrwxrwx  1 user user    51 čen 19 14:19  infamous-trailer-1_h1080p_afx.mov -> /array_HDD/ProRes/infamous-trailer-1_h1080p_afx.mov
lrwxrwxrwx  1 user user    47 čen 19 14:19  infamous-trailer-1_h1080p.mov -> /array_HDD/ProRes/infamous-trailer-1_h1080p.mov
lrwxrwxrwx  1 user user    55 čen 19 14:19  irresistible-trailer-1_h1080p_afx.mov -> /array_HDD/ProRes/irresistible-trailer-1_h1080p_afx.mov
lrwxrwxrwx  1 user user    51 čen 19 14:34  irresistible-trailer-1_h1080p.mov -> /array_SSD/ProRes/irresistible-trailer-1_h1080p.mov
lrwxrwxrwx  1 user user    42 čen 19 14:34  J012_C003_0923FV_001.R3D -> /array_SSD/ProRes/J012_C003_0923FV_001.R3D
lrwxrwxrwx  1 user user    38 čen 19 14:19  J012_C003_0923FV.RMD -> /array_HDD/ProRes/J012_C003_0923FV.RMD
lrwxrwxrwx  1 user user    30 čen 19 14:19  MVI_0794.MP4 -> /array_HDD/ProRes/MVI_0794.MP4
lrwxrwxrwx  1 user user    30 čen 19 14:19  MVI_0795.MP4 -> /array_HDD/ProRes/MVI_0795.MP4
.....

Pro vyuziti /NVMe pres SaMBa bylo v smb.conf nutne povolit naslednovani symbolickych linku. Pri pristupu k souborum share /NVMe z Windows je nutne k namapovanemu pismenu doplnit Mapped Mount definici v Media Storage (odlisnost / filesystem v Linuxu a pismen disku ve Windows).

Do skriptu chybi doplnit odstranovani souboru z /array_SSD v pripade, ze se nedostanou do listu polozek ci neprojdou cutem (nedostatecna kapacita). Nejjednodussi asi bude porovnani predchoziho listu a aktualniho listu s automaticky vymazem v novem listu chybejicich polozek. Sym linky se vzdy vytvari kompletne znova, takze pokud by zmizel soubor z /array_HDD (z originalni storage), zmizi i link na nej.

Reseni nastoluje dalsi otazky, jako je umisteni .souboru (.gallery, .proxy_media., .cache). Filesystem, z nehoz jsou soubory otevirany (/array) by svou docasnou povahou nemel byt predmetem zapisu souboru ze strany DRS. Nastaveni DRS (pripadne projektu) by melo umoznit se tomuto vyhnout.

[PetebLazar]

U projektu, ktery mel osazen Timeline klipy v DRS spusteneho z notebooku s Windows 10 se ukazuje, ze cesty odkazujici na media jsou v Postgres repository DRS ulozeny OS-dependent (klipy byly umisteny na Timeline pred naplnenim Mapped Mount, ale mam pochybnosti ze by to zajistilo do repository preklad cest Win->Linux).

/NVMe/Output/ProRes/A001_04250244_C065.braw                                                           | Untitled Project 52    |        1655640722
 Z:\ProRes\A002_06122335_C002.braw                                                                     | test z windows DRS     |        1655639039
 Z:\ProRes\A001_04250244_C065 (copy).braw                                                              | test z windows DRS     |        1655639039
 Z:\ProRes\A001_04250244_C065 (copy).braw                                                              | test z windows DRS     |        1655639039
 Z:\ProRes\A002_06122335_C002.braw                                                                     | test z windows DRS     |        1655639039
 /NVMe/Output/ProRes/irresistible-trailer-1_h1080p_afx.mov                                             | Untitled Project 51    |        1655637623

Otevreni tohoto projektu z DRS pod Linuxem vyzaduje u nastaveni DRS (poplatne stanici) do Mapped Mount dat pro \NVMe dat Z:\, to umozni pochopit vyznam cest. Z pohledu vyse zmineho skriptu to znamena, zajistit v seznamu TimelineItem nahradu Z:\ za \NVMe\ a zpetnych lomitek za normalni pro naplneni /array_SSD konkretnim souborem a linku na nej z /NVMe (v opacnem pripade zustanou skrze sym-link v /NVMe pristupny pouze z pomale /array_HDD).

[PetebLazar]

Skript funguje, ale resi pouze "cachovani" souboru, ktere jiz v minulosti byly pouzity na Timeline existujicich projektu. Asi nebude problem skript doplnit o parametr umoznujici doplnit/odebrat slozky (+path -path) do seznamu explicitnich slozek jejichz soubory maji byt take nacachovany do /array_SSD. Tim by se zajistila vyssi pruchodnost i v uvodu editace novych projektu. Pri vyuziti pole s vice HDD se sice da dostat na vyssi sekvencni rychlost prenosu, ale latence nemene dulezita pri scrubbingu bude podobna jako u single HDD reseni, nemluve o situaci prekryvajicich se vice video streamu (prechody, ..). To muze byt s ohledem na vzdalenost souboru na plotnach prilis i pro pole HDD.

[PetebLazar]

Casto zminuji nevhodnost urcitych formatu pro NLE. Pripravil jsem ukazku chovani originalniho Sony A1 8K zaberu (HEVC 400Mbps) v Davinci Resolve Studio 18b4 na 8K timeline.

K levemu klipu byla vytvorena OptimizedMedia ve full res ve formatu DNxHR HQX 12bit 4:2:2 cca 14MB/frame tj. pro 24p cca 330MB/s coz je asi 7x vice nez originalni material, pravy klip na timeline je primo originalni soubor.

Ani snimani chovani OBS Studiem nezakrylo vyrazny rozdil v plynulosti(odezve) pohybu po timeline u jednotlivych klipu. HW: Epyc 7343(16c), RTX A4000(16GB), 8-ch 512GB.

Za testovaci klip patri dik redakci www.dpreview.com.

[Max]

Jak dlouho trvá vytvoření té optimalizace?
Zdar Max

[PetebLazar]

Ve vyse popsanem pripade tj. OM 8K (zkusebni klip mel delku 16s) trvalo vytvoreni 12s. Pri vytizeni CPU (16c/32t) dle top CPU 2800% (GPU 60%), takze to velku slusne s rozlisenim skaluje.

Pri OM o polovicnim rozliseni tj. 4K to trvalo 10s (CPU 750%, GPU 60%) a zabralo 1/4 kapacity tj. 3,7MB/frame (90MB/s).

Pri ctvrtinovem rozliseni OM tj. 2K take 10s (vytizeni CPU 300%, GPU 50%) s 0,75MB/frame (tj. 19M/s).

Vyhodou prace v plnem rozliseni s minimalni ztratou kvality je pravdepodobna shoda vysledku s finalnim renderingem z originalu (napr. u zaostrovani/blur, chroma keying, noise reduction, qualifier, ...). Na druhou stranu, napriklad zvukari bude asi vcelku jedno zda ma obraz v plnem ci ctvrtinovem rozliseni (musi rozpoznat talenty).

[Max]

Díky. Osobně jsem podobné hodnoty čekal.
Zdar Max

[PetebLazar]

Zatez CPU pri prehravani originalniho materialu na timeline je tak nizka, za predpokladam vyuziti HW decoderu v Geforce, na druhou stranu bitrate 400Mbps je jiz patrne blizko hranic jejich schopnosti. Neoveroval jsem to zatim pomoci nastroje nvidia-smi, ktery umi zobrazit zda se NVDEC/NVENC aktualne vyuzivaji.

[LarryL]

Používáš Davinci Resolve cíleně v Linuxu, protože je to v něčem lepší než na Windowsu?

[PetebLazar]

Linux (dříve Xubutu 18.04 a nyní Ubuntu Studio 22.04) je na mém PC primárním OSem, takže DRS provozuji hlavně na něm. Mám ho nainstalován i na multiboot Windows 10, to když zkouším funkce nedostupné v Linux edici DRS (např. .VST pluginy, či Blackmagic Proxy Generator z verze 18, nebo rozdíly v podpoře některých formátů). Nemyslím si, že z hlediska rozhraní (GUI) a používání včetně stránky výkonu je nějaký rozdíl při provozování pod Windows či Linuxem. DRS je obecně považován za stabilní SW (zvlášť ve srovnání s komerční konkurenci). V běhu pod Linuxem vyžaduje proprietární ovladače u Geforce (kvůli CUDA/OpenCL), s provozem na Radeonech nemám osobně zkušenost (tam je údajně možné kombinovat OSS ovladače s proprietárním knihovnami pro OpenCL).

Teď zkouším optimalizaci rozmístění souborů na HDD/SSD storage (s cílem zajistit živým projektů soubory na rychlé SSD_storage místo pomalé HDD_storage) což patrně bude úkol pro bash skript. Nejsem si jist zda by ekvivaletní konstrukce ve Windows co vytvoří z formatovaného psql výstupu prostý unikátní seznam souborů pro mne měla pod Windows taky takové kouzlo.

./sql_seznam.sh | sed 's/ *\| *//g' | sed '1d' |sed '1d' |sed '$d' | sed '$d' | sed 's/|/\t/g' | awk -F "\t" '{ print "$1 }' | sort -u,

[LarryL]

Linux (dříve Xubutu 18.04 a nyní Ubuntu Studio 22.04) je na mém PC primárním OSem, takže DRS provozuji hlavně na něm.

Dik za odpověď. Chápu. Taky by mi bylo příjemnější provozovat pracovní SW nativně pod Linuxem. Ptal jsem se hlavně proto, že v minulém blogu jsi psal:

"na rozdíl od verze DRS pod Windows nabízí verze pro Linux pro H.264/HEVC pouze encodéry postavené na NVENC(při využití GK NVIDIA)."

a teď píšeš, že VST pluginy pod Linuxem také nefungují. Tak mě právě zajímalo, jestli DRS má na Linuxu i nějaké výhody, třeba ve výkonu, ale jak se dívám, tak podle měření je to na Win i Linuxu velmi podobné.

[PetebLazar]

Myslím, že výhodou Linuxu může být dostupnost širší palety filesystémů (zvolených podle potřeby o výkonných pro temporary po redundantní pro longterm storage), jde asi také o přirozenější prostředí pro případné předcházející/následující dávkové zpracování (bez ohledu na to, že řada ostatních nástrojů jsou multiplatformní jako např. ffmpeg). Overhead OS(Windows/Linux/MacOS) je proti množství užitečných operací CPU/GPU aplikace řádově asi zanedbatelný, případné rozdíly v efektivitě OS budou asi na hraně měřitelnosti.