ogv.js VS hyperfine

Yeah, that's what they do using this https://github.com/brion/ogv.js/

I've been told this at least three times now on HN over the years (pretty soon I'm going to start keeping a list of URLs so people know I'm not exaggerating.) Every single time it turns out that it isn't actually true.

It was added to desktop Safari. iOS Safari supports VP9 only in WebRTC. It may have changed, but I can't find any evidence that it has.

If you see it working somewhere, it is almost definitely using the polyfill[1].

[1]: https://github.com/brion/ogv.js/

I found a library "ogv.js" that says it decodes .ogg/.webm using WebAssembly, and this demo plays on my iPhone SE3 in Safari.

I believe Wikipedia has resorted to polyfilling it using this:

https://github.com/brion/ogv.js

That's great and all, but it has limitations, and obviously, is ludicrously less efficient than it should be.

We already have JS/WebGL video decoders (e.g: Broadway.js, OGOV.js). Much of the earlier video playback/acceleration work was getting it accelerated on GPUs-- using DirectX, OpenGL, or other GPU programming standards.

This is great and overdue. Hopefully all major browsers will add some support for open source/royalty free codecs.

Emscripten/WebAssembly actually worked rather well with audio (OPUS is just awesome) but when it comes to video it's just unfeasible, especially if you are looking at doing low latency streaming. That said, I cannot fail to mention the incredible effort done by ogv.js [1] to make a/v decoding possible almost anywhere.

Looking forward to experiment with this new API.

[1] https://github.com/brion/ogv.js/

Check out the official hyperfine Github repo

And then I used hyperfine to run the benchmarks on my MacBook Pro 14 M2 Max, and here are the results:

Search "benchmarking tools for linux" and decide that hyperfine is good for what I'm doing. Run Jennifer's new python script against my refactored perl and find that the python is 1.26 times faster for k=3 and 1.47 times faster for k=4. For the Covid-19 sequence, these are both on the order of hundreds of milliseconds.

> It is very possible to write sub 100ms procedures in TS, […]

I will not disagree with this statement because I don’t have a way to test inshellisense right now. Could you (or anyone with a working Node + NPM installation) please install inshellisense and post the actual numbers? Perhaps using a tool like hyperfine (https://github.com/sharkdp/hyperfine).

Yeah, while it's not as thorough as these tools, the method is at least reproducible and sane, and with ~10 or so samples, you get an interval with a nice confidence.

Another through method will be hyperfine[0], yet I wanted to provide a method which requires no installation and can be done in a whim, without jumps and hoops, with the tools already at hand.

[0]: https://github.com/sharkdp/hyperfine

That is native and inbuild but I would suggest below options instead 1. Using lazy's Profile tab instead https://github.com/folke/lazy.nvim 2. Using a dedicated plugin to do this https://github.com/dstein64/vim-startuptime. 3. Using an external program hyperfine is one that I use https://github.com/sharkdp/hyperfine

Fair enough, although might I recommend using hyperfine for your testing? ;p