VideoLAN werkt aan browserversie VLC op basis van WebAssembly

Het ontwikkelteam van VideoLAN werkt aan een nieuwe browserversie van VLC op basis van WebAssembly en JavaScript, waarmee het mogelijk wordt naar films te kijken vanuit een webpagina. Ook brengt het team dit jaar VLC 4.0 uit.

Volgens Jean-Baptiste Kempf, de voorzitter van de VideoLAN-stichting, is VLC voor het web nog niet af, maar is er flinke vooruitgang geboekt. Hij zegt tegen Protocol dat de browserversie in feite het draaien van VLC in een webpagina omhelst en dat gebruikers elk ondersteund videobestand zo in een browser af kunnen spelen.

VLC had al een plug-in om in browsers te kunnen draaien, maar deze was op het inmiddels niet meer ondersteunde Flash gebaseerd. De nieuwe variant is op basis van WebAssembly en JavaScript ontwikkeld. WebAssembly is een open W3C-standaard die door vrijwel alle populaire browsers ondersteund wordt en bedoeld is om applicaties op webpagina's te kunnen draaien zonder plug-invereiste.

Kempf meldt verder dat versie 4.0 van VLC dit jaar gaat verschijnen. Deze versie bevat onder andere een gewijzigde interface tegenover de huidige VLC-versie. Volgens de voorzitter maakt VideoLAN het daarbij mogelijk om meer online content van derde partijen in de videospeler te integreren via extensies. Hij liet daarbij volgens Protocol de deur open voor het ondersteunen van video's met advertenties.

Ten slotte maakt de voorzitter bekend dat beveiliging hoog op de agenda staat en dat er gewerkt wordt aan sandboxing van VLC, zodat criminelen niet via kwetsbaarheden in de videospeler de rest van een systeem kunnen benaderen. Volgens Kempf is een videospeler een belangrijke attack-vector op een systeem, omdat mensen steeds minder applicaties installeren, naast een browser, videospeler, pdf-lezer en fotoapplicatie.

VLC 4.0
Concept van de interface van VLC 4.0 uit 2019

Door Olaf van Miltenburg

Nieuwscoördinator

12-02-2021 • 15:49

49

Reacties (49)

49
49
27
4
0
14
Wijzig sortering
...omdat mensen steeds minder applicaties installeren, naast een browser, videospeler, pdf-lezer en fotoapplicatie.
Op onze telefoon daarentegen installeren we voor elke website een apparte app. Ik kan er nog steeds niet over uit.
Is dat zo? Voor heel veel websites worden er inderdaad ook apps uitgebracht maar zijn er veel mensen die voor al die sites een app installeren? Ik heb er een paar voor sites die ik heel vaak bezoek, maar de meeste bezoek ik gewoon via de browser.

En ik snap ook websites die een app leveren: het is toch een stuk laagdrempeliger om een app te openen dan in de browser naar die pagina te gaan. En de kans is groot dat gebruiker bij jou blijven hangen en niet naar de concurrent gaan.
Veel mensen weten de webbrowser nauwelijks te vinden op hun telefoon. Letterlijk! Weten niet welke app de webbrowser is omdat ze hem nooit gebruiken.

Maar waarom zou het laagdrempeliger zijn om de app van een willekeurige dienst/website te openen in plaats van de browser-app :?

[Reactie gewijzigd door STFU op 22 juli 2024 22:01]

Ik ken niemand in mijn kennissenkring die niet hun browser kan vinden of niet gebruikt op de telefoon. Ook niet onder de digibeten. Dus of het veel mensen zijn vraag ik me af. Zijn er ergens cijfers van of is er onderzoek naar gedaan?
Anekdotisch: mijn vrouw wist niet dat er een browser beschikbaar was op haar telefoon. Als ze een webpagina nodig had zocht ze deze op in de Google zoekbalk op haar homescreen en browsde ze op die manier het internet.
He ik dacht dat de mijne uniek was :o
Ik wilde bijna precies dit verhaal ergens neerzetten hahaha
Ik ken iemand die niet wist dat edge een browser was die al op zijn computer stond, hij gebruikte nog steeds internet explorer in windows 10, ik bedoel maa.
Dat begrijp ik dus ook totaal niet. Op mijn laptop installeer ik idd alleen een aantal noodzakelijke applicaties. Waarom zou ik op mijn telefoon dan iets anders doen en 300 apps installeren?

Is het dan makkelijker te vinden op je telefoon? Want erg veel functionaliteit hoef je niet te missen. Ik gebruik als het kan eigenlijk altijd gewoon de website en dat werkt prima. Waarom zou je voor iets simpels als Nu.nl een app nodig hebben?

