浅压缩、深压缩、双引擎、计算机屏幕编码……何去何从?

2024-02-04 14:36

本文主要是介绍浅压缩、深压缩、双引擎、计算机屏幕编码……何去何从?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

专业视听领域尤其显示控制和坐席控制领域,最近几年最激动人心的技术,莫过于分布式了。

分布式从推出之日就备受关注:担心稳定性的,质疑同步性能的,怀疑画面质量的……

诚然,我们在此前见多了带着马赛克的模糊不清的监控画面,遇到过电脑上网刷个网页几秒钟不出来的事情。

这么不靠谱的网络上能担当起专业音视频所需要的高画质、高度同步和低延时?

但是分布式音视频带给人们的体验确实是革命性的,因此吸引了众多的行业精英倾其所能的投入研发。

路虽远行则将至,事虽难做则必成。

至今,无论过去对分布式持何种看法的主流视听领域的公司都在投入研发,并且提出了各自的解决方案。

因每个公司看问题的角度,解决问题的出发点不同,提出了不同的解决方案,浅压缩、深压缩、双引擎、计算机屏幕编码……眼花缭乱。

这些分布式方案都对音视频进行IP化,但IP化必然会对视频压缩,毕竟视频的带宽比网络的带宽大太多了。

压缩就面临画质和码率问题。

分布式产品最基本的是解决显示问题,如果图像不好,再丰富的功能也是舍本逐末;如果码率过大,IP化不“彻底”,不能获得IP化的红利。

因此可以说,图像压缩和还原技术好坏,是评判一家公司技术水平的关键,也是评判一款产品优劣的核心要素。

那么何谓浅压缩、深压缩、双引擎、计算机屏幕编码?各自有什么优劣?这应该是系统建设方、使用方、设计方最关心的问题了。

首先我们以一个表格来列举下各种方式的对比,然后再逐一尽量详细客观的列出其优缺点,以便读者在设计和建设音视频系统时参考。
在这里插入图片描述

计算机屏幕编码:只用低码率、高压缩比编码方式(一般H.264/265),实现达到计算机屏幕级别(表现为颜色突然跳变,如黑底红字,黑底蓝字,红底黑字,红底蓝字等)画质要求的编码技术。高通、微软、华为都具备这方面的发明专利,国内分布式领域也有公司具有这方面的发明专利技术。系统不论大小均可胜任,缺点是成本较高。

在这里插入图片描述

优点之一:画质好,即便严苛的计算机测试画面,也和原图几乎没有差异(如上图);

优点之二:是带宽低。其采用的编码方式还是HEVC(H.265)或者H.264,因此码率1路1080P@60一般就在10-20Mbps水平,对一般的有线网络来说非常轻松,甚至可以用现有的计算机网络(甚至因特网)承载而不影响业务网络;

优点之三:和安防、视频图像网、AI等无缝衔接(因为都是H.264/265),分布式的优势体现得更大(如无需任何解码器直接取安防平台流上显示墙,直接取流进行人、车以及人脸识别等)。

缺点:技术难度大,用以实现的芯片组价格昂贵,往往还需要配合FPGA或者DSP之类,设备成本高,价格往往比较高;

浅度压缩:视听行业中一类高码率视频压缩算法的总称,这类算法因压缩程度相对较低,算法复杂度也较低,故称为浅度压缩。浅压缩分布式主要采用SDVoE、VC-2、JPEG2000和私有算法等编码方式,对视频的压缩较小,视频画面的还原度高,相比深压缩产品,画质更好,同步性更高,延时更低。但同时因为码率高,所以较多用于本地会议级的小规模场景应用,整个系统对网络带宽的要求也会高出很多,整体建设成本更高。
在这里插入图片描述

优点之一:相对降采样为4:2:0后的深度压缩画质好,尤其计算机画面,基本能做到视觉无损;

优点之二:一般来说浅度压缩用帧内编码,编码延时比较小;但是因为码率大,往往消除网络抖动的时间余量都留得比较大;综合后延时有的产品和深压缩相当,有的略优。

优点之三:器件要求不高,成本低,容易实现。

缺点之一:码率太大,一般1路1080P@60就达到300-900Mbps,1路4KP@60最大可能达到4000Mbps,远超1路千兆网的承载水平,和5G等结合就更没可能了。

