Hogyan készítsünk webböngésző-alapú videószerkesztőt?

HUP cikkturkáló

Hogyan készítsünk webböngészőben futó, telepítés nélkül működő videó szerkesztő programot?

Ennek a cikknek az az érdekessége, hogy a végeredmény ténylegesen működik is, sőt már előfizetőik is vannak, tehát még fizetnek is érte a felhasználók (linkelt oldalon lehet élesben kipróbálni). Az a különlegessége a cikknek, hogy nagyjából leírják, hogyan alkották meg a böngészőben, telepítés nélkül futó videó szerkesztő szoftverüket.

Én is kipróbáltam és tényleg működik, nem kell hozzá semmit telepíteni.

Jó, egy hollywoodi filmet nem ezzel fognak megszerkeszteni, egyelőre elég alap funkciókat tud csak.

De a cikk érdekessége, hogy leírja a használt technológiákat, valamint hogy már működő böngésző-alapú videószerkesztőt is lehet írni. Egy idő után szerintem minden programból csak webes verziót fognak fejleszteni, mert minek asztali verzió, ha megy böngészőben is?

  • 1268 megtekintés

( bocs | 2021. 05. 05., sze – 21:30 )

Szerkesztve: 2021. 05. 05., sze – 21:31

Tanulság, ha komoly teljesítményű szoftver kell:

  • Java kuka
  • node js kuka
  • Python kuka
  • C++ elővesz
  • A web frontend nagy teljesítményre szintén alkalmatlan, csak közelíteni tudja a végleges megjelenítendő videot

Szóval a tanulság: bár a webes technológia erre pont nem való, 10 fős csapat 2 évi munkájával cipőkanállal bele lehetett szuszakolni, erősen hunyorítva még jó is az eredmény.

Success?

Hát ha az embereknek nem kell desktop app, és nem érdekli őket az sem, hogy intim házi videóikat webre töltik fel, akkor végülis az...

Úgy is megfogalmazhatnánk amit írtál - amivel végül is alapjában én is egyetértek -, hogy ha alkalmatlan nyelven, alkalmatlan futtató környezetbe tudnak írni kellő elszántsággal és felkészülséggel ilyen szoftvert, akkor mindenki másnak, alkalmas nyelveken és alkalmas futtató környezetbe hogyan sikerül akkora sz@r, teljesítmény és hely zabáló, lassú, és temérdek hibával megáldott programot előállítani?

Úgy, hogy nem elég az, hogy kezdetben egy kompetens valaki meghozza a döntést a technológiáról, amiben az optimális megoldás elkészülhet. Hónapok és évek múlva is kell garantálni az eredeti fejlesztési irányelveket. Ehelyett rendszerint három dolog szokott történni.

  • A kompetens elemeket akadályozzák a technológiában teljességgel inkompetens projektmenedzserek, termékmenedzserek, termékgazdák. Stresszelik őket, szűk határidőket jelölnek meg a versenyre™, a konkurenciára™, költségoptimalizálásra, gazdasági okokra stb. hivatkozva. Méginkább szar a helyzet, ha ezt mikromenedzser stílusban művelik le. Itt a kompetens fejlesztőnek két választása van. Vagy felmond vagy behódol idealistáéknak és nem hagy időt az optimális megoldásnak.
  • A kompetens elemeket felerőltetik (értsd: előléptetik) egy olyan magasabb pozícióba, ahol már kevésbé kompetensek, a helyüket viszont a választott technológiában kevésbé kompetens elemek veszik át.
  • A kompetens elemeket nem hajlandóak inflációkövető piaci bérezéssel megfizetni, ott tartani, ezért előbb-utóbb felmondanak. A helyükre olcsóbb, silányabb, tehát inkompetens szürkeállomány érkezik.

Végső soron tehát igen nagy az esély rá, hogy inkompetens babzsákfejlesztők és stackoverflow-generációs koffein-kód biokonverterek folytatják a munkát, az eredeti koncepciót commitonként megcsúfolva és minden szart is behúzva, hogy végül akkora bloat legyen, mint egy eleve bloated framework-kel, webökrök által összetákolt JS-szutyok.

Mármint ami "nem igazán sikerült optimálisra" annak fényében, hogy valakik csináltak egy böngészőből használható videószerkesztőt?

Hát, mondjuk majdnem az összes rendszer amit az állam készíttetett/üzemeltet, az itthon fejleszett ügyviteli rendszerek nagy része, de hogy ismerteket is mondjak, pl. a Lightroom is ilyen sok más mellett.

