Version 4.5.2 of Flash Media Server is now available. Besides numerous bug fixes, it includes a major improvement – robust HDS/HLS failover for origins.

 

 

 

 

 

 

 

 

It’s not simply a “good-to-have”, but a “must-have” feature for HTTP streaming deployments. The key issues it addresses are liveness and dropout situations.

Liveness is a server-side situation in which a packager advertises a stale bootstrap (that is, a stale view of a live stream). Although there are other potential scenarios, the following describes one liveness situation:

  1. The stream has been running normally for some time on the server side.
  2. Packager 2’s connection to the encoder fails. The connection between Packager 2 and the proxy continues running. Suppose that at the time of this failure, the last successfully written fragment on Packager 2 was still #700 with current media time as X.
  3. A short amount of time elapses, in this case, 10 fragment intervals.
  4. The server-side now suffers from liveness. Packager 2 is serving stale bootstrap information. Packager 2 indicates that there has been no update in the bootstrap after time X, even though more recent fragments are available on Packager 1 (that is, the current media time is greater than X.)
  5. Playback stalls at the player end.

Dropout – is a server-side situation in which a packager has gaps in its bootstrap (that is, gaps in its fragment list). The following scenario describes a dropout situation:

  1. The stream has been running normally for some time on the server side.
  2. Packager 2’s connection to the encoder fails. The connection between Packager 2 and the proxy continues running. Suppose that at the time of this failure, the last successfully written fragment on Packager 2 was still #700.
  3. A short amount of time elapses, in this case, 10 fragment intervals.
  4. Packager 2’s encoder connection is restored and remains restored for a long time.
  5. The server-side now suffers from dropout. Packager 2’s bootstrap is missing entries for #701-710, even though those fragments are still available on Packager 1.
  6. Playback stalls at the player end.  [via FMS documentation]

The solution to those fundamental challenges.

Enable best-effort fetch

Best-effort fetch enables the OSMF and iOS video players to continue playback as normally as possible in the presence of short-term liveness and dropout problems on the server-side.

Code the control plane application

To implement HTTP Streaming failover, you write a client application that manages the state of events and streams by using a set of REST-based control plane APIs. Control plane is a router term and in effect, that is what your client application does through these APIs.

The basic workflow is as follows:

  • Begin repeatedly checking stream status at a set interval. The exact interval depends on your configuration.
  • Disable any stream with a bad status code.
  • You could also compare the age of the bootstrap file and disable the stream for which the bootstrap is older than some predetermined interval.  [via FMS documentation]

The counterpart on the client side for these features is OSMF 2.0. You can find more detailed information in the FMS failover documentation. HTTP failover is an absolutely critical improvement for HTTP streaming deployments.

Jens Loeffler

Author of Overdigital.net. The views/posts are my personal opinion.

http://www.overdigital.net

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

banner
Follow

Get every new post delivered to your Inbox

Join other followers: