OTT platforms are gaining popularity as consumers want to watch fresh video content on all their connected devices. For content owners like TV channels, telcos, or product companies, it may be time to launch a multi-screen OTT offering. The Arumai Multiscreen OTT Platform uses APIs as its foundation, with dedicated endpoints optimized for different devices. Its API architecture is designed for service reusability, agile development, and to generate significant traffic. Arumai's system delivers multimedia content over HTTP. An MPD manifest describes available content, URLs, and characteristics. The Arumai client parses the MPD to learn about program timing, media availability, and selects the appropriate encoded alternative to

1. OTT PLATFORM WITH SOCIAL MEDIA LAYER FOR OEMS
Problem: OTT sites increase to gain popularity as consumers are eager to watch
fresh video contents on all their connected devices. For content owners, a TVfresh video contents on all their connected devices. For content owners, a TV
channels, telcoms, or a products and solutions company it may be the right
time to (re)launch your Multiscreen OTT offering.
Solution: The API is the foundation of Arumai‐Multiscreen OTT Platform™, theSolution: The API is the foundation of Arumai Multiscreen OTT Platform , the
alpha & the omega of service reusability and agile development on a maximum
of heterogenous client platforms. Clever API architecture with dedicated
endpoints by devices to optimize the data exchanges, API degradability
strategies ‐‐ this is definitely the major key of Arumai‐Multiscreen OTT
Platform™ anticipated success and the reason why its API will generates the
most traffic in the U.S. for a single platform. Arumai will balance investments
in (hardware) systems and connectivity with the required scalability andin (hardware) systems and connectivity with the required scalability and
flexibility. Today’s encoding systems are dimensioned on peak loads (e.g.,
during special events) while the financial returns on those systems are driven
by overall utilization of the infrastructure. As a result, content providers have
not enough infrastructure for peak hours and special events, although their
existing infrastructure is underutilized or idle at the rest of the time.

2. STREAMING VIDEO PROTOCOL (cont’d)
Solution: In Arumai’s proprietary system: (i) multimedia content is captured and stored and
delivered on an HTTP server and is delivered using HTTP. The content exists on the server in two
parts: Media Presentation Description (MPD), which describes a manifest of the available
content, 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 multiple
files; (ii) To play the content, the Arumai client first obtains the MPD. The MPD can be delivered
using 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 Arumai
client learns about the program timing, media‐content availability, media types, resolutions,
minimum and maximum bandwidths, and the existence of various encoded alternatives of
multimedia components, accessibility features and required digital rights management (DRM),
media‐component locations on the network, and other content characteristics. Using this
information, the Arumai client selects the appropriate encoded alternative and starts streaming
the content by fetching the segments using HTTP GET requests; (iii) After appropriate buffering
to allow for network throughput variations the client continues fetching the subsequentto allow for network throughput variations, the client continues fetching the subsequent
segments and also monitors the network bandwidth fluctuations. Depending on its
measurements, the client decides how to adapt to the available bandwidth (“transfer rates”) by
fetching segments of different alternatives (with lower or higher bitrates) to maintain an
adequate buffer.