Js-ipfs: Video player with js-ipfs

[daviddias]

Similar to https://github.com/ipfs/js-ipfs/issues/127, but that loads a video from IPFS (with seeks and everything)

[daviddias]

@moshisushi is paving the path by taking the lead and implementing hls over IPFS with js-ipfs \o/

Demo on: https://ipfs.io/ipfs/QmPJB4FyoM8CMGt9PdsTwUsiaNho6TGnL1NyPkoFVjtZgH/examples/index.html

Code at: https://github.com/moshisushi/hlsjs-ipfs-loader

This is is pretty cool stuff @moshisushi ! Let me know how we can help :)

[moshisushi]

@diasdavid The media I've used for this example is audio only actually. Video works as well (yes, a Big Buck Bunny test flight was carried out 😄) but due to the higher bandwidth requirements I run into some performance issues with libp2p (well, that's the theory), which makes the buffering of segments a bit slow (see also: https://github.com/moshisushi/ipfs-lab/tree/master/secio-test)

[daviddias]

@moshisushi nice! Could you submit a PR with an example that has two options, audio and video streaming, with some data about the throughput, load time, seek time, browser resource consumption and any other data that is relevant to use it as a good test for perf checks? Thanks!

[moshisushi]

@diasdavid Sure I'll write something up soon! PR for an example to go in here? https://github.com/ipfs/js-ipfs/tree/master/examples

[dignifiedquire]

@moshisushi @diasdavid I started looking at the perf profiles for chrome and seeing some interesting results, there might be some small wins we can get easily, though the bottleneck seems to be calling hmac.sign on webcrypto currently. Which is the native c++ implementation in chrome. But because we have tiny messages the overhead is quite high for communications. It might be possible to do some tricks for this, buffer calls, but not sure yet that we can do that.

[dignifiedquire]

I was able to reduce both average and mean send time by 100ms with this hack: https://github.com/libp2p/js-libp2p-crypto/commit/92f94a800cd6a57d697744da8e638b62213de434 as the current nodeify version users setImmediate in the browser.

[daviddias]

@moshisushi, exactly, that is the right spot :)

@dignifiedquire thanks! Did you run those here? @moshisushi has been doing some perf testing on secio

[dignifiedquire]

@diasdavid that is with the benchmark from @moshisushi, not sure it will hold in non benchmark situations though, need to change the benchmark to use more realistic message sizes first

[dignifiedquire]

Doing some more digging I found out that most of the time is spent in doing AES CTR in the browser, which is to be expected, given that it is a pure js implementation, as webcrypto doesn't support CTR mode.

Looking at the tracer it is very likely that that code can be improved quite a bit though, as it seems to be generating a lot of gcs + new buffer allocations which should be avoidable.

This is using the example from https://github.com/moshisushi/hlsjs-ipfs-loader

[dignifiedquire]

Alright, got rid of the buffer creation + gc issues in aes-ctr: https://github.com/crypto-browserify/browserify-aes/pull/48

[dignifiedquire]

Modified demo with improvements: https://ipfs.io/ipfs/QmdBZhDLEsooVKkmgRgNzjo2JirSbddp8FvnccJ4c2orH2/

[moshisushi]

WIP pull request here: https://github.com/ipfs/js-ipfs/pull/947

Definitely interesting comparing the performance of that one:
https://ipfs.io/ipfs/Qmf5bNjseYcCtpuWZ5urjLgjxCy6ED6nqXGeYEDSMEhv34/

to @dignifiedquire's demo above. Seeing a massive improvement over here at least!

[daviddias]

Amazing! Thank you @dignifiedquire and @moshisushi :)

[dignifiedquire]

Good news with https://github.com/libp2p/js-libp2p-crypto/pull/104 I am able to reduce the "slow" methods to validateCIDand pure cbor decryption :)

[dignifiedquire]

I spoke too soon, the above profile is from when the content is already stored in cache

[moshisushi]

@diasdavid Added a README to the PR now (0% proof reading at this point): https://github.com/moshisushi/js-ipfs/tree/master/examples/browser-video-streaming

Wasn't sure if you still wanted a discussion about performance in there (so I mostly left it out for now), or if that could go elsewhere.

[Beanow]

I'm working on a very similar project, it's inspired by the old Grooveshark broadcasts feature.
With https://github.com/ipfs-shipyard/ipfs-pubsub-room/ I send coordination messages for leader election, syncing playlists and playback position. And straight IPFS files for data transport. (Though HLS looks very interesting to do chunking, I'm currently fetching the whole mp3/ogg file and turn them into blobs as a proof of concept.)

Even with recent performance boosts, secio still appears to be the greatest performance offender. However I might have my topology wrong and be getting excessive chatter between peers. Having 1 host and 1 listener generally works well enough on a desktop. A phone will struggle with either of those though. It's when I add more listeners, say 4, that it starts crashing chrome tabs and makes firefox freeze within a minute or 2.

There's a lot more moving parts in my proof of concept code, so it might be tricky to profile. Perhaps it can make for a good stress test though? A recent build: https://ipfs.io/ipfs/QmYHgYysnGmiEc7f8CSzoNiJYyJoXS15eP9kaQNdZKReSs/

1. Wait for leader election to select a host.
2. If the host is you, you'll have a red "ON AIR".
3. Use the file picker to add an mp3/ogg to the playlist.
4. Open another instance to listen, it should mirror what the host does and fetch files in the playlist.

[mitra42]

One performance issue I'm seeing is inability to seek, but I see references to seeking above, so I'm wondering how people are doing it in a browser - the other libraries I've used see the Video tag calling back to a createReadStream(opts) where opts passes start and end vaues, but despite it being a Node ReadableStream there doesn't appear to be a way to get to this "createReadStream" on IPFS ?

[daviddias]

Update here:

• We have a HLS.js example at - https://github.com/ipfs/js-ipfs/tree/master/examples/browser-video-streaming by @moshisushi
• @achingbrain is working on a new one with videostream at https://github.com/ipfs/js-ipfs/pull/1231/files