Webtorrent scaling, streaming

[klonodo]

1. It would be nice to have a tool to make .mp4 meta file readable by webtorrent and functionality in webtorrent that would check in the list of files in current torrent file, if file named for example 'meta.info' exist, if true then seeking could be enabled.
2. When streaming into tag will be implemented into browser webtorrent client? Could you provide some ETA please?
3. From what i see webtorrent is using websocket tracker. On daily basis i have around 200k peers. Normally if i set interval of announce at minimum 15 minutes then i have around ~222 announces per second, so i have 222 connections a second, so i only need resources for around 200-300 connections at any time for tracker. Current design of webtorrent make me need resources for 200 000 connections via websockets.
   You wrote that " * This is necessary to facilitate the WebRTC signaling (peer introduction) process."
   Can we offload peer introduction to clients making ajax calls instead of using websockets?

[feross]

Thanks for opening this issue and asking such excellent questions.

1. @jhiesey had some thoughts about how to make mp4 seeking work. We've discussed different approaches at length. I know he's currently busy, but he might be able to implement this in the coming months.

2. I'll work on building tag streaming directly into the webtorrent module this weekend. It's not that hard to add.

3. Eventually, we want to use a WebRTC DHT to lighten the load on webtorrent trackers, because you're right. They don't scale as well as bittorrent trackers.

   With a bittorrent tracker, the server can just give out peers' IPs and ports (1.2.3.4:6666) and the requesting peer can connect directly. That's it. With WebRTC, there's a signaling process (see this slide to get an idea) where the tracker server needs to actively push data to both peers in order to connect them. For the requesting peer, that's easy. It could just use XHR. But for the peer that's being given out, the server needs to push signaling data to it, and it needs to send a response back through the tracker to the other peer. Only then can they connect directly.

   Unfortunately, I don't see a way to make this part scale better. If anyone has ideas, please share.

[yipperr]

@feross
how is the signalling needed for webrtc to connect peer to each other after the tracker announce implemented i din't find any write up on the webtorrent protocol (by this i mean the how webtorrent protocol is written not the webrtc signalling which is already document obviously) so lot of it is just in my head it will be cool if u had a page where the current model for the webrtc protocol is written up so people can voice their own views and change as required

[feross]

The webtorrent tracker is basically a webrtc signaling server. You can read about webrtc signaling here: http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-signaling or you can watch me talk about it here at LXJS: https://www.youtube.com/watch?v=QpQhR9fBNnk#t=18m45s

Writing up a spec is on my todo list.

[yipperr]

can video sources using the mkv container playback on video tag because many of the higher quality torrents use this container they seem to be the preferred choice for the major uploaders

[nextgenthemes]

As I understand it browsers do support webm and this seems to be a "sibling" of mkv. I have read something about it but I am not sure what the exact deal here. Is it the same with a different header or does it just only support VP8 as codec?

http://www.matroska.org/news/webm-matroska.html

http://www.webmproject.org/code/specs/container/

https://bugzilla.mozilla.org/show_bug.cgi?id=476727

Most mkv videos on bittorrent use h264.

h264 support on firefox desktop is "platfom dependant". For Ubuntu for example it is not supported by default but you can enable it http://askubuntu.com/a/389439/195243

There is also the fact that firefox 33 supports a OpenH264-Videocodec plugin for webRTC videochat now but not normal embeded files. http://yro.slashdot.org/story/14/07/23/1312227/firefox-33-integrates-ciscos-openh264
So I guess this will apply so Webtorrent as well so this issue about mkv supported or not will probably just end ups to what codecs are acually inside it. Maybe all it needs it to declare the video as webm even if it a mkv maybe the header has to be rewritten on the fly but my guess is that plenty of h264 encoded torrents will stream just fine if its ready.

So exited about this, sorry if this went a bit offtopic here.

[klonodo]

@feross

