search

CS-FreeStyle / 10000-How-To-Do-in-CS

1 stars 0 forks source link

IDR: instantaneous decoding refresh frame #162

Open liuty10 opened 3 years ago

liuty10 commented 3 years ago

https://www.cnblogs.com/lihaiping/p/4167930.html https://blog.csdn.net/skygray/article/details/6223358 https://gitee.com/kusebingtang/my-blog-markdown/blob/master/H264%20NALU分析.md

⼀个序列的第⼀个图像叫做 IDR 图像（⽴即刷新图像），IDR 图像都是 I 帧图像。I和IDR帧都使⽤帧内预测。I帧不⽤参考任何帧，但是之后的P帧和B帧是有可能参考这个I帧之前的帧的。 原始图像： IDR1 B2 B3 P4 B5 B6 P7 B8 B9 I10

IDR1 P4 B2 B3 P7 B5 B6 IDR8 P11 B9 B10 P14 B11 B12 这⾥的B9就只能参照IDR8和P11，不可以参考IDR8前⾯的帧

其核⼼作⽤是，是为了解码的重同步，当解码器解码到 IDR 图像时，⽴即将参考帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始⼀个新的序列。这样，如果前⼀个序列出现重⼤错误，在这⾥可以获得重新同步的机会。IDR图像之后的图像永远不会使⽤IDR之前的图像的数据来解码。

liuty10 commented 3 years ago

playback buffers: https://blog.csdn.net/Fri_ay/article/details/107128595 https://blog.csdn.net/fri_ay/category_10010319.html https://www.youtube.com/watch?v=xQQEpvSEHh0 https://www.youtube.com/watch?v=08H119wc_Uc

liuty10 commented 3 years ago

package loss and delay: What does TCP do on packet loss? RFC 793 "When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgement for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted".

Jitter: variation in arrival time; worse with multiple routers.

https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484106&idx=1&sn=71d9d7865723bfe50bbeef6c4f024a3a&chksm=e9513d96de26b48050e377a1c4d4ed52b6ac67b151669ff3ba6eb127ecd5df56f366291be5a8&scene=21#wechat_redirect tcp拥塞控制算法（reno, bio, cubic）：基于丢包、延迟不可控。 传统的TCP拥塞控制算法，是基于丢包反馈的协议。基于丢包反馈的协议是一种被动式的拥塞控制机制，其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。 TCP在发送端维护一个拥塞窗口cwnd，通过cwnd来控制发送量。采用AIMD，就是加性递增和乘性递减的方式控制cwnd，在拥塞避免阶段加性增窗，发生丢包则乘性减窗。 这个拥塞控制算法的假定是丢包都是拥塞造成的。 TCP拥塞控制协议希望最大程度的利用网络剩余带宽，提高吞吐量。然而，由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性，一方面大大提高了网络的带宽利用率；但另一方面，对于基于丢包反馈的拥塞控制协议来说，大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了，所以这些协议在提高网络带宽利用率的同时也间接加大了网络的丢包率，造成整个网络的抖动性加剧。 TCP拥塞控制算法的假定是丢包都是拥塞造成的，而事实上，丢包并不总是拥塞导致，丢包可能原因是多方面，比如：路由器策略导致的丢包，WIFI信号干扰导致的错误包，信号的信噪比（SNR）的影响等等。这些丢包并不是网络拥塞造成的，但是却会造成TCP 控制算法的大幅波动，即使在网络带宽很好的情况下，仍然会出现发送速率上不去的情况。比如长肥管道，带宽很高，RTT很大。管道中随机丢包的可能性很大，这就会造成TCP的发送速度起不来。

gcc: webrtc默认使用，基于延迟+丢包； 接收端-remb(卡尔曼滤波器)、发送端-transportcc(线性滤波器) 带宽估计不准确，低带宽过降 与tcp竞争，过度退让；时延抖动场景，带宽估计波动大； bbr: (bottleneck bandwidth and round-trip propagation time) 2016年由google提出，算法核心是尽量不排队、低延迟。 带宽估计准确、与tcp竞争，不吃亏。

