Dotaz: Výměna a synchronizace audio stopy

[Fanda]

Zdar! Víte o nějakym nástroji, kterým vyměním audiostopu ve videu a zároveň synchronizuju s videem? Předpoklad je takový, že kamera natočí obraz a zvuk. Vedle bude separátní mikrofon, který natočí ten samý zvuk. Tím se bude při synchronizaci čeho chytit. Napadl mě ffmpeg, protože ten podle mě umí všechno, ale jak to udělat? Víte o něčem? Díkes.

Odpovědi

[PetebLazar]

Davinci Resolve? https://youtu.be/7ciOkTi39ho?t=73

[Fanda]

Tak zrovna na tohle video jsem narazil, viděl jsem tam jabko a vůbec mě nenapadlo, že to je i pro Linux Ještě jsem narazil na https://github.com/bbc/audio-offset-finder ale zatím nevím, jestli je to, co hledám.

[PetebLazar]

Je to cca 4+ roky co uvedli free (za registraci) verzi pro Linux.

Davinci Resolve je jedna z těch vlaštovek co jaro (příchod komerčních desktop aplikací do prostředí Linuxu) nedělá.

[PetebLazar]

Uvědomil jsem si, že free verze Davinci Studio pod Linuxem asi nepodporuje dekódování H.264/H.265 (používám placené Studio tak mi to vypadlo).

[Fanda]

Uvidíme.. Super, díky za tip. Už se těším, až to večer prubnu

[Fanda]

Tak jsem se vrhnul na instalaci. Vytvořil si balíček a nainstaloval

dpkg -i davinci-resolve_17.1.1-mrd1.4.6_amd64.deb 
Vybírá se dosud nevybraný balík davinci-resolve.
(Načítá se databáze … nyní je nainstalováno 475499 souborů a adresářů.)
Připravuje se nahrazení davinci-resolve_17.1.1-mrd1.4.6_amd64.deb …
Rozbaluje se davinci-resolve (17.1.1-mrd1.4.6) …
Nastavuje se balík davinci-resolve (17.1.1-mrd1.4.6) …
Zpracovávají se spouštěče pro balík gnome-menus (3.36.0-1ubuntu1) …
Zpracovávají se spouštěče pro balík desktop-file-utils (0.24-1ubuntu3) …
Zpracovávají se spouštěče pro balík bamfdaemon (0.5.3+18.04.20180207.2-0ubuntu2) …
Rebuilding /usr/share/applications/bamf-2.index...
Zpracovávají se spouštěče pro balík mime-support (3.64ubuntu1) …

Jenže v dashi nemůžu najít davinci spouštěč. Jak to spustím?

[PetebLazar]

Ja na Xubuntu 18.04 používám přímo jejich installer. Davinci Resolve u mne jde spustit pomocí /opt/resolve/bin/resolve

[Fanda]

Tak jsem to spustil také tak. Hned v úvodu se mi ale objeví grafická hláška Unsupported GPU Processing Mode / Please review the GPU drivers and GPU configuration under preferences. Kliknu na update Configuration v menu nastavim třeba media storage, kliknu na vybrat spadne to na

Host 'Fusion' [42420] Added
Host 'Fusion' Removed
FusionScript Server [42632] Terminated

Tak nevim..

[PetebLazar]

DR je hodně závislé na GPGPU(CUDA/OpenCL), to je v Linuxu dostupné snad jen na AMD/NVIDIA proprietárních ovladačích (praktickou zkušenost osobně pouze s Geforce).

[OldFrog {Ondra Nemecek}]

Da Vinci je asi advanced řešení, ale chce to dedikovanou pracovní stanici odladěnou pro dané použití. Konkrétně u mě se Da Vinci vůbec nespustil.

[PetebLazar]

Na té vyladěnosti asi něco bude. Kdybych měl označit jediný problém, tak je to ztrácení se PCIe 4x playback karty z pohledu SW. Nevím zda to je důsledkem HW nekompatibility mé platformy(X399/195OX) či stavem OS. Při rebootu do Windows jsem tento úkaz snad nepozoroval. BMD je holt malou firmou, takže jejich výčet oficiálně podporovaného HW bude nejspíš silně v korelaci s tím co sami běžně používaji.

[Fanda]

Existuje nějaký ntb kolem 20k, na kterém by bylo jisté, že to bude bez problému makat?

[Fanda]

