首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >问答首页 >大型视频的慢速加载

大型视频的慢速加载
EN

Stack Overflow用户
提问于 2022-01-06 20:28:23
回答 1查看 276关注 0票数 3

我有一个AVPlayer正在播放一个中等大的视频(~150 is )。当最初加载视频时,我发现播放机在AVPlayerWaitingWhileEvaluatingBufferingRateReason状态下的空闲时间超过10-15秒。我的问题很简单:我怎样才能防止AVPlayer在这么长时间内“评估缓冲速率的原因”而转而立即播放视频呢?

我使用的是自定义资源加载器(尽管这种行为是在不使用自定义资源加载器的情况下显示的)。下面是创建AVPlayer (所有标准样板)的相关代码:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
AVURLAsset * const playerAsset = [[AVURLAsset alloc] initWithURL:videoURL options:nil];
[[playerAsset resourceLoader] setDelegate:self queue:dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0)];

AVPlayerItem * const playerItem = [[AVPlayerItem alloc] initWithAsset:playerAsset];

AVPlayer * const player = [[AVPlayer alloc] initWithPlayerItem:playerItem];
[player play];
_player = player;

然后,我有了一种处理数据请求的方法,可以使用该方法获取有关AVPlayer试图加载的内容的更多信息:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
-(void)handleDataRequest:(AVAssetResourceLoadingDataRequest *)dataRequest loadingRequest:(AVAssetResourceLoadingRequest *)loadingRequest {

    NSLog(@"handleDataRequest: %lld-%lld (%@)",[dataRequest requestedOffset],[dataRequest requestedOffset] + [dataRequest requestedLength],[[self player] reasonForWaitingToPlay]);

    NSMutableURLRequest * const request = ... // construct the request
    [request setValue:[NSString stringWithFormat:@"bytes=%lld-%lld",[dataRequest requestedOffset],[dataRequest requestedOffset] + [dataRequest requestedLength]] forHTTPHeaderField:@"Range"];

    NSURLSession * const downloadURLSession = ... // get the session
    NSURLSessionDataTask * const dataTask = [downloadURLSession dataTaskWithRequest:request];
    [dataTask resume];

}

现在,谈这个问题。假设视频长度为~100 in,下面是上述方法中的handleDataRequest日志的结果:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
handleDataRequest: 0-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 3080192-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 5570560-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 7143424-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 9699328-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 12713984-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 14811136-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 17235968-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 20054016-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 22675456-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 25427968-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 28311552-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 30932992-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 32374784-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 35192832-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 37224448-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 39780352-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 41549824-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 43778048-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 46465024-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 49414144-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 52166656-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 54984704-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 57802752-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 60293120-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 62783488-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 65732608-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 68550656-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 70975488-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 73531392-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 76480512-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 79495168-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 82313216-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 83951616-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 86573056-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 88866816-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 91422720-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 92667904-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 95289344-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 98172928-100000000 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 32768-5570560 (AVPlayerWaitingWhileEvaluatingBufferingRateReason)
handleDataRequest: 2032769-5570560 (AVPlayerWaitingToMinimizeStallsReason)
handleDataRequest: 4032770-5570560 (AVPlayerWaitingToMinimizeStallsReason)
handleDataRequest: 5668864-22675456 ((null))
handleDataRequest: 7668865-22675456 ((null))
handleDataRequest: 9668866-22675456 ((null))
handleDataRequest: 11668867-22675456 ((null))
handleDataRequest: 13668868-22675456 ((null))

正如您所看到的,有将近40个HTTP请求只是为了评估缓冲状态的原因。这需要很长时间。

以下是我尝试过的:

play

  1. 使用AVPlayer的playImmediatelyAtRate:代替playImmediatelyAtRate:

我在网上看到了这个建议。我想逻辑是,立即演奏就能做到这一点,立即演奏。这不起作用,因为玩家在比赛前仍然要花时间(和请求)来评估缓冲率的原因。

将AVPlayer的NO设置为

  1. automaticallyWaitsToMinimizeStalling

似乎是合理的。我们可以告诉球员不要等待,以尽量减少拖延。不幸的是,这失败了,因为玩家在播放前仍然会发出相同的请求来评估缓冲速率(但是,奇怪的是,在进行此操作时,reasonForWaitingToPlaynull )。

  1. 调用加载请求的finishLoading方法,以立即加快缓冲速率评估

