mbebenita

The bytecode for AVM2 is fairly well documented, and there is a test suite that you can compare against. We reached 99% compatibility with that, and were at times much faster than the Flash VM (simply benefiting from years of investment in JS engines).

The hard part was understanding what the Flash player was doing, and the differences between all the different Flash Player and SWF File Format versions. Not to mention, re-implementing the rendering engine and the entire API surface of Flash, which was HUGE. We basically took existing content and tried to make sure Shumway did the same thing the Flash player did, wrote a regression test and repeated the process.

To this day, I still don't understand exactly how the timeline worked (or was supposed to work). It's like a web page DOM, but you can jump back and forth in the timeline, it's wild.

We certainly learned a lot working on Shumway. Firefox got a lot better, we stressed the JS engine and the graphics stack quite a bit, and had to make improvements all throughout the codebase to make Shumway possible.

In a lot of ways, Flash was great. Its rendering engine was (and still is) quite impressive, and nothing has really replaced it yet.

As one of the main developers on the project I can say that yes, 20+ years of undocumented baggage made it a really hard problem to solve.

AFAIK, Figma only uses WebGL/Canvas for non-UI elements.

If you're referring to SIMD, then the answer is not yet, very soon though.

Re WebAssembly.Studio, you can also just drag your .wat, .wasm file in without creating a project.

That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.

That's one of our goals, we're already doing a lot client side but the goal is to client side all things - https://github.com/wasdk/WebAssemblyStudio/projects/3

Built on top of the great work of many : https://github.com/wasdk/WebAssemblyStudio#credits

The goal of the project is to help you "learn and teach others about WebAssembly", so it's more of a fiddle environment than an IDE.

Depends on the template really. Our goal was to not hide any of the magic, the tool only really needs a build.ts file, where you define what the Build button should do.

AssemblyScript is slightly more involved because the author of the template loads the compiler dynamically.

This is exactly why we need to keep ASR tech open. These kinds of issues affect DNNs in general, and other ASR engines based on them are also vulnerable. Having models and the data used to train them open is a great way to help academia make progress in this space.

Mozilla is an AOM member. A lot of the technology in Daala has been integrated into AV1, along with Cisco's Thor.

ActionScript3 (or AVM2) is fairly well documented and Shumway did a fairly good job executing ABC files, I think we got to like 99%+ compatibility on the reference tests. Getting Rendering + Timeline + Library working correctly, ... that's another story. You have to bug-for-bug compatible AND do different things for different versions of SWF and AVM versions. If anyone needs a decent emulation of AVM2 bytecode, Shumway has a pretty good one in there.

With some work, it can be revived and used to port old content to the web. One of the difficulties with Shumway was being but-for-bug compatible with the Flash player, which turned out to be nearly impossible... If the developer is in the loop, the task is a lot easier.

That's correct. There isn't a good open dataset for that type of material. Perhaps we should try to build one.

Indeed, and a big problem for STT models, which is why we're trying to collect this type of data.

That is correct. The DeepSpeech project, https://github.com/mozilla/DeepSpeech will use this data to train and validate open source / freely available speech to text models. The training data, along with the trained models will be made available for free to all users and researchers alike.

Yes, the data will be made freely available.

I can't hear the difference between Opus 1.2 @ 32 kb/s and Uncompressed audio. I'm now excited about Opus 1.2 AND worried about my hearing.

Emscripten should produce an asm.js fallback if wasm support is missing. The biggest wins in the short term will be smaller code size, and faster first startup time.

That's in the works. Here is a patch that provides some of the foundation for getting first-class support for WASM: https://reviews.llvm.org/D26722

Interestingly enough, the "clunky" Emscripten compilation path is quite a bit faster than the WASM backed ATM because it bypasses all the cruft in the LLVM backend which can be pretty slow.

Here is the most recent update on Daala, from IETF 97:

https://www.ietf.org/proceedings/97/slides/slides-97-netvc-d...

We use a wide variety of metrics to compare codecs, not just the usual PSNR metric:

https://arewecompressedyet.com/?job=av1_rt_ctrl_new_twitch%4...

While none of these metrics are as good as the "human quality" metric, some are better than others, in different ways, so we try to optimize across the board.

If you're curious about this sort of thing, you can play with http://aomanalyzer.org/ which is a tool that lets you inspect AV1 (AOM/VP9) bit streams.

You can read the licensing details here: http://epdf.hevcadvance.com/pdf/embed?hash=45a69e5fbd2854d3a...

I believe the latest terms removed the content revenue fee.

Daala continues to be research platform for new ideas. New techniques are a lot easier to prototype in Daala than in more mature code bases.

The toolchain is C/C++/LLVM, which is pretty well baked.

You can compare various codecs: HEVS (x265), VP9 and the latest Daala build) at:

https://arewecompressedyet.com/?r%5B%5D=x265_1.6_ntt-short-1...

The results vary wildly depending on test clips, the metrics used and bit-rates, so an accurate comparison is quite difficult to do

Mozilla Research | Intern | Bay Area, Paris & Toronto

We are looking for PhD or MS level interns to take on various projects within our Research Group: Rust, WebAssembly, Daala, Servo and more.

Past interns have done substantial work in Language Design, Compiler Optimizations, Garbage Collection, Static/Dynamic Analysis, Record-and-Replay Debugging, Parallel Algorithms, Video Codecs, and Web Application Optimization.

Apply at:

https://careers.mozilla.org/en-US/position/oj092fwe