Co říkáte na tohle?

https://www.alza.cz/lenovo-ideapad-gaming-3-15?dq=6274942

Bude na tom chodit Ubuntu a Davinci resolv?

[OldFrog {Ondra Nemecek}]

Obrátil bych se na dokumentaci a uživatelské fórum Davinci. Jde hlavně o grafickou kartu a provozuschopnost akcelerovaných knihoven, které Davinci používá.

[PetebLazar]

Takto HW limitovaný ntb (z hlediska GPU/VRAM) a pouhými 8GB RAM bych si pro daný účel (DR) nezvolil.

Pro 4K timeline se v souvislosti s DR zmiňuje požadavek 8GB VRAM (4GB VRAM pro HD) a 32GB RAM. Na omezenou velikost framebufferu GK si při 4K timeline DR stěžovalo u mé desktop GTX 1660Ti s 6GB (musel jsem se proto zříci multi-GPU a využívat pro DR jen GTX1080Ti s 11GB). Tato hladovost mne v současnosti odrazuje od nákupu ntb s Geforce vybavenou 8GB. Doufal jsem, že se v ntb objeví RTX3060 s 12GB jako takový kompromis ceny/výkonu (Alza jeden takový dokonce zmiňuje, nejspíš chyba ve specifikaci), ale ty se na trh asi nedostanou.

Free(non-Studio) edici DR je vhodnější provozovat na Windows (vypadá to, že tam aspoň nechybí podpora H.264, HEVC je snad jen v placeném DR Studio). Cesta konverze materiálu H.264 externími nástroji do podporovaných formátů např. DNxHR (jako workaround chybějící podpory v Linuxu) je vykoupena drastíckými kapacitními nároky (například ve formátu 2,4:1 4Kp24 4:4:4 si vezme DNxHR cca 500GB na hodinu záznamu .. 1,2Gbps bitrate).

[Fanda]

To už jedeš v ultimate řešení Zeptám se blbě na názorném příkladu. Když bych vzal tenhle ntb s 16GB RAM a 4GB VRAM https://www.czc.cz/lenovo-ideapad-gaming-3-15arh05-cerna_9/306719/produkt, udělám v něm např. tohle https://www.youtube.com/watch?v=PJoJq-Tvgxo&t=3s ve FullHD bez toho, aby se mi to sekalo? Jestli se bude 30 minutové video exportovat celou noc, to mi asi vadit nebude

[PetebLazar]

Tak jsem si to zkusil u sebe. Dva klipy 1080p a následoval zmíněný postup. Ve chvíli kdy jsem se přepnul do Fusion (v něm je efekt vytvořený) a začal trasovat, alokace VRAM samotným DR (dle nvidia-smi) přesáhla výrazně 4GB a držela se okolo 8GB. Těžko odhadnout nakolik těch 8GB DR opravdu nutně potřeboval a nakolik je jen využil jelikož mu byly k dispozici.

Vyjádření bych přenechal na těch co mají s podobnou HW konfigurací praktickou zkušenost (těch z prostředí Linuxu bude pravděpodobně velmi málo, poznatky v tomto směru asi budou přenosné mezi platformami Win/Linux).

[Fanda]

Velký díky za reálný test! Testovals na win nebo na Linuxu?. Předpokládám teda, že v tomhle případě mi proxy nepomůže.

[PetebLazar]

Příloha:

• b-raw_speed_test.png (224617 bytů)

Testoval jsem to na Linuxu v Davinci Resolve Studio 17.1.1 (Geforce 460.56).

Proxy (či Optimized Media) ve smyslu práce v nižším rozlišením je otázkou. V případě color gradingu kdy se posuzují větší plochy pixelů je to asi vcelku jedno, ale jak například posoudím na downsamplovaném proxy souboru míru zvoleného doostření obrazu či úspěšnost denoise? Co asi může mít smysl, je vytvoření Optimize media ne ve smyslu nižšího rozlišení, ale pro editaci vhodnějšího formátu. U profesionálních kamer problém není ty produkují dobře zpracovatelné soubory (pravda za cenu větších bitrate), ale běžné kamery produkující dnes typicky H.264/HEVC formáty primárně určené/navržené k broadcastu/streamovaní, nikoli ke zpracování v NLE. Takže konverze z například IPB H.264 do "all-I" formátu (tj. každý snímek sám za sebe) se projeví na plynulosti při scrubbingu timeline. Samozřejmě jsme zpět u nároků na kapacitu, protože jakkoli jsou H.264/HEVC nevhodné k editaci jsou objemově úsporné.

