This paper on a malloc() replacement that DOES COMPACTION even on C/C++ is making the rounds: https://arxiv.org/pdf/1902.04738.pdf
Ok, I can enable SharedArrayBuffer in a custom WebKit build but there's still no WebAssembly threading support so the decoder can't run. ;_;
abort("Assertion failed: requested a shared WebAssembly.Memory but the returned buffer is not a SharedArrayBuffer, indicating that while the browser has SharedArrayBuffer it does not have WebAssembly threads support - you may need to set a flag"). Build with -s ASSERTIONS=1 for more info.
Fixed another old weird bug in ogv.js. Sometimes after playing a file to the end, it would get stuck when you tried to re-play it.
Turned out to be that when flushing the demuxer's buffers, it got left thinking it was at the exact byte position where it had to seek to to read the keypoint cues at the end of the file... but since buffers had been flushed it had no data to read, and got confused.
Tweaking it to discard the position on flush means the demuxer issues an i/o seek which refills the buffer. \o/
Performance of the dav1d AV1 decoder in WebAssembly is not great, but good enough to work if Apple doesn't end up shipping AV1 support in Safari.
iPad Air (first-gen 64-bit iOS device) top out around 240p at 24fps; newer iPad Pro is comfy with 360p but drops some frames at 480p.
On macOS, Safari also does significantly better than Chrome or Firefox, by like 25% or so! But Safari doesn't yet have threading, which can double throughput in Chrome/Firefox with the necessary flags enabled.
@KelsonV this implies the existence of meat IKEA furniture
I think I found my packet corruption bug. Currently ogv.js's file fetching uses the old XHR "binary string" hack in order to do progressive downloads (since you can slice out parts of the string during progress events).
At a particular byte position we do an XHR for a chunk that starts with.... 0xFE 0xFF, which is interpreted as a UTF-16 BOM overriding the x-user-defined charset.
The chunk gets turned from 1 megabyte into 0.5 megabyte with every other byte copied.
Had an out-of-bounds memory access bug in the emscripten-compiled AV1 decoder that I worried was an optimizer bug.
Turned out to be an unsafe optimizer option that I had explicitly enabled to shave a few bytes off the generated WebAssembly... it had just never broken anything on my other decoders.
Looks like AWS charges about $16/day for 16-core "c5.4xlarge" instances in US-Oregon region, or $8/day for the 8-core version. This is pretty good for rare usage spikes, but would add up if used frequently.
That's with a reasonably current Xeon with AVX512, which should help a lot with video encoding.
I also noticed AWS has ARM servers available now! This would not be wise for video encoding. ;)
MediaWiki, ogv.js, OGVKit, mtpng, formerly StatusNet, human decency, puns.
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!