Realtime streaming from torrents in the browser | Hacker News Reader

Realtime streaming from torrents in the browser

iflix.io

138 points0x413991 comments

This is neat, but what we really need is BitTorrent over WebRTC, for actual decentralized BitTorrent in the browser. See http://webtorrent.io

The project's goal is to build a browser BitTorrent client that requires no install (no plugin/extension/etc.) and fully-interoperates with the regular BitTorrent network. We use WebRTC Data Channels for peer-to-peer transport.

WebTorrent is designed to match the BitTorrent protocol as closely as possible, so when the time comes, existing BitTorrent clients can easily add WebRTC support and swarm with web-based torrent clients, "bridging" the web and non-web worlds.

WebTorrent is already working as a node.js bittorrent client (just do `npm install webtorrent -g` and use the `webtorrent` command), and as a web-based client (though the docs for this latter part are currently very lacking -- this will improve in the coming days!).

Nice! Why not create a different protocol then if they're not yet compatible? Adoption for a browser-based p2p streaming tool should be seamless. If the only problem is BitTorrent integration, go your own way.

ps: your site seems down.

Site is back up! I set up TLS today and made DNS changes. :)

> Why not create a different protocol then if they're not yet compatible?

I want existing bittorrent clients to add WebRTC support. The task of convincing the existing clients to do this will be a lot easier if the protocol is unchanged except where absolutely necessary to accommodate the WebRTC signaling (peer introduction) process.

I don't want to get distracted by trying to improve the BitTorrent protocol itself. It works quite well, despite not being the most elegant for implementors.

The site is down now. Did they kill it already ?

Would you happen to have a working demo of the webtorrent.js in the browser?

Check out http://instant.io which is powered by WebTorrent

The strength of Bittorrent comes from the network. If you start with little to no peers, you will have a hard time convincing users to migrate. If you can leverage the existing Bittorrent network, you will be able to build something meaningful much more easily.

And the likelihood of that integration is unlikely. Just because WebRTC operates over TCP does not mean it acts anything like a proper TCP socket. There is an unbelievable amount of overhead involved, not to mention how reliant most modern torrent work can be on UDP nowadays. It simply can't scale, it might be good enough, but it can't scale. In-client WebRTC 'support' would nearly mean an entirely different stack, built on WebRTC's clunky non-standards and take years of proper testing. Why go through the effort? And hell, torrent clients are bloated enough already.

And let's not even get started on the comparable differences in security (personal or code-wise) when running this all through Javascript training wheels, then through the browsers' secret optimization sauce, browser/plugin fracturing, then through the gamut of ads, fingerprinting, cookie drops, and who knows what else kind of tracking can be slipped in from here forward... Let's call it what it is; a cool, non-commercial, in-browser p2p file sharing protocol, not BitTorrent.

Just to further this point: AFAIK, The BitTorrent protocol was not designed in order to stream content in any kind of order. I think the emerging P2P web technologies is good opportunity to iterate on BitTorrent and design a better-fit protocol.