这里的逻辑是,在AVPlayer计算缓冲速率时,我可以立即发出加载已经完成的信号,而不是触发实际的HTTP请求。结果各不相同。在一些测试中,视频会立即播放,但只播放几秒钟,而在其他测试中,视频根本无法播放,并且会超时。

总之,在播放更大的视频时,有没有办法避免这种延迟?在开始一个视频之前,AVPlayer必须评估缓冲率,这真的有必要吗?

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2022-02-07 09:31:18

苹果公司已经证实,问题不在于视频的大小,而是一个有太多moof+mdat原子的畸形moof+mdat。

到目前为止,这已被确定为是按计划进行的。虽然,我希望看到一些方法来避免这种最初的缓冲在未来,即使MP4是错误的。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/70616620

复制
相关文章
Facebook的慢速视频分类器AI
灵长类动物的视网膜神经节细胞能从感光器接收视觉信息,然后再传递到大脑,但值得注意的是,并不是所有的眼部细胞都具备这种精密的能力,科学家通过测试发现,80%的细胞只能在低频率下工作并识别出细微的细节,剩下的20%才能对快速的变化做出反应。
AiTechYun
2019/11/07
6780
Facebook的慢速视频分类器AI
C++对于大型图片的加载缩放尝试
Qt对于图片的操作主要集中在这几个类 QImage ,QImageReader ,QPixmap 其中QImage这个类对图片的缩放有几个很不错的技巧,不过对于大图片却并不好使,当我们去看QImage的实现代码时,会发现其中读取QImageReader来加载图片,当我们去看QImageReader的实现的时候,我们会发现QImageReader的加载模式是unbuffer-->无缓冲加载模式,而且加载速度也是相当的快,所以QImageReader对大图片进行缩放很好使. 但是QImage也是有一些独特的优势
Gxjun
2018/03/27
1.8K0
go慢速入门——函数
go中的函数非常重要,因为go没有类那套东西,因此函数go中最重要的单元。go中函数声明形式如下所示:
zy010101
2022/07/30
2300
go语言慢速入门——包
go也使用包来管理代码,在使用一个包中的可导出标识符时(对于包外而言,只有可导出标识符是可见的),需要先引入包。
zy010101
2022/07/27
3270
[译] 网速敏感的视频延迟加载方案
一个大视频的背景,如果做的好,会是一个绝佳的体验!但是,在首页添加一个视频并不仅仅是随便找个人,然后加个 25mb 的视频,那会让你的所有的性能优化都付之一炬。
尹光耀
2022/05/06
1.3K0
[译] 网速敏感的视频延迟加载方案
一个大视频的背景,如果做的好,会是一个绝佳的体验!但是,在首页添加一个视频并不仅仅是随便找个人,然后加个 25mb 的视频,那会让你的所有的性能优化都付之一炬。
前端下午茶
2019/06/27
2.4K0
[译] 网速敏感的视频延迟加载方案
方法的查找流程——慢速查找
在NSObject的分类(NSObject+LG)里面定义并实现了sayMaster方法:
拉维
2021/03/10
4060
【开源】慢速 UIPickerView 动画实现
【Github】https://github.com/OpenMarshall/SlowPickerView
KyXu
2019/04/11
8100
【开源】慢速 UIPickerView 动画实现
慢速http测试(dos攻击)
在法律允许的范围内,本人在此声明,不承担用户或任何人士就使用或未能使用本人所提供的信息或任何链接或项目所引致的任何直接、间接、附带、从属、特殊、惩罚性或惩戒性的损害赔偿(包括但不限于收益、预期利润的损失或失去的业务、未实现预期的节省)
网e渗透安全部
2023/02/25
2.3K0
慢速http测试(dos攻击)
慢速排序算法到底有多慢
慢速排序算法在 1986 年由 Andrei Broder 和 Jorge Stolfi 发表,主要采取了分治和递归的思想:
五分钟学算法
2019/06/18
9110
慢速排序算法到底有多慢
与慢速设备通讯异步化方案
与慢速设备通讯异步化方案.pdf像MySQL、被对接的银行系统等,都可称作慢速设备。它们的共同特点是只提供了同步调用接口,而且响应通常会比较慢。
一见
2018/08/10
4150
与慢速设备通讯异步化方案
slowhttptest 慢速攻击工具入门
slowhttptest 攻击是一款慢速攻击工具,其擅长攻击Apache/Tomcat这里应用层服务,通常情况下,http协议在接收到完整的客户端请求数据包时才会开始处理本次请求,但如果攻击者通过修改数据包中的Window窗口大小,实现慢速发送数据包,那么服务器就会始终为其保留连接池资源占用,此类大量的并发请求将会导致目标应用服务的连接池爆满,从而无法相应正常用的请求。
微软技术分享
2022/12/28
1.5K0
OpenCV-加载和保存视频
OpenCV不仅能够很方便的加载和保存图片,而且对于视频的加载与保存也可以很简单的通过OpenCV中的函数轻松实现。本篇主要介绍如何加载保存视频。
触摸壹缕阳光
2019/11/13
2.3K0
go语言慢速入门——流程控制语句
go的流程控制语句很有特色。if-else,for,switch-case。注意go没有while和do-while语句。除此之外go还有和特定类型绑定的流程控制模块。例如,用于容器类型的for-range循环。 go支持break,continue以及goto语句,另外go还支持特有的fallthrough语句。
zy010101
2022/07/28
4160
FLEX 3 有关视频加载处理1
1. 创建一个NetConnection 对象,它的作用是连接到远程服务器,调用命令,播放视频
py3study
2020/01/06
4680
FLEX 3 有关视频加载处理1
go语言慢速入门——基本内置类型
表中特地强调了类型是否支持类型转换,这是因为go语言对类型要求是非常严格的,是真正的强类型语言。一个具体的例子如下所示:
zy010101
2022/07/27
4520
Regmap 框架:简化慢速IO接口优化性能
Regmap 机制是在 Linux 3.1 加入进来的特性。主要目的是减少慢速 I/O 驱动上的重复逻辑,提供一种通用的接口来操作底层硬件上的寄存器。其实这就是内核做的一次重构。Regmap 除了能做到统一的 I/O 接口,还可以在驱动和硬件 IC 之间做一层缓存,从而能减少底层 I/O 的操作次数。
233333
2022/05/10
9790
Regmap 框架:简化慢速IO接口优化性能
OpenCV基础 | 2.图像,视频的加载与保存
数字图像由二维元素组成,每一个元素具有一个特定位置(x,y)和幅值f(x,y),这些元素就称为像素
快学Python
2021/08/09
1K0
大型视频监控存储方式_私人云存储解决方案
在建设和谐社会的环境下,国家对很多单位的视频监控系统提出了更高的要求,要求他们把视频监控录像保存更长的时间,要求视频监控的画面更加清晰一点;这些要求的提出,导致原有视频监控系统的存储空间不能满足最新的需求,需要一个更大的存储空间来保存视频录像,如何给原有的监控系统进行存储空间的扩容,以及如何满足将来进一步扩容的需求,正在成为系统集成商和客户的难题。
全栈程序员站长
2022/11/10
2.6K0
大型视频监控存储方式_私人云存储解决方案
墨者安全分享:CC攻击的变异品种--慢速攻击
对网络安全有过一定了解的人肯定都听过DDOS攻击和CC攻击,DDOS主要针对IP攻击,CC攻击主要是用来攻击网页的,两者都是通过控制大量僵尸网络肉鸡流量对目标发起攻击的,对于没有高防服务的企业来说简直就是灭顶之灾。而且这两种攻击方式还在不断“进化”,让防御变得越来越困难。今天墨者安全就来说说CC攻击的一个变异品种--慢速攻击。
墨者盾
2018/11/08
1.2K0
墨者安全分享:CC攻击的变异品种--慢速攻击

相似问题

大型集合的慢速查询

11

节点JS中大型MongoDB数据库的慢速加载

14

大型表上的慢速MySQL选择

21

慢速网络中的大型RabbitMQ消息

28

Heroku慢速加载

14
添加站长 进交流群

领取专属 10元无门槛券

AI混元助手 在线答疑

扫码加入开发者社群
关注 腾讯云开发者公众号

洞察 腾讯核心技术

剖析业界实践案例

扫码关注腾讯云开发者公众号
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文