seolu于2023-10-09发布在短视频迎合了碎片化时间，或者是当下追求“短、平、快”的环境下人们的精神娱乐需求。 我也有点沉迷于短视频。 我经常闲着没事就频繁的去刷某些短视频应用，以至于忽略了某个头条、某个易。 我很少点击新闻。 如果把时间加起来的话，我大概可以读几遍。 当然，这是一篇技术文章。 其他心理、社会学问题和产品问题在此不再讨论。 我们还没有达到那个水平。
言归正传，我们也推出了短视频相关的产品。
在短视频的体验中，启动速度无疑是最影响体验的指标之一，因为短视频很短，少则十几秒，多则几分钟。 如果加载十几秒的视频，则需要3秒。 这一定是一次非常糟糕的经历； 所以在产品定义之初，就将启动速度设定为控制在1秒左右，大部分视频都在1秒以内，也就是业内所说的“秒播”。 这需要了解播放过程。 优化。 艾玛，终于进入正题了。
在说具体优化之前，我们先来看一下播放短视频的大致流程？
然后通过拆解过程，找到可以优化的模块或点，最后将它们连成一条线短视频优化，给出优化方案。
如上图所示，移动设备的播放器通过某个视频URL的域名通过DNS服务请求IP地址，通过这个IP地址与视频服务器建立TCP连接，进而建立http协议在连接之上，最后请求数据。 ，音频和视频由播放器解析、解码并显示。 用户看到图像、听到声音，广播过程结束。
为了更好地发现可以优化的地方，我们根据实际情况对上图进行了拆解，给出了下图。
图中蓝色部分可以优化，但由于实际情况，内容只在客户端访问，内容放在CP服务器上。 虽然还有优化的空间，但是这里不能优化，但是在后面我们也会介绍哪些优化空间可以操作。 这就是行业的现状，但是如果能有更多的内容选择不是更好吗？ 图中灰色部分无法优化。 流程上没有优化的余地，而且这部分很容易受到网络状况的影响。 因此，我们后面提到的优化是基于大多数网络条件的，尽管有些逻辑适合极端的网络条件。 也适用，但这不是我们讨论的重点。 图中绿色部分可以在项目实际中进行优化实现。
下面对这些项目进行一一介绍： 1． name：域名解析
耗时原因：
DNS请求报文首先会被发送到本地DNS服务器。 如果找不到，就会递归到根域名服务器。 这个过程非常耗时。 当然，如果你已经请求过，或者期间有其他人请求过同一个域名，那么域名服务器就会有缓存，下次请求会很快； 但一般缓存周期很短，需要有人不断请求来保持更新，所以不确定性很大。
解决方案：
1. 注意请求中使用的IP协议版本。 做播放的人一定绕不过去。 为了兼容，设置了DNS请求的IP协议版本，这样在发出请求时会优先请求IPv6地址。 如果没有，将请求 IPv4。 地址很安全，但是在实际项目中，没有IPv6地址，导致递归到根域名服务器也找不到IPv6地址，浪费了巨大的时间。 可以使用指定的请求IPv4地址，节省一半以上。 时间，第一次请求或者缓存过期后的请求，大约需要几十毫秒到100毫秒，可以通过监控函数的时间来确定。
.=;
（，，＆，＆人工智能）;
2. 预设或预解析域名IP地址。 100 毫秒仍然是很多时间。 为了秒级播放，这个解决方案是提前解析域名，使用时直接使用IP地址。 然而，该解决方案有局限性。 可能适合特定的音视频直播。 对于短视频播放地址来说，由于播放地址多种多样，操作起来比较困难。 而且，还有CP流切换、接入CP更换的情况，所以这100毫秒暂时只能放在这里。 。
二， ：
耗时原因：
TCP基本上是在客户端的具体操作中实现的。 TCP中有一个缓冲区的概念。 发送端先将数据写入缓冲区，接收端数据也先经过缓冲区网站优化，然后从缓冲区读取并移动设备作为接收端时，接收端缓冲区设置太小影响效率。 接收端缓冲区设置太大会在短时间内吃掉带宽。 如果带宽不足，就会造成网络传输问题，浪费流量。 这些都会影响首屏数据的及时传递。
解决方案：
根据实际情况调整接收端的缓冲区大小，通过计算和测试数据得到比较合理的值。 可以在tcp中进行调整。 这是一个比较低级的修改。 为了通用性，可以扩展http/tcp，并通过提供的机制在API层透传相关设置参数。
（＆， ““， “ 的 ”）;
(fd, , ,&len,(len));
三，
耗时原因：
在播放端，一开始并不知道要播放的视频的相关信息，比如封装格式、分辨率、音视频编码等，需要先读取一段数据，然后检测数据来获取相应的信息。 ，并且需要一个来存储该检测数据。 如果此设置太小，则可能无法分析信息并重新检测。 如果设置太大快速排名，会增加采集流的时间，影响首屏的播放。 如果太小或太大，都会造成延迟。
解决方案：
根据实际情况对此进行调整，通过计算和试验数据得出较合理的值。 对对的限制可以通过结构之和透明地传递下去。 您可以通过观察此函数来评估检测时间。
-> = n;
-> = m*;
4. 清单
耗时原因：
检测过程也是如此。 一开始，播放器不知道数据是什么格式。 它需要根据其支持的格式通过检测得到一个分数，然后根据这个分数给出对应的格式，类似，所以如果设置支持的格式越多，检测列表就会越长，对应的检测时间会更长。 对于短视频来说，CP的内容格式基本确定，基本上是MP4+H264/H265（不常见）+AAC。 因此，无需探究多种格式。
解决方案：
删除无用的格式并仅保留所需的格式，例如 mp4，以最小化列表。 您可以通过观察此函数来评估检测时间。
视频
非洲猪瘟
MKV
等等…
五，
耗时原因：
对于非直播玩家来说，业内的通用做法是在内部设计一个缓冲区。 这是为了播放流畅和音视频同步的需要。 当网络不稳定或较差时，这个缓冲就显得尤为重要。 。 一般这个缓冲是根据帧数来设置的，有的设置为1-2秒，有的设置为3-5秒，因为一般的播放比如网络电影电视剧考虑到整个播放过程是几十秒几分钟甚至几秒钟。 对于一个小时的体验来说，开始时几秒钟的缓冲是可以接受的，但在短视频场景中这是不可接受的。
解决方案：
策略优化保证视频尽快输出，缓冲机制移至首屏播放后。 当然，还必须考虑音频，保证音视频的同步，必须做出一些权衡。
这其实是一个非常重要的环节。 由于框架设计时这些因素的限制，启动速度远远达不到要求。 于是又建了一个，但是不进行二次开发还是不能满足需求。 这个需要根据自己的播放框架来设计。 我们使用自主开发的播放框架。 该框架上线近两年，支持多种音视频业务。 我们在这里不再赘述。
6. MP4尺寸：分辨率/QP/I帧位置
耗时原因：
该决议并不难理解。 如果视频文件的分辨率很高，那么一帧的数据量就会很大，相应的传输时间就会更长。 因此，在生成内容时，选择合适的分辨率进行录制或者转码为合适的分辨率也是要考虑播放端的负载。 移动端720P左右对于个人秀等短视频以及内容聚合的短视频分辨率来说已经足够了。 它可以更低。 QP是指图像质量。 相同分辨率的图像可以有很多级的QP，这与编码密切相关。 QP越高，图像质量越高，码率也越高，相应的传输时间也会更长。 同样，QP越高越好。 对于不同场景之间不能快速切换的720P视频，3M和5M码率相差并不大。 选择合适的QP，在画质和传输之间找到平衡点。
I帧位置是指视频I帧在视频文件开头的位置。 为了防止屏幕模糊等问题，播放器在开始播放或寻道时通常会找到第一个I帧进行解码。 一般视频文件一秒有25-30帧。 显然，将I帧放在第一帧和最后一帧对第二次广播有影响。
解决方案：
根据实际情况，在产品服务链中选择合适的分辨率/QP。
将 I 帧放在文件的开头。
7. MP4 MOOV 盒子 & Http 重新
耗时原因：
如果在广播过程中出现http重新，那么耗时肯定会增加，并且http的时间消耗基本无法优化，所以应该避免http重新的发生。 但由于mp4是主流的短视频封装格式，其MOOV框在文件中的位置直接影响是否会发生http re-。 说白了，如果将MOOV框放在文件的后面，即MDAT框之后，就会发生http re-。 ，引入延迟。
解决方案：
1.上传mp4文件时将MOOV框放在前面
2、mp4文件上传到服务器后，重新封装，将MOOV框放在前面
如果您是一位具有传统音视频背景的工程师，您应该对MOOV box非常了解。 这里简单介绍一下。 MP4是由很多个盒子组成的。 MOOV盒子存储了音视频编码以及其他对于播放非常重要的信息。 必须先获取此信息才能播放。 因此，如果将MOOV框放在文件前面，就可以通过http请求直接读取、解析、播放音视频数据。 MOOV框被放置在文件的后面，但是播放器不知道它被放置在文件的后面。 需要发起http请求来读取起始数据。 如果发现没有 MOOV 框，它将查找文件的后面并读取 MOOV 框。 读完后，再寻道到文件的前面短视频优化，从起始位置读取音视频帧数据，每次寻道时重新发起http请求。 因此，将 MOOV 框放在后面比放在前面需要多两次 http 调用，并且花费的时间是放在前面的三倍。 下面是两个短视频。 一个moov盒子放在前面，另一个放在后面。 可以看到放在后面的传递日志中会发生re-，请求文件中最后一段数据来获取moov框。
8./CDN
耗时原因：
CDN节点部署、路由策略
缓存或流式传输
都会对延迟产生影响
解决方案：
进行相关优化。
9.TCP协议
耗时原因：
协议的时间消耗，例如TCP握手机制等，在稳定的网络下基本是固定的，但在网络较差的情况下会花费更长的时间。
解决方案：
CDN骨干网的部署可以改善这一状况。
