Comment 107 for bug 339772

Revision history for this message
In , Chris Hubick (hubick) wrote :

(In reply to Comsultia, Ltd. from comment #99)
> would be nice have supported torrent protocol in HTML5 video tag:
> <video src="torrent://">

I would like to see this too, but also supporting the new "magnet:" style torrent links.

Discussion proposal, answering questions raised by bug 203571 comment 13:

I think, regardless of protocol, referencing *any* file over a certain size within a video (or img, etc) element could result in the opening of the download manager, with that content being added to the active downloads (giving the user some opportunity to cancel the operation), ie, what happens if someone does <video src="http://2_gigabyte_video.webm"> on a HTTP/1.0 server that doesn't support range requests? I would expect any large content being downloaded could be shown in the download manager and also play within the page element as that data becomes available. I would expect such downloads to be automatically be terminated if the user navigates away from the download-spawning page.

I think, again regardless of protocol, the Firefox video UI displayed within the page has/needs some way to provide status for buffering, streaming stalls, etc, and the page level torrent UI could be handled using the same mechanism. I don't think elongated startup display times would be a problem as long as the user is provided status information ("connecting to server/tracker...", "downloading/buffering...", "estimated time till playback begins: unknown/1 minute", or some such).

Similarly, I would expect referencing a torrent file from a video tag to result the download manager being opened and having that torrent added to it's active downloads. I would expect the embedded torrent client to have user prefs for seeding/sharing/ratio/lifespan, like any other torrent download software. I would expect the embedded client to be patched with the ability to attempt to download chunks somewhat in order (ie, try to download the beginning of the video first).

If there is a 10MB video on a page, regardless of whether you watch the whole thing or just the first 10%/1MB before navigating away from the page, I would expect the torrent client to seed the content you did download until you reach the regularly configured share ratio. And, again, I would not expect any remaining content to be downloaded after you navigate away from the page, unless you resume the downloaded manually within the manager, perhaps so you can save the content upon completion for later viewing.

Video content is becoming increasingly popular on the web, and users today are confined to big providers like YouTube who can afford the servers and bandwidth required to support distributing such content. This restricts the ability of small individuals to create and distribute large multimedia content. While embedded torrent support might not be as seamless/ideal as other mechanisms, it does give *everyone* the freedom to become their own YouTube, and I hear that's what Firefox and the Open Web are all about.