VBrick dme Admin Manual page 104

network bandwidth, as well as storage requirements for the DME. Once content is ready, Rev
instructs all pre-positioned DMEs to retrieve it. When the DMEs receive the download
command, they first inspect their local storage to see if they already have the content and, if
so, they are done.
For DMEs that do not have the content, a specific, randomly assigned, rotating DME (from
the set of pre-positioned DMEs) will immediately begin downloading the content while the
other DMEs wait a random amount of time (no more than 5 minutes). This allows the first
DME to be seeded with the content, and subsequent download requests will utilize the DME
mesh architecture if possible. (Larger content may require more time than is allotted and thus
be requested directly from Rev until it is seeded in the mesh.) After the wait, each of the
other DMEs will begin by first inspecting the mesh for the content, or download it from Rev
as necessary.
Note: Pre-positioning is determined by customers. DMEs are
defined as pre-positioned by system administrators within the Rev
interface. Please see Rev Online Help for details.
In terms of improving playback, the DME mesh also focuses on state-of-the-art edge caching
and multi-protocol first-time. Once the content is in the DME mesh, Vbrick leverages several
technologies so it can be distributed and retrieved seamlessly by Vbrick players.
To illustrate the mesh architecture, several common use cases are presented below. Consider
the example of 3 DMEs, DME-1 (prepositioned), DME-2, and DME-3 all reachable. DME-1
is the only prepositioned DME, so any new content uploaded to Rev will automatically be
downloaded to DME-1. DME-1 currently has the following stored videos: video1.mp4,
video2.m3u8 (HLS).
• Case 1: HTTP. A player requests to play video2.m3u8 from DME-2. DME-2 first
checks locally for the HLS, but cannot find it. DME-2 then checks with the mesh. The
mesh reports DME-1 has the HLS file and delivers it to DME-2. DME-2 caches the HLS
file and then delivers it to the player. Playback begins for the user from DME-2. DME-2
will (first-time) cache all the .ts files that make up the HLS stream. Any additional (new)
player requests for the HLS stream to DME-2 will pull from its cache.
This is the general solution when dealing with HTTP based content. If it is not local,
then the Mesh is inspected. If it is found in the mesh, it is cached on the second DME. If
it is not in the Mesh, then the player will fall back to Rev delivery.
• Case 2: RTMP. A player requests to play video1.mp4 using RTMP from DME-2. DME-
2 first checks locally for the video1.mp4 file, but cannot find it. DME-2 then queries the
mesh. The mesh reports DME-1 has the file. We cannot use the shared cache for delivery
across RTMP to the player, so we redirect the player to DME-1. Playback begins for the
user from DME-1.
DME-2, in parallel, has identified missing requested content that is present in the mesh,
but not locally present. DME-2 will then initiate a mesh-copy of the content to get a
local copy of video1.mp4. Once local, this copy can be provided directly for any
subsequent RMTP requests. This is the general solution when dealing with requests
across RTMP.
• Case 3. Ultimate Fallback. A player requests a video from DME-2 that is not present
or in any reachable DMEs. At this point, if it is not on the DME-2 and it is not within
the mesh architecture, the request will fail and the player will fall back and play from Rev.
Playback begins for the user from Rev.
92 © Vbrick Systems, Inc.