Bittorrent the protocol was built so that you can fetch any part of the content in any way order you want (that's the beauty of it: traditional forward streaming is not different than out-of-order streaming)

Bittorrent the network, now, lives because peers have an incentive to behave correctly and spread the content on nodes as much as possible. It's a specific use of the protocol, but not the only one. The problem is that many people (even technical) conflate the protocol with how it's used the most: spread stuff illegally. In order to do this there is a need for peers fetching parts out-of-order. But if, say, Netflix were to distribute its content over Bittorrent, it would be perfectly fine to stream in-order, because the Netflix peers all have all the content so there is no need to spread the content here.

And there already is an enhanced protocol, in the IETF pipeline: PPSP [0]. It integrates a lot of good things that were incompatible with Bittorrent yet desirable. It's also called swift (before it was cool), and has 2 implementations [1] [2].

[0] https://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protoc...

[1] http://libswift.org/

[2] https://github.com/skunkwerks/swirl/

Correct, it was not. Though even a moderately healthy swarm today can easily stream (prerecorded, this is important) linear content. It's a lot easier now that residential bandwidth and seedboxes are so prevalent.

> There is an unbelievable amount of overhead involved

It's a handful of bytes per segment. Plus you can use SCTP with essentially no overhead. Emscripten uses it to emulate UDP.

So (in theory) I can upload this to my server and stream content from torrents straight out (since I'm on lousy ADSL while my VPS sits on ... well a way faster connection)?

If that's what these guys after, that's amazing :-)

I created (and later closed) a similar service using mega.co.nz instead of torrents. The main problem I see with your approach is that you serve video from your server (and presumably do the torrent fetch server side). This opens you up to liability, makes you responsible for DMCA take downs and puts the workload on the server.

In contrast NimbusVid was entirely client side. The drawback was that the source data needed to be a web friendly seekable format; you couldn't play an arbitrary video file.

This one is client-side:

http://www.popcornexpress.me/

It uses Bittorent's Torque plugin.

http://blog.bittorrent.com/2012/07/06/introducing-bittorrent...

Of course at that point you might as well install the real thing, rather than a plugin. It's a shame there isn't a standard web-based torrenting protocol. I imagine it's technically pretty hard to do, but even if it wasn't, now that MPAA is on W3C's board and owns it, and with Google, Microsoft and Apple also being in bed with them, there's slim to zero chance such a protocol will ever become reality.

" there's slim to zero chance such a protocol will ever become reality."

Even if you think that, I don't think you should say it out loud. Lots of great things were created because people were dumb and tried to do the impossible. There's too much gloom and doom and I think that's putting people off. Not to say that we shouldn't highlight the issue, just more in a positive light i.e "X is really tough, but if it's done this could change the Y landscape"

Merely my opinion, of course.

I am building a browser-based bittorrent client. Check it out: https://github.com/feross/webtorrent

WebTorrent makes BitTorrent work in the browser using WebRTC. It's designed to match the BitTorrent protocol as closely as possible, so when the time comes, existing BitTorrent clients can easily add support for this extension and peer with web-based torrent clients.

Torque is an absolute piece of steaming manure imo. A torrent client running any time you start your browser with no GUI? how many torrents are seeding? when does it start / stop? What's the bandwidth throughput how do i turn it off?

One thing that's good that came from torque though is BitTorrent's RPC api (originally known as BtApp.js) , which I reverse-engineerd (Since it's some of the messiest JS code ever) into DuckieTorrent, it works just by passing your browser's torrent tasks to your already existing torrent client: http://github.com/SchizoDuckie/DuckieTorrent/

> The drawback was that the source data needed to be a web friendly seekable format; you couldn't play an arbitrary video file.

Maybe I should revive the VLC web plugin and the torrent input plugin :)

Plugins aren't a great solution, people don't want to install them.

I agree very much, which is why I did not push too much the VLC web plugin. Yet I don't know how to solve this problem, in any another way.

On the other hand, Popcorntime and other soft are getting installed by users, so maybe if plugins are easy to install, maybe they could work... (?)

The "right" way to solve it is for everyone to use seekable MP4 (or seekable WebM), especially since things like Chromecast don't natively support anything else. That's hard to do but possible if you provide a highly desirable service (people will start to complain for torrents in unsupported formats).

WebM and mkv are the same container format.

Popcorntime doesn't open up my browser to security holes for every website I visit.

Every plugin you install increases the surface area for attacks.

Of course. But plugins are now in separated processes and plugins shouldn't autoplay (a contrario from flash).

i was thinking about using the vlc web plugin :) for avi/vmw

Please report bugs :)

China is so far ahead of the west in real-time (and live) peer to peer streaming. Look at video systems like QVOD (now dying after state intervention), Xigua, JJVod: they all have a central tracker and use swarms of users to supply realtime video streaming. PopcornTime was a decent example of this but China's been doing it for years - it was live television streaming over p2p first with PPLive, PPS, Sopcast, etc and this then morphed into streaming of films and television. All use a slightly modified version of bittorrent. Most use bittorrent hashes to mark content.

I still can't understand why this has been Bram Cohen's main focus for the last few years and he still doesn't have a working prototype.

> he still doesn't have a working prototype

I suspect he still doesn't have a working prototype he can safely monetize. I don't think the wants to move to China.

Safe is the word but BitTorrent Inc have a habit of throwing things at the wall to see what sticks. They've released so many little products over the years. Sync is one of the few examples that has gained some traction. I'd have expected some kind of live streaming beta if there was a decent example around. But from what I've read, he seems to want to market it to legit networks and distributors and they are not going to do business with BitTorrent Inc.

