[idea],[proposal] Pseudo Blob (for video not getting stuck)

[kocoten1992]

What is it? Why?

Let's me give a demo:

1. Video webtorrent: https://www.youtube.com/watch?v=M-ClDIiDm9Y

Sometime it will stall (happen much when seek very far distant on a long video), even when video have been fully download (129/129 MB).

2. Everything was in blob: https://www.youtube.com/watch?v=QXNXp2Fr7XM

Seeking work flawlessly, Blob will allocate a block of data on your memory, result in very fast seeking.

Currently there is

file.getBlob(function callback (err, blob) {}) //(browser only)

and

file.getBlobURL(function callback (err, url) {}) //(browser only)

But both required when the file have been fully download, meaning I can't use that api for blobURL for video as soon as I want, then I would like to proposal pseudoBlob.

Mind this (got cha)

Because Blob will allocate in memory, we need to carefully treat it especially at large video (2GB or up), have a read at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management

We can trick garbage collector to delete what we don't want anymore (It might not immediately release memory, but after some seconds (0-5s), generally it work, but consider this some seconds factor).

Proposal

Before spending lots of time on something, ask for feedback on your idea first!

Thing might not work, but here is my proposal:

-We will create pseudoBlob base on torrent's file size.
-When more data come, we slice and recompute the pseudoBlob.
-At any given time, we can provide user a getPseudoBlob and getPseudoBlobURL.
-When the file is fully download pseudoBlob will become true Blob.

When seeking video on pseudoBlob, if data haven't download yet, it will jump to to the closet valid data, and because it is blob, video will not getting stuck :). What do you think about this?

[feross]

I was telling @jhiesey about this issue and he just debugged for the last few hours and found a really subtle bug in videostream. Basically we're piping a file stream from webtorrent (file.createReadStream()) into TWO writable streams, one each for video and audio, that get passed into tracks in the MediaSource API. But we think that whenever either the video or audio writable stream applies backpressure, then the file stream from webtorrent is pausing.

That means that if the video writable has too much data it could apply backpressure and potentially starve the audio writable from the data it needs. Then the whole video tag will stall.

We're now creating a file stream for each media track and the problem seems to be gone!

New version of videostream incoming!

[feross]

@kocoten1992 Also, thanks for the proposal, but I think we should fix this at the source.

[kocoten1992]

@feross glad to hear that, I thought this is about html5 video feature and can't be fix, let this issue live for a while longer, I'll test if videostream new version fix it and will close the issue 😄.

[kocoten1992]

Wonderful, it seem it really gone.

Got a question, did I have to do anything other than:

file.appendTo(rootElem, [opts], [function callback (err, elem) {}]) //(browser only)

file.renderTo(elem, [opts], [function callback (err, elem) {}]) //(browser only)

Cause, when looking around I saw no videostream in package.json, where is it ?

[feross]

Yes, that's all you need to do. We depend on render-media which depends on videostream.

render-media handles all the different video playing strategies: videostream, mediasource, and blob url.

[lock]

This thread has been automatically locked because it has not had recent activity. To discuss futher, please open a new issue.