Eigenlijk zie ik alleen voordelen voor de eigenaar van de site/app. Je kunt de gebruiker met een app veel makkelijker tracken en zijn/haar aandacht trekken.
Opdat een website een emulatielaag is met beperkte rechten tot hardware en software. Wat de app kan en zijn performance verschilt ook browser per browser. Zo kon Safari lang geen 4k afspelen op de youtube website.

Een smartphone is ook veel complexer dan een pc.

Het klopt wel dat er erg veel niet native apps zijn die alle nadelen van een app combineren met de nadelen van een emulatielaag en dan heb je als consument enkel een nadeel van een html-app. Maar het idee dat je van alle apps websites kan maken klopt niet.

Een app praat directer met de OS api’s en via een app heb je de mogelijkheid om 100% van uw gpu/cpu/ml-cores/ram resources te gebruiken. Browser tabs hebben niet die zelfde ongebreidelde low level toegang.

Ook toegang tot sensoren zoals camera’s luchtdruk,bluetooth, lidar, gps, accelerometer enz maar ook toegang tot interne OS services zoals telefoonboek, notificaties, gebruikersbeheer, background services, trilmotor, schermverlichting, tekenpennetjes enz.

[Reactie gewijzigd door Coolstart op 22 juli 2024 22:01]

Gemak van gebruik? Op een telefoon klik je ergens op om het te openen, dus ligt het meer voor de hand om teug te gaan naar het beginscherm en de dedicated app te openen.
Home en dan een andere app openen is toch exact evenveel werk als op de adresbalk van de webbrowser klikken en 1 van je meestbezochte websites kiezen!? :?
apps zoals nextcloud en bitwarden vind ik persoonlijk fijner aanvoelen als app dan als website op de smartphone. Op de laptop/desktop is de webbrowser vaak voldoende en is een aparte app niet noodzakelijk. En ja, ook nieuwssites zoals de NOS vind ik overzichtelijker in de app. Op de laptop/desktop heb je veel meer screen real estate waardoor UI compromissen vaak niet nodig zijn.
Ik heb amper apps en bezoek alles in de mobiele Edge browser. Alhoewel het gros wat minder smooth verloopt gaat het prima. Het is vaak een keuze :)
ik vraag me nu toch echt af wat ik hiervan moet denken.

komt er een soort webessembly code id als een soort remote front-end voor een VLC-service draait vanuit de browser of gaan ze een hele player (inclusief codecs) implementeren. En voor wie is dit nu eigenlijk.

vroeger had je een windowsmediaplayer of quickitime plugin nodig om uberhaubt in je browser iets te bekijken, ergo toen zou je nut hebben kunnen hebben aan een vervanger in de vorm van een VLC-plugin maar die tijden zijn lang voorbij en browsers ondersteunen nu een aantal formaten al standaard.

er zijn altijd diensten die dan liever hun eigen platform onderhouden maar dan lijkt de integratie van een online-vlc me juist weer minder nuttig. dus zou in die zin vlc4 met een plugin-bridge voor bijvoorbeeld netflix appleTV of Disney+ wellicht een optie zijn. zodat het meer als een hub kan gaan fungeren voor verschillende online kanalen. (eigenlijk op de manier zoals kodi dat nu ook al is maar dan binnen een eenvoudige mediaplayer).
Volgens mij is Videolan al via LLVM te compilen, dus dan zou het theoretisch een kwestie van opnieuw compilen naar webassembly en dan een wrapper schrijven tussen de browser en VideoLan. Dus dan zou je alles inclusief codecs ter beschikking hebben.
Daar gaat wel wat meer in zitten.

Je zal implementaties moeten schrijven voor o.a. je presentatie laag en je netwerk laag, omdat webassembly weer andere API calls heeft. Daarnaast kan je afaik in webassembly geen UDP verkeer doen, en zijn er nog een stuk meer dingen die (iets) anders zijn.
Genoeg in ieder geval om niet met slechts één recompile klaar te zijn ;)
Je kunt eventueel gebruik maken van WebRTC in wasm voor je UDP, maar dit staat nog in de kinderschoenen, je hebt een (externe) signaling server nodig, en 't zaakje wordt alleen maar nog een reden waarom je niet met zomaar een recompile klaar zult zijn.
En voor wie is dit nu eigenlijk.
Wellicht voor Chromebook gebruikers? Al is er al wel een VLC in de store te vinden
https://www.videolan.org/vlc/download-chromeos.html
Voor iedereen. Waarom zou ik nog een app downloaden en installeren, als ik video gewoon in de browser kan kijken?
GPU acceleratie. Is ook een groot probleem op het moment met ffmpeg.wasm.
Maar je hebt wel toegang tot de GPU vanuit WebAssembly.. Of denk ik dan te eenvoudig, omdat het alleen openGL etc is?

[Reactie gewijzigd door DutchKevv op 22 juli 2024 22:01]