O "nenáročnosti" či optimálnosti například B-RAW formátu si lze učinit představu pomocí Blackmagic RAW Speed Testu, který při dekódování na GTX1080Ti (její výpočetní silou .. při zátěži 90%) je schopen dekódovat 259FPS (to je zjednodušeně deset 4Kp24 záznamů současně, letité CPU 16-core 1950X se se 172FPS také docela drží). (viz příloha). Dnešní (včerejší s ohledem na situaci na trhu s HW) trend bych viděl jako snahu se proxy pokud možno vyhnout, díky nárustu výkonu CPU/GPU (jejich optimálního využití) to nemusí být nesplnitelný sen. Samozřejmě někdy splněný pomocí nasazení 64-core Threaripperů..

[lertimir]

No mě osobně připadá na vážnou práci s videm notebook jako nevhodné řešení. Z mnoha důvodů. První je ten, že zpracování videa je jedna z nejnáročnějších operací a tam je podstatný výkon, No a silnější výkon se nedá z těch optimalizovaných notebooků odchladit (jak procesorový tak grafický). Druhý je ten, že notebook je v podstatě neupgradovatelné zařízení. Pokud po čase zjistím, že třeba 32GB (nebo 64GB) zvýší výkon na operace, které dělám tak s notebookem mám smůlu. Třetí je hluk, notebook ve výkonu se velmi těžko odhluční, protože tlačí vzduch malým průchodem a jedině se ztišit dá snížením výkonu. A jako poslední pořád stejný výkon dostanu v desktopu levněji. A je jen otázka jestli přenositelnost zařízení to vykompenzuje.

[Josef Kufner]

Video se běžně upravuje tak, že se pracuje se zmenšeninou, která se nastříhá a pak se hotový sestřih v podobě skriptu spustí na původních datech. Takže můžeš v klidu pracovat na notebooku a pak mít někde schovaný server, který to přechroupe v plné kvalitě.

Jinak kvalitní notebooky nemají s chlazením problém a ani při tom nedělají moc rámusu. Upgradovatelnost je pro práci nezajímavý parametr – to je zajímavé při pořizování stroje (kdy namísto nového můžeš jen doplnit to či ono), ale pak už je to jedno, prostě pracuješ s tím, co máš.

[lertimir]

No jak trh v současnosti nesleduji tak s překvapením zjišťuji, že normální karta se nedá koupit. Prokletí těžaři. Takže možná nebude zbytí s notebookem, ale ta GTX 1650 v mobilní verzi má TDP 50W, což v notebooku potěš kotě. To je na odpálení větráku v záruce. Notebooky prostě nejsou vyrobeny na stabilní zátěž na plném výkonu.

[PetebLazar]

Herní ntb do 2,5kg se dnes osazují dGPU s TDP 140W, 50W dGPU proti tomu není nic.

[lertimir]

No já jsem asi velká konzerva. Menší větrák na chladiči než 12cm nemá smysl a ideální je vodník 12x36. A middle tower je nejmenší rozumná krabice.

[Fanda]

No, takže jsem nakonec vzal tohle: https://www.datart.cz/hp-pavilion-gaming-15-ec1005nc-ryzen-7-4800h-octa-15-6-fhd-antiglare-ultraslim-ips-250-nits-144hz-narrow-border-16gb-ddr4-2dm-3200-ssd-512gb-pcie-nvidia-geforce-gtx-1660ti-6gb-with-max-q-non-odd-wifi-ac-2x2-bt-5-backlit-keyboard-freedos-2-2-0.html Tak uvidím... když tak to vrátím.

[PetebLazar]

U něj bude asi nejslabší článkem LCD (což se dá nakonec vyřešit připojením slušného ext. LCD). Pokrytí 45% gamutu NTSC je opravdu málo na grafickou práci (72% NTSC cca objemově odpovídá 100% sRGB).

[Fanda]

Tak to je to nejmenší Zbytek snad něco zvládne.

[PetebLazar]