bbr原理： https://tools.ietf.org/id/draft-cardwell-iccrg-bbr-congestion-control-00.html bdp(带宽延迟积) = (max bw) * (min rtt) 最大带宽和最小延迟不能同时得到。 Google 的BBR出现很好的解决了这个问题（长肥管道）。BBR是一种基于带宽和延迟反馈的拥塞控制算法。它是一个典型的封闭反馈系统，发送多少报文和用多快的速度发送这些报文都是每次反馈中不断调节。 BBR算法的核心就是找到两个参数，最大带宽和最小延时。最大带宽和最小延时的乘积就是BDP(Bandwidth Delay Product), BDP就是网络链路中可以存放数据的最大容量。知道了BDP就可以解决应该发送多少数据的问题，而网络最大带宽可以解决用多大速度发送的问题。如果网络比作一条高速公路，把数据比作汽车，最大带宽就是每分钟允许通行的汽车数量，最小RTT就是没有拥堵情况下，汽车跑一个来回需要的时间，而BDP就是在这条路上排满汽车的数量。 如图所示，横轴是网络链路中的数据量，纵轴分别是RTT和带宽。可以发现在RTT不变的时候，带宽一直在上升，没有达到最大，因为这个时候网络没有拥塞，而带宽停止上涨的时候RTT持续变大，一直到发生丢包。因为这个时候，网络开始拥塞，报文累积在路由器的buffer中，这样延时持续变大，而带宽不会变大。图中BDP的竖线所标识的就是理想情况下最大带宽和最小延时。很明显，要找到BDP, 很难在同一时刻找到最小的RTT和最大带宽。这样最小RTT和最大带宽必须分别探测。 探测最大带宽的方法就是尽量多发数据，把网络中的buffer占满，带宽在一段时间内不会增加，这样可以得到此时的最大带宽。 探测最小RTT的方法就是尽量把buffer腾空，让数据交付延时尽量低。 由此，BBR就引入了基于不同探测阶段的状态机。 状态机分为4个阶段，Startup，Drain，ProbeBW， ProbeRTT。 Startup类似于普通拥塞控制里的慢启动，增益系数是 2ln2，每一个来回都以这个系数增大发包速率，估测到带宽满了就进入 Drain状态，连续三个来回，测得的最大瓶颈带宽没有比上一轮增大 25%以上，就算带宽满了。 进入 Drain状态，增益系数小于 1，也就降速了。一个包来回，把 Startup状态中产生的拍队排空，怎样才算队列空了？发出去还没有 ACK 的数据包量 inflight，与 BDP 进行比较，inflight < BDP 说明空了，道路不那么满了，如果 inflght > BDP 说明还不能到下一个状态，继续 Drain。 ProbeBW是稳定状态，这时已经测出来一个最大瓶颈带宽，而且尽量不会产生排队现象。之后的每个来回，在 ProbeBW状态循环（除非要进入下面提到的 ProbeRTT状态），轮询下面这些增益系数，[5/4, 3/4, 1, 1, 1, 1, 1, 1]，如此，最大瓶颈带宽就会在其停止增长的地方上下徘徊。大部分时间都应该处于 ProbeBW状态。 前面三种状态，都可能进入 ProbeRTT状态。超过十秒没有估测到更小的 RTT 值，这时进入 ProbeRTT状态，把发包量降低，空出道路来比较准确得测一个 RTT 值，至少 200ms 或一个包的来回之后退出这个状态。检查带宽是否是满的，进入不同的状态：如果不满，进入 Startup状态，如果满，进入 ProbeBW状态。 BBR算法不会因为一次或者偶然的丢包就大幅降低吞吐量，这样就比TCP就有较强的抗丢包能力。 如图所示，cubic在丢包率上升的时候，吞吐量下降很快。而BBR在5%以上的丢包才会出现明显的吞吐量下降。 BBR与基于丢包反馈的cubic和基于延时反馈的vegas算法的本质区别在于，BBR无视随机丢包，无视时延短暂波动，采用了实时采集并保留时间窗口的策略，保持对可用带宽的准确探知。事实上，丢包并不一定会造成带宽减少，延迟增加也不一定会造成带宽减少，cubic无法判断是否拥塞造成的丢包，vegas对延时增加过于敏感，会导致竞争性不足。 BBR可以区分出噪声丢包和拥塞丢包，这样意味着，BBR比传统TCP拥塞控制算法具有更好的抗丢包能力。

