Recently we released a pure JavaScript implementation of in-browser player for our lossless video codec
ScreenPressor. It supersedes our old player
made with Flash. Here's some anecdotal evidence of how fast current JavaScript interpreters in browsers are.
The chart shows Frames Per Second:
Here we took a screen recording with resolution 1364x768 - 1M pixels, 4MB RGB32 data per frame -
and measured how fast our players could decode 480 consequent delta-frames when seeking from 0 (a key frame)
to frame 490 (while the next key frame is the 500th).
When the player is at position 0 it decodes and buffers
a few frames in advance, in this case 10, so when seeking then to frame 490 the number of frames to decode is
480. You can see the test video here
(btw this sample shows ~300x lossless compression).
"v2" and "v3" mean codec versions: we tested implementations of both 2nd and 3rd versions of ScreenPressor,
they use different entropy coders and have other differences.
Of course the speed depends a lot on the video content, how complex and diverse it is, so on different videos numbers
will be different. In typical screen videos there are not so many changes from frame to frame, most of the frame
can be copied from previous one, this includes scrolling and window movement scenes. But anyway it's quite impressive
how a JS-based player can produce 150-200 4MB frames a second.
In this case we can see how different JS speed is in different modern browsers. Firefox Quantum is incredibly fast and smooth
when it comes to browsing sites but its JS engine in this test is slower than of MS Internet Explorer and Edge, while
Chrome is king when it comes to JS speed.
All JavaScript engines here worked faster than Flash, this probably shows how they evolved since our
previous test
three years ago. However native code is still 2-4 times faster than JS, thanks to well optimizing vectorizing compiler,
more compact data representation and no dynamic types with their runtime costs.
More information about both (JS and Flash) web players for ScreenPressor and more samples
here.
This autumn, by request of our client, we developed a video deshaking method that
works in a single pass, in streaming mode. I know there is a very nice Deshaker filter
for VirtualDub but it works in two passes: first it collects motion data, then plans
for whole movie and in the second pass performs actual changes to the video. When
your video processing pipeline is quite heavy, loaded with many filters or something
computationally expensive, doing the work twice or saving it into a huge lossless file
and then processing twice with Deshaker can be extremely time-consuming. So, there
might be a need for something quicker, working in one pass.
Here are a couple of examples showing our own deshaker in action (before/after) :
RSS