Mármint ami "nem igazán sikerült optimálisra" annak fényében, hogy valakik csináltak egy böngészőből használható videószerkesztőt?

Hát, mondjuk majdnem az összes rendszer amit az állam készíttetett/üzemeltet, az itthon fejleszett ügyviteli rendszerek nagy része, de hogy ismerteket is mondjak, pl. a Lightroom is ilyen sok más mellett.

Kicsit szigorú vagy, egyelőre ezt a linkelt programot egyszerűbb videók szerkesztésére szánják, pl. social media videókhoz, vagy egyszerűbb videóvágási feladatokhoz meglévő videóknál. De nyilván egyre több funkciót tesznek bele, hogy minél többet tudjon.

Az viszont elvitathatatlan, hogy működik böngészőből, nem kell hozzá semmit telepíteni, nem kell frissíteni, platformfüggetlen (Windows, Mac, Linux, Android stb.), könnyen használható. A videó export a felhőben történik, tehát lassú gépen is gyors lesz a videó export. Vannak azért előnyei ennek a technológiának...

Én is elkezdtem írni egy hasonló választ, aztán elengedtem, mert igazából nem akarok vitatkozni róla.

De +1, borzasztóan számításigényes dolgokat is csinálnak Javában. Mondjuk ahol egy több ezer (!) szerverből álló HPC grid számolgat pénzügyi szimulációkat egy 500+ fejlesztő által megírt kódbázis alapján, ott nem a JVM lesz a szűk keresztmetszet. :)

Én még azt is elhiszem, hogy videorenderelő program írására nem jó választás a Java, de így kategorikusan kijelenteni, hogy abban nem lehet "komoly teljesítményt" csinálni, az elég furcsa, tekintve, hogy a fél világ Javában írja a mindenféle number crunching alkalmazásokat

Igen, hallottam ilyen projektekről.
Nézzük meg mondjuk a lineáris algebra csomagokat, mekkora részük van Javaban írva?
https://en.wikipedia.org/wiki/Comparison_of_linear_algebra_libraries
Kb 0% ?

off: amúgy engem nem különösebben érdekel ez a prog nyelv háború, csak nehogy valami kezdő komolyan vegye, hogy "mindegy, milyen nyelvet választasz, a for ciklus az for ciklus!"
bocs, de abszolút nem. Magam nagyon szeretem a c#-ot, de biztos, hogy csak akkor választanám egy projekthez, ha nem a teljesítményen, hanem a gyors, kényelmes, rugalmas fejlesztésen van a hangsúly.

Vannak a díszes paripák és az igáslovak. Mindkettőnek megvan a maga szerepe, én olyan területen mozgom általában, ahol inkább igáslóra van szükség.

( uid_21476 | 2021. 05. 05., sze – 21:39 )

Lassan már az anyák is böngészőn keresztül fogják a babáikat megszoptatni.

Anyám!

Egyébként működik

A csiligépeden, egységsugarú vagdosásra. Esetleg.

https://www.veed.io/ -> Try sample

Vesd tekinteted a timeline-on lévő 3 felirat klipre (piros, sárga, kék). Próbáld meg őket átméretezni. Közben figyeld a CPU használatot. Elárulod nekem, hogy miért kell egy ötödik generációs gépen is 2 és fél magot kizabálni ahhoz (250% CPU), hogy egy fillrect-elt téglalap vízszintes mérete az egérkurzort követve módosuljon, majd ez alapján egy megjelenő felirat hosszát beállítsuk? Tényleg idáig süllyedtünk?

Felcsapnál esetleg egy network traffic monitort és megnéznéd, hogy a timeline csúszka adott időponthoz igazításakor és lejátszáskor is folyamatosan miért kell 100 Mbit/s fölött zabálni a hálózati forgalmat? Hogy ez mennyi mobilnetet fog felzabálni egy valódi, hosszabb film elkészítésekor? Hogy mi a faszom értelme van tapicskoló, touchscreen-idealista felületet csinálni hozzá, ha tableten és mobilon irreálisan magas lesz az adatforgalom-fogyasztása?

Ha olyan kibaszott hatékony a renderelés, mint ahogy áradoznak róla a blogban, akkor miért kell 200% CPU ahhoz is, hogy elindítsd a lejátszást és nézzed a videót?