实时音视频系统要求低延时，流畅性好，而实际网络状态却是复杂多变的，丢包，延时和网络带宽都在时刻变化，这就对网络拥塞控制算法提出了很高的要求。它需要一种带宽估计准确，抗丢包和抖动能力好的拥塞控制算法。 目前Google的webrtc提供了GCC控制算法，它是一种发送侧基于延迟和丢包的控制算法，这个算法的原理在很多地方都有详细描述，这里不再赘述。GCC用于实音视频的主要问题还在于在带宽发生变化时，它的带宽跟踪时间比较长，这样就会造成带宽突变的时候无法及时准确探测带宽，可能造成音视频卡顿。 既然BBR有良好的抗丢包能力，自然也被想到应用到实时音视频领域。但是，BBR并不是为处理实时音视频设计的，所以需要对一些问题做一些优化。 第一，BBR在丢包率达到25%以上，吞吐量会断崖式下降。 这是由BBR算法的pacing_gain数组[5/4, 3/4, 1, 1, 1, 1, 1, 1]的固定参数决定的。 在pacing_gain数组中，其增益周期的倍数为5/4，增益也就是25%，可以简单理解为，在增益周期，BBR可以多发送25%的数据。 在增益期，丢包率是否抵消了增益比25%？也就是说，x是否大于25。 假设丢包率固定为25%，那么，在增益周期，25%的增益完全被25%的丢包所抵消，相当于没有收益，接下来到了排空周期，由于丢包率不变，又会减少了25%的发送数据，同时丢包率依然是25%...再接下来的6个RTT，持续保持25%的丢包率，而发送率却仅仅基于反馈，即每次递减25%，我们可以看到，在pacing_gain标识的所有8周期，数据的发送量是只减不增的，并且会一直持续下去，这样就会断崖式下跌。 怎样才能对抗丢包，这就需要在每个周期考虑丢包率，把丢包率补偿进去。比如丢包率达到25%的时候，增益系数就变成50%，这样就可以避免由于丢包带来的反馈减损，然而，你又如何判断这些丢包是噪声丢包还是拥塞丢包呢？答案在于RTT，只要时间窗口内的RTT不增加，那么丢包就不是拥塞导致的。 第二，BBR的最小RTT有个10s超时时间，在10s超时后，进入ProbeRTT 状态，并持续最小200ms，此状态下，为了排空拥塞，inflight只允许有4个包，这会导致音视频数据在这段时间内堆积在发送队列中，使得时延增加。 可行的解决办法是，不再保留ProbeRTT状态，采用多轮下降的方式排空拥塞，然后采样最小RTT，也就是在infight > bdp的时候，设置pacing gain为0.75，用0.75倍带宽作为发送速率，持续多轮，直到inflight < bdp, 此外，最小RTT的超时时间改成2.5s，也就是说不采用非常激进的探测方式，避免了发送速率的大幅波动，可以改善探测新的带宽过程中发送队列中产生的延时。 第三，开始提到pacing gain数组上探周期为1.25倍带宽，随后是0.75倍带宽周期，这两个RTT周期之间会出现发送速率的剧烈下降，这可能会使音视频数据滞留在buffer中发不出去，引入不必要的延时。 解决办法可以考虑减小上探周期和排空周期的幅度，比如使用[1.1 0.9 1 1 1 1 1 1]这种pacing gain参数，这样做的优点就是可以保证媒体流的平稳发送，发送速率不会大幅波动，缺点是，网络带宽改善的时候，上探时间会变长。 第四，BBR探测新带宽收敛慢的问题 原始的BBR算法的收敛性受到pacing gain周期影响，带宽突降的时候，BBR需要多个轮次才会降到实际带宽。这是由于BBR每轮只能降速一次，而pacing gain的6个RTT的保持周期大大加长了这个时间。解决的办法就是随机化pacing gain的6个保持周期，如果是0.75倍周期，就一次降速到位，这样可以极大的减少BBR的收敛时间。 最后，BBR算法看似简单，但是应用到实时音视频却没有那么简单，需要大量的实验优化，谷歌也在webrtc中引入BBR，目前仍在测试中。本文提到的改进方法是网易云信在这方面的一些尝试，希望能够抛砖引玉，有更多有兴趣的人能够为BBR应用到实时音视频领域出力。

