Cloud DVR: Responding to the technical challenges of the future media ecosystem

At a time when many service providers are struggling to differentiate themselves, the addition of integrated Cloud DVR (cDVR), OTT and on-demand capabilities are likely to become table stakes, particularly at a time when many consumers are becoming frustrated by a user experience that is become increasingly difficult to navigate. In the case of cDVR, how should we judge its future?

Meir Lehrer

Digital TV Europe recently hosted a deep-dive webinar titled “Video Storage/Cloud DVR: Complex Considerations, Big Payoffs”, which featured expert contributions from Omdia’s Merrick Kingston, and MediaKind’s Meir Lehrer, Vice President, Portfolio Development, and Stuart Boorn, Vice President, Product Development.

The webinar is now available to watch on demand, but there were so many great questions, we didn’t have time to answer them all. So here, Lehrer addresses some of these questions from the Q&A, focusing on some of the technical challenges of cDVR and influencing market factors such as the growth of 5G and OTT content.

Q1: What do you see as the advantage of Software Defined Storage (SDS) over Object Store?

There are three areas where SDS architectures are exceptionally good in optimising cDVR over Object Stores:

• First, SDS architectures pool all CPUs (central processing units) and HDDs (hard disk drives) into a single network interconnected namespace that acts like a large load-balanced resource. This maximises the amount of activities on CPUs, bandwidth across data buses, and read-write I/O across HDDs (with a defined maximum HDD-utilisation to prevent early RMAs/burnouts). The need for numbers of servers is now reduced, because the physical resources you do have are being utilised much more efficiently than a separated Control Plane and Data Plane Object Store architecture.
• Second, SDS architectures also optimise the network and focus all video ingest, processing and egress within an interconnected group of nodes (servers), as opposed to sending individual PUT/GET requests across a separated network to a secondary system, for example Data Plane.
• Third, the playout efficiency, or reduction of latency, is optimised far better in an SDS architecture due to the “content awareness” of the SDS system, as video chunks are being read and written to/from HDDs. The fact that Just-in-Time-Encryption and Packaging are within the same operating nodes as disk I/O also ensures a much faster action for each video retrieval and playout stream.

Q2. Cloud DVR sounds like this great thing. Why then do we see so little of it (full blown implementation; not its simpler pause + replay variant) in the market?

Rolling out time-shift TV solutions such as catch-up/start-over, which is what is referred to by this question, is more straightforward because it involves fewer complexities such as schedule ingest and conflict resolution, disk quotas, recording planner integrations and DVR notifications. This is usually a matter of buffering a channel and enabling the Packager to route to the correct feed, live or buffered. Often, you’ll see this solution provided by Packager vendors with a minimal amount of storage as time-shift services don’t typically require more than a few hours of storage. Once things get beyond a certain point, the linear programme is already made into an asset, as VOD content and the backend will often follow that workflow to provide catch-up/start-over playback and trick-modes. Cloud DVR is far more complicated and involves lots of moving parts, including those just mentioned, and in markets such as the U.S. In LATAM and Germany, some of the programming also involves the complexities of Private-Copy replication, De-Duplication and Re-Duplication. Operators have traditionally had more to consider and contemplate for cDVR implementations than time-shift, so that always creates a natural push-back.

Q3: Is there really a scope for cDVR in an OTT feature set? Isn’t cDVR more relevant to linear transmissions?

cDVR architecture must be able to natively ingest, process and egress specific types of video, so it cannot be immune to input and output video encoding formats or streaming protocols. There may be times where a legacy cDVR will need to deal with MPEG-2 and MPEG-4 SD and HD encoding CBR transport stream ingress, plus egress via RTSP. Furthermore, a cDVR that deals with MPEG-4 CBR ingest and serves OTT devices, may need to transcode the h.264 to h.265 (HEVC) and stream to HLS iPhone/iPad devices, alongside a number of Microsoft HSS devices and newer DASH CMAF (Common Media Application Format) LLC (Low Latency Chunk) supporting devices. All of this occurs within the Packager of the cDVR in real-time (“Just-in-Time”) as it is reading out video chunks from hard disk to play upon a consumer request.

SDS architectures include the Packager as a fundamental part of the functionality of every interconnected processing node in the cDVR, whereas Object Store systems do not. Object Stores require the content to be gathered one chunk at a time. First, over the network from the Data Plane, and then the Control Plane has to pass these chunks to a typically separate Just-in-Time-Packager or write them to the Data Plane already encrypted and in packaged format, precluding multiple device support without storing multiple copies. This shows that the cDVR is very aware of OTT content and how to deliver it. The CMAF LLC HTTP chunk transfer and low-latency features of OTT must be implemented by the Just-in-Time-Packager component of the cDVR for them to work. Therefore, a cDVR is decidedly video specific and must be able to handle all of these protocols for both linear recordings and buffered time-shifted linear catch-up services, as well as On Demand Origin recordings.

Q4: Does it not make more sense to refer to this trend towards video storage as Edge DVR, rather than Cloud DVR?