Extrának még annyi, hogy ha túl sokat matatsz benne vagy túl sokáig van nyitva a "videószerkesztő", akkor képes szétcseszni annyira a Chromium renderingjét, hogy más oldalak kirajzolása is elkezd lagzani anélkül, hogy bármi magas CPU fogyasztás lenne adott pillanatban.

teljesen jól használható

Te vagy nagyon hülye vagy, vagy olyan jól takar a szemellenződ, hogy az atomvillanást is csak pislákoló félhomálynak látnád benne.

Jelen megoldás egy undorító, szélsőségesen idealista, ritka nagy bloated JS-szemétdomb, ami minden lehetséges módon pazarolja és pazaroltatja az erőforrást.
 

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 92
model name	: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
stepping	: 9
microcode	: 0x3c
cpu MHz		: 1868.511
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 21
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch cpuid_fault cat_l2 ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts md_clear arch_capabilities
vmx flags	: vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs
bugs		: spectre_v1 spectre_v2
bogomips	: 2995.20
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual

Ez egy marha gyenge proci ám, a 4 mag ne tévesszen meg, mert a freki, cache elég alacsony, alig pár 4-6 W-os proci, aminél még a legtöbb laptopban lévő 15-35W-os mobilproci is sokszor erősebb, nem hogy egy tisztességes 65-120W TDP-s asztali proci.

Egyébként nekem sem tetszik ez a legyen minden webapp, meg JS szemétdomb fejlesztési modell, szerintem még a hardverek és a netsávszélességek nem értek meg hozzá igazán, de a trend tényleg ebbe az irányba mutat. Nyilván aki tud reálisan gondolkodni, az utálja ezt, de azt kell érteni, hogy ebben nem a userek és a szakma dönt, hanem nagy cégeknél öltönyös-nyakkendős managerek, meg babzsákfeljesztők (soydev-ek), ahogy te hívod, és nekik ez nem csak azért kényelmes, mert egy platformra kell csak megírni a szoftvert, hanem a cégnek is jó, mert ha ilyen online bejelentkezős, havi bérléses alapon megy, akkor az egyszeri usernek nincs esélye lewarezolni a ×4rjukat, ha nem fizet elő, nem tejel, bukta az egészet, meg nincs az, hogy az offline szoftvert nem update-eli lustaságból, és ezért több verziót kell támogatni, foltozni, debugolni, meg könnyen így online szoftvert futtatva mindenkit könnyebben megfigyelhetnek, privát adatait eladhatják marketingcélokra. A Google a Doc-sal régóta így működik, ebbe az irányba megy a MS is a webes Office365-tel, meg az Electron/Chrome alapú szutykaikkal (Zoom, Skype, stb.), Adobe már régóta előfizetési modellben tolja. Ez lesz a jövő szomorú valósága, és még a legkisebb baja, hogy bloat, meg JS f0schtócsa az egész.

Nem csak a webes dolgokra igaz, de már a natív alkalmazások is úgy mennek lassan, hogy minden virtualizálva, konténerben, stb. fut, meg disztróagnosztikus univerzális csomagformátumban jön. Lassan már ez a natív alkalmazást használok, natívan, natív disztrócsomagként, már a Linux világában is konzervativizmusnak számít.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nekem elég régi gépem van (12 éves), de megy rajta gond nélkül (Ubuntu, Chromium).

Memória: 3,7 GiB

Processzor: Intel® Core™2 Duo CPU P8400 @ 2.26GHz × 2 

GPU: Mobile Intel® GM45 Express Chipset (CTG)

Sőt ilyen régi gépre pont jó, hogy a felhőben történik az export, mert különben egy örökkévalóság lenne kivárni a lokális gépen egy pár perces videónak is az exportját. De mivel az ő szerverükön történik az export, ezért egy ilyen régi gépen is gyorsan megvan.

"Sőt ilyen régi gépre pont jó, hogy a felhőben történik az export, mert különben egy örökkévalóság lenne kivárni a lokális gépen egy pár perces videónak is az exportját. De mivel az ő szerverükön történik az export, ezért egy ilyen régi gépen is gyorsan megvan."

Nem látom ebben az újdonságot. Mármint abban, hogy szerver oldalon csináljuk videorendert, mint a számításigényes feladatot. A Google is csinált ilyet, korábbi androidokon (4-5 körül rémlik) pont így működött a GPhotos-ban lévő videó szerkesztő. Amit lokálisan összeraktál előnézetben, azt feltolta szerverre és ott renderelte a kész videót. Sőt, teljesen magától is csinált neked videókat (értsd: ő vágta össze neked a feltöltött videóidból Ai támogatással), amiket felkínált aztán letöltésre.

