web-codecs VS caniuse

Encoding alpha, please! https://github.com/w3c/webcodecs/issues/672

From developer.mozilla.org [0]

> WebCodecs API

> The WebCodecs API gives web developers low-level access to the individual frames of a video stream and chunks of audio. It is useful for web applications that require full control over the way media is processed. For example, video or audio editors, and video conferencing.

And from w3c [1]:

> The WebCodecs API allows web applications to encode and decode audio and video

All this looks really promising, I wouldn't have thought that we could use browsers directly to render videos. Maybe Puppeteer could then stream the content of the page it is rendering, for example a three.js animation.

[0] https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

[1] https://github.com/w3c/webcodecs

As I understand it, Web Codecs is quite a ways away from being a web standard - it is currently just a draft[1] for a recommendation for a possible future standard.

Just beware of any major API changes or any indication that it might be dropped in its entirety!

[1]:https://w3c.github.io/webcodecs/

WebCodecs has Mozilla and Microsoft coauthors: https://w3c.github.io/webcodecs/

WebGPU was chartered in 2017, with more Apple people in the initial membership than Mozilla or Google people: https://gpuweb.github.io/admin/cg-charter.html

Google specifically has approached Apple for input about scheduler.postTask(), and they say they've presented the proposal before at a working group that Apple is part of: https://lists.webkit.org/pipermail/webkit-dev/2021-June/0319...

I won't disagree that there's a ton that can be improved about the process, but it seems pretty unsubstantiated to claim that Google is "rushing forwards as fast as possible" given that they've been spending years working on these APIs in public. You can see from the rest of the post that they're running some experiments which they're specifically choosing not to enable by default, though they could.

I work for PaperlessPost.com, and for our Flyer product we export mp4s from ffmpeg compiled to WASM, which is similar to ffmpeg.js but optimized for our use case which sounds similar. We have this WebAssembly method working well but iOS 15 (and the other major browsers) now support MediaExporter which might be a better way to go if you have something else to convert these files. This becomes and issue because you can't control the format MediaRecorder is recording to but the management of memory, the image quality, the compression, the performance hit will be more ideal than these other methods. OMGgif is very slow and will produce large files or very bad looking ones. Keep in mind that GIFs limit the colors so something that looks nice on the screen might not look the same after it is saved. The other thing to look out for is the WebCodecs APIs which should be the ultimate way to handle all of this in the future but it is only working in Chrome I think https://github.com/w3c/webcodecs

While in theory it might be possible to run ffmpeg through emscripten and run it in a web worker (I certainly assume someone has done this), it's not necessarily practical to try and use the same technique from node to transcode audio on the web. The good news is that the w3c has chartered a working group to focus on web codecs. While this is at the time of writing still in early stages, the working group is powering ahead on designing and proposing an API to enable media transcoding on the web, and hopefully that will become available to us in the near future.

You forgot to mention (Web)Workers. This is explicit creation, management, and communication with additional threads within JavaScript. What's more, they've been around in JavaScript longer than the V8 engine has even existed!

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

https://caniuse.com/?search=webworkers

Do you happen to know where can I check out the cutoff version for each browser? https://caniuse.com/?search=wasm doesn't have it (or other things like WasmGC for that matter)

(https://caniuse.com/) A handy tool for checking the browser compatibility of HTML, CSS, and JavaScript features. Can I Use provides up-to-date support tables for various web technologies across different browsers.

Caniuse

Can I Use (https://caniuse.com/)

> Is it though?

In my experience it's the buggiest browser out of the big three, and is often missing basic features like e.g.:

https://caniuse.com/?search=opus

Supported in Firefox for *12 years* now, in Chrome for 10, still no support in Safari.

They only "support" Opus audio in their special snowflake '.caf' container, which is super buggy and the last time I checked no open source program could even generate Opus '.caf' files that could be played by Safari on all Apple platforms. I ended up writing a custom converter which takes a standard '.opus' file and remuxes it on-the-fly (I only store '.opus' files on my server) into Safari-compatible '.caf' files, taking special care to massage it so that it avoids all of their demuxer/decoder bugs. You shouldn't have to do this to have cross-browser high quality audio!

Well I'll be! In my mind I had this clear picture of Firefox implementing it.

It correct, it was only Chrome: https://caniuse.com/?search=html%20import

https://caniuse.com/?search=web%20bluetooth

which might be great because you have the choice...

and you can use open source chromium or brave (like the jvm to run cross platform java) to run web apps seemlessly that need web bluetooth or such but use safari or firefox for personal use if you find them more secure

I mean using chromium engine as the running environment where chromium only ever runs special trusted web domains and never goes to other "malicious" web domains that may fuck up iOS as Apple claims would be still a secure choice

like you will not download spyware from Apple Store because you are an adult not because Apple can protect you there