Davinci Resolve (Ubuntu Studio 22.04)

24.4. 15:42 | Přečteno: 1561× | Linux | poslední úprava: 26.4. 13:05

Davinci Resolve a Fusion v prostředí Ubuntu Studio 22.04 (chovani, poznatky, ..).

Použitý HW: MB:Taichi X399, CPU: Thr 1950X, RAM: 4x8GB 3200CL14, GPU: GTX 1080Ti, OS: SSD 2,5" WDC 500, DATA: několik M.2 NVMe, přídavné karty HW: BMD Intensity Pro 4K (capture/playback)

Dosud jsem na této stanici využíval Xubuntu 18.04 (po neúspěšném upgrade XFCE jsem přešel na KDE Plasma). Po dobrých zkušenostech s Ubuntu Studio 21.10 (tvurci distra z XFCE take presli na KDE Plasma) na ntb jsem se rozhodl dát distribuci v LTS verzi šanci i na stanici. Krome znamosti prostredi byl hlavnim lakadlem defaultni low-latency kernel a obecna orientace distribuce na produkci (audio/video/music/...). K přechodu na rolling-distro jsem zatím odvahu nenašel, mozna příště.

Instalace OS na vyhrazené SSD (v režimu BIOS) proběhla bez problémů (s jednou výhradou .. výsledné slovinské názvy složek, po zopakování s pečlivějším výběrem locales US.UTF-8 již bez problémů).

Vzhledem ke GPGPU(CUDA-based) v DRS jako ovladace GPU zvoleny proprietarni nvidia-drivers-510 nabizene ve spravci ovladacu distribuce.

Instalace Davinci Resolve Studio (placená edice) ve verzich 17 i 18beta z oficiálních instalačních souborů proběhla bez zjevných problémů. Pozn. Oficialne je zminovan pouze CentOS 7.3.

Instalace aktualniho Desktop Video (SW podpora BMD pro přídavné karty, šírena jako .deb/.rpm) proběhla také bez zjevných problémů, HW je viditelný z aplikací (DavinciResolve, MediaExpress, OBS Studio). Na Xubuntu 18.04 jsem pozoroval občasné ztracení PCIe Intensity Pro 4K, uvidím jak na novějším kernelu/OS. Ve Windows 10 jsem tento jev nepozoroval, takze duvod nemusi byt HW nekompatibilita.

Jako repozitory projektu DRS vyuzivany database PostgreSQL-9.5 hostovane na tomto mini PC.

Používaný vychozi kernel je 5.15.0-24-lowlatency #24-Ubuntu SMP PREEMP.

Zatím jsem zažil dve totální zamrznutí primo v prostredi OS, příčina neznama.

OT: Pro kalibraci monitorů v prostredi Linuxu používám DisplayCAL (s ArgyllCMS). Jelikož v rámci tohoto projektu jiz nejsou vydávány balíčky pro nové verze distribucí, s ohledem na závislost DisplayCAL na Python2 jsem jeho instalaci v Ubuntu Studio 22.04 vyřešil pomocí flatpak. Kalibrace LG 27UD68 (UHD LCD) s vyuzitim X-Rite i1 DisplayPro proběhla úspěšně, s vyslednym jasem 49cm/m2, teplotou bile 6491K, průměrnou dE <0,5, velmi tmave odstiny <3dE (pravdepodobne dano modrym castem podsviceni).

       

Komentáře

[VoDo]

Jen ti tak trochu unesu zapisek. Mam dotaz hledam nejakej fakt jednoduchej nastroj na strihani? Jsem navyklej na iMovie jak na jepku tak na iOS a me to proste staci to co to umi, ale na linuxech jsem proste nic tak jednoduse ovladatelnyho nenasel. Bud to ma hnusny prostredi kde aby clovek stravil hodiny jak se delaj zakladni veci, nebo se to trha jak krava nebo to ma milion nastaveni. Chci nahodit videa v mp4 chci je jen sestrihat a pak aby to vyprdlo jedno video v mp4 bez kompresi atd... a aby to na i7 netrvalo dyl nez na ipadicku :) Mozna jsem nasel FlowBlade ale jeste jsem tomu moc nedal

[PetebLazar]

Osobně jsem si z GUI video editorů vědom pouze kdenlive, OpenShot, ShotCut, Pitivi, Blender, Davinci Resolve. Z tech open-source mne zadny neoslovil.