A great question, but one that focuses on network architecture more than the functionality of a cDVR. Many cDVR architectures, whether SDS-based or Object Stores, have the capability of being deployed centrally or regionally (e.g. at the edge). An ideal solution is one in which the majority of the cDVR functionality is centralised, since this is how most largescale MVPD operations architectures are designed. There is then the possibility of an Edge Delivery Node, which possesses most of the cDVR capabilities, but localises the content for a particular neighbourhood or region. It also reduces the need to send all content to every region over the Core Network and handles all encryption, packaging and streaming locally.

The combination of cDVR and media edge localised delivery nodes can deliver an effective blend of efficient local video cache, Just-in-Time-Encryption, Just-in-Time-Packaging and onboard RTSP delivery for legacy devices. This obviates the need to send entire formats from every piece of content to every network edge Delivery Node. It can be sent once in one format and handle per-device variation in real-time.

Q5: How much flexibility does the consumer have in order to adjust the time of the recording, so that the last minutes of a movie or session are not lost and the slot in the EPG schedule is not too restricted?

This is set by the consumer via their device User Interface (EPG). The back-end system of the MVPD or Streaming Service that propagates the data for the User Interface may not have a way of getting real-time updates for events that carry on past their event window and therefore cannot be handled internally. In this instance, the consumer’s only way to compensate is to hit “record” on the next event that appears sequentially in the User Interface after the desired recording. The bottom-line from a cDVR perspective is that a cDVR is like a local DVR in the cloud, and the Scheduler System acts as the hand and fingers that know when to press the DVR’s “record” button.

Some cDVR systems also provide a back-end Scheduler as an option, but this is separate from the core cDVR functionality itself. The Scheduler would then need to handle these drifting events and would typically require TV listing information (flat-files) or Traffic System information (live API) to update them in real-time. This is usually not a reliable process, and when it does work it’s more often in the European market as opposed to the Americas where flat-file systems update event information for User Interfaces once daily, typically with a 7 to 21-day look-ahead data set.

Q6: Are there APIs available for integrating non-media applications in an environment where video plays a key role, alongside other non-video data types?

Looking atcDVR systems specifically, the ingest APIs are typically for video only. These can be linear feeds, such as multicast or unicast IP addresses for Transport Stream inputs, (and in some cases CDN pull) or file-type ingests for reading VOD assets from a NAS (Network Attached Storage). There are often metadata interfaces as well. There are many operational interfaces to a cDVR, such as the Scheduler System APIs (EPG-based or time-based being the most common), Monitoring & Control APIs (such as SNMP (Simple Network Management Protocol), Log-Files, etc), OSS/BSS entitlement APIs and  Encryption APIs (CAS/DRM) being a few examples.

Q7: Given the fact that we will enter the 5G era not tomorrow but in a few years – therefore existing for a decade in parallel with 4G – will Cloud DVR look old fashioned in the short-term future?

It is important to bear in in mind that cDVR is like the big DVR in the cloud. It’s efficient, cost-effective and contains low-latency video storage and playout. It connects to a pipe, but it is not the pipe itself, whereas 4G and 5G networks are seen as the pipes. Why will 5G create more demand for cDVR? That’s because any 5G capable device will suddenly be able to download or stream large bitrates that would have been previously difficult if not impossible over 3G or 4G. However, the cDVR will only grow in importance the larger the pipe. AR and VR are video and device types that will increase the trend for larger bitrates, stream sizes and file sizes, as better picture quality and multiple camera angles will most likely be involved. This growth in larger requested bandwidth will only be satisfied by a bigger data pipe, such as 5G. However, it’s equally true that recording any high-quality video of increasing size on a local disk drive will be an impossible demand to satisfy. This is why cDVR will be critical, since only a malleable storage system off-device can grow to support this unceasing demand.  Think of your 64GB or 128GB iPhone. Most people take so many pictures and videos that it would be impossible to live within the constraints of this on-device storage while also making sufficient room for apps and data. The iCloud enables us to store our pictures and videos with far greater flexibility regardless of how large the unplanned demand grows. The same concept holds true for video storage on any mobile device (or even in-home DVR) and a cDVR.

Q8: With 5G, do you see a big chance for mobile operators to compete with traditional pay-TV operators by providing fixed broadband through 5G CPE + competitive pay-TV content? Can mobile operators access this market that was previously closed to operators providing fixed connectivity?

Excellent question. Yes, this is certainly an opening for mobile operators to provide added value by offering live video streaming and/or on-demand video services. Culturally, organisationally and operationally speaking, a telecom operator who has never offered video before will have a significant curve to overcome by adding such services native to their platform. More likely there will be partnerships by major mobile carriers who provide a video bundle with existing streaming services as a value-added, single billing offering upon purchase of a mobile subscription. Even some current cable MSOs as well as a telco RBOCs, ILECs and CLECs have already stopped carrying their own video services or are considering doing so. Instead, they are opting to focus on the data pipe while providing attractive bundles with retail service provider offerings from other streaming services.

Watch the Digital TV Europe webinar ‘Video Storage/Cloud DVR: Complex Considerations, Big Payoffs” on-demand here.