De browser zit niet constant de zuivere pixels van elke frame uit je video binnen te nemen. De video komt binnen in geëncodeerd formaten zoals H264 e.d. Jouw pc doet de decoding.
Voor hardware accelerated video decoding moet er platform specifieke driver/middleware voorzien worden,
die bijvoorbeeld H264 streams decodeert naar gekleurde pixels. WebGl (de web tegenhanger van OpenGL)
kan vooral snel 3D instructies uitvoeren op je framebuffer, welke daarna ook via de gpu op je beeldscherm terecht komen. Video decoders zetten dus H264 om naar naar een canvas, webgl neemt dit canvas en tovert dit op het beeldscherm. Het webgl gedeelte doet dus eigenlijk niet echt spectaculaire berekeningen, maar de video decoder wel. Als je deze hardware decoder niet hebt, komt die last op je CPU terecht. Natuurlijk, bij veel dekstop gpu's zit video decoding van de meeste gekende encodering algoritmen als onderdeel van de videokaart.
Duidelijke uitleg! Dank daarvoor :)

Maar is WebGL niet gewoon een middleware tot OpenGl en niet echt een tegenhanger? op windows word ook gewoon een directx layer aangesproken..

https://stackoverflow.com...runtime-or-opengl-runtime

Kortom, snap dat WebGL op een canvas rendered etc, en omdat het een middlware is, WebGL v2 beperkt is tot simpelweg modern OpenGL 3.* (ofzo, weet niet precies welke versie)...

Bedoelde eigenlijk vooral: kan WebAssembly niet veel dieper dan WebGL? Gezien je complete libs zoals SDL en GLFW enzo kan inladen.. Waarom dan niet iets voor ML en / of hardware decoding?

Vermoed dat de WASM Sandbox (nog) geen toegang geeft tot de driver functies zoals encoding / decoding inderdaad....

[Reactie gewijzigd door DutchKevv op 22 juli 2024 22:01]

Klopt, uiteindelijk is WebGL idd gewoon middleware die afhankelijk van platform, browser en browserinstellingen bepaalde achterliggende stacks (DX, opengl) gebruikt.

Betreffende WebAssembly en het gebruik van de VPU (video processing unit, ik gebruik WebAsm niet professioneel (ik ken dus zeker niet alle beschikbare bibliotheken), maar praktisch gezien zou je net zoals op desktop iets moeten hebben zoals ffmpeg, gstreamer o.i.d. Dit zijn multimedia bibliotheken die allerhande video encoding en decoding taken kunnen afhandelen. Doorgaans hebben deze vele bibliotheken en plugins waarom ze verder bouwen, en ergens in dit hele verhaal zullen de APIs geïntegreerd moeten zijn die op kernel/driver niveau de juiste dingen oproept zodat het video decoding langs de VPU gaat indien deze aanwezig (en ondersteund) is. Op bepaalde platformen werkt men wel eens met custom forks van zulke multimedia bibliotheken, of met plugins, om dit voor elkaar te krijgen.
Ik zie dat ffmpeg wel bestaat voor webasm, en dat er ondertussen wel al een hele boel video codecs ondersteund worden. Momenteel zit denk ik het hardware decoding nog in development fase, en gaat dit momenteel gewoon via de CPU. Het werkt wel, maar vraagt wel wat resources van je CPU, en mogelijks gaat dit niet al te goed op talrijke embedded boards.
De UX van een (goede) app is vaak net iets beter dan iets in een browser.
Uit bron:
https://www.protocol.com/...ebelltitem=2#rebelltitem2
Now, the VideoLAN team is working on a new version that is powered by Webassembly and JavaScript. "You basically run VLC inside the web page, so you could play any type of movie right inside your web browser," Kempf explained. "We're not there yet. But it's getting closer."
Gezien je gewoon bestaande code, zoals onder andere C/C++, kan compileren voor webassembly moet het vrij makkelijk zijn de hele speler in de browsers draaiend te krijgen. Gezien VLC zijn eigen codecs gebruikt zal dit waarschijnlijk ook wel in de web-versie zijn.
Anoniem: 310408 @i-chat12 februari 2021 16:44
En voor wie is dit nu eigenlijk.
Voor iedereen die VLC nodig heeft en het niet wil of kan instaleren.
Lijkt me best praktisch voor een Plex of voor een Emby om een volwaardige mediaspeler te kunnen importeren. Momenteel maken dit soort projecten hun eigen standalone player met sommige features wel/sommige features niet, wisselende UX-kwaliteit, etc.

Als je met wat lichte aanpassingen gewoon heel VLC in de front-end kan plempen, wordt de ervaring voor veel mensen denk ik een stuk beter. Het nadeel is natuurlijk de hardware decoding die je mist, maar wie weet kun je daar de browserdecoder voor inschakelen als de stream ondersteund wordt door de hardware die je gebruikt.
Wat betreft de combinatie met Plex, zou ideaal zijn. Misschien de omweg om toch DVD iso's te kunnen afspelen. Iets wat Plex blijkbaar zelf niet ondersteund of gaat ondersteunen omdat het tegen een éénvormige GUI ervaring zou zijn (menu in menu mag niet volgens Plex team). Dus, kom maar op VLC!
Het is niet persé voor een bepaalde doelgroep. Veel apps kunnen worden omgedoopt tot webapp waardoor het op elk modern device werkt en er geen playstore nodig is om gebruik te maken van de service.
Is het idee van webassembly niet nou juist dat het in een container (de browser) draait, dus niet (zomaar) bij de rest van het systeem kan, dus redelijk veilig is?
Edit: de stand-alone app is daarmee een veel groter veiligheidsrisico.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 22:01]

