Note the distinction between two types of js driven video playback that are possible. Those which require transcoding and those who can do with just transmuxing.
HTML5 playback can only support few codecs but FLV can contain a wide variety of video and audio codecs. Flv.js does a great job of transmuxing h.264 frames in a different container, hence it only plays those flv which are h.264/aac. Transcoding can make it possible to even play HEVC or any non-standard codec on browser. This can be heavy on CPU especially hand-held devices. When using one of these in production you must understand that it is not very practical to do transcoding on the fly like this : https://strukturag.github.io/libde265.js/ . It is theoretically possible to play vp9 on an ios or a hevc on a pc but this will be impractical for low-cpu devices.
Obviously this has value as a drop-in solution for some, but given what it's doing it seems like it'd be preferable for most situations to just re-mux the videos ahead of time.
I wonder if something like this could ever support DRM. I'm thinking of this mainly for playing Hulu videos on Linux[0].
I consistently have issues with Flash on Ubuntu with Hulu freezing or displaying something along the lines of "Error loading DRM content"
As long as Flash DRM doesn't use TPM/smartcards/etc it's a cat and mouse game - it's theoretically possible to reverse engineer Flash software and write new implementation, but then it's likely that Adobe would switch to new keys/protocols and/or Hulu would drop Flash support to prevent ripping.
Maybe if you asked very kindly, Adobe themselves would release a heavily obfuscated Javascript blob which implements Flash DRM. But at this point they could as well simply fix bugs in their browser plugin.
And I don't even know how Flash derives its decryption keys. If this process involves contacting some Adobe servers, it's possible that your problems are caused not by client software, but by network failures or server downtime.
Do you also get this problem with Chrome browser? If you are using Firefox, it uses an old flash player 11.2 which does not have full support for flash drm. Google chrome for linux comes pre-packaged with pepper-flash, a chrome-only port of the latest flash player. That one should work.
I'm not sure what kind of protection Hulu uses, but if it's like most streaming websites, this should do the trick: https://github.com/K-S-V/Scripts/wiki
I routinely use it to play protected video content (subscription sports channels) with my favorite video player https://mpv.io/ instead of the horrible flash plugin.
I wonder. Could something like this be packaged as an extension and thus enable javascript-powered codecs for browsers that do not have the full set? (webm for Safari comes to mind)
This is a little different than codec support, though as other replies indicate, that can be done too. This is just demuxing the stream in one format, re-muxing it in a different format, and feeding it into <video> to actually do the decoding and playback.
On the other hand, something like https://github.com/brion/ogv.js/ is actually doing all of the decoding and playback in JavaScript/asm.js, using C libraries compiled with Emscripten.
Anyhow, yes, it probably would be possible to package up extensions that would apply one of these automatically to <video> tags with unsupported codecs or container formats. It's just a simple matter of programming.
A similar idea, HLS.js [0], allows playback of HLS on platforms that do not support it natively. Open-sourced by Dailymotion, it is used by The NYTime [1] amongst others to reduce the number of video renditions they have to produce for each video.
Yes, it is possible. However, note that webm on safari will require transcoding vp8/vp9 into h.264. This is much more compute intensive than just transmuxing a flv (which has to be in h.264/aac) into another container (in this case fragmented mp4).
IIRC, before Google bought them, some of On2 Technologies' earlier VP codecs were used in Flash Player (Wikipedia says VP6 and VP7). Are they similar enough to WebM's VP8 that transcoding would be simple? (I'm guessing not.)
I'm wondering if Adobe couldn't just run flash through emscripten for WebAssembly. I'd be curious what problems are still there. Offscreen Canvas is coming soon which should help in some ways.
Honestly, that would make sense and make a lot of people who are still invested in Flash pretty happy. They may prefer to devote those resources toward their current technologies rather than continuing to support the dying Flash development platform, though.
I imagine this is for video site's that still have a lot of flv's which they'll never reencode but want to work on devices that don't have flash player.
To keep running with your great story about the king, it is not the JS library which is the successor, as you claim, it's still FLV. Which brings us back to the original question of why this was done in the first place - the reason now I don't even care to know.
I assumed it was done for historic reasons so in the future websites like archive.org could continue playing flash. (like Shumway [0]) We would lose a huge library of videos that were created in the format if we could no longer play them due to browser policies and the obsolescence of the format. In terms of video encoding, there are much better options these days that don't involve transmuxing from flash when you're already encoding in h.264, so it likely isn't so sites can continue serving Flash.
HTML5 playback can only support few codecs but FLV can contain a wide variety of video and audio codecs. Flv.js does a great job of transmuxing h.264 frames in a different container, hence it only plays those flv which are h.264/aac. Transcoding can make it possible to even play HEVC or any non-standard codec on browser. This can be heavy on CPU especially hand-held devices. When using one of these in production you must understand that it is not very practical to do transcoding on the fly like this : https://strukturag.github.io/libde265.js/ . It is theoretically possible to play vp9 on an ios or a hevc on a pc but this will be impractical for low-cpu devices.