DVR playback starts at the current live program

I have been able to successfully install the nDVR module, and i have been able to playback the file correctly. What i have found with all the players i have tried is that when i start the dvr stream, the player will always go to the current live posistion. What i would like the system to do is start the video file at the beginning of the dvr stream and playback from that point.

Is that possible?

I have tried the included OSMF player in the examples directory and i have even tried the strobe 1.6 and 1.5 players.

I don’t think this is possible at present.

Richard

Jeff,

Why did you choose dvrSnapToLiveClockOffset: 1000000? I cannot find any decent documentation on this apram, but it seems the default value is 4 or 5.

Scott

Jeff,

I’m curious how you are passing dvrSnapToLiveClockOffset into the OSMFplayer. Are you adding it as a param in the StrobeMediaPlayback.html shipped with Wowza?

I’ve been playing with this setting and nDVR, but setting it to a large value does not start the playback at time=0 for me.

Scott

It’s good to hear (~read :slight_smile: ) 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. :slight_smile:

Within 2 weeks there will be some enhancements to nDVR by which one will be able to provide a delegate to provide the requested playlist start and end points.

However, this does not address the play start time, only the beginning and end of the known DVR playlist.

The seekStart within that playlist is a different issue, and is entirely dependent on functionality provided by the client players. The typical approach of the players is to start playing at the live point for currently recording streams, and to start playing at the earliest time for streams that are no longer being recorded. nDVR has recently enhanced to differentiate the ‘actively recording’ from the ‘recorded’ to support this play start time for San Jose and Cupertino streaming. Smooth Streaming is coming.

For example, in the Strobe/OSMF player which you are concerned with does not provide a way to specify the seekStart time.

For streamType=dvr, some folks have said they can use dvrSnapToLiveClockOffset to force the the player to start playing at time=0. I have not been able to get that to work, and looking through the strobe code, it’s not clear to me if this would work in all cases as a seekTime. It seems doubtful as a general solution for seek time, as this is not its intent.

So, actually, I think your customization for specifying start/seek time would be on the Strobe/OSMF side not in Wowza.

This is open source, so any enhancements in this area would be greatly appreciated by the community.

Scott, I have been following this thread and been wondering if this enhancement will do the following:

  • One will be able to restrict playback of certain parts of a particular stream - i.e. if a stream recorded on the nDVR goes from 9 - 9:30, we can programmatically (either on a Wowza level or player level) allow a particular user to access that stream from 9:15 to 9:30, but no earlier than 9:15?

Yes. A development build is posted that has the initial implementation: https://www.wowza.com/downloads/WowzaMediaServer-3-0-3/WowzaMediaServer3.0.3-patch2.zip

You can read an article about it here: Use Wowza nDVR Playlist request with the Wowza Streami

The intent is to programmatically be able to limit the playlist. It does not control that ‘startSeekTime’.

The implementation is based solely on ‘dvr=time’, meaning a DVR recording starts at time=0. In the future we hope to add additional functionality to map between different time bases.

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.

The playlist API is to provide the initial playlist request to the client. So the first playlist.m3u8 (iOS), Manifest (smooth), or manifest.f4m (Flash HDS) request by a given client coming in to the server. Different HTTP Streaming clients get updates to live streams in different ways, so I think your way of trying to trick into a seek time won’t work.

The playlist start and end times are based on the beginning recording time of DVR, which is time = 0.

SO, if you have a recording that has a 65 minute DVR window, and you’ve been recording to 120 minutes:

    • Your current playable recording’s time has a start time of time = 55:00 (120 minus 65).
    • If you want to provide a live playlist starting back in time 1 hour, you would create a playlist with a start time of 1:00:00 minutes, and no end time.
  • live means that user can continue to view newly recorded parts of the stream.

  • The players we use as examples, all start playing a live recording at the live point-- not one hour back

  • If you wish to provide a “non-live” playlist back in time one hour, you would create a playlist with a start time of 1:00:00 and an end time of 2:00:00.

  • "non-live/recorded means that the user can only view between the times specified.

  • The players we use as examples start playback of a recorded stream at the earliest time.