S DavinciResolve je to asi jako s Mikrotikem, prvotni strach ze složitosti (manual DR atakuje 4000 stran) je po urcite dobe nahrazen radostí ze schopností. Neprekonatelnou prekazkou pro vyuziti neplacene edice DR pod Linuxem patrne bude z licencnich duvodu chybejici podpora decodingu/encodingu prave tech nejpouzivanejsich formatu H.264/HEVC/AAC. Material tohoto formatu je tak nutne u DR non-Studio pred vstupem zkonvertovat do podporovanych (vetsinou objemove podstatne narocnejich) formatu a pripadny vystup nastroji tretich stran take. Placene verzi DR Studio pod Linuxem napr. chybi podpora decodingu/encodingu AAC, encoding ProRes je dostupny pouze na platforme MacOS.

[j]

A neprijde ti strihat 264/265 ponekud nechutne uchylny?

Teda ne ze by to jako neslo pouzit na nejaky to vystrihnuti neceho (reklama) +- autobus nekde kolem, ale pokud je rec o strihani v tom smyslu ze mam rekneme desitky ruznych kanalu a skladam z toho nejakej vysledek, tak je to fakt jako meh ...

Tohle se prece dela tak, ze si vyrobis nejakej master v nejakym typicky neztratovym formatu (nekdy to je i vylozene sekvence full frame obrazku) a teprve kdyz to mas, tak ten vysledek prozenes tou kompresi, ale na to uz nepotrebujes striznu, na to uz pouzijes nejakej cistokrevnej kompresor.

Takze to ze to jakoze "zadarmo" neumi, neni podle me vubec na skodu, spis naopak.

---

Dete s tim guuglem dopice!

[PetebLazar]

A neprijde ti strihat 264/265 ponekud nechutne uchylny?

Chybějící podporu těchto formátů ve free edici Davinci Resolve pod Linuxem jsem zmínil z toho důvodu, že je většina lacinějších zařízení (SF, D-SLR, camcordery) jako výstup produkuje. Jakkoli jsou to k editaci z celé řady důvodů nevhodné formáty (jsou navrženy/optimalizovány pro přehrávání "vpřed"), jejich rozšířenost je prostě realitou. O širší přítomnosti RAW formátů si do budoucna u této třídy zařízení nedělám iluze, za pokrok bych považoval i pouhou dostupnost těchto nešťastných formátů ve slušnějším subsamplingu/bitratech/bitdepth v ALL-I (to by aspoň omezilo ztrátovost a usnadnilo scrubbing proti té typické IPB hrůze).

Tohle se prece dela tak, ze si vyrobis nejakej master v nejakym typicky neztratovym formatu (nekdy to je i vylozene sekvence full frame obrazku) a teprve kdyz to mas, tak ten vysledek prozenes tou kompresi, ale na to uz nepotrebujes striznu, na to uz pouzijes nejakej cistokrevnej kompresor.

Samozřejmě asi nic nebrání (při dostatku kapacity a IO bandwidth) předem si zkonvertovat H.264/HEVC (cokoli na vstupu) do prakticky bezeztrátových NLE-ready formátů a editaci provést z nich. Nemusí se pak dlouhodobě uchovávat, lze si je vždy při dodatečné reeditaci z originálního materiálu reencodingem vyrobit. Pokud je výstupem více formátů/rozlišení/bitrate je vcelku logické, že rendering do "masteru" proběhne v něčem lepším (AVID DNxHR, ProRes 444, uncompress) a až případné soubory určené ke konzumaci v něčem cílovém (H.265/HEVC/VP9/AV1/...) kvalitním externím encodérem. Pozn. V Linuxu se mi nabízí u placeného Studia pouze NVENC(jak pro H264, tak HEVC), ve Windows je krome NVENC u Studio i nějaký nejspíš sw encoder "native" (pomoci MediaInfo o vzniklem souboru pomocí něj se nedozvime nic blizsiho o tvurci encoderu).

Takze to ze to jakoze "zadarmo" neumi, neni podle me vubec na skodu, spis naopak.

