Apple HTTP Streaming + Wowza nDVR

This should already work fine with the adaptive provider and the Apple HLS output of Wowza DVR.

Pausing/resuming the DVR stream will work, only seeking in the window is not possible at present. I'd be happy to get some ideas on how that could work in the UI.

Hi JeroenW

How about following the same UI setup as described here:
http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/12398/enabling-dvr-streaming

Maybe add a new button called "Go-Live".

Any time line on the Adaptive provider, release month/year?

Yes, I think that functionality would work if the window is set to 0 (entire history available). If not, it's harder b/c the the player then has to display the live window tail too.

At present, we don't have any plans for rolling the Adaptive provider into the default player. That's mostly a matter of third-party ecosystem support. Once more encoders, streaming servers (FMS) and devices (Android) support it, we will release it.

Is the adaptive provider stable enough for a production environment ?

The window setting you reference to, is that something that is set on the server side ?

The adaptive provider is very stable in combination with Wowza. Do note users need to have Flash Player 10.1 at least (Stats: http://riastats.com/).

The window duration is indeed a server side setting.

WindowDuration ofc :)

Happy new year :)

@JeroenW: "Pausing/resuming the DVR stream will work, only seeking in the window is not possible at present. I'd be happy to get some ideas on how that could work in the UI."

I have now tested JWplayer 5.8 with new Wowza 3.0.3 using the adaptive provider.

Any plans on adding support for seeking in the window (like rtmp dvr)?

Is it possible to send jwplayer.seek(-1000) ?

Well, if you have any ideas on how that could work in the UI, I'd be happy to hear! For now, the only thing that's supported is "pausing", meaning that the stream resumes at the point you paused (and not the live head). There's no "scrubbing" functionality for DVR.

How about something like this:

By default, when using a DVR-enabled liive(spam filter blocks live, HAHA) stream, the duration will grow as the stream records more time-shifted content,
and the user can seek to the live portion of the stream by scrubbing to the end of it.

The controlbar in this instance looks like it's playing a normal HTTP :) stream, although the duration constantly updates.

http://www.longtailvideo.com/support/sites/default/files/FMSDVR_4.png

Don't know if this is possible, but the Adobe strobe player does this very well with Adobe HTTP streaming.

Maybe add a function like this:
http.dvr = true

Adobe Strobe Media playback sample running against Wowza 3.0.3 streaming Adobe HTTP streaming.

Yes, I believe something like that should work. We do that for RTMP DVR too indeed.

The only question is what to do when a certain window is defined (e.g. 30 seconds). Do we then dynamically change the start of the black bar in the controls too? Or do we simply keep it black from the start and then simply correct for seeks beyond the time window?

It may be a matter of testing what works nicest ...

Hi Guys.

Just jumping on this thread as it is the closest i have found to the issue i am facing at the moment.

It would seem that programatically calling seek when using the adaptive providor does not take the play head to the correct time, instead it seems to take it to the beginning of the chunk.

has anybody else experienced this issue do you know?

This is correct. The provider seeks to the start of a chunk and not to a specific frame. Frame-accurate seeking is not possible in Flash, unfortunately.

Hi Jeroen

Thanks for answering my question.

Can you explain further why seeking seems to work properly when moving the progress bar on the control area but not when using the seek method in javascript?

i m hoping that there will be a workaround as would love to use your adaptive provider to get around corporate firewalls that block rtmp ?

thanks again for you help..

Seeking with the controlbar should result in the same behavior as seeking with the API. The controlbar is internally just a plugin that uses the API - at least in Flash.

On the iPad, we use the built-in controls, and maybe Apple is giving some finer grained control over searching. But I believe you mean Flash?

If it's indeed different in Flash, do you have an example URL?

Sure Jeroen,

I have set up a couple of players for you to have a look at, cheers :)

this one uses rtmp for flash falling back to progressive download.

http://avtplatform.avtclient.co.uk/VMP/155088f4-6a38-4579-8510-2ac4062673c6

this one is using your new adaptive providor with an hls stream from a wowza server for flash and falls back to html5 and hls if flash is not present.

http://avtplatform.avtclient.co.uk/VMP/test/155088f4-6a38-4579-8510-2ac4062673c6

i am putting out debug information via console log that you can look at in firebug.

you will hopefully notice that instigating a seek command via clicking on a new slide after using the slider works correctly using rtmp but not on the hls based player.

in this case a seek command goes to the begining of a chunk , which seems to be dirrerent behaviour than is exhibited when using the controlbar.

is this as expected do you think.

once again , thanks for looking into this for us. :)

Andy

This is indeed as expected. RTMP can seek frame-accurate, but HLS unfortunately not yet. Maybe we can add that at a certain point, but I'm not sure how to do that yet.

Okay - thanks for this, i would be very interested if this can be added since at the moment i cannot use hls for this kind of player which would be kinda neat.

all the best

Andy

actually , thinking about it , that still does nt anser the question of why the control bar seeks correctly ,, is this using a different set of function calls?

On the iPad, we use the system built-in controlbar. That controlbar indeed talks directly to the iOS media engine, while on desktop the controls takl to the Flash media engine.

thanks for the info, you certainly know your stuff , in fact i have noticed your name on some of the jwplayer namespaces :).

i assume that jwplayer.seek() talks to the same media engine , i m just confused that the control bar seems to work correctly whilst the javascript call can only go to the beginning of the chunk.

oh i get it now , the control bar will only let the user seek to the beginning of a chuck, in my example every ten seconds so 1:11, 1:21, 1:31 , any other point of time cannot be selected..

andy

Have you checked the Key frame setting in your encoder ?

In wirecast the standard setting is 240, try setting it to 50/60(pal/ntsc)