ogv.js VS line_profiler

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/

LineProfiler is the best tool to learn how to write performant Python and code optimization.

https://github.com/pyutils/line_profiler

You can literally see the hot spot of your code, then you can grind different algorithms or change the whole architecture to make it faster.

For example replace short for loops to list comprehensions, vectorize all numpy operations (only vectorize partially do not help the issue), using 'not any()' instead or 'all()' for boolean, etc.

Doing this for like 2 weeks, basically you can automatically recognized most bad code patterns in a glance.

You may want to try using a package like line_profiler to narrow down where the time is spent.

When tuning for performance, always measure. Never assume you know where the slow parts are. Run a line profiler and see where all the time is actually going.

Either way I would highly recommend running a profiler on your code to see where the program is spending most of its time. line_profiler is a very nice one, as it shows you execution time for each line.

There are dedicated tools like line_profiler for python - if this doesn't do exactly what you need it can be easily modified.

It's surprising to me that an sklearn pipeline and a spacy pipeline both doing simple regexing are vastly different in performance. I would go one layer deeper with measurement with something like line_profiler, which I've used to great effect to get line-by-line perf stats. This should illuminate why.

This looks really nice! Does it use line_profiler or is it a different implementation for the profiling? Either way the interface is fantastic!

# https://github.com/pyutils/line_profiler pip install line_profiler kernprof -l -v some-code.py # This might take a while... Wrote profile results to some-code.py.lprof Timer unit: 1e-06 s Total time: 13.0418 s File: some-code.py Function: exp at line 3 Line # Hits Time Per Hit % Time Line Contents ============================================================== 3 @profile 4 def exp(x): 5 1 4.0 4.0 0.0 getcontext().prec += 2 6 1 0.0 0.0 0.0 i, lasts, s, fact, num = 0, 0, 1, 1, 1 7 5818 4017.0 0.7 0.0 while s != lasts: 8 5817 1569.0 0.3 0.0 lasts = s 9 5817 1837.0 0.3 0.0 i += 1 10 5817 6902.0 1.2 0.1 fact *= i 11 5817 2604.0 0.4 0.0 num *= x 12 5817 13024902.0 2239.1 99.9 s += num / fact 13 1 5.0 5.0 0.0 getcontext().prec -= 2 14 1 2.0 2.0 0.0 return +s