缺点之二:存储需求的存储空间太大,几乎不可用。按平均码率500Mbps算,也是H.264/265码率的20-50倍。

缺点之三:编码方式和安防平台几乎都不兼容,分布式的红利发挥不出来,还需要大量的转码器、编解码器和安防平台对接。

深度压缩:视听行业中一类低码率视频压缩算法的总称,与浅度压缩相反,这类算法因压缩程度相对较高,故称为深度压缩。行业内一般特指用安防H.264/265编码芯片的,降采样为4:2:0后进行编码的方式。因为画质比较低,所以一般应用于低成本,要求不高的场合。
在这里插入图片描述

优点之一:带宽低。其采用的编码方式是HEVC(H.265)或者H.264,因此1路1080P@60码率一般就在10-20Mbps水平,对一般的有线网络来说非常轻松,甚至可以用现有的计算机网络承载而不影响业务;

优点之二:和安防、视频图像网、AI等无缝衔接(因为都是H.264/265),分布式的优势体现得更大(如无需任何解码器直接取安防平台流上显示墙,直接取流进行人、车以及人脸识别等)。

优点之三:成本低,容易实现。因为采用安防芯片,芯片成本低,而且一般有较为成熟的方案,进行功能性研发即可。

缺点:画质较差。一般视频画面,电脑画面没问题,但是有强烈反差的画面,如CAD图、轨道交通图、雷达图、电力运行图,甚至部分情况下word,excel的效果都无法接受(如当excel表格选中一列时就模糊了,特别是当文字是红色时)。

双引擎(双码流):一个设备里边同时放置高码率编码芯片和低码率编码芯片,严格来说它并不是一种编码方式,但它是一种解决码率和画质的方法:高码率芯片用于解决本地显示清晰度问题,低码率编解码芯片(一般是H.264/265)为了解决远距离传输和对接安防平台的问题。实现较为容易,但网络较为复杂,同时只解决了本地画质问题,异地画质和存储画质问题还是未能解决。
在这里插入图片描述

优点之一:能兼顾本地显示画质和远距离传输的低码率要求;

优点之二:低码率引擎其实一般就是安防编解码芯片,所以也能和安防、视频图像网等对接。

优点之三:成本虽然比浅压缩和深压缩略高,但是浅压缩芯片和安防芯片(深压缩)都便宜,所以即便都放置进去,成本也低,而且容易实现。

缺点之一:远距离传输和存储的画质始终还是安防级的画质,是难以让人满意的。高码率和低码率同时编码1路图像,始终只是权宜之计,并没有从根本上解决压缩率和画质的问题。

缺点之二:浅压缩的码率还是很高,即便本地应用,大规模的应用对核心交换机的压力非常大,接入交换机选型也非常苛刻(系统必须满足极限要求,即每个端口900Mbps,48路的接入交换机,则上行44G,10个10G口都不够,但是往往接入交换机达不到48个千兆线速+4个万兆线速的包交换速度)。

缺点之三:系统互相影响大,系统稳定性,特别是大规模项目的稳定性,尚需要时间检验。

结语

一方面,是网络技术的飞速发展,虽然主流还是千兆网络,但是万兆网络也不再昂贵,且全部的千兆网络迭代到万兆尚需时日;
另一方面是视频清晰度往更清(4KP30,4KP60,8KP30均已经较为常见)、色彩更丰富(从24位色往30、36位升级,内容增加50%)方向升级的速度更快。

正在建设中,且可预见的近5-10年内大放异彩的5G,虽然下载速度达到500Mbps甚至更高,但是普遍上行速度为50+Mbps,即便网络良好的地方上行速度也就在200Mbps,是无法承载哪怕1路1080P@60的浅压缩视频流的,更别说1路4KP60了。

所以现阶段看来,分布式在未来5-10年内要充分5G的红利,依托5G生态建立更多精彩的应用,甚至能否跳出显示控制的狭窄应用,无缝融合到指挥、业务流程,实现更大的价值,低码率和画质始终是绕不过去的槛。

何去何从,我们拭目以待!
原文链接:https://mp.weixin.qq.com/s/jvp1I9BcngYxX0OVwqHivw