I see. I supose It needs introduction mostly because of safety measures, as doing it other way would be unsafe like allowing browser to open and listen on sockets. Design of introduction is very similar to FXP in FTP protocol.

@yipperr

Currently video tag doesn't support mkv containers.
It supports ogg, webm and mp4 only.
Webm supports VP8 and VP9 codecs.
MP4 supports H264.
OGG supports Theora.
Another thing is that mkv is not about better quality, but about functionality of this format (multiple streams of video/audio/subs). MKV movie quality can be the same as MP4 quality, as they can have identical video streams.

@nextgenthemes

It's not about codecs, it's about structure of file formats. Current design will not parse mkv containers properly. mkv allows multiple video and audio streams while mp4 doesn't allow that.
Structure of both of that file formats is different. Currently there is no way to support mkv format in browser without third party plugins. It will stay like this until W3C will change that by making mkv support as a standard.

[yipperr]

@klonodo
see that's my point almost all of the torrent being released now use mkv to take advantage of the subtitle and other functionality and since google has deprecated the npapi none of the third party players can stream these video files in browser

vlc summer projects mentions about a rewrite for the vlc media plugin to ppapi but i dnt think there is any progress
https://wiki.videolan.org/OPW_Summer_2014/#Port_VLC.27s_NPAPI_web_plugin_to_PPAPI

also i realize this does not concern webtorrent so much but since one of the goals for this project is to facilitate streaming this should be of some importance but like klonodo said only way to parse mkv will be through third party extension because browser won't really feel the need to do so support mkv parsing

[feross]

Okay, a basic version of streaming into a video tag is implemented now. Here's how to do it:

var WebTorrent = require('webtorrent')

var client = new WebTorrent()

client.download(magnet_uri, function (torrent) {
  // Got torrent metadata!
  console.log('Torrent info hash:', torrent.infoHash)

  // Let's say the first file is a webm (vp8) or mp4 (h264) video...
  var file = torrent.files[0]

  // Create a video element
  var video = document.createElement('video')
  video.controls = true
  document.body.appendChild(video)

  // Stream the video into the video tag
  file.createReadStream().pipe(video)
})

[feross]

Currently, this is making very specific assumptions about the codecs. If the extension is webm it assumes the type is video/webm; codecs="vorbis,vp8". If the extension is mp4 it assumes video/mp4; codecs="avc1.42c01e,mp4a.40.2". This is for purposes of using the MediaSource browser API.

Obviously, this might not be correct for many files. We need a good way to discover what the type is on-the-fly.

If you're looking for some files which have said codecs, test with these:
https://dl.dropboxusercontent.com/u/1780186/BEST_DUBSTEP_CAT.webm
https://dl.dropboxusercontent.com/u/1780186/BEST_DUBSTEP_CAT.mp4

I figured out what values to use with MP4Box, but we need something written in JS that can figure out the type using just the first bit of the video file, so that streaming will continue to work.

[feross]

To test this out, make sure you're using webtorrent 0.10.0.

[feross]

Support added in a0d3ba2

[yipperr]

@FerrOS

here are test files of most containers and format from the yify team
http://us-chi.cdn.ptn.pm/nwtests/

[yipperr]

and it appears there is a modified webkit used by popcorn time that can parse the mkv container

[thibauts]

I've heard mkv and webm are very close in structure. Have you tried to play a mkv forcing a webm content-type ? (with the right audio and video codecs inside of course)

[feross]

Video streaming arbitrary MP4s into the <video> tag is now possible, using the videostream module by @jhiesey. This module repackages the MP4 or M4A on-the-fly in JS so that it can be played back by the MediaSource API in the <video> or <audio> tag. videostream is build on top of a forked version of mp4box.js.

videostream isn't built into WebTorrent directly yet, so you can't just use the file.createReadStream().pipe(video) API. You can see an example of how to use it here, and it's running live on https://instant.io right now!

@klonodo's original issue is now resolved, so I'm closing this.