存在的问题： 收敛速度慢；（解决办法：bbr v2提出在probe bw的0.75x周期一次排空到位；随机化6个1x平稳发送周期，缩短排空需要的时间） 抗丢包能力不足，原版算法超过20%丢包，带宽断崖式下降；（解决办法：把丢包率补偿到probe bw的各个周期内，可以有效提升抗丢包能力） probertt只发4个包，不适合低延迟的流媒体应用。（解决办法：bbr v2把probe rtt缩短到2.5s一次，另外使用0.5 bdp发送）。

服务器分发网络：传统cdn树形拓扑： 存在问题：顶层容易成为瓶颈与单点；层级越深、延迟越大。

服务器分发网络：nrtc低延迟拓扑方案： mesh, tree, proxy融合 控制层级、控制延时、水平扩展性强、无单点。

基于机器学习的拥塞控制算法：pcc 当前的拥塞控制算法依赖hardwired mapping来控制发送速率，本质上是对网络的一种假设。 pcc类似机器学习，设置一个目标函数，然后不断地尝试各种发送速率，最终使得目标函数达到最优。 pcc v2: vivace是一个很有意思的方向。

bbr算法： https://mp.weixin.qq.com/s?__biz=MzI0MjEwNTUyOA%3D%3D&mid=2650032597&idx=1&sn=ff854fe3696743ef6230769f54f4b06a&scene=45#wechat_redirect

liuty10 commented 3 years ago

video encoding textbook https://github.com/leandromoreira/digital_video_introduction https://www.youtube.com/watch?v=dqxbBl-BGho https://web.stanford.edu/class/ee398a/ https://www.youtube.com/watch?v=uOLF0RynLEQ

liuty10 commented 3 years ago

how an image is captured from the world to the bits. https://www.cambridgeincolour.com/tutorials/camera-sensors.htm

liuty10 commented 3 years ago

DCT https://web.archive.org/web/20150129171151/https://www.iem.thm.de/telekom-labor/zinke/mk/mpeg2beg/whatisit.htm https://arxiv.org/pdf/1702.00817.pdf

https://zhuanlan.zhihu.com/p/85299446 https://www.zhihu.com/question/22085329/answer/774074211 https://www.cnblogs.com/byeyear/p/4513255.html JPEG 2000 是基于小波变换的图像压缩标准

liuty10 commented 3 years ago

码率控制： https://blog.csdn.net/leixiaohua1020/article/details/12720135 https://zhuanlan.zhihu.com/p/250585488 视频编码（有损）的目标是尽可能多的节省比特（码率）的同时尽量保持视频质量。码率控制是平衡码率和质量的重要工具。 码率控制有多种方式，你将会了解到"1-pass","2-pass","CBR","VBR","VBV Encoding"和"CRF"等。

选择哪种码率控制模式往往取决于你的应用场景。通常有以下几种常见场景： 存档：压缩一个文件存到硬盘或网盘上。这时你希望文件编码后质量尽可能好同时码率尽可能低，但是你不关心压缩后文件的具体大小。 流媒体：你想要通过网络传输一个文件。这是你要确保文件码率不超过网络带宽，或者你需要在不同带宽下提供不同码率的文件。（例如，在网上看视频网络不好时将视频从高清切换到低清）。 直播流：和2类似，但是你需要尽快编码（实时），并且直播时你无法提前预知视频内容。 面向设备的编码：例如你想向DVD或蓝光碟上存放文件，你想使文件编码后达到特定大小（正好占满碟片空间）。

VBV(Video Buffering Verifier) 对于VBV可以确保码率不超过某个最大值。这对于流媒体非常有用，你现在可以确定你不会发送比你承诺的更多的比特。VBV可以和2-pass VBR（在两遍编码中都使用）或CRF一起使用。如果你在直播流中应用VBV，且你想加速编码过程，你可以使用-tune zerolatency和-preset ultrafast选项。这会牺牲一部分质量来加速编码。

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/null
ffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=1:vbv-maxrate=1000:vbv-bufsize=2000 -f null /dev/null
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/null

视频编码码率控制：CBR、VBR和ABR https://zhuanlan.zhihu.com/p/189497566 分析了导致音视频延时的原因，今天他主要讲解传输维度，分别从传输协议、拥塞控制算法、分发网络拓扑、第一公里角度等讲解了低延时这块网易云信的实践. 传输协议先比较了RTMP和SRT协议的优缺点，再提出了自研基于UDP协议。从各种RTC大会来看，大家基本都认可这么一个观点：要做好低延时实时视频，还是要果断抛弃TCP，无论自研还是选用开源项目，都要基本UDP，至少我也认为这个方向是正确的。 https://www.zhihu.com/column/c_1289953273844809728

