...
The VidiStream application and its core functionalities are described in detail in Multimedia Content Delivery with VidiStream [INT ENT XY21.Z IG3 ARC]. Instances of VidiStream serve one or more of the following different purposes which are called modes from here on:
...
The following table gives an overview on the various aspects of the three modes of operation before going into detail regarding their differences.
Mode | stream | render | trickplay |
|---|---|---|---|
Purpose | On-the-fly DASH packaging of individual files without processing them | On-the-fly DASH packaging of timeline segments involving decoding and encoding of potentially multiple sources | Serve individual video and/or audio frames as fast as possible |
Used when? | Streaming without requiring following additional features:
| Streaming with need to enable one or more of these additional features:
| Need for very fast random access to individual video and/or audio frames but not for a linear playback |
Used where? |
|
|
|
Resources |
|
|
|
Users per instance | ~ 150-200 | ~ 30-50
| ~150-200 |
Loadbalancing Strategy | Bounded-load Consistent Hashing | Consistent Hashing | Consistent Hashing |
External Endpoints |
|
|
|
Internal URL structure |
|
Timeline is in |
|
Kubernetes Architecture
The following sections give an overview on the overall VidiStream architecture when hosted in Kubernetes.
...
In the worker-based VPMS system there exists a client-side load balancing where the client applications are aware of all existing streaming endpoints and select them in a round-robin manner. Once a session with a single endpoint is established it is held until the connectivity to the endpoint is lost and then the next endpoint is contacted:
...
| Expand | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|
This model lacks several demands that arise from the use cases above. While it does enable to have sessions to VidiStream instances it does not select streaming endpoints efficiently since the client has no knowledge of the server side instance load at any time.
...
The unique way to establish a 1:1 relation between VidiStream instance and accessed files is to base the load balancing on the clients request URI for a file to stream in stream mode. Fortunately the same approach also is usable to establish 1:1 sessions between clients and VidiStream instances in the session based scenarios. Obviously the routing of requests to VidiStream instances can not be based on the complete number of URI segments present but only on the given depth of segments that form the stable identifiers:
Mode | stream | render | trickplay |
|---|---|---|---|
URI Style |
|
|
|
Depth | 3 | 3 | 3 |
Explanation | The URI is stable for request to an individual file because the URI segments contain the Base64 encoded path to the file | When a client initiates a render session, an URL containing a random and unique session identifier is initially created and used for the remainder of the clients rendering session. Timeline data is posted in the body of the request. | The trickplay API was built to also include a session UID in the path making it a URL with several levels of constant segments addressing the unique session |
In order to guarantee a strict session binding between client and VidiStream instance the Consistent Hashing algorithm is applicable. In a simplified sense, with Consistent Hashing the source value (here the URI segments of the given depth forming the stable endpoint) is subjected to a hashing function that consistently associates the source value with one of n target values (here the VidiStream instances available). If n changes the algorithm aims for reducing any re-targeting as much as possible.
...
The following diagram visualizes this productive setup of three separately scalable VidiStream deployments based on their mode:
...
| Expand | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|
However, for test systems you can have a single deployment provide all three modes of operation. This is possible because all endpoints are distinct from each other and a single deployment can alternatively be configured to serve all modes.
...
The following table summarizes all routes that shall be available at the same DNS address/hostname (depending on whether the client is a part of the system or not):
Application | Routes |
|---|---|
MediaPortal (21.1 or newer) |
|
MediaLogger |
|
EditMate |
|
VidiEditor |
|
VidiStream |
|
...
| Expand | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|