Few questions:

  1. If one is recording a live stream (and we have already completed 1 hour of the recording), and we want the playback from the beginning of the stream (and not at the current live point), I cannot understand why the start time must be 1:00:00. I would think that the start time should be “0”, because “0” is the DVR time of the beginning of the show. Alternatively, if “0” represents the current, live point, then shouldn’t the start time set to -60? (the negative 60 representing 60 minutes ago)?

  2. Please read my explanation again. The example I gave was a 2 hour recording in which you wanted to start one hour back.

In your case of a 1 hour recording and you want to start one hour back, yes the start time would be 0.

  1. Consider a hypothetical situation - a user wants to record 10 minutes prior to the show and 10 minutes after the show to account for shows that start early and/or end late (say football match over-runs). Now, the user has one recorded stream starting at 9 am going for 60 minutes (9am_to_10am_stream OR STREAM_1), and another stream starting at 10 am going for another 60 minutes (10am_to_11am_stream or STREAM_2). When the user tries to playback STREAM_2, is it possible to playback from STREAM_1 from minute 50 (i.e. 10 minutes prior to the end STREAM_1 and continue on to the 10am_to_11am_stream seamlessly and transparent to the user?

!

The playback URL for Wowza is for a single stream. So there’s currently not a way to combine 2 streams.

If I was implementing this, I would do it on the client side-- play URL1 followed by URL2.

Separately, what do you mean by “65 minute DVR window” and where is this “DVR window” setting specified?

See WindowDuration here: https://www.wowza.com/docs/how-to-set-up-and-run-wowza-ndvr-for-live-streaming

Hi Folks, I believe that during playback (using OSMF player) of a stream that is currently being recorded, the playback is from the live point. According to Adobe,

“If the stream is recording, OSMF always starts playback from the live point, regardless of the use of dvrInfo and windowDuration. This behavior is called “snap to live” and is new with OSMF 1.6”

With OSMF 1.5, the starting point was the beginning of the stream. I am curious if there is a way to disable this “Snap to live” function on a player level. It appears it is not a Wowza issue, and if anyone has done that, it would be greatly appreciated.

Someone earlier in this thread used the OSMF property “dvrSnapToLiveClockOffset” to snap it to the earliest time. I did not get this to work myself though.

I do not know of a way to change it (short of checking out the Strobe/OSMF project and changing the code).

I have the same problem…

I tried to open on ipad

http://ip:1935/nDvr/ts1.stream_360p/playlist.m3u8?DVR&wowzadvrplayliststart=60000

as of Use Wowza nDVR Playlist request with the Wowza Streami

but always starts at “live”

with bellow Application.xml

<Root>
	<Application>
		<!-- Uncomment to set application level timeout values
		<ApplicationTimeout>60000</ApplicationTimeout>
		<PingTimeout>12000</PingTimeout>
		<ValidationFrequency>8000</ValidationFrequency>
		<MaximumPendingWriteBytes>0</MaximumPendingWriteBytes>
		<MaximumSetBufferTime>60000</MaximumSetBufferTime>
		<MaximumStorageDirDepth>25</MaximumStorageDirDepth>
		-->
		<Connections>
			<AutoAccept>true</AutoAccept>
			<AllowDomains></AllowDomains>
		</Connections>
		<!--
			StorageDir path variables
			
			${com.wowza.wms.AppHome} - Application home directory
			${com.wowza.wms.ConfigHome} - Configuration home directory
			${com.wowza.wms.context.VHost} - Virtual host name
			${com.wowza.wms.context.VHostConfigHome} - Virtual host config directory
			${com.wowza.wms.context.Application} - Application name
			${com.wowza.wms.context.ApplicationInstance} - Application instance name
			
		-->
		<Streams>
			<StreamType>live</StreamType>
			<StorageDir>${com.wowza.wms.context.VHostConfigHome}/content</StorageDir>
			<KeyDir>${com.wowza.wms.context.VHostConfigHome}/keys</KeyDir>
			<!-- LiveStreamPacketizers (separate with commas): cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer, cupertinostreamingrepeater, smoothstreamingrepeater, sanjosestreamingrepeater, dvrstreamingpacketizer, dvrstreamingrepeater -->
			<LiveStreamPacketizers>cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer, dvrstreamingpacketizer</LiveStreamPacketizers>
			<!-- Properties defined here will override any properties defined in conf/Streams.xml for any streams types loaded by this application -->
			<Properties>
			</Properties>
		</Streams>
		<Transcoder>
			<!-- To turn on transcoder set to: transcoder -->
			<LiveStreamTranscoder>transcoder</LiveStreamTranscoder>
			<!-- [templatename].xml or ${SourceStreamName}.xml -->
			<Templates>${SourceStreamName}.xml,transcode.xml</Templates>
			<ProfileDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/profiles</ProfileDir>
			<TemplateDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/templates</TemplateDir>
			<Properties>
			</Properties>
		</Transcoder>
		<DVR>
			<!-- As a single server or as an origin, use dvrstreamingpacketizer in LiveStreamPacketizers above -->
			<!-- Or, in an origin-edge configuration, edges use dvrstreamingrepeater in LiveStreamPacketizers above -->
			<!-- As an origin, also add dvrchunkstreaming to HTTPStreamers below -->
			<!-- To turn on DVR recording set Recorders to dvrrecorder.  This works with dvrstreamingpacketizer  -->
			<Recorders>dvrrecorder</Recorders>
			<!-- As a single server or as an origin, set the Store to dvrfilestorage-->
			<!-- edges should have this empty --> -->
			<Store>dvrfilestorage</Store>
			<!--  Window Duration is length of live DVR window in seconds.  0 means the window is never trimmed. -->
			<WindowDuration>0</WindowDuration>
			<!-- Storage Directory is top level location where dvr is stored.  e.g. c:/temp/dvr -->
			<StorageDir>${com.wowza.wms.context.VHostConfigHome}/dvr</StorageDir>
			<!-- valid ArchiveStrategy values are append, version, delete -->
			<ArchiveStrategy>append</ArchiveStrategy>
			<!-- If this is a dvrstreamingrepeater, define ChunkOriginURL to point back to origin -->
			<!-- And define Application/Repeater/OriginURL to point back to the origin -->
			<Repeater>
				<ChunkOriginURL></ChunkOriginURL>
			</Repeater>
			<!-- Properties for DVR -->
			<Properties>
				<Property>
					<Name>dvrPlaylistRequestDelegate</Name>
					<Value>com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRequestDelegate</Value>
				</Property>
				<Property>
					<Name>dvrPlaylistDurationQueryParameter</Name>
					<Value>wowzadvrplaylistduration</Value>
				</Property>	
				<Property>
					<Name>dvrPlaylistStartQueryParameter</Name>
					<Value>wowzadvrplayliststart</Value>
				</Property>	
			</Properties>
		</DVR>
		<!-- HTTPStreamers (separate with commas): cupertinostreaming, smoothstreaming, sanjosestreaming, dvrchunkstreaming -->
		<HTTPStreamers>cupertinostreaming,smoothstreaming,sanjosestreaming</HTTPStreamers>
		<SharedObjects>
			<StorageDir></StorageDir>
		</SharedObjects>
		<Client>
			<IdleFrequency>-1</IdleFrequency>
			<Access>
				<StreamReadAccess>*</StreamReadAccess>
				<StreamWriteAccess>*</StreamWriteAccess>
				<StreamAudioSampleAccess></StreamAudioSampleAccess>
				<StreamVideoSampleAccess></StreamVideoSampleAccess>
				<SharedObjectReadAccess>*</SharedObjectReadAccess>
				<SharedObjectWriteAccess>*</SharedObjectWriteAccess>
			</Access>
		</Client>
		<RTP>
			<!-- RTP/Authentication/[type]Methods defined in Authentication.xml. Default setup includes; none, basic, digest -->
			<Authentication>
				<PublishMethod>digest</PublishMethod>
				<PlayMethod>none</PlayMethod>
			</Authentication>
			<!-- RTP/AVSyncMethod. Valid values are: senderreport, systemclock, rtptimecode -->
			<AVSyncMethod>senderreport</AVSyncMethod>
			<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>
			<IdleFrequency>75</IdleFrequency>
			<RTSPSessionTimeout>90000</RTSPSessionTimeout>
			<RTSPMaximumPendingWriteBytes>0</RTSPMaximumPendingWriteBytes>
			<RTSPBindIpAddress></RTSPBindIpAddress>
			<RTSPConnectionIpAddress>0.0.0.0</RTSPConnectionIpAddress>
			<RTSPOriginIpAddress>127.0.0.1</RTSPOriginIpAddress>
			<IncomingDatagramPortRanges>*</IncomingDatagramPortRanges>
			<!-- Properties defined here will override any properties defined in conf/RTP.xml for any depacketizers loaded by this application -->
			<Properties>
			</Properties>
		</RTP>
		<MediaCaster>
			<!-- Properties defined here will override any properties defined in conf/MediaCasters.xml for any MediaCasters loaded by this applications -->
			<Properties>
			</Properties>
		</MediaCaster>
		<MediaReader>
			<!-- Properties defined here will override any properties defined in conf/MediaReaders.xml for any MediaReaders loaded by this applications -->
			<Properties>
			</Properties>
		</MediaReader>
		<MediaWriter>
			<!-- Properties defined here will override any properties defined in conf/MediaWriter.xml for any MediaWriter loaded by this applications -->
			<Properties>
			</Properties>
		</MediaWriter>
		<LiveStreamPacketizer>
			<!-- Properties defined here will override any properties defined in conf/LiveStreamPacketizers.xml for any LiveStreamPacketizers loaded by this applications -->
			<Properties>
			</Properties>
		</LiveStreamPacketizer>
		<HTTPStreamer>
			<!-- Properties defined here will override any properties defined in conf/HTTPStreamers.xml for any HTTPStreamer loaded by this applications -->
			<Properties>
			</Properties>
		</HTTPStreamer>
		<Repeater>
			<OriginURL></OriginURL>
			<QueryString><=!=[=C=D=A=T=A=[]=]=></QueryString>
		</Repeater> 
		<Modules>
			<Module>
				<Name>base</Name>
				<Description>Base</Description>
				<Class>com.wowza.wms.module.ModuleCore</Class>
			</Module>
			<Module>
				<Name>properties</Name>
				<Description>Properties</Description>
				<Class>com.wowza.wms.module.ModuleProperties</Class>
			</Module>
			<Module>
				<Name>logging</Name>
				<Description>Client Logging</Description>
				<Class>com.wowza.wms.module.ModuleClientLogging</Class>
			</Module>
			<Module>
				<Name>flvplayback</Name>
				<Description>FLVPlayback</Description>
				<Class>com.wowza.wms.module.ModuleFLVPlayback</Class>
			</Module> 
		</Modules>
		<!-- Properties defined here will be added to the IApplication.getProperties() and IApplicationInstance.getProperties() collections -->
		<Properties>
		</Properties>
	</Application>
</Root>

I am using

3.0.3 build882
INFO server comment - OS Name: Windows 7
INFO server comment - OS Version: 6.1
INFO server comment - OS Architecture: amd64
INFO server comment - OS CPU: amd64
INFO server comment - Java Name: Java HotSpot(TM) 64-Bit Server VM

Another question, can the same queries apply to rtsp streams ? I think I haven’t seen any dvr examples apart from http.

Note that playlist start determines what portion of your available playlist is available for playback, not what the seek start time is.

So your request “&wowzadvrplayliststart=60000” will clip the available playlist starting at time=60 seconds.

Both iOS and Strobe players start playing a live stream at the live point and a non-live stream at the earliest known point in the stream.

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?

Not sure about action script versus javascript support.

As I’m sure you know, Strobe is built on OSMF. Our examples should work with OSMF but our DVR testing has been done primarily with Strobe.

In our examples, the examples/LiveVideoStreaming/clientOSMF is an OSMF player that I have used with DVR from time to time. Just use a DVR-ish URL in it.

I am a bit confused, is there a way to apply traditional time-shifted functionality ? e.g I have 2 days recording and I want to allow the user via EPG to select a program from yesterday.

I don’t want to show the whole available seek bar, just a chunk that reflects the EPG entry and start playing from the beginning of it.

As I understand there is no functionality to select by date-time yet (correct if I am wrong). What I am looking is more like VOD for the DVR store.

Any guidelines to get started ? Since the content is already recorded shouldn’t be easy to stream it ?

Yes you can do that. A couple things to know.

The playlist start and end times are different than the initial playback seek time. (The point where the players start playback of the stream)

The players (iOS and Strobe/OSMF) play back content that has a known end starting at the earliest time.

However, if the stream is still recording, its a live stream and the players start playing at the live point.

So in the case you presented, it looks like you were still actively recording and you said start playing at dvrTime=60 seconds.

Wowza sent a playlist to the player that started at time=60 but with no end, and since its recording still, the playlist is presented as a live playlist, which means there is more data coming so be prepared to receive it.

However, if you also specify a duration in your URL:

&wowzadvrplayliststart=60000&wowzadvrplaylistduration=300000

then the playlist sent to the player will have an end point and the player will only know about the recording from time 1:00 to 6:00. It will start the playback at time 1:00 and will not be expecting new live data to be sent.

Scott

p.s. Yes, selecting by packetTime and ‘real Time’ is not there but coming. It will likely be via Java API only initially.

Note: I originally incorrectly advised using wowzadvrplaylistend but this param does not exist. Instead the correct answer was wowzadvrplaylistduration. I’ve edited the post with the correct information. Scott


Thanks Scott for the reply.

However I still can’t get it to work… skips to live

but just to be sure, in the page it says so I don’t have to compile any code right?

Correct, you don’t have to compile any code. You do have the latest version? And the times specified in the URL exist, right?

Why don’t you send an email to support@wowza. We can look at your logs and config. Reference this thread. Describe what happens briefly (again). Attach your conf/ and logs/ file zipped up.

It would be really helpful if you could also get the playlist that is returned. Instead of putting the URL in your your iOS device, put it in a browser

Browser:

http://IP:1935/nDvr/ts1.stream_360p/playlist.m3u8?DVR&wowzadvrplayliststart=10000&wowzadvrplaylistduration=50000

This will return a playlist that has the URL in it again except with a wowzasessionID in it. Cut this wowzasessionid out and re-enter the URL (like this except with the returned session ID in it)

Browser:

http://IP:1935/nDvr/ts1.stream_360p/playlist.m3u8?wowzasessionid=1622247448&DVR&wowzadvrplaylistduration=50000&wowzadvrplayliststart=10000

This will return a playlist that looks something like this. Attach that to the email too.

#EXTM3U

#EXT-X-ALLOW-CACHE:NO

#EXT-X-TARGETDURATION:4

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-ENDLIST

#EXTINF:3,

dvr_0.ts?wowzasessionid=1622247448&DVR&wowzadvrplaylistduration=50000&wowzadvrplayliststart=10000

#EXTINF:3,

. . .

Thanks Scott for the reply.

However I still can’t get it to work… skips to live

http://IP:1935/nDvr/ts1.stream_360p/playlist.m3u8?DVR&wowzadvrplayliststart=10000&wowzadvrplaylistend=50000

I told you wrong information. The params are wowzadvrplayliststart and wowzadvrplaylistduration NOT wowzadvrplaylistend.

And the properties used to set the identifiers are dvrPlaylistStartQueryParameter and dvrPlaylistDurationQueryParameter, NOT dvrPlaylistEndQueryParameter. In fact you don’t need to even add these two properties unless you want to use different names in your URL.

If you just want to use the defaults, you don’t even need to set these. You can just do this:

In Application.xml, have this:

<Properties>
    <Property>
        <Name>dvrPlaylistRequestDelegate</Name>
        <Value>com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRequestDelegate</Value>
    </Property>
</Properties>

Then for the URL use this:

http://host:1935/app/Stream/playlist.m3u8?DVR&wowzadvrplayliststart=10000&[B]wowzadvrplaylistduration[/B]=100000

Note that end = start + duration. So its a bit different.

And if you want to use different values in the URL, then do this:

<Properties>
    <Property>
        <Name>dvrPlaylistRequestDelegate</Name>
        <Value>com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRequestDelegate</Value>
    </Property>
    <Property>
        <Name>dvrPlaylistDurationQueryParameter</Name>
        <Value>dvrDuration</Value>
    </Property>
    <Property>
        <Name>dvrPlaylistStartQueryParameter</Name>
       <Value>dvrStart</Value>
    </Property>
</Properties>

And then do this:

http://host:1935/app/Stream/playlist.m3u8?DVR&dvrStart=10000&dvrDuration=100000

I have the same problem…

I tried to open on ipad

http://ip:1935/nDvr/ts1.stream_360p/playlist.m3u8?DVR&wowzadvrplayliststart=60000

as of https://www.wowza.com/docs/how-to-use-wowza-ndvr-playlist-request-api

but always starts at “live”

with bellow Application.xml

<Root>
	<Application>
		<!-- Uncomment to set application level timeout values
		<ApplicationTimeout>60000</ApplicationTimeout>
		<PingTimeout>12000</PingTimeout>
		<ValidationFrequency>8000</ValidationFrequency>
		<MaximumPendingWriteBytes>0</MaximumPendingWriteBytes>
		<MaximumSetBufferTime>60000</MaximumSetBufferTime>
		<MaximumStorageDirDepth>25</MaximumStorageDirDepth>
		-->
		<Connections>
			<AutoAccept>true</AutoAccept>
			<AllowDomains></AllowDomains>
		</Connections>
		<!--
			StorageDir path variables
			
			${com.wowza.wms.AppHome} - Application home directory
			${com.wowza.wms.ConfigHome} - Configuration home directory
			${com.wowza.wms.context.VHost} - Virtual host name
			${com.wowza.wms.context.VHostConfigHome} - Virtual host config directory
			${com.wowza.wms.context.Application} - Application name
			${com.wowza.wms.context.ApplicationInstance} - Application instance name
			
		-->
		<Streams>
			<StreamType>live</StreamType>
			<StorageDir>${com.wowza.wms.context.VHostConfigHome}/content</StorageDir>
			<KeyDir>${com.wowza.wms.context.VHostConfigHome}/keys</KeyDir>
			<!-- LiveStreamPacketizers (separate with commas): cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer, cupertinostreamingrepeater, smoothstreamingrepeater, sanjosestreamingrepeater, dvrstreamingpacketizer, dvrstreamingrepeater -->
			<LiveStreamPacketizers>cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer, dvrstreamingpacketizer</LiveStreamPacketizers>
			<!-- Properties defined here will override any properties defined in conf/Streams.xml for any streams types loaded by this application -->
			<Properties>
			</Properties>
		</Streams>
		<Transcoder>
			<!-- To turn on transcoder set to: transcoder -->
			<LiveStreamTranscoder>transcoder</LiveStreamTranscoder>
			<!-- [templatename].xml or ${SourceStreamName}.xml -->
			<Templates>${SourceStreamName}.xml,transcode.xml</Templates>
			<ProfileDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/profiles</ProfileDir>
			<TemplateDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/templates</TemplateDir>
			<Properties>
			</Properties>
		</Transcoder>
		<DVR>
			<!-- As a single server or as an origin, use dvrstreamingpacketizer in LiveStreamPacketizers above -->
			<!-- Or, in an origin-edge configuration, edges use dvrstreamingrepeater in LiveStreamPacketizers above -->
			<!-- As an origin, also add dvrchunkstreaming to HTTPStreamers below -->
			<!-- To turn on DVR recording set Recorders to dvrrecorder.  This works with dvrstreamingpacketizer  -->
			<Recorders>dvrrecorder</Recorders>
			<!-- As a single server or as an origin, set the Store to dvrfilestorage-->
			<!-- edges should have this empty --> -->
			<Store>dvrfilestorage</Store>
			<!--  Window Duration is length of live DVR window in seconds.  0 means the window is never trimmed. -->
			<WindowDuration>0</WindowDuration>
			<!-- Storage Directory is top level location where dvr is stored.  e.g. c:/temp/dvr -->
			<StorageDir>${com.wowza.wms.context.VHostConfigHome}/dvr</StorageDir>
			<!-- valid ArchiveStrategy values are append, version, delete -->
			<ArchiveStrategy>append</ArchiveStrategy>
			<!-- If this is a dvrstreamingrepeater, define ChunkOriginURL to point back to origin -->
			<!-- And define Application/Repeater/OriginURL to point back to the origin -->
			<Repeater>
				<ChunkOriginURL></ChunkOriginURL>
			</Repeater>
			<!-- Properties for DVR -->
			<Properties>
				<Property>
					<Name>dvrPlaylistRequestDelegate</Name>
					<Value>com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRequestDelegate</Value>
				</Property>
				<Property>
					<Name>dvrPlaylistDurationQueryParameter</Name>
					<Value>wowzadvrplaylistduration</Value>
				</Property>	
				<Property>
					<Name>dvrPlaylistStartQueryParameter</Name>
					<Value>wowzadvrplayliststart</Value>
				</Property>	
			</Properties>
		</DVR>
		<!-- HTTPStreamers (separate with commas): cupertinostreaming, smoothstreaming, sanjosestreaming, dvrchunkstreaming -->
		<HTTPStreamers>cupertinostreaming,smoothstreaming,sanjosestreaming</HTTPStreamers>
		<SharedObjects>
			<StorageDir></StorageDir>
		</SharedObjects>
		<Client>
			<IdleFrequency>-1</IdleFrequency>
			<Access>
				<StreamReadAccess>*</StreamReadAccess>
				<StreamWriteAccess>*</StreamWriteAccess>
				<StreamAudioSampleAccess></StreamAudioSampleAccess>
				<StreamVideoSampleAccess></StreamVideoSampleAccess>
				<SharedObjectReadAccess>*</SharedObjectReadAccess>
				<SharedObjectWriteAccess>*</SharedObjectWriteAccess>
			</Access>
		</Client>
		<RTP>
			<!-- RTP/Authentication/[type]Methods defined in Authentication.xml. Default setup includes; none, basic, digest -->
			<Authentication>
				<PublishMethod>digest</PublishMethod>
				<PlayMethod>none</PlayMethod>
			</Authentication>
			<!-- RTP/AVSyncMethod. Valid values are: senderreport, systemclock, rtptimecode -->
			<AVSyncMethod>senderreport</AVSyncMethod>
			<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>
			<IdleFrequency>75</IdleFrequency>
			<RTSPSessionTimeout>90000</RTSPSessionTimeout>
			<RTSPMaximumPendingWriteBytes>0</RTSPMaximumPendingWriteBytes>
			<RTSPBindIpAddress></RTSPBindIpAddress>
			<RTSPConnectionIpAddress>0.0.0.0</RTSPConnectionIpAddress>
			<RTSPOriginIpAddress>127.0.0.1</RTSPOriginIpAddress>
			<IncomingDatagramPortRanges>*</IncomingDatagramPortRanges>
			<!-- Properties defined here will override any properties defined in conf/RTP.xml for any depacketizers loaded by this application -->
			<Properties>
			</Properties>
		</RTP>
		<MediaCaster>
			<!-- Properties defined here will override any properties defined in conf/MediaCasters.xml for any MediaCasters loaded by this applications -->
			<Properties>
			</Properties>
		</MediaCaster>
		<MediaReader>
			<!-- Properties defined here will override any properties defined in conf/MediaReaders.xml for any MediaReaders loaded by this applications -->
			<Properties>
			</Properties>
		</MediaReader>
		<MediaWriter>
			<!-- Properties defined here will override any properties defined in conf/MediaWriter.xml for any MediaWriter loaded by this applications -->
			<Properties>
			</Properties>
		</MediaWriter>
		<LiveStreamPacketizer>
			<!-- Properties defined here will override any properties defined in conf/LiveStreamPacketizers.xml for any LiveStreamPacketizers loaded by this applications -->
			<Properties>
			</Properties>
		</LiveStreamPacketizer>
		<HTTPStreamer>
			<!-- Properties defined here will override any properties defined in conf/HTTPStreamers.xml for any HTTPStreamer loaded by this applications -->
			<Properties>
			</Properties>
		</HTTPStreamer>
		<Repeater>
			<OriginURL></OriginURL>
			<QueryString><![CDATA[]]></QueryString>
		</Repeater> 
		<Modules>
			<Module>
				<Name>base</Name>
				<Description>Base</Description>
				<Class>com.wowza.wms.module.ModuleCore</Class>
			</Module>
			<Module>
				<Name>properties</Name>
				<Description>Properties</Description>
				<Class>com.wowza.wms.module.ModuleProperties</Class>
			</Module>
			<Module>
				<Name>logging</Name>
				<Description>Client Logging</Description>
				<Class>com.wowza.wms.module.ModuleClientLogging</Class>
			</Module>
			<Module>
				<Name>flvplayback</Name>
				<Description>FLVPlayback</Description>
				<Class>com.wowza.wms.module.ModuleFLVPlayback</Class>
			</Module> 
		</Modules>
		<!-- Properties defined here will be added to the IApplication.getProperties() and IApplicationInstance.getProperties() collections -->
		<Properties>
		</Properties>
	</Application>
</Root>

I am using

3.0.3 build882
INFO server comment - OS Name: Windows 7
INFO server comment - OS Version: 6.1
INFO server comment - OS Architecture: amd64
INFO server comment - OS CPU: amd64
INFO server comment - Java Name: Java HotSpot(TM) 64-Bit Server VM

Another question, can the same queries apply to rtsp streams ? I think I haven’t seen any dvr examples apart from http.

Note that playlist start determines what portion of your available playlist is available for playback, not what the seek start time is.

So your request “&wowzadvrplayliststart=60000” will clip the available playlist starting at time=60 seconds.

Both iOS and Strobe players start playing a live stream at the live point and a non-live stream at the earliest known point in the stream.

I am a bit confused, is there a way to apply traditional time-shifted functionality ? e.g I have 2 days recording and I want to allow the user via EPG to select a program from yesterday.

I don’t want to show the whole available seek bar, just a chunk that reflects the EPG entry and start playing from the beginning of it.

As I understand there is no functionality to select by date-time yet (correct if I am wrong). What I am looking is more like VOD for the DVR store.

Any guidelines to get started ? Since the content is already recorded shouldn’t be easy to stream it ?

Thanks Scott for the reply.

However I still can’t get it to work… skips to live

http://IP:1935/nDvr/ts1.stream_360p/playlist.m3u8?DVR&wowzadvrplayliststart=10000&wowzadvrplaylistend=50000

changed to these in Application :

			<!-- Properties for DVR -->
			<Properties>
				<Property>
					<Name>dvrPlaylistRequestDelegate</Name>
					<Value>com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRequestDelegate</Value>
				</Property>
				<Property>
					<Name>dvrPlaylistEndQueryParameter</Name>
					<Value>wowzadvrplaylistend</Value>
				</Property>	
				<Property>
					<Name>dvrPlaylistStartQueryParameter</Name>
					<Value>wowzadvrplayliststart</Value>
				</Property>	
			</Properties>

but just to be sure, in the page it says

Wowza nDVR includes one playlist request delegate: “com.wowza.wms.dvr.impl.DvrStartDurationPlaylistRe questDelegate”

so I don’t have to compile any code right?

Scott, I have been following this thread and been wondering if this enhancement will do the following:

  1. For a currently being recorded stream (say the stream records from 9 to 9:30, but it is only 9:15 at the moment). Can I ensure that if a particular user tries to playback the stream, it “snaps to” 9:10 (i.e. 10 minutes from the beginning of the stream OR a 5 minute offset from the current “live” point, which is 9:15). Besides, the user cannot rewind any earlier than 9:10.

  2. For a stream already recorded (say it is 9:30 now and the full stream has been recorded from 9 to 9:30) - can I ensure that when a user attempts to playback the stream it “snaps to” 9:10 (i.e. 10 minutes after the beginning of the stream)

Thanks!

If you want to provide a live playlist starting back in time 1 hour, you would create a playlist with a start time of 1:00:00 minutes, and no end time.

Few questions:

  1. If one is recording a live stream (and we have already completed 1 hour of the recording), and we want the playback from the beginning of the stream (and not at the current live point), I cannot understand why the start time must be 1:00:00. I would think that the start time should be “0”, because “0” is the DVR time of the beginning of the show. Alternatively, if “0” represents the current, live point, then shouldn’t the start time set to -60? (the negative 60 representing 60 minutes ago)?

  2. Consider a hypothetical situation - a user wants to record 10 minutes prior to the show and 10 minutes after the show to account for shows that start early and/or end late (say football match over-runs). Now, the user has one recorded stream starting at 9 am going for 60 minutes (9am_to_10am_stream OR STREAM_1), and another stream starting at 10 am going for another 60 minutes (10am_to_11am_stream or STREAM_2). When the user tries to playback STREAM_2, is it possible to playback from STREAM_1 from minute 50 (i.e. 10 minutes prior to the end STREAM_1 and continue on to the 10am_to_11am_stream seamlessly and transparent to the user?

Separately, what do you mean by “65 minute DVR window” and where is this “DVR window” setting specified?

Thanks!

Hi Folks, I believe that during playback (using OSMF player) of a stream that is currently being recorded, the playback is from the live point. According to Adobe,

“If the stream is recording, OSMF always starts playback from the live point, regardless of the use of dvrInfo and windowDuration. This behavior is called “snap to live” and is new with OSMF 1.6”

With OSMF 1.5, the starting point was the beginning of the stream. I am curious if there is a way to disable this “Snap to live” function on a player level. It appears it is not a Wowza issue, and if anyone has done that, it would be greatly appreciated.