Dotaz: Strih videa na remote stroji nebo client - server sestava

[ok2zar]

Zdravim,

resim otazku strihu videa, protoze na laptopu je to jiz neudrzitelne. Poridil jsem proto stroj urceny pouze na strih (jine plany s nim zatim nemam). Ale vyvstala dalsi vyzva - kam ho dam, monitor, mys, atd... proste pohodli pro praci. Muzu ho dat pod stul a mit prepinac monitoru a klavesnice. Ale moc se mi do toho nechce. Daleko vice se mi zamlouva varianta dat ho do "datacentra" ve sklepe, ale vyvstavaji dalsi otazky, jak s tim pak pracovat. Pres VNC nebo RDP je to volovina. Googlenim jsem zjistil, ze podobny dotaz melo vic lidi (i pred cca 12ti lety), ale tehdy zustaly bez odpovedi. Pak jsem nasel nazor, ze si to mam pripravit na desktopu, pak to rsyncnout na remote a tam dat export vysledneho videa. To je zase polovicate, protoze uz ted pri strihani narazim na vykonove limity laptopu.

Asi bych se nebranil prejit na neco jineho. Vim, ze Shotcut je linuxovy bracha Ediusu pouzivanem v profi sfere, ale dal jsem nedohledl. Proto si rikam, ze tu treba bude nekdo, kdo poradi a nebo mi vysvetli, ze vymyslim kraviny. Kazdopadne diky za nazory.

Odpovědi

[Aleš Kapica]

Pres VNC nebo RDP je to volovina.

To jo, ale pokud to chceš primárně jen kvůli střihu, tak by to mělo stačit. I když já osobně bych použil spice. To za A. A za B, pokud použiješ ke střihu blender, tak ti stačí adresář sdílený z toho remote stroje přes NFS. U sebe si to nachystáš, a na tom vzdáleném výkonném stroji to pak vyrenderuješ. Budeš-li mít strojů víc, můžeš to mít i rychleji. Během kovidu jsem takhle blbnul s celou laborkou.

[Max]

VNC rozhodně ne, to je šíleně pomalé. S RDP to bude o dost lepší, ale nejsem si jist, jak dobře funguje v Linuchu real time (Windows má RemoteFX).
Třeba 2X Client podporuje RemoteFX dlouho a asi dost stable.
Akcelerace GPU běží na straně serveru, takže pokud bude rychle a stabilně fungovat RemoteFX, neměl by to být asi problém.
Zdar Max

[J]

Vymyslis totalni pitchovinu. Strih videa me jednu dobu zivil a zajima te u nej nejenom vykon toho stroje ale i moznosti zobrazeni u strihu. Zajimaji te barvy, zajima te moznost vyberu na uroven snimku a tohle pres remote desktop (jakykoliv) bude problematicke. Shortcut je fajn pro takove lepsi domaci pouziti, jakmile ho ale porovnas s necim profesionalnim (a ma te to zivit takze te zajima efektivita) tak zjistis ze jsou daleko lepsi aplikace (final cut pro x, adobe premiere,…).

[PetebLazar]

Pokud je cilem Linux platforma, pak se nabizi i Davinci Resolve.

Samozrejme, u neplacene edice (za registraci) je treba pocitat s omezenou(chybejici) podporou patentove chranenych formatu (H.264/HEVC/AAC/...). Je nutne si vstupni material predem prevest do DR podporovaneho formatu, coz nakonec muze mit u tech IPB hruz svuj prinos.

[Jendа]

Daleko vice se mi zamlouva varianta dat ho do "datacentra" ve sklepe, ale vyvstavaji dalsi otazky, jak s tim pak pracovat.

Existují extendeéry HDMI a USB po Cat6 nebo optice.

Ale jinak třeba v Kdenlive se to dá dělat tak, že si vygeneruješ "proxy klip" s nižším rozlišením, stříháš s těma, a finální render se provede na vzdáleném počítači z originálních dat ve vyšším rozlišení.

[ok2zar]

Ahoj,

jo to mas pravdu a pri rekonstrukci a tahani kabelaze me napadlo, ze v pracovne budu mit jen monitory a pres optiku dotahnu HDMI + USB (usetrim misto v male pracovne) a udelat toto i se strihovym strojem by bylo logicke, ale porad jej musim pripojit k monitoru a dat mu klavesnici s mysi, takze to znamena prepinat svoje monitory, klavesnici a mys....a to jsem zase u toho, ze je to nejjednodussi reseni a ja se mu branim

[lertimir]

No pak je otázka jestli ten "střihový stroj" nemít jako pracovní stanici na vše? Připojit k němu natrvalo monitory a mít na něm přesnou a automaticky synchronní kopii s notebookem. Když jsi doma "na pracovišti" jedeš na monitorech a stanici, když jinde tak na notebooku a máš to stejné. Tak to provozuji již léta. Pracovní stanice s třemi monitory a lehký notebook. Synchronní část - Dokumenty v domácím adresáři - a synchronizace pomoci unisonu. Vždy když odcházím/přicházím zesynchronizuji a pokud nechám stanici běžet a něco počítá, tak mám možnost i vzdálenou synchronizaci. unison se připojí přes sftp s klíčí a přenese, co potřebuje. Máš tím i vyřešenu zálohu okamžitého stavu (i když archivní zálohy jedu ještě navíc.)

[ok2zar]

I tuto variantu jsem uvazoval, ale jeste jsem nezkousel, co bude delat firefox, az mu budu prenaset "zive" soubory, abych prenesl stav (otevrene taby, hesla, formulare, atp....) a zaroven to nedelal pomoci te jejich synchronizace, protoze zase bezpecnostni politika.

