Feature Request: Multiple Connection Segmented Streaming

other-dev

#1

Hi,

I use Plex quite a lot as I travel on a weekly basis, and one of the things that I unfortunately encounter quite often is how hotels/coffee shops etc typically limit the speed of each TCP connection you open. For example: the hotel I am currently sat in gives you a 3Mb internet connection, however no single TCP connection will actually hit that (each connection is limited to 1Mb).



If my understanding is correct (and please feel free to correct me if I am wrong), when we start streaming a video remotely it gets transcoded into chunks which the client then requests in sequence one at a time. The transcoder itself however will try and encode multiple chunks at once (providing it has the cpu horsepower/cores to do it).



What would be nice (and I know it is a bit of a niche request), is if we had the option for our client to use two or more connections to the server to download either the same stream (i.e. replicating the http range function), or to have it try and download two or more sequential segments at the same time. To be honest I would expect the former is the better approach as it should mean (in theory) that you can stream a video at higher bandwidth without having to rely on the server transcoding multiple chunks at the same time. This would be brilliant for connections where the traffic is shaped per connection, and combining them would give you the aggregate speed.



I know there is an issue that downloading two separate streams of the same segment could mean that enough data doesn't get buffered from steam 1 for seamless playback, however I believe that with the right data rate selected and the right number of streams and chunk size that shouldn't be an issue. Either way it would be a non-default option.



Developers, what are your thoughts?


#2

[quote name='DodgyGeeza' timestamp='1341643058' post='277437']


What would be nice (and I know it is a bit of a niche request), is if we had the option for our client to use two or more connections to the server to download either the same stream (i.e. replicating the http range function), or to have it try and download two or more sequential segments at the same time. To be honest I would expect the former is the better approach as it should mean (in theory) that you can stream a video at higher bandwidth without having to rely on the server transcoding multiple chunks at the same time. This would be brilliant for connections where the traffic is shaped per connection, and combining them would give you the aggregate speed.

[/quote]




This might actually be easier to build as a stand-alone tunneling tool. You could tunnel an arbitrary number of TCP streams though an arbitrary number of transit streams to obscure the underlying content from stream-oriented shaping tools. Think UDP-encapsulated IPSec, but with randomized source port numbers. Put one of those on either end and you wouldn't need Plex or any other app to specifically support whatever multiplexing or de-multiplexing scheme was appropriate for your current connection; just route traffic through the tunnel and apps will get magic multiplexing (or de-multiplexing if desired).



Alternatively, any byte-range-capable HTTP proxy in front of Plex would give you the server-side support for this without the PMS needing to know a thing about it, and probably without any special configuration in the proxy -- the initial request would trigger the segment transcode, which would be cached by the proxy almost immediately after it was available, and later byte-range requests would be filled by the proxy as normal. The client would need some modification to use it efficiently, but that's something you could fake with a fairly simple proxy on the client -- tell the Plex client to use a local SOCKS proxy and have that proxy issue the initial request, wait for data to start streaming back, then issue a series of byte-range requests to multiplex the transfer of the (now cached) segment.


#3

I have to second this request. And if anyone knows of anyway to get this to work by other means please do tell...



I have a 100 mbit uplink, but single connection speed is severely limited under some circumstances.



So... BUMP!!!!


#4

+1 for the request.



You may want to post this in getsatisfaction if you have not done so already.


#5

I would like to +1 this request.


This would really help with ISPs that place per connection limits; and also in high Bandwidth Delay Product environments.


#6

I'm sorry to bring this back from the dead, but this is the only thread related to this that I could find.

Has anybody by chance had success with this type of approach? I have a remote server.

This might actually be easier to build as a stand-alone tunneling tool. You could tunnel an arbitrary number of TCP streams though an arbitrary number of transit streams to obscure the underlying content from stream-oriented shaping tools. Think UDP-encapsulated IPSec, but with randomized source port numbers. Put one of those on either end and you wouldn't need Plex or any other app to specifically support whatever multiplexing or de-multiplexing scheme was appropriate for your current connection; just route traffic through the tunnel and apps will get magic multiplexing (or de-multiplexing if desired).