Guys I just broke into some guy's house that's known to be suuuuuper litigious. Check out all my selfies!

Just a couple of not-very-deep comments:

The service did nothing at all on Chrome with ad-block-plus installed.

On Firefox the service did show some very nice blue balls moving from left to right after I did a search on some common video content and selected it, but that was about it.

http://i.imgur.com/EGQAKbt.png

What could possibly go wrong?

Awesome idea, but I don't see how this will last very long. I expect your host will pull the plug in a few days to a week, especially if you're opening yourself up to downloading and then hosting the content.

I run www.moviemagnet.net which surprisingly is hosted in the US, but hasn't been taken down yet.

Creator of http://tormovies.org and http://tv.tormovies.org here.

Can I put a "Watch Live" link to iflix.io which would stream the specified torrent (known by it's hash) next to each torrent download button ?

I love the concept, and I think it's wonderful especially for mobile device users...

The only fear I have, as other have noted is that I do really see how you will be able to scale if it takes off, and how you will be motivated to maintain it if it does not :/

Cheers anyway ! :)

sure thing dude, go ahead :), don't worry this is the least of my concerns, i hope it will take off ^^

BitTorrent doesn't order file fragments by design. So how can you stream it without downloading the whole thing first (to the server at least)? Which defeats the purpose of streaming really.

You can. BitTorrent doesn't order file fragments by design, but clients can choose to ignore this and request pieces in order. See Popcorn time and many other implementations out there.

Why don't the other clients in the swarm penalize the client for this behaviour? Downloading all the fragments in order means that if the initial uploader drops off, everyone is stuck.

It kinda works here because the shared files are already very popular, and there's a lot of seeders (ie peers who have 100% of the file and can share any part).

It wouldn't work for unpopular files.

Yes, it goes against the distributed nature of the protocol so I think other clients should penalize such behavior in theory.

You use a client which request fragments in a specific order.

This is not something new.

In FF: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://ec2-54-68-78-110.us-west-2.compute.amazonaws.com/deta.... This can be fixed by moving the resource to the same domain or enabling CORS.

Chrome Failed to load resource: net::ERR_EMPTY_RESPONSE

in p0rn mode just shows the player and nothing is going on.

cors is enabled but sometimes it just hangs because of the traffic http://i.imgur.com/EGQAKbt.png

Haven't got this to work yet. I'd love to see a BT streaming solution not as a centralized service, but as a locally running app. Does such a thing exist?

My personal preferred suggestion: the Bittorrent Channel for Plex[0]. Plex is, effectively, a media indexing, library management, and transcoding daemon, that also provides plug-ins (Channels) to access virtual media items. In this setup, you have a streaming player (e.g. a Roku) and a PC running Plex--you access the torrent through the interface on the media player, and the PC will start downloading and transcoding the torrent and streaming the result to the media player.

[0] https://forums.plex.tv/index.php/topic/102253-rel-bittorrent...

Not possible currently with web technologies because browsers don't let javascript connect to arbitrary TCP servers. The webtorrent project aims to make torrent clients compatible with WebRTC, so when that gets widespread adoption it should be possible.

Tribler (http://tribler.org/) does this, but it receives much less publicity.

Tribler has been around for a long time and it has tons of good research behind it. However, it simply doesn't work. Tried stream a variety of content and it just doesn't show anything unless it's a really healthy torrent which is very rare.

the machine is a 10 dollar digital ocean droplet, it's curently at it's peak, this can be packed(and it will be) with node webkit

I would enthusiastically use this product. Please allow for specifying any BitTorrent file and not just searching Pirate Bay. Kat.ph is much better :)

So, this is a server side solution?

Popcorn Time?

That's close but I want arbitrary BT files, not a hand curated content selection.

You can use peerflix[1] for that, eg:

    peerflix "magnet:?xt=urn:btih:44052304ac07aa461b4828c63c52a44f34df2ce7&dn=FIFA.World.Cup.2014.Group.B.Spain.vs.Netherlands.720p.HDTV.x264-&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337"

And then watch at http://localhost:8888 with your favorite player.

[1] https://github.com/mafintosh/peerflix