这篇关于浅压缩、深压缩、双引擎、计算机屏幕编码……何去何从?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/677827

相关文章

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

hdu1565(状态压缩)

本人第一道ac的状态压缩dp,这题的数据非常水,很容易过 题意:在n*n的矩阵中选数字使得不存在任意两个数字相邻,求最大值 解题思路: 一、因为在1<<20中有很多状态是无效的,所以第一步是选择有效状态,存到cnt[]数组中 二、dp[i][j]表示到第i行的状态cnt[j]所能得到的最大值,状态转移方程dp[i][j] = max(dp[i][j],dp[i-1][k]) ,其中k满足c

C++ | Leetcode C++题解之第393题UTF-8编码验证

题目: 题解: class Solution {public:static const int MASK1 = 1 << 7;static const int MASK2 = (1 << 7) + (1 << 6);bool isValid(int num) {return (num & MASK2) == MASK1;}int getBytes(int num) {if ((num &

C语言 | Leetcode C语言题解之第393题UTF-8编码验证

题目: 题解: static const int MASK1 = 1 << 7;static const int MASK2 = (1 << 7) + (1 << 6);bool isValid(int num) {return (num & MASK2) == MASK1;}int getBytes(int num) {if ((num & MASK1) == 0) {return

form表单提交编码的问题

浏览器在form提交后,会生成一个HTTP的头部信息"content-type",标准规定其形式为Content-type: application/x-www-form-urlencoded; charset=UTF-8        那么我们如果需要修改编码,不使用默认的,那么可以如下这样操作修改编码,来满足需求: hmtl代码:   <meta http-equiv="Conte

4-4.Andorid Camera 之简化编码模板(获取摄像头 ID、选择最优预览尺寸)

一、Camera 简化思路 在 Camera 的开发中,其实我们通常只关注打开相机、图像预览和关闭相机,其他的步骤我们不应该花费太多的精力 为此,应该提供一个工具类,它有处理相机的一些基本工具方法,包括获取摄像头 ID、选择最优预览尺寸以及打印相机参数信息 二、Camera 工具类 CameraIdResult.java public class CameraIdResult {

通用内存快照裁剪压缩库Tailor介绍及源码分析(一)

背景 我们知道内存快照是治理 OOM 问题及其他类型的内存问题的重要数据源,内存快照中保存了进程虚拟机的完整的堆内存数据,很多时候也是调查其他类型异常的重要参考。但是dump出来的堆转储文件.hprof往往很大,以 LargeHeap 应用为例,其 OOM 时的内存快照大小通常在512M左右,要有效的存储和获取都是一个问题。 线下拿到hprof文件相对容易,也可以预防OOM,但覆盖的场景十分有

Python字符编码及应用

字符集概念 字符集就是一套文字符号及其编码的描述。从第一个计算机字符集ASCII开始,为了处理不同的文字,发明过几百种字符集,例如ASCII、USC、GBK、BIG5等,这些不同的字符集从收录到编码都各不相同。在编程中出现比较严重的问题是字符乱码。 几个概念 位:计算机的最小单位二进制中的一位,用二进制的0,1表示。 字节:八位组成一个字节。(位与字节有对应关系) 字符:我们肉眼可见的文字与符号。

在Eclipse环境下修改Tomcat编码的问题

问题: 由于BMS需要设置UTF-8编码,要不就会出现中文乱码问题; 一、项目保持UTF-8格式; 二、由于可能会多次移除项目、加载项目,不想每次都要修改tmp0\conf 原因: 如果在eclipse中配置了tomcat后,其实,tomcat所用的所有tomcat配置文件,都不是catalina_home/config下面的xml文件,而是在eclipse所创建的Serve

在Unity环境中使用UTF-8编码

为什么要讨论这个问题         为了避免乱码和更好的跨平台         我刚开始开发时是使用VS开发,Unity自身默认使用UTF-8 without BOM格式,但是在Unity中创建一个脚本,使用VS打开,VS自身默认使用GB2312(它应该是对应了你电脑的window版本默认选取了国标编码,或者是因为一些其他的原因)读取脚本,默认是看不到在VS中的编码格式,下面我介绍一种简单快