When evaluating IPFS for a video platform I am thinking on some functional design requirements that could be tailor made for IPFS. I would like to receive some input on those subjects.
Videos for the web are typically made available at an adaptive bitrate. Two standards that come to mind are HLS and MPEG-DASH. They both segment videos in smaller pieces, and allow the end user to ‘choose’ at which quality the video is displayed, or let the player guess which quality should be downloaded. While such HLS or MPEG-DASH approach could be replicated using IPLD they are still based on the core idea of having multiple variants of the same, rather than ‘more data for better quality’.
IPFS natively would split a large file in several blocks. I wonder if with a more intelligent segmentation approach, the most naive thing for video would be key frames, IPFS could intrinsically support common features of a video player.
I would like to take this one step further. In image encoding wavelet transformations allow encoding from a more generic to specific. If this could be employed where the file is ordered in IPFS blocks from less complex to more complex, the player would receive a list of blocks being key frames, and by that list decide at what level of detail it would download the individual blocks.
I wonder if people would like to discuss this approach.
IPFS split data into blocks for easy transportation and deduplication, this size is fixed and quite small. It’s make blocks unsuitable for audio/video chunking. At first glance IPFS chunking and video segmentation seams like the same but in this case they serve very different purpose.
Had to search wavelet compression but from what I understand there’s no good implementation yet and browsers don’t support it.
Would be fantastic to just add data to get more quality but seams like it only exist in idea form right now.
@SionoiS it seems that a block can be variable but < 256kB. Could you point to documentation which states differently? Wavelet video codecs are not theoretical, Dirac, VC-2 (DiracPro). I agree that browser support may be sparse, but that is something solvable if we come up with a killer application.
It is not about alternative services for file storage or decentralised encoding. The point of this discussion is in the direction: what can be designed to have an media container format that is IPLD aware, and uses that in its advantage.
I created ipds video to showcase the mediasource api combined with ipfs-js. There is also an ipfs backend for the hls video player. The means that you could do adaptive bitrate by having the client pick the quality stream they like.
I don’t really like this solution as the serving party has to do recoding for different quality levels, and I think we should try to come up with a solution where this can distributed to the client.
For ipfs.video I choose to highlight webm vp8 and opus for streaming and that seems to be fairly well supported by browsers. Next up for me is content indexing, then majority signed recoding (however the problem here is that most recoding is non-deterministic, making it impossible for two parties to agree on the hash of a recoded video).
I don’t really like this solution as the serving party has to do recoding for different quality levels, and I think we should try to come up with a solution where this can distributed to the client.
I share the same opinion. It would be the status quo but stored decentrally at N-times the original size in order to facilitate the different variants. I think there could be a case to be made where each recording would be a new resource, linked from the main resource, but I would like to leapfrog that by the ability to have graceful degradation of the content.
Are you aware of the ability to align vp8/webm with the IPFS blocksize in order to implicitly get indexable starting points at keyframes?
No, sorry. I have no idea wether that would be possible or not. The formats are open, so you should be able to educate yourself and find out wether this would be possible. My guess would be that you should be able to get more efficient seeks if your chunks align with elements from the container, but I would be surprised if the whole optimization would end up doing a lot. As the container already has fast indexing support, the perofrmance hit of missing a single chunk by a few bytes (resulting in needing more chunks) is probably not that important.
Having the decoder aware of how to split up make sure not to request everything… I really don’t know but it sounds way more complicated than just having the same file encoded with different quality formats collected in the same ipfs unix fs node
I must also educate myself on IPFS-blocks. If it is possible to ‘stream’ the content of a single block before it is fully available at the node.
I really don’t know but it sounds way more complicated than just having the same file encoded with different quality formats collected in the same ipfs unix fs node
Isn’t that just a general thing: everything is complicated until you actually do it? Reminds me how years ago we required webserver voodoo to allow MP4 seeking, while now that code is implemented in the client (javascript) and the only thing a webserver has to support is the range query, which it already supported from the start.
The bandwidth saving would not be huge (such format would be less optimal in quality than a lower bitrate encoding specifically targeting that bitrate), the storage saving would be huge, because it would not require recoding for each variant.
Here’s a YouTube video presentation of video streaming over IPFS that I was thinking of that you might be interested in Live Streaming Over IPFS - YouTube
