OTT or over the top streaming is delivery of video over the open Internet to multiple devices. Traditional IPTV uses managed IP networks to deliver DVB signals to Set Top Boxes. The main technical difference is that OTT uses HTTP/TCP which is easy to configure through firewalls and NATs.
Different technologies for OTT
Currently there are five different solutions for OTT:
There is also an initiative for a real standard protocol called MPEG Dash.
In this document we will focus on the HLS ecosystem, but the philosophy will be applicable to the other solutions.
Video On Demand for OTT
Video on Demand content has been available for OTT for a long time and each video file is segmented into a number of smaller files typically 10 seconds duration. When starting the VOD session the client downloads a playlist file containing URLs to all media files. This gives the client full access to the entire program. This is important for subtitles since the client will know the duration of the movie and thus have a timeline available. If a subtitle file is available it will have a S.O.M of 0 and run until the duration of the movie. A common subtitle file format for VOD OTT is the SRT. Below is an example of a SRT file.
1 00:02:17,440 –> 00:02:20,375
Senator, we’re making
our final approach into Coruscant.
2 00:02:20,476 –> 00:02:22,501
Very good, Lieutenant.
Publishing a VOD OTT movie including subtitles the resulting HTML can look like this:
<video controls=”controls” width=”320″ height=”176″>
<source src=”jellies.mp4″ type=”video/mp4″ /><!– WebKit –>
<source src=”jellies.ogg” type=”video/ogg” /><!– Firefox / Opera –>
<track src=”jellies.srt” kind=”subtitle” srclang=”en-US” label=”English” />
Your browser does not support HTML5 video. </video>
The video content can be different depending of the Browser or platform, in this case .mp4 and .ogg. A “track tag” is added to indicate the URL to the subtitle file and the client will overlay the subtitle track on the video content.
Our customers that provide OTT services for VOD can write an export script in SAM that extracts the subtitles files and converts them into SRT or equivalent (e.g. Web VTT). This is already implemented at several customers, e.g. HBO Asia and Canal+ France. Often they do this without our involvement since all the tools for doing this is available in current products.
In order to improve the workflow management of OTT VOD publishing we plan to integrate a Web Service interface into SAM so that external VOD systems can extract files via an API. This will be demanded by Canal+ France in a short future.
Live OTT is similar to VOD in the segmentation of files, but with the main big difference that the playlist file only contains a few entries and is dynamically changed to add the new media files. So when a client joins a Live OTT broadcast it will receive a playlist containing the most current media files, maybe 1-3 files. All files typically have duration of 10 seconds and the playlist file is continuously updating and removing entries.
So the client has no knowledge of the duration of the entire broadcast event and there is therefore no reference clock to synchronize the subtitles with. In this case it would be a good idea to use an embedded subtitle format similar to DVB subtitles. Unfortunately, this has been addressed by Apple and they have chosen 608 as the closed captioning format also for OTT services. EIA 608 is not a unicode format and most of our customers will thus not be able to use it.
Using DVB subtitles is not feasible since the size of the bitmaps need re-scaling in the client and the bandwidth to deliver bitmaps is significant. Outside the US we must therefore find other solutions to Live OTT subtitling.
The new version of HLS can handle WebVTT files also for Live. In our current discussions with Anevia and the True Vision project we have suggested the Cavena proprietary format distributed in Packet 31 of the DVB teletext. This format is fully Unicode based and has also formatting parameters, e.g. color and positioning. Anevia, providing the streaming platform, extracts the subtitles from packet 31 and creates WebVTT files synchronized to the video files. Each WebVTT file will have a duration of 10 seconds (decided by streaming platform).
The picture below describes the similarities and differences between IPTV and Live OTT. IPTV is just another physical DVB standard and is not different from other DVB distribution format in terms of subtitling. The OTT solution that is currently being discussed with Anevia is based on the Cavena proprietary packet 31 solution. The STU will add an extra stream and create a teletext track with subtitles in the packet 31 of the DVB teletext. The subtitles are inserted in synchronization with the video content and extracted by the streaming server where WebVTT files are created/segmented in a similar way as the video content. Each subtitle file will have a 10 second duration, i.e. the same as the video files.
Using the Cavena proprietary format requires that OTT vendors have a basic subtitling and teletext knowledge. It also puts some of the subtitling functionality that traditionally has been a Cavena area into the streaming/transcoding servers. This could potentially be a threat to parts of our market and at least to the emerging OTT market. An alternative solution would be more in-line with DVB subtitling, I.e. we receive timing information from the streaming server and create the required file format, e.g. WebVTT. To do this we need an interface to the streaming server to receive the video file index, duration of each file and the PCR. We would then create the 10 second long subtitle files and send them to the streaming server.
By doing this we are more involved in the OTT solution and we can potentially charge a higher price than just an extra stream format.
This solution can also be used in a real transcoding configuration. We may however have to implement OCR reading of DVB subtitles to create text based files from bitmap data.