Je otázkou zda nepřítomnost podpory H.264/HEVC ve free verzi DR pod Linuxem je záležitostí obchodní (nekanibalizovat prodeje edice Studio), technickou (otázka kompatibility) či licenční (povinnost platit za formáty správci poolu patentů MPEG LA). Asi by BMD mohl postavit decoding/encodig ve free DR na funkčnosti VDPAU(NVIDIA GPU), VA-API (Intel GPU, AMD GPU), které u dnešních GPU/iGPU musí licenční stránku za tyto formáty mít pokrytou. Další otázkou je zda šíře kompatibility těchto HW decoderu/encoderu obstojí vůči spectru variant těchto formátů (možná se bez schopností a tudíž i platby za SW decoding/encoding nelze v programu obejit, logicky pak nemohou být zahrnuty ve free verzi). Mám za to, že ve Windows jsou možnosti free verze v tomto ohledu širší (minimálně podpora H.264), reinstaluji na W10 DR Studio na Free, abych to ověřil. ....... Ověřeno: Tak to mi hlava nebere, Davinci Resolve Free (konkretne 18Beta) ma decoding H.264 (u HEVC footage hlasi error media), ale pritom ma na vystupu H.264/HEVC encoding (nema NVENC encoding), pro decoding je mozne v nastaveni DR zaskrtnout GPU Geforce.

Disproporce podpory formátů mezi platformami je realitou hovorici v neprospěch Linuxu (nejlépe je na tom asi MacOS díky podpoře enc. ProRes), nefunkční podpora .VST pod Linuxem muze byt pro nekoho z dalších no-go.

BMD není v těchto odpovědích moc sdílný, za jeho primární Linux platformu (z pohledu podporovaných distribucí) lze asi považovat CentOS 7 (konkrétně asi 7.3). A i když jeho podpora končí za cca 2+ roky, zatím snad není náznak toho co bude poté. Je pravda, že za dva roky nemusí řada současných distribucí existovat, takže asi nemá cenu předbíhat. Spustit aplikace DR jde na celé řadě distribucí (stabilita bude otázkou jinou), tak to asi nebude neřešitelný problém. U Desktop Video (sw podpora BMD hw) v posledni Bete zminuje dokonce platfromu Linux AArch64, tak snad na Linux obecne BMD do budoucna nezanevre.

[PetebLazar]

Tak to nakonec vypadá, že Linuxovým tvůrcům pro Tik-Tok by asi mohla stačit schopnost Saver node v BlackmagicDesign Fusion compositoru renderovat výsledek do ProRes. Pokud si tedy vystačí s podle všeho aplikačním hard limitem 1000 frames (tj. cca 40sec pri 24p).

[Max]

Máš nějaké public projekty, se kterými by jsi se mohl pochlubit? Technické řešení už známe i z předešlých blogů, zajímala by mě i nějaká samotná tvorba.
Díky.
Zdar Max

[Petr]

Nebylo by na škodu uvést, co to ten Davinci Resolve je. Ze zápisku to nejde poznat :)

[Max]

Je to pokračování serie, viz historie jeho blogu: l_eonardovo_odhodlani.
Zdar Max

[_]

jo prectu si serii abych se dozvedel, o cem

[PetebLazar]

Dal jsem odkaz vedoucí na první zápis blogu, kde snad již z perexu bude jasné o co jde.

Mělo by jít o technicky zaměřený blog týkající se provozu/fungovaní DavinciResolve(Studio) v prostředí Linuxu, téma jemuž se moc zdrojů (natož v češtině) nevěnuje. Slouží mi k ujasnění doměnek/myšlenek/informací/skutečnosti.

Před pár dny s velkým nadšením celosvětová komunita okolo DR v představené verzi 18 přijala novou funkcionalitu "DaVinci Resolve Cloud". Po vyprchání prvotního zděšení z názvu (evokujícího hrozbu ala předplatné Adobe Creative Cloud) se ukázala užitečná služba, umožňující za poplatek 5US$/měsíc současnou kooperaci nad projekty různými (i vzdálenými) pracovníky týmu postprodukce. Díky dlouhodobé možnosti provozovat repozitory DRS v databázi PostgreSQL tu tato možnost v kombinaci s hostingem DB a VPN existuje vlastně již řadu let, ale díky mezeře znalostí (kreativní versus techničtí uživatelé) nebyla šířeji využívána. Nedosažitelnost řešení, které by v rámci VPS zvládl průměrný návštevník ABCL realizovat patrně v řádu jednotek hodin. Cílem blogu mj. je pokusit se takové mezery odstranit(zúžit).