Alternatively, any byte-range-capable HTTP proxy in front of Plex would give you the server-side support for this without the PMS needing to know a thing about it, and probably without any special configuration in the proxy -- the initial request would trigger the segment transcode, which would be cached by the proxy almost immediately after it was available, and later byte-range requests would be filled by the proxy as normal. The client would need some modification to use it efficiently, but that's something you could fake with a fairly simple proxy on the client -- tell the Plex client to use a local SOCKS proxy and have that proxy issue the initial request, wait for data to start streaming back, then issue a series of byte-range requests to multiplex the transfer of the (now cached) segment.


#7

So I know this is once again an old thread and I'm resurrecting it, but since plex never implemented this feature and It doesn't look like anyone found a solution, @profplump (most of his post is over my head) mentions:

any byte-range-capable HTTP proxy in front of Plex would give you the server-side support for this without the PMS needing to know a thing about it, and probably without any special configuration in the proxy -- the initial request would trigger the segment transcode, which would be cached by the proxy almost immediately after it was available, and later byte-range requests would be filled by the proxy as normal

While I am not really sure how to set this up on the server side...the part he talks about the client side here:

The client would need some modification to use it efficiently, but that's something you could fake with a fairly simple proxy on the client -- tell the Plex client to use a local SOCKS proxy and have that proxy issue the initial request, wait for data to start streaming back, then issue a series of byte-range requests to multiplex the transfer of the (now cached) segment. 

I think is already easily implemented with a google code project called jspeedstreamer.  I used to use it for streaming plugins in XBMC since I could never saturate my home broadband with just one connection to the (flakey) servers most of those things used.  It worked great, and since its java I would think it should work on any platform...now I just need to find a "byte-range-capaple HTTP proxy" and I'll be all set


#8

I am super keen to have this implemented. I have a 100mbps line, but at night can quite often only get 3mbps to my server on one connection. If I open many connections, I can max my line out. This would be so helpful it's not funny!


#9

+1

ISP's use tcp reset's to set downloads speeds to 3 MB!

multi connection is needed for WAN environments.


#10

I would like to +1 this request.

Please asap !!!


#11

 +1

Please as soon as possible :)


#12

+ over 9000!!!

This would make running Plex on a VPS within the EU 1000x better.  

P.s.  Has anyone found a manual way to accomplish this that they would like to share? 

EDIT:  I made a similar request over in the Plex Pass request section.  If you are a Plex Pass member, head over there and vote.

https://forums.plex.tv/topic/145313-request-multi-segmented-streaming-ideally-to-speed-up-remote-streaming/


#13

+1


#14

+1
with 1 connection I can rarely download anything with more than 30 Kbyte/s, but with 3-5 connections it works alot better (over 100 Kbyte/s).
I think youtube implements this, because I can watch 480p without any problems, but when it comes to plex even the 320 kbit/s option always needs to buffer and stutters.
My remote Plex server has a 40 mbit/s upload connection and i5 6500 processor.
So it's clearly the problem of having only 1 TCP connection.


#15

+1 for implementation! Would make plex significantly more stable.


#16

This is probably my biggest feature I need. I have 1GBps available upload bandwidth, and each conneciton is being limited to about 13Mbps for some reason.


#17

+1 !!!
Would be really great addition to plex.


#18

+1!!!
I have a VPS on France and I’m from Brazil, the maximum stable upload speed I can get is about 2 Mbit/s, but my server has a connection of ~8 Mbits/s to Brazil:
$ speedtest-cli --server 3065
Retrieving speedtest.net configuration…
Retrieving speedtest.net server list…
Testing from *** (***)…
Hosted by TIM Brasil (Rio de Janeiro) [9176.39 km]: 222.252 ms
Testing download speed…
Download: 12.59 Mbit/s
Testing upload speed…
Upload: 8.50 Mbit/s


#19

BUMP. With the addition of 4K content, this will be necessary. I have a 1 gigabit upstream pipe, and can’t stream 4K to anyone.


#20

+1
bandwidth delay product and long fat networks are killing plex for me