Overview of workflow changes

One of the greatest advantages with live DVR functionality in Flash with Flash Media Interactive Server 3.5 is that there is nothing special you have to do on the server or the client. All this great functionality in its simplest form is available right out of the box with the same processes already being used to stream and record, and then have a client access the content. The very root of the live DVR functionality of Flash Media Server is its ability to stream video as it is being recorded. This was the biggest problem Adobe solved, plus the ability to scale the delivery and functionality through content delivery networks (CDNs).

Understanding the NetStream.Play options

The client controls the DVR playback, not the server. Control is achieved through the NetStream ActionScript class. This class is responsible for managing the playback; specifically, the NetStream.play or NetStream.play2 commands.

The key point in all of this is that, instead of playing the live stream, you actually play the recorded (live cache) stream as if it were a VOD stream. This is done from the client-side NetStream.play() or play2() methods and the start time parameter. For the older play() method, the start time parameter is the second parameter directly following the stream id. The new play2() method (Flash Player 10 and later) uses the NetStreamPlayOptions class as its parameter and a start property within the class. Have a look at the NetStream.play(), and the NetStream.play2() method API references.

By default the of NetStream.play() start parameter value is –2, instructing Flash Player to play a live stream first and, if that does not exist, to play a recorded stream if it exists with that ID. If neither stream exists it will create a live stream and wait. To play a recorded stream, the parameter is set to a value > 0 unless you want to limit the amount of time a specific user can seek back in time. In that case, a value of 0 would indicate to start playing back the recorded file from the beginning. If a value > 1 is specified, it will start the playback from there, in seconds, and will not allow the client to seek to a point previous in the video's timeline.

Here are some examples. The following looks for a live stream first, then a recorded stream. If neither of those is available, it creates a live stream and waits for content:

NetStream.play(streamID, -2);

The following looks for a live stream only and plays it if it exists:

NetStream.play(streamID, -1);

The following plays a recorded stream from the beginning, and allows users to seek back to any time in the stream:

NetStream.play(streamID, 0);

The following plays a recorded stream from 10 seconds in, but prevents the user from seeking to the first 10 seconds of the stream:

NetStream.play(streamID, 10);

Setting the "start" parameter to a value > 1 can be valuable for live DVR if there is a need to trim the beginning of the recording made available to users, perhaps during startup or preparation. From there you can seek, pause, play, and catch up just as you normally would. It's important to make sure you want live DVR functionality to allow the client applications to play the recorded stream, not the actual live stream.

One commonly implemented feature is the ability to seek to the latest point in the stream that would most closely represent the live content. For simplicity's sake, this will be referred to as the live point. Figure 1 illustrates the workflow to consider.

Figure 1. Live streaming workflow

This workflow would often be called immediately upon playing, so that users start at the live point and then are given the option to seek back in the timeline of the content if they choose. So you would have the users first play at the beginning of the content intended for DVR access (40 seconds from the start in Figure 1) and then seek their view of the stream to the live point. It is important to note that you should not try to play the live recording stream immediately from the live point. Calling the initial play command with the current live point as its start time will limit the backwards-seeking window to that initialized point.

To ensure that viewers do not see any content on the DVR-cached stream that occurs at the beginning of the cache (also known as the dirty head of the stream), make sure tyou don't start users at the very beginning of the stream, or else they will be able to seek back to it. The same applies at the end of the stream. Close viewers' streams before the end of the cache to allow more content at the end of the stream to be made unavailable to viewers.

Best practices

A best practice is to start playing the stream at the DVR-accessible content start time. Once the client application's NetStream instance broadcasts a NetStatusEvent with the event.info.code value of "NetStream.Play.Start," invoke the seek() method of the NetStream instance and seek to the live point in the content, which you can determine by the metadata or initially by seeking to a very high value, such as 1000000.

For best management and performance, we recommend that you keep track of the live point either with a server messaging solution or locally for each client. A solution for managing this locally for a client application will be explored in the upcoming walkthrough. A nice tip to know is that, if you ever try and seek past the available duration in a live DVR stream, it will end up seeking to the live point in the end, but does not perform as fast as knowing the appropriate seek time, as it will flush the buffer and reinvoke the stream. However, if the live event is over and a user tries to seek past the end, it will restart the stream from the beginning, as is standard with the media server.

Another important note regarding live DVR and playing content at a determined live point is that Flash Media Server has to process the live video and make it accessible to the recorded streaming mechanisms on the fly as the stream comes in. What this means for the user is that, if they are viewing a live DVR stream, they will always experience a little delay in the content compared to the true live stream that is still available. This is not a fixed delay and can vary depending on many factors, such as hardware, cache size, video quality, and encoding parameters.

Page 3 of 6

Previous Page

Next Page