As I’ve written video files can be streamed via Bit Torrent protocol. Although responsiveness (time to start, time to seek) is notably worst that in specialized solutions, it is still usable for normal user, with a bit of patience.

Video files are also provided by file sharing servers,  but in many cases download rate is limited, so it’s not enough to stream video file. However it’s often possible  to open several requests for same file, and combine download rate – this method is quite common in download managers. And if we add possibility to stream downloaded content to video player, we can achieve satisfactory results, possibly similar as or better then streaming via Bit Torrent.

Inspired by my previous work on btclient (video streaming via Bit Torrent protocol), I extended it to stream video also from HTTP source,  with possibility of several concurrent connections.  Video file is divided to pieces (2MB, similarly to BT) and pieces are downloaded by concurrent connections as needed.

In order to enable seeking, pieces are scheduled in priority queue (heap),  with a piece at current playing point and next few following  pieces having highest priority (similar to piece deadline in libtorrent – priority set concept explained in previous article ). Otherwise pieces are downloaded sequentially.

General principle of client operation is:

• Start first connection, begin with resolving given URL to final link to video file (we use plugins to enable  easy adaptation of  client for different services)
• Get first block to get file size, calculate number of pieces
• Start  next x connections (again starting with resolving URL – each connection is basically independent client/user agent from point of view of the server) , each one taking  a piece at time  from priority queue and downloading it
• Combine pieces together
• Server them via HTTP server on local computer
• If seeking is initiated via HTTP request, and a piece mapped for given seek offset is not already downloaded,  piece is added to  priority queue with highest priority,  and following 5 pieces with decreasing priority (but still higher then normal priority).

The concept was tested on uloz.to file sharing service,  together with some of my previous work on decoding audio captchas ( to help here to resolve video file link) I was able to start to playback of  HD content after app. 40 seconds,  and live play  relatively reliably video files encoded with byte rate up to 800kB/s, streaming them from 4 concurrent connections (having download rate about 1000kB/s).