TCP缺陷: 延迟不可控（ack机制）； 抗丢包能力差； 拥塞控制在内核，优化成本高；

QUIC优势: 0 RTT连接 前向纠错FEC, 抗丢包能力有所提升。 改进灵活的拥塞控制，可插拔（多种选择）。

QUIC缺陷： 本质上是可靠协议，对延迟不可控。 对音视频媒体不友好。

SRT是有haivision和wowza共同创建的SRT开源联盟。 特点： 安全方面：SRT支持AES加密，保障端到端的视频传输安全。 可靠性方面：SRT通过前向纠正技术（FEC）保证传输的稳定性。 低延迟方面：由于SRT建立在UDT协议之上，解决了UDT协议传输延迟高的问题。UDT协议基于UDP.

劣势： 复杂度过高。 丢包场景下速度退避过大。

基于UDP的自研协议： 描述不同可靠性、优先级； 完全面向音视频媒体，方便描述各类音视频媒体类型； 描述视频分片信息、视频时域分层信息、视频多流信息； 全局统一续；支持FEC; 应用层MTU切片；支持扩展丰富媒体信息；支持携带应用层路由信息；

对于传输拥塞控制算法，基本还是对比了GCC算法和BBR算法的优缺点，其次讲解了BBR算法的原理，网易云信对这块的实践基本是BBR算法和GCC算法交叉使用。根据不用的业务场景选用不同的拥塞控制算法，因为拥塞控制算法想达到一个比较好的效果都有它的场景和前提，最后介绍了目前基于AI对拥塞控制这块的处理新算法PCC算法，虽然云信还没实践，但是觉得这个算法是解决这类问题的新思路，后面保持关注会跟进。

liuty10 commented 3 years ago

流媒体传输协议：RTMP、HLS和RTSP介绍 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484355&idx=1&sn=46a11b64d8ec6f8dea950a39c6dde0e6&chksm=e9513c9fde26b58925308e96479d54087b92b37c1db2ec695e9dbfbe8c29fe86d07c7a1f351d&scene=21#wechat_redirect 基于HLS-TS&RTMP-FLV的微信小程序点直播方案 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484310&idx=1&sn=78bfc5c650a8a88a992471553a4ce29f&chksm=e9513ccade26b5dc5ed517dccafd535f0a66fbfee9a38d67ef2c6c8c5bed466441ff01e61bb8&scene=21#wechat_redirect SDP在RTSP、国标GB28181、WebRTC中的实践 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484139&idx=1&sn=6759a1e205bbd1026c1effb79e9e06ba&chksm=e9513db7de26b4a1ae6f2bb0d7906e2424350cbcf55a881bb6c527902e6bb06d3e7db0ba9e87&scene=21#wechat_redirect 音视频压缩：H264码流层次结构和NALU详解 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247483871&idx=1&sn=dce2703f857b99b137a928fa4fc1432d&chksm=e9513e83de26b795cfcdae2ed36ad60a5170a9cbfda7758aa35168e76f6e11cc87edf014ceca&scene=21#wechat_redirect 音视频传输：RTP协议详解和H.264打包方案 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247483855&idx=1&sn=28f5243f7c71d165564d117a4a8f1730&chksm=e9513e93de26b785a6f630112732dcdea5fc92f84ec7c5f6e44c4ad98370b952c1f749c8f132&scene=21#wechat_redirect webrtc demo: https://cloud.tencent.com/developer/article/1755169 国产开源流媒体 SRS4.0 对视频监控 GB28181 的支持 https://xie.infoq.cn/article/69be9ce4d7523554bc82ad87c 音视频基础知识-时间戳的理解 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247483661&idx=1&sn=92c907d2d94298106ae56a59661da9a3&chksm=e9513e51de26b7476ea6030410c23fdf7e8d911962d1821f7f5a58bb0fa9ab005e3efbb07afa&scene=21#wechat_redirect 2021上海LVS音视频大会观感和思考 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484474&idx=1&sn=5106a41d5a65d4c89342755dd64d132c&chksm=e9513b66de26b27021ae497731f0fbf2a9bbe992d3460ca695a2e835184d337304286c445673&scene=132#wechat_redirect C的概念从communication拓展到compute、connection等概念，这种理解还是非常新颖的观点. 5G解决的是空口延时（大概就是从设备端到5G基站这块的延时），显然空口延时只是传输延时的一部分，像音视频领域的编码延时，骨干核心网的传输延时以及路由器的处理排队延时，这些是没办法通过5G进行解决的。 即使享受了5G eMBB带来的空口延时优势，但是使用APP不是在公司WIFI就是在家里WIFi,只有在户外没有WIFi情况下我们才会用5G移动流量。随着WIFi6技术的到来，5G产生的空口延时效益将迅速被追平。所以5G对大部分消费者和应用来说，带来的效益和红利没有想象那么高。

  1. 未来5G产生收益应该更多的ToB业务，比如车载娱乐应用以及工业互联网领域，一些远程医疗和边缘计算可能会有比较大的收益。5G对消费者的影响可能在户外直播和虚拟现实AR上。
  2. 未来端上网络理想情况应该是WiFi完成室内通信，户外城市等场景使用5G，在野外等人迹罕至的场景可能还要依赖马斯克的天际同步卫星来提供联网功能。

