Peertube: Support for scalable video ?

[inkhey]

SVC video are a great feature for normal streaming website in order to adapt content to user bandwith,
it seems to me really important that peertube support this kind of feature.
Don't know how difficult it can be to do this in peer to peer.

Some links :

https://forum.bittorrent.com/topic/29889-bittorrent-scalable-video-coding/
https://pdfs.semanticscholar.org/ea81/c29cac62cda6104432ca90040d7fdc0637b8.pdf
Edit: Not sure this link use scalable word as referring to "SVC" Video : https://github.com/bradparks/nile.js__Scalable-peer-to-peer-live-video-streaming-built-on-torrents-and-webRTC

[Chocobozzz]

SVC seems great but unfortunately it doesn't seem to be supported by web browsers.

For now we generate multiple resolution files (so 1 torrent per resolution), and the client choose its definition -> we have 1 swarm per resolution. It's not ideal but better than nothing.

[inkhey]

As far as i understand, firefox and chrome support SVC for VP8 temporal (aka framerate) scalability. (VP8 doesn't support other kind of scalability). i do think it's a bit more complex than just framerate, as i understand this technology, frame are create in order to match the most correctly without some frame.
https://bugzilla.mozilla.org/show_bug.cgi?id=1343143
Not sure if temporal scalability is very useful for replay, but if peertube plan to support livestream, that's important.

For vp9, which support also quality and spatial (aka size) scalability, the feature exist in chrome. Don't know if is it activated now. You can have all these feature at the same time in fact.
https://webrtchacks.com/chrome-vp9-svc/

SVC required also special encoding (SVC file is a bit bigger than AVC, standard equivalent) and of course special filetype, that's why vp8 (and soon vp9) should be the preferred format of transmission.

[arthurlutz]

@Chocobozzz "we generate multiple resolution files", I don't seem to be getting this on a dev installation of peertube (the one from PeerTube-Docker), is this documented somewhere ? Is there an option ? Does it require additional software ? Is it only available for certain types of formats ?

[Chocobozzz]

@arthurlutz This is opt-in.

https://github.com/Chocobozzz/PeerTube/blob/develop/config/default.yaml#L46

[nyanloutre]

Maybe this Javascript library would be of some help : https://github.com/Dash-Industry-Forum/dash.js

It's entirely client-side and you only need to generate the video properly with ffmpeg

[Chocobozzz]

I think we can close this issue since the server generates multiple video definitions and the client handle them.

[MayeulC]

@Chocobozzz This seems like a potential game-changing improvement to me.

I am no specialist, but as far as I know, scalable video coding (introduction) allows to store multiple streams with different resolutions (spatial) or framerates (temporal), for a marginal increase of file size, and a few improvements can be gained from that (it seems like you are already aware of most, though):

So, we already have a way to work around that basic problem, so why is SVC important?

• The same video file is used for low quality and high quality peers, which increases the number of potential peers
• The same stream might be (I don't know enough about this) distributed via multicast to viewers with different quality settings
• A low quality stream can be upgraded to a higher quality one, or downgraded seamlessly, depending on available data.
• This also allows playback to start much sooner, as the low quality part is quickly downloaded.
• This might probably help if PeerTube goes down the livestreaming road at some point.
• Low-quality keyframes could be used to generate thumbnails for the progress bar
• The low-quality stream could also be used to animate the regular video thumbnails in the search view, while contributing back useful data.

Consider the following use case: 5 people are streaming a video, two of them with a lower quality setting. Currently:

1. High quality viewers exchange data with the server and together. The server has to send at least one full high quality file.
2. Low quality viewers likely have less bandwidth, and more troublesome is that they typically have less peers to exchange with, making things worse.

Now, with SVC:

1. Every user receives the full low-quality video first, this part could even be prioritized for uploading on every video. Every peer can participate in the exchange.
2. Peers that would like a higher quality video can get it from the server, and exchange pieces between them as they are made available
3. As every player starts with a low quality video, playback can start much more quickly, and without annoying buffering, and improve the resolution as needed.
4. If the bandwidth drops (mobile connection cut/downgraded, etc.), the video can fall-back to a lower quality video.
5. No buffering should be ever needed when downgrading video quality.

Note: (3) could be configurable as an "auto" option like on YouTube: if the user selects a quality, the client would wait for the video to be fully buffered before unpausing it.

In my opinion, what makes SVC a strong fit for PeerTube, much more so than the other platforms, is that it makes every client download the same and unique file (or parts of it), which is nice for torrenting.

---

Now, on the downsides:

• SVC is widely less known and understood than more classical video formats
• Being less known and used, it might have less support from players and converters
• Of course, this is more work to implement, etc

But in any case, I don't think that having multiple video files quite solves the same problems, so I wouldn't have closed this issue ;)