In PopcornTime, you can drag and drop arbitrary BT files.

This doesn't seem to work in the latest version.

If you're referring to Time 4 Popcorn, that's not it. It's also malware.

There are now several forks with different features.

Hosed. Getting timeouts for /details. 2 issues in general, though:

(1) The BitTorrent protocol is not hospitable to linear downloading.

(2) Pirated video content is extremely incompatible with browser-based playback... stuff like MKV and AVI containers, DTS/AC3 audio, multiple audio tracks, segmented RAR files.

If this works even for vanilla MP4 content, I will be super impressed - but the browser is the wrong place for this type of media app right now.

EZTV YIFI and many more don't pack anymore the data inside rar files, and it works, you can watch silicon valley from an EZTV torrent from here http://iflix.io/#/play/ef87a3f97c653d487dece0e6ea8e60b7731a5...

Yify torrents are total garbage at any rate, you'd be better off just not watching whatever you wanted to watch rather than stare at the eyesore that is Yify. Seriously, Yify encodes are like watching something through a window coated in vaseline.

http://screenshotcomparison.com/comparison.php?id=87460

http://screenshotcomparison.com/comparison.php?id=10115

Yuck. This is a good example of why you're supposed to reduce the dimensions of the video if you want to reduce bit rate with H.264. If you simply reduce the bit rate, you end up losing detail.

e.g. for a video with a typical level of motion, if you want to achieve 1 Mbps, encoding at 854x480 is going to look significantly cleaner & sharper than encoding at 1280x720 (even when upscaled).

This is why adaptive streaming uses quality levels with varying dimensions. e.g. on Netflix, the low bandwidth streams are not 1920x1080, as that would look like garbage.

Looks okay to me.

Do you have a pony in this race?

No...I'd rather not watch something fuzzy. If you think it looks OK, then you may as well download proper SD rips. They'll look better with less artifacting.

I dunno, it seems to me Yify's torrents are a great balance of file size and quality.

They're a horrible balance, a proper SD rip will look better than a Yify encode

Hmm, at least that link actually shows me a video widget but I still don't see any actual video.

Doesn't work for me, even if I allow Facebook CDN. Search works, but then...

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://ec2-54-68-78-110.us-west-2.compute.amazonaws.com/deta.... This can be fixed by moving the resource to the same domain or enabling CORS.

try again, resized the machine, too many users

Don't mean to hijack the thread, but has any of these stream-from-torrents-services developed any kind of "magnet link metadata database"? By metadata, I do not mean the common torrent metadata, but some kind of queryable index.

What I have in mind would be some kind of mapping between magnet link and themoviedb (or tvdb, musicbrainz id, etc). Seems like an obvious feature for me...

When I can get the page to load (which i assume is due to the HN DDOS of love) i still get "video format or mime type not supported" on Firefox 32.

There's another service that I use that exactly do the same thing and it works well. http://put.io

it's not the samething, iflix.io streams almost instantly (if it wasn't for the huge load)

Well technically it's not but I think the objective is quite the same. It lets me stream video from a torrent.

I can confirm that it works in Chrome. (I tried with a Korra episode. It started playing almost instantly, with a few image glitches here and there.)

For me worked only for 'porn' which had a huge load of seeders. Not for anything meaningful (which doesn't have 2500 seeders...)

Nicely done. A(nother) webapp that refuses to do anything unless you allow it to load facebook's javascript.

it's just react nothing more

I guess an app like this would be better off, if it didn't use the FB servers at all.

i can just take the react lib to host it on my own

that's what I wanted to say :)

Searched and started playing an episode of the Simpsons on my iPhone within a minute. Impressive!

Can you use magnet links?

yes, the id that you see in /details /play is the magnet link unique id

  Uncaught ReferenceError: React is not defined

Make sure facebook is not blocked. Same problem for me since i am running self control.

How long until the creator gets arrested with a full military gear tactical swat team and paraded before CNN as an evil technical mastermind hurting the country's entertainment industry and an interview with MPAA ?

At least use a server located in countries which US cannot freely exercise it's jurisdiction powers to buy you time. Hosting Digitalocean node in Singapore won't help.

To be fair to our protectors,

they don't remember how to serve a warrant any other way.

I hope you have good lawyers.

Reply on news.ycombinator.com