Pak je tu ovsem otazka, proc tu mit trvale zapnutou takovou potvoru, kdyz striham "jednou za cas".

[PetebLazar]

S HDMI by dnes problem byt asi nemel, jsou vcelku bezne nabizeny HDMI opticke kabely vetsich delek. https://www.krup.cz/Default.asp?cls=spresenttrees&strid=2731

I na USB3.0 existuji extendery, praktickou zkusenost mam pouze s cca 10m USB2.0. https://www.krup.cz/Default.asp?cls=stoitem&stiid=5295

[ok2zar]

Jo, to je v poho. Krom tri pokoju mam optiku vsude, kdyz clovek nekouka uplne na cenu, daji se koupit "krabicky", ktere protahnou HDMI i USB jednou trasou. Vetsinou je to teda USB 2.0, coz je v poho na beznou praci (klaveska, mys, zvukovka,...). Na USB 3.x jsem to videl jen samostatne, tedy bez HDMI. Ale ano, je to pekne resitelne. Blby to je pak u KVM prepinacu. Ja jsem rozhodil site a vypada to, ze by mi tam mohl uviznout lepsi prepinac, ktery se vudci PC chova jako monitor, ackoli ten je v dany okamzik pripojen k jinemu vstupu a nedochazi tak k "sesypání oken" na jiny (nebo hlavni) monitor, kdyz to prepnu tam a pak zpet.

[PetebLazar]

Já přemýšlel o prostupu podlahou do dílny, kde se nedílnuje (PC přidělat na konzoli pod strop). Pak by se vše vešlo do cca 5m což není problém. Ale před pár lety jsem si pořídil výškově nastavitelný stůl a ten sám alokuje cca 5m kabeláže.

[czjaromir]

Kdysi dávno, v době nevykoných strojů existovala možnost se připojit k serveru a stanici mít jako terminál. Dělo se to přes nějaký port. Jestli je pro toto podpora v současných jádrech to taky nevím. Zkoušel jsem googlit ale je to na dlouho. Taky by mě ta možnost zajímala.

[PetebLazar]

Znakové terminály byly typicky připojeny přes sériovou linku/modem a později síťově např. protokolem telnet. Grafické UNIX terminály byly postaveny na X-Window protokolu. Aplikace na serveru generovala přikazy pro X-server, který běžel na terminálu. Poprvé jsem se s tím potkal v 90-tých letech v učebně FELu, kde HP-UX snad bezel na serveru s 68030 a graficke terminaly snad mely 68000. V případě vektorové grafiky to asi není problém, pro dnešní bitmapově orientované aplikace je to tragédie.

[czjaromir]

Přesna a korektni odpovoed. ,diky.

[lertimir]

Právě proto jsem navrhoval samostatný stroj a samostatnou práci s ním. Nenapadá mne žádný datové náročnější práce pro přesuny mezi pamětí a video zobrazovačem než je práce s videem a případně 3D animace.

Také je třeba brát v úvahu, že kapacity rostou mnohem rychleji než rychlosti. Někdy v roce 88 mělo PC něco mezi 512kB paměti a 20MB hdd, ale bylo na Ethernetu s rychlostí 10Mbit/s přičemž normální pracovní velikost souborů byla 10-200kB. Soubor sítí proletěl okamžitě, Celý hdd se přes síť překopíroval do minuty. Frekvence procesoru byly nízké desítky Mhz, takže přístup to paměti byl cca 20-100MB/s a přístup na vlastní disk byl mnohdy pomalejší než přenos po síti.

Dnes jsou diskové kapacity cca milionkrát větší, operační paměť cca 100 000 krát větší, Podobně narostla velikost objektů/souborů které zpracováváme, ale rychlost lokálních sítí vzrostla jen 1000 krát (když se praštíme přes kapsu a máme 10Gbit) nebo i jen 100 krát pro 1Gbit. Síťová grafická práce začíná upadat kolem přelomu tisíciletí. Fast Ethernet (100Mbit) z roku 95 dokázal zmírnit rostoucí disbalaci mezi kapacitou a rychlostí, ale už v roce 2000 měly disky kapacity ve desítkách GB a přechod z vektorových grafik na bitmapové to dorazil.

[PetebLazar]

Pokud bude v požadavcích schopnost paralelního přenosu několik fotage v bitrate rozsahu 100-1000MB/s (4K+ RAW) může se na HDD řešení asi zapomenout. I kdyby nakrásně škálovalo (například pole 8+2) v sekvenčním čtení ke 1000MB/s, patrně pohoří při požadavku na paralelní přenos několika záběrů současně (multi-cam na timeline) a při scrubbingu timeline. Dnešní desktop řešení díky své PCIe lanes chudokrevnosti a potřebných kapacitách jsou prakticky mimo. Takže asi zbývá řešení postavené na dospělých platformách (Epyc/ThrPo/Xeon W-3400), které by díky dostatku PCIe linek a bifurkaci měly umožnit obsluhovat desítky NVMe a poskytnout i dostatek výpočetního výkonu (v případě řešení na serverových CPU s omezeními vyplývajících z jejich konzervativních ST taktů).

Otázkou je, nakolik by šlo efektivně kombinovat výkonný desktop (s rychlou NIC 40/100Gbps) a NVMe based storage (např. Epyc). Je bohužel smutnou realitou, že dnešní AM5/sc1700 platformy nenabízí PCIe slot 8x(3.0/4.0) bez využití PCIe linek primárně určených pro GK. Vzhledem k tomu, že výrobci GPU ignorovali ve své poslední generaci GK PCIe 5.0, musí se GK v případě osazení druhého PCIe 16x slotu spokojit s 8x 4.0, což pro GPGPU s velkými přenosy dat CPU<=>GPU není ideální.