Další oblastí, která je s DR neodělitelně spjata je oblast Color Managementu, což je další z Popelek nejen světa Linuxu. Rozdíl úrovně znalostí mezi laickou a odbornou veřejností je značná, může tak jít o další ze studen "Radosti z poznání".

[VoDo]

pokud nevis co je davinci resolve tak to neni zapisek pro tebe neasi, kazdej kdo kdy nekdy strihnul video tento program vi ze existuje :)

[Gréta]

tttsss třeba použil kdenlive :D ;D

[TechnikTom]

Díky za tu poznámku s DisplayCal a nepodpoře na nových verzích Ubuntu. To jsem vůbec netušil. Po instalaci přes flatpak funguje pak automatické načtení profilu po startu systému jako doposud? Minulý týden se mi totiž rozsypalo Lubuntu 18.04, tak jsem to bral jako pokyn shůry konečně přejít na 20.04, i když z toho LXQt moc nadšený nejsem. Co se týká vzhledu a výkonu oproti LXDE. Takhle to možná ještě zkusím nějak zachránit.

Takže sem asi brzo přijdu s nějakým dotazem na pomoc :o)

[PetebLazar]

Otázku neumím zodpovědět, jsem na Ubuntu Studio 22.04 zatím pár dní (a tomuto jsem se vědomě vyhnul), ale předpokládám že pokud kalibrací vyzniklý profil bude k dispozici např. pro colord asi by CMS mělo fungovat v podobném rozsahu jako dříve. Přiznám se dobrovolně, že průnik CMS OS a CMS APL pod Linuxem mi není zcela jasný. Asi by to chtělo udělat pár testů s agresivními ICM (které totálně zvrátí barvy) a pozorovat (ne)dopad v jednotlivých aplikací. DisplayCAL využívám primárně ke kalibraci a profilaci monitorů.

DR myslím není OS_CMS-aware aplikací a zcela jej ignoruje. BlackMagicDesign jaksi logicky ve svém cílovém segmentu automaticky předpokládá, že výstupní zařízení bude přesně gamutem/gammou odpovídat zvolenému barevnému prostoru/gamme timeline (ach ti naivové ). Získal jsem dojem, že aplikací kalibrací vzniklé 3D LUT (.cube) na výstup DR jsem schopen existující přesah gamutu kompenzovat (možná jde jen o dojem). Mám tady jeden starší DELL LCD s interní LUT kalibrací, který kalibruji z prostředí MacOS (z Windows se i1 Profiler s ním přes USB z nějakého důvodu nedomluví) s výsledkem cca 99% pokrytí Rec.709 a na ten posílám výstup DR skrze Intesity Pro 4K. Jde o monitor z doby AdobeRGB (gamut, který videoprodukce asi bere za zakázané slovo), dá se na něm dosáhnou i relativně slušného pokrytí gamutu P3 D65 cca 95%. Mam je oba ulozeny v monitoru takze se mezi nimi da dle potreby prepinat.

Chystám se k jednomu dílu na téma kalibrační sondy (mám v plánu koupi své čtvrté v pořadí). Díky změnám názvu GretagMacbeth, Pantone, X-Rite, Calibrate je to jak ten příběh o strýčkovi z Mukačeva co za svůj život žil v pěti státech a přitom nikdy nevytáhl paty ze své rodné vesnice.

[TechnikTom]

Tak jsem vyzkoušel a funguje to stejně jako v 18.04

Profil se načte při startu systému.

A k těm změnám názvů kalibračních sond -já ji mám pod značkou Hewlett Packard :o)

[PetebLazar]

Využíváte v DisplayCAL on-line dostupných korekcí pro kontrétní typ LCD panelu(podsvícení) a použitou kalibrační sondu?

[TechnikTom]

Korekce nevyužívám, pokus o načtení končí chybou a i když mám originální CD k sondě, nedaří se mi nalézt, který soubor tomu předhodit.

A bohužel musím opravit svoje tvrzení o načtení profilu při startu systému v 22.04

Abych profil aktivoval, musím pustit DisplayCal a provést "install profile".

I když colord běží hned po spuštění systému, profil se automaticky nezavede.

Zatím nijak neřeším, jedu na 22.04 jen jako na záložním a asi zůstanu u 18.04, na mém starém stroji je méně náročný.