Accidentally committed some time travel during this encoding... O_O

That feeling when frame-parallel threading is working in the AV1 decoder...

Did I mention Safari's WebAssembly engine is great? Running the dav1d AV1 decoder is a smidge faster single-threaded in Safari than multi-threaded in Firefox, at least on this first set of test files. Chrome's in between.

Safari doesn't support Wasm threading yet, but when it does that'll be insanely great. :)

Multithreaded WebAssembly build of dav1d AV1 decoder in ogv.js plays back files _moderately_ faster (left) than the single-threaded build (right).

I'm encoding some new test files that use tiled encoding, which should help with the multithreaded decoding I think.

Ok, I just wasn't patient enough at the start of my encoding. ;) Somewhere around 50 frames into this test it started actually using up to 8 threads for part of each frame. (4 tile columns + row-mt)

Still has times of single-threaded goodness, but total throughput is much improved.

I am just *really excited* about WebAssembly threading being just around the corner...

When Safari picks it up, 2-core and 4-core Macs and iOS devices will be able to play video on Wikipedia faster, at least until the day we and Apple agree on a patent-unencumbered video format. :)

Here's my old 8-core Xeon workstation decoding 1080p VP9 in Firefox with threading enabled on Win10, loading up 4 cores. Using more than 4 cores w/ libvpx will only help at 1440p and 2160p, which you'd want faster CPUs for too.

A Core 2 Duo mid-2010 MacBook Pro running Windows 7 fares better than the Atom netbook, running 180p with a fair amount of headroom. There's some dropped frames, but it keeps up.

Under macOS, the same computer handles 480p ok in Safari.

My worst case scenario for ogv.js in IE 11 is an old Atom-based netbook tablet. Maxes out at 1.67 GHz and I can barely get it to play 120p VP9 where my faster machines handle 240p well. I expect most IE 11 users will be somewhere between the netbook and the MacBook in speed -- that's enough to handle low resolution inline play but unsatisfactory when zoomed in.

Using any other browser resolves this of course. ;)

Safari's Wasm engine is pretty great these days... Especially if you compare it against IE 11's JS engine. ;)

(For ogv.js these are my main targets: Safari on Mac and iOS, and old PCs with IE 11, neither of which grok Ogg or WebM video.)

Here I've got Safari running a (cropped widescreen) 720p24 VP9 video comfortably while old IE has to bump down to 240p to maintain frame rate - 9x fewer pixels! With future Wasm threading, Safari should be able to hit 1080p. SIMD support would improve that further...

Not a fan of Babel's transpiling turning all my method names into 'value' in IE 11's debugger. wheeeee

On the left, single-threaded Wasm VP9 video decoding on an ancient Xeon is too slow at 720p. On the right using threads, decoding is 3-4x faster and doesn't drop a frame! (Beyond 4 threads makes no difference at HD resolutions.)

Logo interpreter now retains the source code and token locations for parse nodes and the "debugger" can display it with the actively running node highlighted, comments and all.

Added execution observer hooks and a pause ability to my Logo interpreter.

The observer is async/await, so can also delay operations or force the event loop to run... This allows for real-time visualization of execution and allows infinite loops to be paused from a button on the web page.

My Logo now has timer waits so you can make your turtle drawing look awesome!

The 'wait' command for the interpreter uses setTimeout and resolves a Promise manually, which interops perfectly with the async/await execution loops (all Promise-based under the hood).

Of course now I need to add a global interpreter lock... ;)

Garbage collection pauses in Atari Logo took "at least one second". O_O

Got map/foreach working in my little Logo-in-JS interpreter. :)

Think I've got the hang of the linked lists now; using proper lists terminated with an immutable List.empty instance, and doing forward-building of lists using a ListBuilder so the exposed final lists are immutable. That lets list work in the Logo side pop off the head efficiently, or unshift a new head onto a list, without a copy (as would be needed with Array-based lists)

Show more
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators.

Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!