Wowza Community

RTMP with Progress Download Cache

Is there any way to achieve the complete YouTube experience by letting the stream buffer ahead of where the user is playing so that High Bandwidth users can skip ahead to already buffered areas without the unnecessary “pause while seek” problem?

Basically, stream WITH progressive download.

I have tried several combinations of what I think should work but I’m still stuck trying to figure this out.

There is no messaging from the client to the server to indicate the fullness of the buffer. I am not sure what you are trying to achieve. You don’t have control of the playback speed in the player. Wowza Pro will attempt to keep the buffer full but it is doing it blindly. It knows the size of the buffer but not the fullness at any point in time.

Charlie

It will work if you use the FastPlay module. You can read about it in the User’s Guide and see it in action in the FastPlayVideoStreaming example. If you set the playback rate (multiplier) to 4 and set the frame rate to a super high value like 30000 then it will playback all the frames at 4x the speed. Give that a try. It should just work.

Charlie

You are right. It is. Well, then I guess it won’t work. I will think about it.

Charlie

Not really because youtube using progressive download is writing to disk to achieve that feature, and that doesn’t happen in streaming. You can make the stream buffer as small as possible to optimize seek, because filling this buffer is what is creating the lag.

netstream.bufferTime=.5; //half second

Sure, if you download and install the free MySpeed Plug-in for Flash from our website, you’ll see exactly what I mean. This software controls the playback speed of the flash player. You can get it from this url: http://www.enounce.com. Once installed just try to use the software to speed up playback of any streamed flash media. Websites like YouTube, CNN, FoxNews ABC News that use progressive download work great.

We honor the NetStream.setBufferTime(secs) setting and will fill the client side buffer as quickly as we can. After that we throttle the content to match the bitrate of the content.

We also support trick play (fast forward, fast rewind and slow motion) of VP6 and Sorenson Squeeze content (we do not support this for H.264 content as of yet). You see this in action with the FastPlayVideoStreaming example that ships with Wowza Pro.

Charlie

Now it makes more sense. We do not currently have a way to do this. The server runs based on a millisecond clock. It will send extra data to fill the client side buffer then it will stream at a constant rate. I need to think about it more. I don’t currently have an API for making this work.

Charlie

We support buffering. You can set a client side buffer by setting the NetStream.bufferTime value in your player. It is described here:

http://livedocs.adobe.com/fms/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000594.html

This thread is talking about increasing the playback rate to play the stream back at faster then real-time (including audio).

Charlie

Wowza Server sends a burst to fill buffer:

http://www.wowza.com/forums/showthread.php?t=5658#2

Richard

Along the same lines as the initial question, is there a setting that will allow the streamed content to fill the buffer faster than what is needed for a particular stream bitrate. Real Server used to have a feature their developers called the Acceleration buffer and the real server would stream out content up to 4 times the content bitrate to fill the buffer faster.

The reason you would want this is, lets say you had a flash player that could speed up the audio/video on the player side. If the server only streams a 300 kbps stream at 300 kbps and your player can play that content faster, you’ll continually run the buffer dry but if the server allows the buffer to fill at 4x the bitrate, say 1.2 Mbps, then you would be able to play that content continuously at speeds up to 4 times normal speed. Windows Media Server 7 used to have this same problem and it was corrected in WMS 9.

Is there a config setting in Wowza that limits the bandwith for a stream to the bitrate of the content? If so, can this be set to allow a higher bandwidth per connection so that the buffer can refill faster and keep up with faster playing content.

… After that we throttle the content to match the bitrate of the content. …

Charlie

I take that to mean that after the buffer is filled initially and the content starts to play, the bandwidth is throttled back to match the bitrate of the content and won’t try to keep the buffer full? Is that because the player doesn’t communicate to the server that the buffer is running low so the player is either playing or buffering? Is that a limitation of the Flash Player or the server?

