81–90 of 96 posts
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?
Tribler ( http://tribler.org/ ) does this, but it receives much less publicity.
Earlier quoted context omitted.
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
Looks okay to me. Do you have a pony in this race?
Earlier quoted context omitted.
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
I dunno, it seems to me Yify's torrents are a great balance of file size and quality.
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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).
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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, b…
It's a handful of bytes per segment. Plus you can use SCTP with essentially no overhead. Emscripten uses it to emulate UDP.
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 need…
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 i…
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/
Earlier quoted context omitted.
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, b…
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 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...