NDVR with nonzero Window Duration

[ozgurdeniz]

Hello,

We have been using Wowza NDVR with a window duration of 0 succesfully for a few months. Now we need to limit the nDVR window. We have set the WindowDuration to 3600 in our Application.xml.
Using the LiveDVRStreaming example with strobe player in Wowza distribution, the current time indicator in the seek bar shows some erratic behaviour for non zero window duration.
First it moves forward as expected and then suddenly jumps back in time and then starts moving forward again, this is repeated as long as the stream is being played. This problem is not present when the window duration is 0.
While debugging, we have noticed that the currentTime method of strobe player returns inconsistent values. For instance for a window duration of 3600, the current time method initially
returns something around 3590 (reasonable) it then decreases significantly before increasing back again.

Can anybody tell us what might be causing this problem?

Best Regards,
Özgür Deniz Önür

P.S
We are using strobe player 1.6.
nDVR params
Archive Strategy -delete
Record On Startup -true

[ScottKell]

Hello,

We have been using Wowza NDVR with a window duration of 0 succesfully for a few months. Now we need to limit the nDVR window. We have set the WindowDuration to 3600 in our Application.xml.
Using the LiveDVRStreaming example with strobe player in Wowza distribution, the current time indicator in the seek bar shows some erratic behaviour for non zero window duration.
First it moves forward as expected and then suddenly jumps back in time and then starts moving forward again, this is repeated as long as the stream is being played. This problem is not present when the window duration is 0.
While debugging, we have noticed that the currentTime method of strobe player returns inconsistent values. For instance for a window duration of 3600, the current time method initially
returns something around 3590 (reasonable) it then decreases significantly before increasing back again.

Can anybody tell us what might be causing this problem?

Best Regards,
Özgür Deniz Önür

P.S
We are using strobe player 1.6.
nDVR params
Archive Strategy -delete
Record On Startup -true

The Strobe player is a bit odd in this regard. The current play time is a delta into the current DVR recording. So if the current time is 1:20 of a 30:00 recording. When say 10 seconds drops off the front of the window, the current time jumps to 1:10 because the current time is now 1:10 into the 30:00 window.

One option would be to leverage the OSMF/Strobe player (it's open source) and modify the behavior of the scrub bar. Clearly this isn't an easy answer, but its an option.

[ozgurdeniz]

Hello Scott,

Thank you for the answer. We have already done what you have suggested.
We implemented our own seekbar.
if the strobe duration is less than the Wowza WindowDuration (This is the case when the stream is first started ) we do not change the original strobe behaviour.
After the strobe duration is equal to WowzaDuration (i.e. the DVR window is full of video data):
We get the system time and subtract the total window duration to get the current dvr start time.
Then we add the strobe players current time to obtain the current position.
This algorithm should correct the issue that you have pointed out.

However even in this scenario the current position indicator is not moving as expected.
Still it seems to move forward and then abruptly moves back before starting to move again

Our guess is that strobe does not correctly determine the amount of shift in the nDVR window.
It either detects it too late or gets the amount wrong.

It is also possible that our algorithm that i described above is flawed.

Can you give us any insight on this?

Regards,
Özgür

[ScottKell]

I'm not sure I have any more insight.

In the default player, the behavior seems to me to be related to when the player gets a new set of chunks, if something has fallen off the the front, this is when the jerk occurred. So I wonder if this jerk still occurs in the underlying values you have built your algorithm on top of.

You might add some logging to the abst parsing code in OSMF to see what values it gets for window duration and when it changes.
Sorry I don't have any more insight than this.