AVPlayer预缓存：prerollAtRate

在播放avplayerItem前要先预缓存视频，可以调用 - ( void ) prerollAtRate: ( float ) rate


    completionHandler:(void (^)(BOOL finished))completionHandler这个接口. 但是需要注意的是,调用这个接口前avplayerItem必须处于停止状态(rate=0)并且status是AVPlayerStatusReadyToPlay. 这个接口可以让你无缝的衔接多个视频的播放。至于接口其中的参数rate我还不太明白，官方文档是这样解释的：The playback rate to use when determining how much data to load. 意思是这个参数决定了要加载多少数据，但是具体rate怎么决定这个加载的数据量，它们之间的计算关系不得而知。另附一篇别人写的博文，跟这个rate怎么决定数据量有点关系，但由于该博文不是关于iOS的，所以不好说。从具体应用来说，这个rate设置跟播放的rate设置对应，设为1表示正常速度（加载的数据量还是不知道），小于1，加载的数据量应该少点，具体没有去调试过，有兴趣的朋友可以去调调看，如果发现上面有什么不对的地方也欢迎指正（毕竟只是稍微接触了一下，没怎么留意调试，只是暂时先记下）。







刚才说的那篇博文如果，博文中说的rate是跟码率有关的：

博文地址：http://blog.csdn.net/da5le/article/details/208857

What is PREROLL?

前段时间接触到一个流媒体客户端的工程，其中对于leaky bucket buffer的管理有些麻烦，而对于音视频的preroll时间有些迷茫，经过查证，原来。。。再次记录表示提醒^_^。

简单描述： preroll是传输速率与解码或者显示需要的数据速度不匹配而产生的buffer需求，具体解释如下：

1．    MSDN

MSDN关于DShow有个preroll函数，其中这么解释的：

This method can be called before the application calls Start to begin buffering data in advance. The parameters here must be set to the same values as those that are passed to Start when it is called. If the parameters are different, Start will do rebuffering. 

It is important to allow sufficient time for the prerolling (buffering data) for the reader to be completed before calling Start. When prerolling local files, 6 seconds normally is sufficient. When prerolling files over the Internet, allow more time before calling Start. If insufficient time is allowed, the effect will be a longer Start time when Start is called.

2．网站上

1）http://www.occupationalinfo.org/glossary_960.html

PREROLL The time (usually in seconds) it takes a videotape to get up to speed, i.e., the lapse time between pressing the play button and when the picture appears on the monitor for the viewing audience to see. 

2)

缓冲时间(preroll)实际是在动画回放前将动画和音频调入用户缓冲区所需的一段时间。缓冲时间越长，支持的数据传输速率就越高，因为更多的信息已经输入到客户机的缓冲区中。 

3．REAL

For example, if your image files add up to 200 Kilobytes, multiply 200 by 8 to get 1600 Kilobits. A presentation that lasts two minutes, for instance, uses an average of 13.3 Kilobits per second:

(200 Kilobytes x 8)/120 seconds = 13.3 Kilobits per second

If your RealPix target is 15 Kbps, your presentation should stream smoothly with bandwidth to spare.

This simple estimate assumes that all images are each about the same size and are streamed at regular intervals. You run into bandwidth problems, however, if you use a lot of images near the start of the presentation. If the presentation begins by fading four big images into four quadrants of the display window, for example, RealServer needs to download a lot of image data before the presentation can begin. This results in a lengthy preroll.

What is Preroll?

Before it delivers a RealPix presentation, RealServer looks at the image sizes and the presentation timeline. Weighing these against the bit rate set in the <head/> tag, RealServer determines how much data RealPlayer must receive before it can start to play the presentation. This ensures that once RealPlayer commences playback, it does not need to halt the presentation while it receives more data. The initial data sent before playback is the preroll. As a general rule, you want the preroll under 15 seconds, ideally under 10 seconds. For example, if a RealPix presentation streams for 60 seconds at 20 Kbps, it can deliver up to 1200 Kb of data during playback. If the RealPix presentation requires 1400 Kb of data, at least 200 Kb of data must be sent as preroll. At 20 Kbps, this equals a 10 second preroll:

(1400 Kb - 1200 Kb)/20 Kbps = 10 seconds

As mentioned above, presentation size divided by presentation length is only a rough guide to preroll length. RealServer considers when each image is introduced in the timeline when it calculates preroll. The following sections give instructions for determining preroll more accurately and for reducing bandwidth consumption.