编解码技术的新突破口-AI 了解编解码技术的同学基本都清楚，目前的编码技术框架大概从30年前就确定下来了。以H.261/H.264/H.265技术为代表，编码的核心都是从人的视觉生物特征入手解决大量的空间和时间冗余，要经过预测、变换、量化和熵编码等过程。这一传统编码方案同样适用于后来的VP9/AV1以及国内的AVS编码框架，在可预见的范围内，这些还是主流的编码框架和技术。随着新一代编码技术H.266和AV1发布，已经显示出传统编码方案复杂性以及对计算量的迅速提升，要向继续向后面演进已经越来越难。 前几年就能听到一些高校老师和大厂音视频实验室分享利用AI技术来突破传统编码框架的想法。这些内容以前听得还是比较朦胧，分享出来能落地的案例也几乎没有。但是本次大会能听到这个趋势越来越明确化，特别是在帧内编码和基于深度学习的Lyra语音编码器的开源和发布，利用AI技术来进行端到端编解码可能要成为下一代编码技术的主流，五到十年之内应该会取得比较大的突破，希望大家关注并留意这一重大技术趋势。

BBR在实时音视频领域的应用 https://mp.weixin.qq.com/s?__biz=MzI0MjEwNTUyOA%3D%3D&mid=2650032597&idx=1&sn=ff854fe3696743ef6230769f54f4b06a&scene=45#wechat_redirect 工具使用：利用SRS和FFmpeg搭建流媒体直播和点播系统 https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484044&idx=1&sn=22cacbcb4b97bb2969f9a73fa3a09a6e&chksm=e9513dd0de26b4c64654a43e7c5b5282283818e8c2075a70f16d6efe16403a15dcc8a91e4454&scene=21#wechat_redirect

周末活动回顾：视频质量主观评价、实时RTC和AV1: GCC, BBR, 4K, 5G https://mp.weixin.qq.com/s?__biz=MzI0NTMxMjA1MQ==&mid=2247484106&idx=1&sn=71d9d7865723bfe50bbeef6c4f024a3a&chksm=e9513d96de26b48050e377a1c4d4ed52b6ac67b151669ff3ba6eb127ecd5df56f366291be5a8&scene=21#wechat_redirect 手把手搭建WebRTC测试环境，实现1对1视频通话 https://cloud.tencent.com/developer/article/1755169

lyra 低码率音频编解码 https://zhuanlan.zhihu.com/p/363176628 https://github.com/google/lyra https://ujoy.net/topics/2943738 Lyra 的代码是用 C++ 所编写的，以提高速度、效率和互操作性，使用 Bazel 构建框架和 GoogleTest 框架进行彻底的单元测试. Google Lyra是一种基于生成模型的新语音压缩方法，通过极大地提高原始语音的声音质量（即大约需要8-16 kbps），可以仅以3 kbps的低带宽获得透明质量.

Multimedia Acceleration eXtensions https://en.wikipedia.org/wiki/Multimedia_Acceleration_eXtensions

liuty10 commented 3 years ago

ccp project: https://github.com/ccp-project https://ccp-project.github.io https://akshayn.xyz/res/ccp-sigcomm18.pdf