De Stand-alone app kun je ook in een container draaien, maar dit is alleen beschikbaar op Linux of in de Microsoft Store.

Eventueel kun je op Linux ook nog de sandbox permissies strenger maken door middel van Flatseal want die zijn nu nog vrij losjes in verband met ondertitels, online metadata en disk playback.

Voor Mac gebruikers is er overigens geen Mac Store versie van VLC, omdat de Mac Store in strijd is met de licentievoorwaarden van VLC.

[Reactie gewijzigd door Eonfge op 22 juli 2024 22:01]

read-only toegang tot een bestandssysteem hoeft geen groot probleem te zijn. Je wil vooral 2 dingen voorkomen met sandboxing:
- schrijftoegang tot de harde schijven
- geheugentoegang bij andere, niet gerelateerde processen.
Huh? Ik wil apps helemaal niet zomaar toegang geven tot mijn data, read only of niet.
Er is weinig geregeld op dat gebied. In principe kunnen ze overal bij. Sommige mediaspelers veranderen ongevraagd de metadata.
voeg hier aan toe internet access; al je bestanden kunnen doorgesluisd worden, ook als ze read only zijn
Edit: de stand-alone app is daarmee een veel groter veiligheidsrisico.
Dat is ook precies waar dat sandboxing over gaat; zie ook:
Volgens Kempf is een videospeler een belangrijke attack-vector op een systeem, omdat mensen steeds minder applicaties installeren, naast een browser, videospeler, pdf-lezer en fotoapplicatie.
Ik zie een paar donatie knoppen op de website staan.

En verder op de Support-pagina:
VideoLAN is free and open source software; and is not backed by any company. Developers are mostly volunteers.
Therefore, please remember that every user support is provided by volunteers doing it in their free time.
Waar kan ik meer vinden over de plannen voor VLC? Zowel op hun forum, wiki als Planet VideoLAN zie ik niks, en ook in dit nieuwsbericht wordt niet naar een bron verwezen.
dit is de bron die ook in dit Tweakers artikel staat. Zei halen dit direct uit hun eigen gesprek met Kempf.

en dit is in 2019 naar buiten gekomen over VLC 4.0
Tijdens deze presentatie delen ze info over de nieuwe interface en plannen om content te integreren:
https://youtu.be/P1qMAupb2_Y?t=1345 (22:25)

Vanaf 31:30 tonen ze designs en screenshots van de nieuwe interface.

[Reactie gewijzigd door P1nGu1n op 22 juli 2024 22:01]

Waar krijgt deze stichting t geld om draaiende te blijven?
Met die comment dat straks wellicht ook advertenties te zien zijn van 3rd party video providers lijkt het me alsof ze van business model proberen te veranderen
Hoogst waarschijnlijk krijgen ze donaties van Google, Microsoft en wat andere techbedrijven aangezien zei ook veel gebruik maken van technieken die Videolan ontwikkeld.
Programmeer het anders met Rust
Ja, want omdat er een nieuwe taal is uitgekomen moet er maar even tientallen jaren aan code weggegooid worden 8)7
Ik ga toch proberen om zo lang mogelijk met gewone binaries te blijven werken - webassembly is iets te geconnecteerd naar mijn goesting.
Met Blazor van Microsoft kan je ook eenvoudig in bijvoorbeeld C# singe page applications maken in WebAssembly. https://blazor-demo.github.io/

Het is wel iets dat in opmars is.
Ik kan die fascinatie om álles maar in een browser te willen draaien echt nog altijd niet begrijpen. Een browser is om webpagina's weer te geven , niet om complete softwarepakketten en besturingssystemen in te draaien (en ja ik weet dat dat kan). Een lichtgewicht applicatie als VLC wordt straks weer een webapp dat veel meer geheugen en cpu vreet. Maargoed, het is te hopen dat het er gewoon bij komt en niet de bestaande applicatie vervangt op den duur zoals helaas bij veel te veel software al is gebeurd.

[Reactie gewijzigd door Metro2002 op 22 juli 2024 22:01]

Op dit item kan niet meer gereageerd worden.