Dnes jsem se zeptal kolegy, jehož syn využívá ve Windows Davinci Resolve (nevím v jak náročných projektec loňský Lenovo Legion 5 (15,6"/4600H/RTX2060). Dle jeho sdělení je s výkonem spokojen (tento model byl jedním z mála Ryzen ntb vybaveným slušným LCD 144Hz/300nits/99%sRGB). GTX1660Ti patrně výkonem příliš vzdálena.

[PetebLazar]

O: GTX1660Ti patrně svým výkonem příliš vzdálena nebude.

[Fanda]

Tak noťas mám doma a zatím se zdá, že zvládne všechno, co potřebuju (Resolve na Ubuntu) :) Díky za pomoc a rady :)

[PetebLazar]

Toto je můj favorit (možná s výměnou RAM za 2x32GB). Uvidíme jaká bude nedostupnost.

[Fanda]

no joooo, to je jiná taky ta cena je úplně jinde

[OldFrog {Ondra Nemecek}]

Dělám to ručně v Kdenlive. K videu přidám extra audio se záznamem a původní ztlumím nebo odstraním. Synchronizaci dělám ručně poslechem echa při současném přehrávání obou audio stop. Když echo zmizí, je to synchronizované. Při delších záznamech se velmi hodí mít přesně nastavený čas na všech záznamových zařízeních - pro základní orientaci z jakého okamžiku který záznam je. Samozřejmě profi postupy jsou o řád dál (lips synchzonization, automatické tagování a sycnronizace), ale můj amatérský postup je stále použitelný a výsledek slušný.

[Fanda]

Díkes za tip

[Jendа]

Tohle je blbý když tam není jenom offset, ale něco horšího, protože ujíždí hodiny proti sobě. Když je to lineární, tak to musíš udělat na začátku a na konci a potom jedno z toho zrychlit (mimochodem kdybych to chtěl udělat bezztrátově… je OK vyrobit video, kterému nastavím 25.01 FPS? nebo to přehrávače co nejsou všehoschopný mplayer/mpv/vlc rozbije?), ale pokud se ujíždění v průběhu záznamu mění, tak bys to potřeboval dělat třeba každých pár minut a to je opruz.

Chtělo by to nabrat vzorek třeba každou minutu, spočítat, jak ujely (nevím jestli by stačila obyčejná crosskorelace, nebo je potřeba porovnávat spektrogramy/používat nějakou jinou lepší „similarity function“) a podle toho resamplovat. Je to minimálně na chvíli programování, ale třeba už to někdo řešil.

[dustin]

Adaptivní resampling se celkem používá. Je spíš otázkou, proč by měl poměr rychlostí (vzorkovacích frekvencí) kolísat, spíš hodiny jdou jen různě rychle, ale pořád stejně. IMO by mělo stačit změřit časový rozdíl na konci a dle toho tu novou stopu převzorkovat, aby byla stejně dlouhá.

Např. knihovna https://docs.rs/rubato/0.7.0/rubato/ je adaptivní resampler, napsaná pro adaptivní resampling mezi vstupní a výstupní zvukovkou v CamillaDSP https://github.com/HEnquist/camilladsp. Výsledek samozřejmě není bitperfect, ale přesnost je hluboko pod hranicí slyšitelnosti.

[Jendа]

Hodiny v naprosté většině zařízení kolísají s teplotou. Na druhou stranu jde o desítky ms za hodinu (tj. tak jeden frame videa), což se asi nepozná.

[OldFrog {Ondra Nemecek}]

Přesně tak, to pak už sahá do oblasti profesionálnějšího zpracování.

V mém případě jsem ale vždy vystačil s offsetem. Točím na zrcadlovku a audio beru recorderem - všude mám nějaké konzervativní hodnoty ftp a samplerate.

[Petr Tomášek]

Na tohle stačí openshot.

[Vtipnéř]

Napadl mě ffmpeg, protože ten podle mě umí všechno, ale jak to udělat?

Všechny zdravím.

Vidím, že na ffmpeg nereagoval nikdo. Pokud je ještě zájem, tak rád poradím.

Jirka

[Fanda]

Klidně poraď, třeba to užiju na starším železe Děkuju

[Michal Kubeček]

Kombinace videa z jednoho souboru a audia z druhého je triviální:

  ffmpeg -i $src1 -i $src2 -map 0:v -map 0:a -c copy $dest

Ale nevím, jestli jde přímo pomocí ffmpeg nějak snadno zjistit ten offset, o který je potřeba zvuk posunout, to by se možná muselo zjistit někde jinde (Audacity?).