拒绝内卷,创造神话
目标: 一站式webrtc直播解决方案(sfu+mcu),包括娱乐直播和实时互动。
安全: 代码部署安全、核心功能安全;
webrtc P2P
基于ffmepg-sdk开发音视频编码/解码相关后端程序,重点就是要多读ffmpeg源码(前提是C/C++编程基础)。
在实时互动直播系统中,很少使用B帧。主要的原因是压缩和解码B帧时,由于要双向参考,所以它需要缓冲更多的数据,且使用的CPU也会更高。由于实时性的要求,所以一般不使用它。不过对于播放器来说,遇到带有B帧的H264数据是常有的事儿。在没有B帧的情况下,存放帧的顺序和显示帧的顺序就是一样的,PTS和DTS的值也是一样的。
显卡解码
对于解码来讲相对简单一些,解码性能最主要看两个指标就可以了,一个是单解码器解码的帧数,一个是解码芯片数。
yuv420sp(I420)
yuv420p
NV12
NV21
对于中小型公司,做音视频直播,视频会议相关的产品,自研 UDP,P2P 是不太可能的,运营这样一个研发团队,一年的开销是千万级别的投入。所以 webrtc,甚至第三方基于 webrtc开发的sdk,成了中小公司进入音视频领域的最快做产品的方案。未来 WebRTC 在国内的应用,也会越来越流行,需要大量的开发者。
做音视频技术,可以深而不广,也可以广而不深。
做AI相关技术
切记: 不要小打小闹,只懂皮毛;要在一个领域深耕,精雕细琢 才能做出精品。-- 小打小闹做出来的东西没有竞争力。
积极拥抱开源
不弄虚作假
解决问题的能力
深度 -》广度
关注前沿技术的发展
突破舒适区
作为音视频技术公司,很多基础指标必须重点研究:(包括开发、测试等环节;测试环境和正式环境)
要尝试各种手段测试,开发各种测试工具。
智能抠图
插帧
webrtc录制的视频 出现先模糊,后清晰的过程。有没有什么优化方法,让webrtc接入 一开始就是清晰视频。
优先级高的问题:播放失败率太高;
为什么大家偏向 srs-librtmp去推rtmp流 ,而不用ffmpeg librtmp去推流?
抽帧截图: 无损压缩,有损压缩。
根据场景选择无损还是有损压缩。 一般的直播场景多考虑采用有损压缩:节约存储和带宽。
(1)在音视频后端处理(混画、转码)时,对一个GOP有丢帧的后,就丢掉剩余的帧;从下一个GOP开始做解码、编码操作; -- 解决方案
(2)直播录制的视频花屏/绿屏,使用ffmpeg转码。ffmpeg解码、编码会丢掉一个GOP内剩余的异常帧。
https://jishuin.proginn.com/p/763bfbd75e45
ffplay 是 ffmpeg 自带的跨平台播放器,使用 C 语言编写。当你在编译 ffmpeg 添加如下参数 「--enable-ffplay」 的时候 ,编译完成会在 「output/bin/」 下产生一个 ffplay 可执行文件,使用 「ffplay xxx.mp4」 就可以播放一个媒体文件,它主要是以 ffmpeg + sdl 实现的一个播放器。其实大名鼎鼎的 ijkplayer 就是基于 ffplay.c 进行的二次开发,所以掌握 ffplay 原理对我们开发播放器有非常大的帮助。
因为开播工具准备好后,传输接入CDN,观众端使用标准的播放器播放;-- 就可以快速搭建娱乐直播、在线教育、电商直播系统。
做一个非常有信念感的人,必须把一件事情做好,并做到极致。
不要内卷,必须提升自己的能力。
windows webrtc编译花了很久时间,陷入了泥潭。-- 所以一定要做擅长的领域,暂时避开不擅长的技术。