It would probably be easier to understand the reason for my line of questioning if you saw the software in action and experienced the same problem that many students are seeing. Since 2000 our company has sold Plug-Ins for Real Player and Windows Media Player that allow users to speed up or slow down the content while maintaining natural sounding audio (so the speech doesn’t sound like the chipmunks). These products are used by 1000s of students to watch lecutres streamed in Real or Windows Media format. Recently we release a new product for Flash that does the same thing. You can imagine this is a big hit for students watching University lectures that are now delivered with system like Echo360. Our product works great if the progressive download method is used but not if the content is streamed. As I said initially, Real Server (rtsp) never had this problem because of their “acceleration buffer” and Windows Media (mms) corrected this with Windows Media Server 9. I encourage you to take a look so you can see what the students see when they try to speed up streamed content. (www.enounce.com).

-Chris

There is no messaging from the client to the server to indicate the fullness of the buffer. I am not sure what you are trying to achieve. You don’t have control of the playback speed in the player. Wowza Pro will attempt to keep the buffer full but it is doing it blindly. It knows the size of the buffer but not the fullness at any point in time.

Charlie

BTW, thank you very much for taking the time to answer my questions Charlie, I really appreciate it. I have installed the Wowza Pro 10 server to experiment with the properties in the config files in hopes I could give advice to the schools using your server but it’s a lot to pick up and understand in just a few hours. I have all the sample content working though and can duplicate the same rebuffering when playing locally so that rules out the question of available bandwidth. If I understand custom modules correctly, perhaps it would be possilble to write a custom module that streamed the content faster.

I thought I read somewhere else in the forum that audio is disabled in fastplay mode. I will give it a try though.

You are right. It is. Well, then I guess it won’t work. I will think about it.

Charlie

Essentially what would work is a way to fool the server into thinking the bitrate of the content was higher than what it really was. So for a 300kbit stream if the server thought it was a 1200kbit stream it would let the data out faster.

Maybe my view of things is too simplistic. Thanks again for giving this some of your time and thoughts. It’s appreciated.

Charlie,

Is there any progress on this?

This is an extremely important issue for rtmp to succeed on most Internet links.

If the server cannot serve the stream at a rate higher than the encoded (play) speed, there is no chance for the player to build a decent buffer to protect the stream from Internet fluctuations. This makes the stream extremely vulnerable to Internet fluctuations and may become unusable on some links.

I think the capability of the server to fill the player buffer and keep it full by serving at a higher rate than the encoded speed is extremely important to give the user a seamless and uninterrupted video experience.

Thanks Charlie. Glad to hear that Wowza could stream at a faster rate than the encoded rate so that it can fill player buffer without impacting on time to start the stream.

I will try this with jw player.

jw player has buffer change after starting with small buffer. This is done to avoid long start delays. I am not sure whether jw uses NetStream.bufferTime value.

I have noticed that they are changing the small start-up buffer to a larger one after the stream start in RTMPModel.as. And then, when user interacts, it reduces to the original start-up-delay buffer (model.config[‘bufferlength’]). They are using stream.bufferTime to adjust the buffer after the start-up. I am wondering whether this should be changed to NetStream.bufferTime.

What would occur when this buffer is full. Would JW maintains a FIFO buffer on a sliding basis so that Wowza can keep it full until it is used to fill the write buffer in case of bandwidth fluctuations?

I could observe that it is almost not using an extra buffer to insulate the stream from bandwidth fluctuations. It appears that youtube is better insulated from bandwidth fluctuations in comparison to a Jw/Wowza rtmp stream.

Thanks.

We support buffering. You can set a client side buffer by setting the NetStream.bufferTime value in your player. It is described here:

http://livedocs.adobe.com/fms/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000594.html

This thread is talking about increasing the playback rate to play the stream back at faster then real-time (including audio).

Charlie

Based on my limited testing, it doesn’t appear that Wowza is streaming faster than the encoded rate to fill receiver buffer. May be I haven’t configured it correctly. Is there a way to tell Wowza to stream at highest possible rate as permited by TCP, until the receive buffer is full. There is no reason for Wowza to restrict streaming rate. If TCP permits, Wowza and the client should take the full benefit of it and stream at the highest possible rate as allowed by TCP. Is this possible?

Thanks for the link Richard. I have posted in that thread.