MULTISCREEN OTT VIDEO STACK FOR OPERATORS

Problem: Consumers have become conditioned to “all my media on all mydevices all the time” from their experiences with digital music and e‐bookservices, and they expect no less from video; meanwhile, Hollywood studiosand other video content licensors have raised, not lowered, their expectationsthat their content be protected from unauthorized use. In general, thetechnological complexity of building, maintaining, and scaling multiscreen OTTtechnological complexity of building, maintaining, and scaling multiscreen OTTvideo services is not decreasing. Operators require a range of capabilitiesincluding streaming video, content protection, application development, andother technologies. Yet no single, “silver bullet” stack with all these capabilitieshas emerged that operators can rely on to build out their services in a future‐proof, scalable, and interoperable manner.

Solution: Arumai‐Silver Bullet Stack™, a multiscreen rights managementcapability on the server side, is the key to minimizing and isolating complexityamong several moving parts as operators build and expand their services tomore and more devices. By making OTT service deployment easier, operatorscan better respond to competitive developments in the marketplace whilecan better respond to competitive developments in the marketplace whileminimizing total cost of ownership (“TCO”). The major moving parts of an OTTprovider’s infrastructure are application development technologies, adaptivebitrate streaming, and digital rights management (DRM).

STREAMING VIDEO PROTOCOL (cont’d)

Solution: In Arumai’s proprietary system: (i) multimedia content is captured and stored anddelivered on an HTTP server and is delivered using HTTP. The content exists on the server in twoparts: Media Presentation Description (MPD), which describes a manifest of the availablecontent, its various alternatives, their URL addresses, and other characteristics; and segments,which contain the actual multimedia bit streams in the form of chunks, in single or multiplefiles; (ii) To play the content, the Arumai client first obtains the MPD. The MPD can be deliveredusing HTTP email thumb drive broadcast or other transports By parsing the MPD the Arumaiusing HTTP, email, thumb drive, broadcast, or other transports. By parsing the MPD, the Arumaiclient learns about the program timing, media‐content availability, media types, resolutions,minimum and maximum bandwidths, and the existence of various encoded alternatives ofmultimedia components, accessibility features and required digital rights management (DRM),media‐component locations on the network, and other content characteristics. Using thisinformation, the Arumai client selects the appropriate encoded alternative and starts streamingthe content by fetching the segments using HTTP GET requests; (iii) After appropriate bufferingto allow for network throughput variations the client continues fetching the subsequentto allow for network throughput variations, the client continues fetching the subsequentsegments and also monitors the network bandwidth fluctuations. Depending on itsmeasurements, the client decides how to adapt to the available bandwidth (“transfer rates”) byfetching segments of different alternatives (with lower or higher bitrates) to maintain anadequate buffer.