DVR playback starts at the current live program

[C_F]

Apparently, the starting at the live point is expected behavior for OSMF 1.6. The behavior you wanted is default in OSMF 1.5.

I believe the only way to achieve this is to trap a “play” event and then “seek” to the beginning of the stream. I do not believe this requires modifying the source code for OSMF 1.6. You could probably trap the event in Javascript or Actionscript. I have heard contradictory views that Javascript is not supported. However, I believe it should work.

The most meaningful post in this is: http://forums.adobe.com/thread/758695.

The other example that is helpful is here: http://osmf.org/dev/1.6gm/hello-world-javascript.html

and here:

http://osmf.org/dev/1.6gm/jsdemo.html

Now, for some reason we haven’t been able to get the actual task done, so if you manage to actually get this to work (starting at the beginning), please let me know on the forum and share the source code with us.

Thanks!

[C_F]

Scott, Correct me if I am wrong, but it appears that Strobe Media Player only supports ActionScript events, but OSMF 1.6 supports Javascript. Would all your examples work just as well with OSMF 1.6?

[Jeff_Oakes]

I think i might have found two solutions to the problem.

If i use an older version of the OSMF player found here http://www.osmf.org/developers.html

and use the OSMF Sample Player for HTTP Dynamic Streaming, it works as I would like.

Also if I use the latest version of OSMF player and change the dvrSnapToLiveClockOffset: 1000000 it will also start the dvr stream to the very begining of the file.

[Jeff_Oakes]

This is what i understood to be happening:

According to the OSMF 1.6 documentation

http://sourceforge.net/apps/mediawiki/osmf.adobe/index.php?title=Live_DVR_Rolling_Window_for_HTTP_dynamic_streams

This feature of going to the current live point is called “Snap to Live” and is the default behavior of the current version of the player.

The option dvrSnapToLiveClockOffset is how many seconds before live should the player start playing at. Since I never know at what point i would need the player to start playing, i had to pick a value that would encompass all my recordings. It seems that if i pick a big enough value, it just defaults to the begining of the file.

1000000 seconds works out to 27 hours or so. Some of my recordings are three hours in length right now, so i could cut that value down to 250000 and i should be safe.

I mainly just picked a million seconds since it would give me the most headroom for my player.

But right now i am still testing, so if i come across anything else i will let you know.

[Jeff_Oakes]

Here are the params i am sending to the clientStrobe player included with Wowza examples.

var parameters = {

src: “http://10.1.84.89:1935/dvr/live/manifest.f4m?DVR”,

streamType: “dvr”,

autoPlay: “false”,

dvrSnapToLiveClockOffset: 1000000,

verbose: true,

controlBarAutoHide: “false”,

controlBarPosition: “bottom”,

poster: “images/poster.png”

};

Everything else remains the same from the default.

[Zsolt_Muller]

It’s good to hear (~read ) that one can create a player that plays the stream with a specific time offset from the current live point. It’s exactly what I need.

I’ve a single incoming stream and I’ve to provide both a player for the current live point and a player that plays the stream one hour from the current live.

As I understand, this can be achieved with the dvrSnapToLiveClockOffset parameter in case of the Strobe player.

What about HTTP Live Streaming (cupertino)? Is there a way to tell an HTTP Live Streaming client to start the playback 1h from the current live point? :-o Or is there any way to tell Wowza to force this “time-shift” on the client?

Since nDVR saves the stream to disk (and if I specify a large enough WindowDuration, ie. 1h), this should be “feasable”, the video data is there.

But as far as I know, this cannot be achieved on the HTTP Live Streaming clients, and not even in Wowza (so that the server already presents the “time-shifted” stream to the client).

I guess I’ve to create a module for this from scratch.

Can you point me to the right direction regarding customization of HTTP Live Streaming (integrated with nDVR AddOn’s functionality)?

Sounds to be quite a steep learning curve for a newbie (in Wowza customization/development), but if I’ve to, then that’s what I’m going to do.

[Zsolt_Muller]

Hi Scott!

I’ve read the DVR playlist request API article and I understand that this will not let me control startSeekTime in any way, but …

If my goal is to provide the recorded stream that came in 1h ago (compared to the current live stream), ie. a 1h time-shifted version of the current live stream, then I could set up an application with DVR and eg. a 65 minute (3900s) WindowDuration, and write a delegate that returns a playlist with a start 65 minutes from now and an end 60 minutes from now (a 5 minute window).

I’m not sure whether this can work (or if my theory is totally wrong) since I’m still new to live streaming + Wowza + DVR.

At which events or intervals do the clients request a playlist? I’ve read parts of Apple’s HTTP Live Streaming (HLS ~ cupertino) docs and it seems to me that HLS clients regularly refresh/redownload the playlist. I guess it’s the same for Adobe HTTP dynamic streaming (sanjose). If that’s true, then my idea might just work.