Az, hogy valaminek a kliens oldali részét meg lehet csinálni böngészőben, az sem újdonság (a browser már olyan, mint egy OS). Hogy konkrétan videóvágás témában ilyet alkottak, ez önmagában szép, de kicsit elkésettnek érzem, illetve nem látom milyen igényre válasz. 10 éve jó lett volna, de ma egy telefonon/tableten is lehet fullhd vagy 4K videót vágni (sőt, jobban lehet, mint egy átlag pc-n). 

Én nem próbáltam, de így a látatlanban is kötve hiszem. Abban igazad van, hogy egymagában a videórendernél segíthet, ha távoli, szerveres vason renderelődik, de míg a vágod, szerkeszted a videót, meg előnézeti képeket nézel, amikor viszed rá az idővonalon az effekteket, abban egy C2D-nál modernebb i5-i7 is le tud térdelni, akkor is, ha natívan futtatja a szoftvert, nem hogy egy C2D, aminek böngészőben még a webes overheaddel is meg kell küzdenie.

Én anno i5-2520M-en, i7-2620M, i5-3340M-en próbáltam, 16 giga RAM-mal, SSD-vel, webes MS Office-t, meg webes LibreOffice-t, hát, nagyon nyögvenyelős volt, nagyon lagolt a GUI, sokára váltotta a menüket, funkciókat, ha belelapoztam hosszabb doksiba, elég komótos volt a renderelés. És itt csak egyszerű docx, és xlsx doksikról volt szó, nem is sok gigás videókról. Ezért fura nekem, amiket írtok, hogy J/N-es mobilcelerongyon meg ősrégi C2D-n milyen jól fut a webes videószerkesztés.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Elfelejtesz egy dolgot. A JS egy megbizhatatlan forrasbol szarmazo, run-anywhere nyelv. A bongeszonek tehat ovatosan kellene futtatnia (security sandbox esatobbi), de ugyanakkor mindenfele hulye API-t es funkciot is tamogatnia kell, es ezt persze nativ kodra forditva es memoriamenedzsmenttel. Na koszi.

Nem mintha a C++ kodok windows/linux-on olyan hu de jok lennenek am! A rendesen megirt nativ executable is ritka, mint a feher hollo. Crashel, cpu-t/mem-et zabal ok nelkul, vagy csak siman lehal. A nativ codec-ek, mikor megprobaljak a legtobbet kihozni a HW-bol, fagyogatnak rendesen. A direkt HW codec-ekrol nem is beszelve, na azokkal robog igazan a szoporoller.

Es ez most ugye OS-tol fuggetlenul.

A browser-ben futo app-ek akkor igazan jok persze, ha van hozza rendes API es nem kell pureJS codec-ekkel meg hasonlokkal bohockodni. Amihez van rendes API es rendes browser support es rendes JIT support, az gyors bongeszoben is. Persze tobb eroforrast hasznal valamivel, mint a nativ kod, de nem annyival, hogy ne tudna ellensulyozni a konnyed install-t.

Amikor a fent leirtak jonnek elo, annak a kovetkezo okai lehetnek (elofordulasi sorrendben):
- rossz programozo
- rossz/hibas bongeszo/JIT compiler
- nincs (standard) API
- A JS es/vagy bongeszo nem valo erre a feladatra

 

BTW, van mar regota webassembly is, lenyegesen jobb architekturalis megoldasokkal. Abban valszeg nem lenne gond egy videoszerkeszto szoftvert irni.

( jantyik | 2021. 05. 06., cs – 00:12 )

Hát... a belinkelt blogposzt eleje félig-meddig kickstarteres "minden a piacon szar, jön a világmegváltás" jellegű. A második felében van esetleg valamennyire érdekes dolog.

Nem feltétlenül látom egyelőre át jelenleg, hogy ez miért igazán különleges.

Az, hogy már videót is lehet szerkeszteni a böngészőben, sőt nem csak játékból, hanem nekik konkrétan már annyi fizető ügyfelük van, hogy nyereségesen működnek (ezt egy másik blogbejegyzésben írták le). És hogy konkrétan ezt írták le, hogy egy ilyen megoldást hogyan fejlesztettek le.

( Tassadar v | 2021. 05. 06., cs – 07:54 )

