media-source
goja
media-source | goja | |
---|---|---|
1 | 25 | |
266 | 4,944 | |
0.4% | - | |
6.9 | 6.3 | |
about 1 month ago | 2 months ago | |
HTML | Go | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
media-source
-
Chrome 0day is being exploited now for CVE-2022-1096; update immediately
It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.
Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).
On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.
Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.
You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.
You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.
Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.
Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).
All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.
goja
- Goja: ECMAScript/JavaScript engine in pure Go
-
SSR React in Go
dop251/goja
-
Show HN: Flyscrape – A standalone and scriptable web scraper in Go
Your comment was posted 4 minutes ago. That means you still have enough time to edit your comment to change it so it contains real URLs:
<https://github.com/PuerkitoBio/goquery>
<https://github.com/dop251/goja>
(Please do not reply to this comment—I won't be able to delete it once the previous post is fixed if it contains replies.)
- Goja: ECMAScript 5.1 implementation in pure Go
-
TySON: TypeScript as an embeddable configuration language, without depending on Node or V8
Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.
-
Examples of using task scheduler with Go?
Goja https://github.com/dop251/goja
-
Running a Js file inside Go
Either call a JavaScript interpreter like node with exec.Command and read its stdout, or use a pure Go JavaScript interpreter like goja or otto.
-
easytemplate - Go's text/template library with JS Super Powers
Just to also say this is implemented in pure Go we aren't including V8 or any external dependencies we instead use https://github.com/dop251/goja which is a JS VM written completely in Go.
-
how to JSON Marshal a struct if one of its fields is a fucntion
If you want to serialize a function to JSON one idea may be to embed a scripting language like JavaScript into your program. The goja package is a very good solution: a native ES5 JavaScript (with some ES6 syntax support as well) natively implemented in Go so you can get tight data bindings to your Go types and funcs. For your JSON marshalling you could serialize a JavaScript function source (text) and when reloading that, parse that text with goja to be able to run it dynamically in your Go program. Basically you'd need to get away from pure Go for this and towards something that is JSON compatible to (de)serialize to text.
-
Anyone experienced in golang ssr?
Not really. It was built in-house and I don't know of anything about it that went public. I recall it using Goja for the JS runtime. Code was embedded into the binary (think embed package). There was some kind of sorcery to convert what would be HTTP network calls in the browser into local function calls during SSR, but I'm hazy on how it worked I'm afraid.
What are some alternatives?
ECMAScript 6 compatibility table - ECMAScript compatibility tables
otto - A JavaScript interpreter in Go (golang)
V8 - The official mirror of the V8 Git repository
v8go - Execute JavaScript from Go
quickjs - Public repository of the QuickJS Javascript Engine.
go-lua - A Lua VM in Go
tiny-snitch - an interactive firewall for inbound and outbound connections
gopher-lua - GopherLua: VM and compiler for Lua in Go
tengo - A fast script language for Go
go-python - naive go bindings to the CPython2 C-API
go-duktape - [abandoned] Duktape JavaScript engine bindings for Go
gval - Expression evaluation in golang