第二个是电商，这方面阿里有非常强的感受。阿里最早做开始手淘直播的时候，也是采用比较传统的技术，场景上面临的最大问题是：主播上来告诉大家，“我要开始卖一个东西了”，然后他要上链接，还要做消息互动。但这时候有可能会出现的是：主播说话与用户观众发消息的两个过程是有延时的，但消息的延时跟视频的延时又可能不一样，消息可能在 1 秒，视频可能在 5、6 秒。
这时候就会出现消息跟视频不在同一个画面的问题——主播可能都已经切到下一场，而买家还在跟他交流上一场的问题。
所以在手淘场景里，我们不断跟手淘团队一起尽可能把延时往下推进。比如在今年双 11 里，手淘大量采用了低延时直播，大概把直播的延时降到 1 秒左右，控制在 1 秒范围内之后，我们可以看到它对整个 GMV 的转化有很大的帮助，因为主播跟观众之间有了更强的互动关系。
在所有直播体系里我们都看到了对于延时的诉求，现在直播都希望走向强互动直播，而不希望是原来那种比较单向的行为，因为观众也希望有更强的互动。
最后一个是大家疫情期间感受最为强烈的场景，视频会议。现在视频会议的延时在技术上能够做到几百毫秒，所以现在大家普遍能开视频会议。虽然以前是电话会议多一些，但现在很显然视频会议的比率在上升。毕竟任何人的交流都更加希望能看到人，而不纯粹只是电话传递的声音。
举另外一个例子，很多公司的面试到决定性或者很关键的一轮时，都会把候选人邀请到本地，然后面对面地完成这轮面试。这是因为觉得在仅通过电话面试、看不到人的情况下，很多东西是难以判断的，需要见到本人。但是有了视频会议以后，一些面试就可以无需把人邀请到现场进行。
所以延时技术在视频领域的作用是非常明显的，从几秒到几百毫秒催进了非常多视频场景的创新。
但对视频来讲，这依然不够。比如视频会议，之前一个学术机构的研究报告显示，其实像视频会议这样存在几百毫秒延时的场景，对比人跟人的当面交流，还是存在很大区别。
大家开视频会议应该都有这样的感受：在视频会议的场景下，仍然会出现抢话情况，你说了一句话，可能还没有说完对面就已经抢话，这是一定会出现的，因为人跟人当面交流的延时并没有几百毫秒。
在视频场景里，我们是有非常强的动力去思考怎么把延时往下推得更低，让大家有更真实的体验，包括现在很多公司做很多东西都是为了让大家在远程会议上，可以有跟当面交流比较接近的体验。对我们来讲，延时如果能够越来越低，是一个非常好的事情，可以在这基础上做更多业务层面的创新。
================================================================================
音视频整体技术可能跟系统层面技术有一些差别，我们来看一下延时。比如直播，音视频中比较典型的场景，你拿一个手机开始拍，这是采集的过程，把一个视频影像留下来，去采集，然后编码，多数可能是在端上去做。这个延时，现在大概在 60ms 左右的范围。
采集完之后会把这个流（比如直播、摄像流）直接推到远端，多数是云端或者自己服务器端。在云端之后，通常还会做一些处理，比如直播通常要做内容审核，内容需要过一遍审核处理，有些稍微复杂点的直播可能还要做其他事情，比如加 logo，做一些镜头的剪辑和镜头的切换。
如果有多个摄像头机位，还会涉及到直播的时候选用哪个机位的问题。另外是分发，怎么把服务器端推到很多的点。然后是把客户端流拉到本地，拉完以后开始解码和播放。
从整个时间耗时看，以前是 3-5 秒的延迟，主体时间多数耗在拉流那一端，这是协议决定的。RTMP 是比较标准的协议。现在业界比较流行的低延迟直播，是把直播延迟从 3 秒推到 1 秒，推到 1 秒以后，我们给它的名词都叫低延迟直播，相比以前更低延时一点。
大家看上图中的整体优化，更多是把协议层开始做替换，现在多数公司的低延时直播都会基于 RTC 协议，就是 Google 开源的 webRTC 协议去做。可以看到，当基于 RTC 推流、RTP 分发，前面协议层都在替换，差不多可以把拉流这端开始压到 1 秒以内。现在阿里手淘的直播，整体延时在 1～1.2 秒范围，1～1.2 秒在消息类互动场景已经足够了。主播跟观众如果是用消息互动，发一条消息或者打赏什么的，大家都不会有太长的延时感觉。可以看到，这种场景下，我们可以通过协议替换把整个延时往下拉低。
但也可以看到，其实还有很多延时是整个网络造成的。如果是网络造成的，现在其实是没有太多很好的解决方案，就非常地难。而标准的 RTC 可以做到 200-300ms 的时间，就是这样一个状况。
这三种延时，除了技术层面的差别以外，另外的层面是当采用这些技术以后，整体的成本是有很大变化的。当你延时要做得越来越低的时候，其实成本是会上升非常多的。像 RTC 相比传统直播延时，有可能成本大概是在 7 倍以上。像低延时直播，现在各家公司在不断努力尽可能让这两者成本开始接近。
为了很好地控制延时，推流最重要的是协议的替换。因为协议替换以后，从 TCP 到 UDP 以后，很多东西需要自己来做了。
各视频厂商关注的最重要的指标是抗丢包，多数公司追求当丢包在 50%、60%、70% 的时候，在不同场景去满足诉求。比如视频会议如果只是为了开会，最大的诉求其实是在音频端——音频清晰度和流畅度，而画面如果有一点卡顿，我们勉强还能接受。当然，如果那个视频会议是讲 PPT，那就不能接受了，那优先级可能变成视频的清晰度。所以，不同场景需要有各种各样不同的策略。
比如大家如果去看直播场景和视频会议类型的场景，它面临最大的不同是什么呢？直播场景的话，比如我是主播，其实只要摄像头跟我、以及我跟服务器的链路整体没有太大问题，基本上观众之间互相是没什么影响，这个观众看的时候会卡，另外一个观众有可能是不卡的，因为观众之间没有什么影响。但如果是视频会议类型的场景就完全不一样了，比如现在有十个人在开会，这十个人里任何一个人，出现卡了或者视频、音频不大正常，就会影响整场会的效率。
在这样的场景里，为了要保证延时，同时又要保证流畅度的时候，抗丢包层面需要做非常多的事情，包括综合的策略。
我们去看很多音视频公司，它们很大的竞争力在于对端的适配能力。因为每个端的状况不大一样，比如有人用苹果，有人用安卓，尤其是安卓，安卓手机有无数种，每种手机的音频能力、视频能力有很大差别，还有大家所处的网络环境，比如现在连了 Wi-Fi，走动的时候可能 Wi-Fi 点会切换，还有可能从 Wi-Fi 切到 4G，这里面网络点怎么去处理也是非常关键的。
所以当整体延时越来越往下探的时候，它的技术门槛在不断地升高，我们怎么样做好卡顿的控制，是各家公司去做这类型业务上面临的最大的一个问题。
这里主要讲的关键技术，一是推流，二是分发，三是整个拉流层面为了控制延时做的一些事情。推流主要是协议层面和抗丢包，分发层面主要是背后整张网络的分发。
很多公司做视频业务，通常有几种方法，一是直接基于云厂商的 CDN 构建整张音视频网络，还有一种是基于边缘计算节点构建一张自己的音视频网络，但这都是有一个问题要解决的。不管用什么方案，都有这样一个问题解决：这么多的节点要怎么更好地调度？这涉及到非常复杂的调度问题，因为每个节点的带宽能力、计算资源能力可能不一样，怎么根据用户的情况去做整张网络的调度。
=========================================================================================
带宽层面，从目前来看，大家都在想 5G 带宽变大了以后，到底找谁把带宽用起来，总得有人把带宽用起来。就像 4G，其实是视频用起来的，短视频把 4G 视频带宽撑起来。现在互联网一大部分流量，主体都是视频构成的。5G 时代也是一样，我们为什么需要更大的带宽消耗，肯定要从业务侧看到很大的变化。
图中可能是大家经常看到的一些清晰度，我们现在多数场景里能看到的 720p 视频、1080 4K 和 8K。8K 其实很少看到，因为 8K 对屏幕要求非常高，基本要很大的屏才能展现 8K 的效果。
阿里曾经在几年前冬奥会的时候做过一个 demo，叫 5G+8K 看冬奥会的滑雪现场，它的运动感非常强，所以是非常明显的。而现在特别火爆的 VR/AR 是需要更高的清晰度，现在很多 VR 还是 4K，所以导致我们会觉得颗粒感很强，但当 VR 结合 8K 的时候，就会觉得颗粒感的问题好了很多，画面比较接近真实。
只有更大的带宽，我们才可能把清晰度更往前推进。关于清晰度，以前有人说，你去问很多人，他都会觉得现在的东西已经够清晰了，不需要更清晰。但当你给了他一个更清晰的东西的时候，他会发现他需要更清晰的。最典型的是，苹果推视网膜屏，当视网膜屏推出以后，大家就有了更好的体验。
现在短视频厂商也在不断推进 4K。很多人以前都觉得短视频没必要那么清楚，因为手机屏幕太小了，还不至于能看出 4K 的差别。
但从业界发展看，我们觉得这个趋势还是比较明显的，整体朝更清晰化发展，它肯定是有诉求的。而为什么现在进展比较慢？有很多原因，第一个是当清晰度要往前推进的时候，不光是后面播放侧的问题，还有很大的问题是制作侧。当然，现在很多摄像机可能是 4K，但是拍了以后怎么把 4K 视频做剪辑、处理，其实是非常复杂的，更不要说带宽消耗。带宽除了能不能放出来以外，还有一个问题是每放一次背后全部是带宽消耗，这个带宽消耗全是成本。
我们觉得超清是一个很好的发展方向，但怎么解决在超清的发展过程中面临的很多问题，是技术侧都需要关注的。
超高清技术里面涉及到很多东西，简单讲就是从视频输入开始，就是拍一段视频，然后到一段视频最后被用户看到的时候，到底我们要做些什么。
大家可能听到过一些词，比如上图里的“超分”。简单来说，就是手机拍出一段 2K 视频，怎么把它超分成 4K 的视频，让你看到一个类似 4K 的效果，这样做是为了制作端的成本问题，因为很多制作端都不具备制作超高清的能力。
另外，大家可能听过窄带高清等技术，其实是为了解决给你一段高清视频，但怎么来控制整个带宽成本的问题。如果做高清业务，成本是非常重要的。长视频就非常典型，多数长视频会提供非常多种清晰度的选择，多数公司会提供越来越清晰化和越来越好的体验，就像优酷自己，我们会提供帧享的东西去让大家能看到更好的不同的体验。
还有很多场景的问题，比如拍不同场景，航拍和运动类的视频对清晰度的要求是比较高的，尤其是运动类的视频就非常明显。阿里优酷做世界杯播放的时候，能明显地感受到，如果清晰度不够，很多时候可能连球在哪儿都不一定能看到，远景的时候是比较难的。在那段时间，大家在不断研究怎么能让这个画面变得更加清晰。
所以我觉得，对于很多公司来讲超高清技术是需要往前演进，需要解决从制作到分发、处理到播放整个链条的问题。带宽是基础，只有带宽越来越大的时候，这个东西才有可能变成现实。
先自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以扫码领取！
总结
阿里伤透我心，疯狂复习刷题，终于喜提offer 哈哈~好啦，不闲扯了
1、JAVA面试核心知识整理（PDF）：包含JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算共30个章节。
2、Redis学习笔记及学习思维脑图
3、数据面试必备20题+数据库性能优化的21个最佳实践
torm，YARN，机器学习，云计算共30个章节。
[外链图片转存中…(img-KQNEXsub-1711192946159)]
2、Redis学习笔记及学习思维脑图
[外链图片转存中…(img-3cAtARJD-1711192946159)]
3、数据面试必备20题+数据库性能优化的21个最佳实践
[外链图片转存中…(img-ShV06vBf-1711192946159)]
需要更多Java资料的小伙伴可以帮忙点赞+关注，点击传送门，即可免费领取！
556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
