Flv.js – An HTML5 Flash Video Player | Hacker News Reader

Flv.js – An HTML5 Flash Video Player

github.com

204 pointsfqj199437 comments

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"

[0] http://www.howtogeek.com/239682/how-to-watch-hulu-on-ubuntu-...

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 can only watch hulu on ubuntu on firefox. 0 problems.

chrome browser just sits there with a black screen.

Chrome did the trick, I wish I had tried that ages ago. Both Hulu and Netflix only work with Chrome on Ubuntu for me.

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.

Otherwise, you can try asking here: http://www.stream-recorder.com/forum/

Relies on Media Source Extensions, pretty widely supported already : http://caniuse.com/#feat=mediasource

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)

Yes, in fact it's even deployed on Wikipedia: https://github.com/brion/ogv.js/

Seriously, the contributions of Brion Vibber to the world are completely undersung.

However, isn't this server side and not clientside?

Nope, it's a clientside "polyfill of <video>", basically. Try out the demo in the page - it does all playback in Javascript and WebGL.

Brion gave a talk about this just a few weeks ago: https://www.twitch.tv/demuxed/v/94956075

Or maybe even include the wasm codec/player along with the video. Then it doesn't matter what the platform supports as long as it can run wasm.

Wasm does not solve problem of hardware acceleration completely. Wasm reduces recompilation time on client side, which is not a big deal in this case.

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.

[0] https://github.com/dailymotion/hls.js

[1] http://open.blogs.nytimes.com/2016/02/08/flash-free-video-in...

I was seriously just thinking that.

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.

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).

Here is an example of playing HEVC with this method: https://strukturag.github.io/libde265.js/

Broadway.js is Android's H.264 decoder compiled with Emscripten to JavaScript:

https://github.com/mbebenita/Broadway

http://mbebenita.github.io/Broadway/foxDemo.html

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.

>just rewrite flash for WebAssembly

FTFY.

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.

This looks like it would have been really useful 5 years ago!

Any live demos of this playing H264 or RTMP?

You can click into any video in bilibili.com (flv.js authoring company's video site) and select HTML5 player(with google translate).

The million dollar question. Will it play flv with alpha channels?

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.

Maybe, but then again it says "long live FLV!" on the github page, as if they actually favor this format.

I think it might possibly be sarcams ;)

It is. :-)

It's a play on the phrase "The king is dead, long live the king!", which means long live the successor, who is flv.js in this case.

Yes I understand the origin of the phrase.

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.

[0]: https://github.com/mozilla/shumway

an htm5 what?

Reply on news.ycombinator.com