Van valami technológiai megkötés, ami miatt a böngészőben futó szerkesztő nem képes a lokális videót szerkeszteni hanem mindenképpen fel kell azt tölteni?

Olyan is van (egy másik cég), ahol a lokális gépen lévő fájlokat szerkeszti, tehát nem tölti fel az ő szerverükre (ez is böngésző-alapú): https://clipchamp.com/

Ennek a hátránya, hogy a videó export is a lokális gépen fog futni, tehát ha lassú a géped, akkor sok idő lesz és a te géped erőforrásait használja az exporthoz.

Talán lehetne a kettőt kombinálni: a szerkesztés a lokális gépen lévő fájlokat használja, export során viszont feltölti a felhőbe és pillanatok alatt kész is utána az export. Sőt talán legjobb lenne, hogy választani lehet a kettő közül: lokális export vagy felhő-alapú.

( vati | 2021. 05. 06., cs – 08:53 )

Nem olvastam vegig a cikket, de  a video bongeszoben valo szerkesztesenek abszolut van letjogosultsaga, (mondjuk nem biztos hogy Magyarorszagon)

Nagy MAM (Media Asset Managment) szolgaltatoknal ez mar regota mukodik (Aspera, Cantemo, sot a Sonynak van). 

Gondold el anyag felhoben, szerkeszto, hirados stb mar helyszinen elkezd osszerakni egy Rough anyagot bongeszoben "nulla eroforassal", amit majd a studioban a vago XML-kent behuz a adot vagoprogramba, finomit es renderel. A fenti szolgaltatok kemenyen fizetosek, de mukodik. 

vati

( BlinTux v | 2021. 05. 06., cs – 09:53 )

Szerintem praktikusak az ilyen online programok:
- Nem kell letölteni
- Nem kell telepíteni
- Ha több géped van nem kell mindegyikre feltenni
- Használható telefonon, tableten is
- Egyszerű frissíteni (nem is neked kell)
- Ha valamire kell megoldás, csak ráguglizol, pl.: "image resize online"

Én ezt szoktam sűrűn használni: https://bulkresizephotos.com
Pillanatok alatt átméretezhetsz rengeteg képet. Ez sem tölti fel, hanem helyben végzi a műveletet.

De szoktam használni online fájl formátum konvertálókat is. 

És a fejlesztők szempontjából:

- ha mondjuk kikötik, hogy csak a legújabb Chromium-alapú böngészőkkel működik az alkalmazás, akkor máris nem kell 4-féle operációs rendszer 40-féle verzióján, azon belül 300-féle konfigurációján futó asztali alkalmazások hibabejelentéseivel foglalkoznia az ügyfélszolgálatnak (+ ezeket a kiadás előtt mind letesztelni, hogy működik-e), hanem drasztikusan lehet redukálni a tesztelendő környezetek számát

- akár naponta is beletehetnek új funkciókat vagy hibajavításokat, és minden felhasználó mindig a legújabb verziót használja anélkül, hogy azt telepíteniük kellene

- nem fog keringeni torrent- és egyéb letöltő oldalakon a szoftverük crackelt változata, tehát nem veszítenek pénzt az illegális letöltések miatt

Cserébe, ha a legújabb Chromium törik szarrá valamelyik alultesztelt oprendszeren (pl. Linuxon elég gyakran), akkor tehetetlen vagy és mehetsz kuncsorogni babzsákfejlesztőéknek, hogy ugyan szíveskedjenek már rendbehozni és figyelmesebben kerékújrafeltalálni, meg refaktorálgatni a fél kódbázist minden egyes főverzió között. Aztán majd ők eldöntik, hogy megjavítják-e vagy sem, te meg nyeld le és az ügyfeleiddel is nyelesd le.

Amit te itt előnynek próbálsz behazudni, az semmi más, mint a felelősségi kör arrogáns tologatása máshová (most épp a Google-hoz). Legyen mindenhol, csak ne nálad.

Ha mégis van, akkor az nyilván rögtön azt jelenti, hogy át kell állni egy bloated JS-frameworkre...

Mondom én, felelősség tologatása, semmi több. Nyugodtan használjon el sokkal több felesleges erőforrást a user, meg legyen kétszer-háromszor akkora erőforráséhségű egy alkalmazás, csakhogy az OS-specifikus bugokat ne neked kelljen kijavítani. Az árát pedig a felhasználók fizetik meg, energiapazarlással és az eszközeik gyorsabb elavulásával. Ráadásul annyiszorosan, ahány felhasználó van.