Coo*_*i45 5 performance http thumbnails processing-efficiency video-thumbnails
我正在尝试为我的简单视频播放器实现Youtube的缩略图预览功能.这是Snap for it:
好消息是:一旦播放器从HTTP服务器获取所有缩略图预览,它就能顺利运行.
不好的是:获取所有缩略图预览需要花费大量时间(20-30秒).(对于14分钟(~110 MB)的视频(.mp4文件),大约有550个缩略图预览(160x120)
我正在做的是:当用户开始播放视频时,我将向服务器发出"total_thumbnails"HTTP请求以获取所有这些视频.
还 - 注意:
- 我将在异步任务中执行多个HTTP请求.
- 我不会这样做,提出请求,等到下载完成然后再提出请求.
- 我将盲目地发出"total_thumbnails"HTTP请求,因此所有请求都在流水线中排队,然后并行接收响应.
额外细节:HTTP(lighttpd)服务器将运行,用户从列表中选择要播放的video.mp4后,我的播放器将从该处获取所有缩略图.此外,播放器将使用相同的服务器来使用HTTP流式传输来获取video.mp4.
问题是:当我开始播放视频,然后我快速搜索时,我最终看到了这个(白色缩略图是默认的,当映射到该时间的缩略图尚未从服务器获取时):
问题是:我如何有效地获取所有(或一些)缩略图预览,以便用户(大多数时间)将获得正确及时映射缩略图的体验?
我已经在视频开始时看到youtube的视频(这很快),播放器能够显示所有及时的正确缩略图(无论你将拇指拖到最后一分钟还是悬停在酒吧的最后几分钟,几乎每次都你会看到正确映射的缩略图).
他们是同时下载所有缩略图还是下载压缩的缩略图预览系列或其他一些智能的东西正在那里发生?
有没有人对此有所了解?
\n\n\n对于 14 分钟 (~110 MB) 的视频(.mp4 文件),大约有 550 个缩略图预览 (160x120)
\n
这里的主要因素可能是您向 HTTP 服务器发出了 550 个单独的请求。我假设您这样做:请求缩略图k,等待它下载,然后请求缩略图k +1。这是非常低效的,因为在下载缩略图k和上传下一个请求时,HTTP 服务器处于空闲状态。
\n\n将所有 550 个缩略图合并为一个大文件,并请求该文件而不是 550 个单独的文件。
\n\n也许有一种很好的现有文件格式可以重复用于此目的。我想到了Tar ,但它\xe2\x80\x99s可能是一个糟糕的选择,因为(1)它\xe2\x80\x99t似乎不支持随机访问(即直接获取第k个缩略图),并且(2)它每个缩略图增加 512 字节的开销。
\n\n无论如何,应该很容易想出您自己的文件格式。像这样的东西:
\n\n使用HTTP/1.1 的HTTP 管道\xe2\x80\x94a 功能,一次发送许多请求(可能全部 550 个),然后一次读取许多响应。您\xe2\x80\x99 不必等待每个缩略图下载完毕后才请求下一个缩略图。
\n\n您需要两件事才能使其发挥作用。
\n\n首先,您的 HTTP 客户端必须支持 HTTP 管道。我不知道 xe2x80x99 在你的平台上是什么最先进的,但在 Python 领域这是一个罕见的功能。似乎支持它的一个客户端是libcurl(通过CURLMOPT_PIPELINING和CURLMOPT_MAX_PIPELINE_LENGTH)。libcurl 适用于大多数平台,并且具有大多数语言的绑定。
其次,您可能需要更改 Lighttpd 配置。默认情况下,该server.max-keep-alive-requests变量设置为 16,这意味着服务器在处理完 17 个请求后将关闭连接,并且您必须建立一个新连接。您可能希望这个数字更大。
管道化大量请求可能(也可能不会)对客户端和服务器产生不良副作用,例如意外的内存使用。请您自己测试一下。
\n\n此外,如果客户端和服务器之间存在任何 HTTP 中介(如代理),它们可能会破坏 HTTP 管道。
\n\n我进行了一些快速而肮脏的测试。Lighttpd\xc2\xa01.4.31 提供 550\xc2\xa0 缩略图(总计 4.2M\xc2\xa0),其中server.max-keep-alive-requests\xc2\xa0=\xc2\xa0600, 来自\xc2\xa0Berlin。客户端\xc2\xa0位于\xc2\xa0莫斯科。平均\xc2\xa0超过\xc2\xa010\xc2\xa0运行。
http.client):27.3\xc2\xa0s。http.client):2.95\xc2\xa0s。