It’s been now more than a decade that TV distribution over Internet is feasible thanks to our ISPs. Such service avoid the need of external antenna, used to be upgradable by a simple firmware upgrade, and got a real un-interrupt bi-directional communication opening Internet to your TV directly from your couch.
As any innovations, the TVoIP has been initially develop by kind of transposing legacy TV Brodcast technologies to IP world: basically the ISP receiving the TV broadcast, processing it, then pushing the channel to any customer Set-Top-Boxes.
Quickly, with the market growing, ISPs realized that bandwith consumption was not that optimized as there were one flow pushed for each customer watching TV no matter if they were watching the same channel or not. Thus they intrdouce the use of IP Multicast to optimize bandwith consumption as much as possible. However this need to be supported by the ISP network up to the customer end, which is not always the case when the local Internet loop is not (fully) unbundled.
Another improvement path was to take advantage of a content distributed network the same way that video streaming website like Youtube, DailyMotion, or Vimeo are using. Basically it is pushing the IP Mulicast concept to the application layer. However as CDN are used to be invoice per amount of traffic, knowing the fact a TV channel is potentially watched by customer 24/7, the bill might quickly become an issue 🙂
Finally in parrallel, the peer-to-peer technology continued to use not only for pure file sharing but more and more as a transport technology: instead of behind dependent of network device capability or 3rd party CDN, the idea is to mutualized Internet users ressources to provide a selfoptimize service network. The first realy example which come to my mind
is was Skype, which initially use P2P concepts to transport voice/video communication between peers over Internet.
Use of P2P protocols for video streaming and even live TV (P2PTV) brodcast is not new at all. A bunch of services and tools are already providing such abilities, the latest I think is Bittorent Live, but I’m still surprise such P2P technologies not having massively replace the legacy IPTV infrastructures yet. From my point of view, the P2P concepts are much more align with the initial Internet creation: Internet is made of multiple individual networks interconnected, where each of them transport someone packet from one to another up to the destination. P2P can be see, in my own point of view, as application layer of the concept where any end point is actively part of this decentralized Internet,versus passive where just browsing a website.
Here are some very interesting readings/papers from which I based my own view/opinion:
As we can see, many solutions exists already with all their pros and cons. Today P2PTV besof arts software/solution need more a HTPC which involve medium to advanced IT skill to make everyhting work as integrated as current STB available on the market. So why not converging all advantages of all solutions.
My opinion is the most difficult part for such Media services, is that customer should not wait a stream to start (or at least less than a TV Ad), and channel swicthing must must be smooth. In P2P words it does mean we have a big amount of seeder to optimize the network as much as possible, where all Internet actors (ISPs, Customers, Public network owners) are participating.
Here is a proposed overview of a P2PTV infrastructure:
The idea would be to propose a “P2PTV open standard” in order to be massively adopted by any hardware manufacturers (SmartTV, STB, HTPC, Smartphones, etc.). Only a massive adoption of an open technology bring it to its perfection.
I’m seeing three types of TV services:
Live TV Channels
Live TV stream as we can get from legacy TV broadcasting technologies. As over the air broadcast technologies, end users do have some playback delay the time the signal/information come up to their TV. On a P2PTV point of view, we need to translate this playback delay into a sliding window where should receive as much chunks (pieces of stream data) as possible during this period of time. The sliding window may different from each clients depending on their Internet access performance: the more (stable) bandwith you’ll have, the more data you’ll be able to download in a certain time, the more you’ll be able to participate to the stream distribution.
BT Sliding window (extracted from this paper)
Indeed, because we are talking about live TV, we don’t know what’s come next until the source broadcast it. It is like a Video conference, or telephone call over IP: if you are missing some parts/packets, don’t bother waiting/redownloading them but focus on what is coming. Thus inside this slinding window, the download policies may be in the following order:
- Firsts chunks of the sliding window first in order to make sure we can start playing something (most urgent)
- Rarest chunks of the sliding window in order to improve distribution of when is coming next into the sliding window (urgent)
- Rarest chunks outside sliding window from clients having bigger sliding window (caching ahead the playback interval)
Again, I’m not inventing/creating anything but just trying consolidate information from sevral readings I made. On that subject the two most interesting one I read were:
Peer-to-Peer Multimedia Streaming Using BitTorrent (from which the above figure is coming from)
Quality-centric design of Peer-to-Peer systems for live-video broadcasting : One of the most interesting paper I ever read on this P2PTV subject – I will reuse lot of Pablo’s work espacially in the PoC section and others related contents. Pablo is one of Goalbit founders and I really appreciate his work. Note that Goalbit is open to the community.
Near VOD Channels
This can be done by simulating a live channel playing pre-define videos playlists: this is actually how 80% of legacy TV channels are.
However on a end-user point of view it will be shown as a normal live channel, playing content in a loop, similar as we could have on some old airline video systems.
Because local loop may be very poor quality, end-users may have to wait almost 10 minutes before even starting watching a movie. Plus they may have some glitchs or have to re-buffer often. To avoid such situation we need to find a way to instantly start playing the requested On-Demand content. The ideal situation would be to have the complete VOD catolog preloaded locally. However this may not feasible in most of cases today, legally (thanks to majors and evil-DRM) and even technically (storage limitation), to store completely all our movies library on the end-users side.
Thus partial distribution of each movie content (including both video/audio channels) on each end-users client may answer this problematic. Indeed, the end-user can start instantly watch his movie from the local storage, and download using P2P technologies the rest of the movie from end-users clients and others media infrastructure.
I was thinking about the following concept:
- Each end-user client will have partially movies on their local storage (sem-random amount/pieces of chunks).
- The content of the library will be announced via RSS-like technology to each end-user client.
- New available movies announced via RSS-like will be simultaneously partially downloaded on all end-user clients.
- All end-users clients will have the first XX% (i.e. first 30 minutes for a 1h30m movie), plus random YY% of each movie.
- XX (default is 30%) and YY (default is 10%) are modifiable variables.
- Movies that are not announced any more in the RSS streams will be deleted from local storage.
- The end-user will be able to immediately start watching his movie, while in the same time last parts of this same movie is being downloaded from the end-users infrastructure swarm.
- The next 30% of the watched movie should be downloaded first when initiating video content play.
- When the end-users finished watching, the movie is being completely kept stored on the local storage for ZZ days and become a major seeder for such amount of time.
- After ZZ days the movie is being deleted partially to only keep first XX% plus random YY% of it, to become a minor seeder again.
Basically I described a sort of mutualized/distributed filestystem over a WAN customized for a specific need. Here is a bunch of papers which can help on that subject:
Improving VoD Server Efficiency with BitTorrent
Pond: the OceanStore Prototype
FS-Cache: A Network Filesystem Caching Facility
OceanStore: An Architecture for Global-Scale Persistent Storage
Cooperative caching and prefetching in parallel/distributed file systems
Pangaea: a symbiotic wide-area file system
WheelFS: Efficient File Distribution in a flexible, Wide Area File System
Multi Bit-Rate Video on Demand for P2P networks (work linked to Tribler research group)
Toward Efficient On-demand Streaming with BitTorrent
Peer Selection Strategies for Improved QoS in Heterogeneous BitTorrent-like VoD Systems
Rarest First and Choke Algorithms Are Enough
Proof of concept
As part of my readings on that P2PTV subject, I was also looking for pieces of codes/projects I may reuse to proof my conceptual approach. I found two projects that are actually very close to what I described above.
P2P-Next, a pan-European conglomerate of 21 industrial partners, media content providers and research institutions, has received a €14 million grant from the European Union. The grant will enable the conglomerate to carry out a research project aiming to identify the potential uses of peer-to-peer (P2P) technology for Internet Television of the future. The partners, including the BBC, Delft University of Technology, the European Broadcasting Union, Lancaster University, Markenfilm, Pioneer Digital Design Centre Ltd, and VTT Technical Research Centre of Finland, intend to develop a Europe-wide “next-generation” Internet television distribution system, based on P2P and social interaction.
As you can see partners heterogeneity is quite interesting: broadcasters, hardware manufacturers, chips manufacturers, etc.
Here is a good slide presentation of this project from Lancaster University. Another one from Pioneer. Also lot of papers have been published on the project website but it appears the project slowdown start 2012. However the scope is very large which may explain this feeling:
When I was working on this idea back in 2012, I tried contact some project members, but the team was looking so dispatched that I was not able to get in touch with the right people at that time. However the project looks fantastic by its scope, but more even by its consortium. This is definately a project to follow.
Some working packages have already been delivered for testing purpose like a browser plugin. Note also that some video of Wikipedia.org are using this technology.
GOALBIT is a peer to peer distribution system, capable of distributing high-bandwidth live-content to all network peers preserving its perceived quality.
I discovered GOALBIT when I read Pablo Rodríguez-Bocca’s Thesis as part of his PhD degree in Computer Science. I really like his approach and then started to dig a little bit about the implementation of his thesis concept. Now Pablo is Goalbit CEO, a company who seems to continue to be closed and open to the Community.
Goalbit is proposing freely a player and a starter suite to get an idea of P2P advantages for (live) video distribution. I was able to use them for testing purpose regarding live channel and confirming that such P2PTV concept/model is the right way to go.
Instant video concept still needs to be proof
So far, I was not able to find any project implementing instant VOD concept the way I discribed it earlier, but based on my readings regarding distributed decentralized file systems over wide area or slow networks, I’m still confident that concept is valid. I was thinking about trying developping myself some kind of “quick & dirty” proof of concept, but because I’m not a programmer (I learned some language when I was at Uni, but didn’t practice so far) I was not able to find spare time enough to jump in yet. Maybe one day 🙂
Few years ago, I did some strategic management and entrepreneurship models reading as part of my continual personnal improvement. I end up to read a veryu interesting book compliling some methods/tips which can be applied to those both subjects: Business Model Generation written by Alexander Osterwalder. I highly recommand to anyone reading this book as the tool presented inside can actually adapted to anything: career, business model defination, team management, etc.
Here is the business model canvas for our current subject:
Propose an unlimited VOD plan, based on the maximum cost that content rights owner might request for each viewings (worst case scenario approach). But:
- Very few people will be actually watching more than 20 movies per month (except maybe at the begining).
- Movies rights costs are based on their success and seniority.
- Others non-subscriptions revenus are bonus.
- Do not move to the next phased without prerequisites met.
- Need to validate the model during the first year.
Cost model (target):
A phased deployment:
- In lab Pilot infrastructure with limited alpha testers clients
- Public Go Live
- Unlimited sVOD
- Max 500 STB customer to proof business model effectiveness
- Close beta for LiveTV
- LiveTV local channel only
- Engage discussion with national/internationa l broadcaster (TF1, Canal+, M6, ESPN, etc.)
- Model stabilization
- LiveTV packages
- Close beta for Mobile LiveTV
- VOD Encoder:
This block is responsible of encoding the On-Demand contents to several encoding profiles in order to adapt the content to the final end-users infrastructure capabilities.
- Ads Encoder:
This block is responsible of encoding the Ads contents to a unique and optimized profile.
- Live Stream Acquisition:
This block receives the live content from different sources like an analog signal, existing streaming signal, stored video files, etc. It processes the signal and pushes it into the media infrastructure. This block is also responsible of simulating live channels by playing videos playlist.
- Live Stream Transcoder:
This block is responsible of transforming the original signal acquired into an optimized content based on transcoding profiles.
- VOD Pre-Fetcher:
This block is responsible of partially distributing specific VOD contents (i.e. including both audio and video) directly to compatible end-users infrastructure. .
- Ads Pre-Fetcher:
This block is responsible of pushing advertising to each end-user infrastructure, in order to play instantly ads before playing requested content without consuming end-user bandwidth. This feature is similar to the “VOD Pre-fetcher” except than advertisement are published completely on the client side.
- Internal Super Peer:
This block is responsible of receiving the content from sub-layer component described above, and processes it in order to push and/or stream it into the P2P network swarm. Thus it is acting as a broadcaster into the P2P swarm as part of the end-users content distribution framework. It first priority is to insert the content into the swarm, even if can also participating in the content distribution.
- Internal Delivery:
This block is sharing and replicating the contents between nodes part of the end-users distribution layer. This component can be used for load-balancing such nodes.
- Remote Super Peer:
Very similar to the Internal Super Peer except it is not acting as a broadcaster but only as peer having high upload bandwidth capabilities. It first priority is to actively distribute content in the swarm. In our model, this component will be place in local ISPs facilities in order to optimize bandwidth usage & costs, but would be remotely managed from the core infrastructure.
- Video On Demand Management:
This block manages VOD contents: source location, number of replicas for each videos, distribution on the end-users infrastructure, encoding profiles available for each content, number of viewers, assigned resources, etc. This block is interacting with following Media Infrastructure blocks: VOD Encoder, VOD Pre-fetcher, End-user delivery layers.
- Ads Management:
This block manages advertising contents: source location, number of replicas for each video, distribution on the end-users infrastructure, number of view, assigned resources, etc. Each ads are tagged per ads customer (3rd Party paying to display their ads), category, price plan (should be played at least 10 times of day for instance), etc.
- Live Stream Management:
This block manages Live contents being processed by the VDI: original signal source, content encoding & transcoding profiles, listing of viewers, assigned resources, etc. This block is interacting with following Media Infrastructure blocks: Live Stream Acquisition, Live Stream Transcoder, End-User delivery layers.
- Media Servers Controller:
This block is responsible of controlling Media Infrastructures nodes components by adding, removing and controlling resources nodes assignments. It is also responsible of securing interactions between each node, using certificates.
- End User Access Controller:
This block is managing and establishing permissions to end-users on specifics components.
- Content Transmission Controller:
This block manages and controls content transmission process all over the VDI and the content distribution to end-users.
- “DRM” Manager:
This block is responsible of managing Digital Rights when required, by making sure the end-users is viewing content as per their rights/permissions, but should not be platform dependent.
- Statistics & Reports:
This block can be sub-divide into three main functions:
Transmission Tracking: Monitor contents (Live and VOD) distribution over the network to the end-users. This may help for detecting transmission and streaming problem. This feature provides information on the quality of the contents distributions.
Content Delivery Tracking: Provides information about contents popularity, availability, etc.
Advertisement Tracking: Provides information about ads being viewed, availability, etc.
End User Tracking: Provides information about end-users profiles: contents requested, IPS, requests time, etc.
- Billing Manager:
This block is computing results from different tracking module (Statistics & Reports block) in order to provide an order to invoice for end-users and advertising customers.
- Administrator Access Control:
This block is controlling administrator access, privileges, and defining securities for the whole VDI.
To go further…
Here are some others documents I created as part of this experience:
Investor/partners presentation: P2PTV_presentation_v4_EN
Platform specification for RFP purpose: P2PTV_Platform_Specifications