编码

01、喷泉码简介喷泉码（Fountain Code）是一种在无线通信、数据传输和网络编码畛域中应用的谬误纠正技术。它与传统的纠错码和编码方法有所不同，喷泉码被设计用于在不确定信道条件下的高效数据传输。传统的纠错码（如海明码、RS码等）通常须要在发送方对数据进行编码，接管方则应用雷同的编码进行解码和纠错。这些办法个别具备固定的码率（Code Rate），即针对肯定长度的原始数据，编码后的长度是固定的，这些办法在面对不稳固的信道或重大的信道失落时可能成果不佳。相比之下，喷泉码通过在发送方生成随机的冗余数据，而后将其注入到原始数据中，以发明出一个“喷泉”流——相应的码率也也就不固定了。接管方能够从这个流中采样任意数量的数据包，并将它们合并以复原原始数据。喷泉码的一种常见利用是在无线传感器网络中，其中网络节点之间的通信可能受到弱信号、烦扰和多径流传等因素的影响。通过应用喷泉码，节点能够在较差的通信条件下实现牢靠的数据传输。喷泉码另外一个罕用的场景是大量文件或者数据的播送，这种时候每位接受者的丢包率是不确定的，因而固定码率的编码就不实用，喷泉码却能够解决该场景下的问题——丢包率高的接受者多收一些包，丢包率少的接受者则少收一些包。本文会介绍最常见的两种喷泉码实现，LT 编码 和 Raptor 编码。通过这两种编码的介绍和比拟能够比拟好的理解喷泉码的个性和根本的实现原理。 02、LT 编码LT 编码 是第一个被实现的具备实用价值的喷泉码，该编码在 2002 年被提出，实现记的基本原理也非常简单，即位运算中的 xor 操作。Xor 操作有如下的个性： 两个雷同的数据块 M，它们 Xor 的后果是 0。即 M ^ M = 0。对一块数据块 M，Xor 两次雷同的数据块 N，最终后果依然为 M。即 M ^ N ^ N = M。假如两个等长的数据块 M 和 N，M ^ N = L。那么 L ^ M = N 并且 L ^ N = M。基于上述的个性，LT 编码的形式就能够形容为下列的步骤： 对于长度为 N 的等宽数据块序列，随机选取一个 degree (d)，1 ≤ d ≤ N。从上述的数据块中选取随机 d 个数据块，将所有选取的数据块进行 xor 操作，最终失去一个编码的数据块。反复上述步骤 1 和 2，咱们能够失去源源不断的编码数据块，如同“喷泉”一样水流一直。编码过程很简略，惟一须要留神一下的问题是如何取得等款的数据块。如果总数长度不可能凑巧分成 N 等分，咱们能够通过在后续加 padding 的形式来实现能够 N 等分。解码绝对比较复杂， 形容如下： ...

一 前言对于一个类别特色，如果这个特色的取值十分多，则称它为高基数（high-cardinality）类别特色。在深度学习场景中，对于类别特色咱们个别采纳Embedding的形式，通过预训练或间接训练的形式将类别特征值编码成向量。在经典机器学习场景中，对于有序类别特色，咱们能够应用LabelEncoder进行编码解决，对于低基数无序类别特色（在lightgbm中，默认取值个数小于等于4的类别特色），能够采纳OneHotEncoder的形式进行编码，然而对于高基数无序类别特色，若间接采纳OneHotEncoder的形式编码，在目前成果比拟好的GBDT、Xgboost、lightgbm等树模型中，会呈现特色稠密性的问题，造成维度劫难， 若先对类别取值进行聚类分组，而后再进行OneHot编码，尽管能够升高特色的维度，然而聚类分组过程须要借助较强的业务教训常识。本文介绍一种针对高基数无序类别特色十分无效的预处理办法：平均数编码（Mean Encoding）。在很多数据挖掘类比赛中，有许多人应用这种办法获得了十分优异的问题。 二 原理平均数编码，有些中央也称之为指标编码（Target Encoding），是一种基于指标变量统计（Target Statistics）的有监督编码方式。该办法基于贝叶斯思维，用先验概率和后验概率的加权平均值作为类别特征值的编码值，实用于分类和回归场景。平均数编码的公式如下所示： 其中： 1. prior为先验概率，在分类场景中示意样本属于某一个\_y\_\_i_的概率 其中\_n\_\_y\_\_i\_示意y =\_y\_\_i_时的样本数量，\_n\_\_y_示意y的总数量；在回归场景下，先验概率为指标变量均值： 2. posterior为后验概率，在分类场景中示意类别特色为k时样本属于某一个\_y\_\_i_的概率 在回归场景下示意 类别特色为k时对应指标变量的均值。 3. __为权重函数，本文中的权重函数公式相较于原论文做了变换，是一个枯燥递加函数，函数公式： 其中 输出是特色类别在训练集中呈现的次数n，权重函数有两个参数： ① k：最小阈值，当n = k时，__= 0.5，先验概率和后验概率的权重雷同；当n < k时，__\> 0.5, 先验概率所占的权重更大。 ② f：平滑因子，控制权重函数在拐点处的斜率，f越大，曲线坡度越缓。上面是k=1时，不同f对于权重函数的影响： 由图可知，f越大，权重函数S型曲线越缓，正则效应越强。 对于分类问题，在计算后验概率时，指标变量有C个类别，就有C个后验概率，且满足 一个 \_y\_\_i_ 的概率值必然和其余 \_y\_\_i_ 的概率值线性相关，因而为了防止多重共线性问题，采纳平均数编码后数据集将减少C-1列特色。对于回归问题，采纳平均数编码后数据集将减少1列特色。 三 实际平均数编码不仅能够对单个类别特色编码，也能够对具备层次结构的类别特色进行编码。比方地区特色，国家蕴含了省，省蕴含了市，市蕴含了街区，对于街区特色，每个街区特色对应的样本数量很少，以至于每个街区特色的编码值靠近于先验概率。平均数编码通过退出不同档次的先验概率信息解决该问题。上面将以分类问题对这两个场景进行开展： 1. 单个类别特色编码： 在具体实际时能够借助category_encoders包，代码如下： import pandas as pdfrom category_encoders import TargetEncoderdf = pd.DataFrame({'cat': ['a', 'b', 'a', 'b', 'a', 'a', 'b', 'c', 'c', 'd'], 'target': [1, 0, 0, 1, 0, 0, 1, 1, 0, 1]})te = TargetEncoder(cols=["cat"], min_samples_leaf=2, smoothing=1)df["cat_encode"] = te.transform(df)["cat"]print(df)# 后果如下： cat target cat_encode0 a 1 0.2798011 b 0 0.6218432 a 0 0.2798013 b 1 0.6218434 a 0 0.2798015 a 0 0.2798016 b 1 0.6218437 c 1 0.5000008 c 0 0.5000009 d 1 0.6344712. 层次结构类别特色编码： ...

编码的重要作用计算机只能解决数字，如果想让计算机解决人类语言，则须要将字符转换为数字，而计算机编码就是将字符转换为数字的过程。 编码还能够用于压缩数据，以便更无效地存储和传输数据。常见的编码方式ASCII 码ASCII 码，能够示意 128 个字符，用一个字节的低 7 位示意，0 ～ 31 是控制字符，比方 换行、回车、删除 等；32~126 是打印字符，能够通过键盘输入并且可能显示进去。 ISO-8859-1128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码根底上又制订了一些列规范用来扩大 ASCII 编码，它们是 ISO-8859-1 ~ ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所以利用的最宽泛。ISO-8859-1 依然是单字节编码，它总共能示意 256 个字符。 GB2312全称是《信息替换用汉字编码字符集 根本集》，它是双字节编码，总的编码范畴是 A1-F7，其中从 A1-A9 是符号区，总共蕴含 682 个符号，从 B0-F7 是汉字区，蕴含 6763 个汉字。 GBK全称是《汉字内码扩大标准》，是国家技术监督局为 windows95 所制订的新的汉字内码标准，它的呈现是为了扩大 GB2312，退出更多的汉字，它的编码范畴是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能示意 21003 个汉字。 GBK 兼容 GB2312，也就是说用 GB2312 编码的汉字能够用 GBK 来解码，并且不会有乱码。GB18030全称是《信息替换用汉字编码字符集》，是我国的强制规范，它可能是单字节、双字节或者四字节编码。 尽管是国家标准，然而理论利用零碎中应用的并不宽泛。 GB18030 兼容 GB2312。UTF-16说到 UTF 必须要提到 Unicode（Universal Code 对立码），ISO 试图想创立一个全新的超语言字典，世界上所有的语言都能够通过这本字典来互相翻译。Unicode 能够表白的字符十分多，须要用多个字节来存储。 ...

sjmj 《数据密集型利用零碎设计》 - 数据编码和演变前言本章的前半部分提到的编码框架目前在GO畛域蛟龙得水，并且有不少成熟的产品诞生，如果是GO工作者必然会接触，如果仅仅是试图理解该畛域设计的一些技术架构，这一章更多的是扫盲和拓展眼界。 本章节的后半局部探讨的RPC和SOAP，以及基于WebService服务跨语言通信服务，和RPC通信协议，然而WebService这货色当初用的人越来越少，反观微服务才是以后的支流。 尽管须要住的是尽管HTTP/2曾经进去不少年头的了，然而RPC仍然占有重要的比重，所以也是值得关注的，最为典型的当然是Dubbo框架。 为什么HTTP2.0都进去了，RPC还在持续倒退呢？因为HTTP2.0 刚刚公布的时候，RPC曾经具备相当的倒退，技术也绝对成熟，另外很多我的项目零碎架构曾经齐全搭建，换回HTTP2费劲不讨好，自身也没有必要，因为RPC协定没有特地大的缺点。并且领有不错的个性 。章节介绍从历史的演变的角度来看，尽管过来呈现过许多尝试代替HTTP协定的WEB通信框架，然而市场总是须要稳固成熟的架构，这些新兴通信协议最终都默默黯淡在历史的长河之中。 零碎的演进除了数据结构和数据模型自身的演变之外，数据编码和数据之间的交互模式也在一直的进行演变，数据模式和格局扭转的时候，通常须要应用程序的对应扭转，而利用零碎的痛点如下： 新版本的部署须要滚动降级（分阶段下线节点而后有序上线），通过这样的形式能够对于大规模降级的零碎能够实现不暂停降级。客户端应用程序须要依赖用户自行进行更新，或者应用强制更新伎俩强制降级。这样的应用程序调整不可避免的带来关键性问题：前后兼容。 什么是前后兼容？ 向后兼容：较新的代码由旧代码编写的数据。 向前兼容：比拟旧的代码能够读取新编写的数据。 向后兼容不是难事，因为在原有的根底上扩大。向前兼容比拟难，须要对于旧代码疏忽新代码的增加。 尽管当初支流的传输构造是应用JSON，然而在这一章节将会扩大更多的数据编码格局介绍，后面两种无需过多介绍，这一章节次要介绍了前面三种针对数据编码而存在相似中间件的框架： JSONXMLProtocol BufferThriftAvro数据编码格局数据表现形式无非两种： 内存中数据保留对象，构造体、列表、数组、哈希表和树结构等等，传统的数据结构对于CPU高效拜访优化。数据写入文件通过网络发送，必须要编码为某种字节序列，然而因为一些虚构字节比方指针的存在所以和内存的表现形式有可能不一样。术语问题，这里的编码其实就是指的“序列化”，然而序列化在不同的构造中意义不同，所以书中用了编码解释这一概念。语言特定格局通常有不少的编程语言反对把内存的对象编码为字节序列码，比方经典的Java.io.Serializable，Ruby的 Marshal，Python的 picle ，还有一些第三方库比方 Kryo。 然而语言的特定格局带来上面的一些问题： 编码和特定语言绑定，无奈实现不同编程语言互通。复原数据的时候须要解码并且实例化对应实现类，序列化存在序列化攻打隐患，比方通过实例化异样对象的形式找到零碎的破绽攻打伎俩。简略疾速编码在编程语言经常导致前后兼容问题。JAVA的官网序列化低效被人诟病等。JSON、XML以及二进制二进制编码目前零碎较为支流的模式是JSON， 而过来XML也风行过一段时间，然而起初很快被更为轻便的JSON取代，JSON最早是呈现在JS上的一种数据结构，起初被宽泛采纳在不同零碎之间的通信格局，至今仍然流行。 XML和JSON的最大益处是应用字符串进行传输，并且JSON是JS内置的浏览器反对，具备很强的兼容性。 然而XML和JSON也暴露出不少问题： 数字编码问题：JSON中无奈辨别数字和碰巧是数字的字符串，尽管JSON能辨认出数字和字符串，然而无奈辨别数字的精度，也就是浮点数。针对浮点数问题，IEEE 754 双精度浮点数在JS上精度不佳。在推特中已经有精度失落的例子，2的53次方会导致一部分数据失落而产生数据不精确问题，基本问题是应用了64位的数字去示意推文内容在JS中产生溢出！为了解决此问题推特最终应用了拆分小数位和整数位，以及应用字符串代替数字的形式示意一个数字，避开了JS语言的缺点问题。JSON和XML对于文本反对较好，可浏览性很强，BASE64编码之后能够解除数据传输失落的危险，然而与此同时也会带来数据大小收缩问题。XML和JSON都有模式可选反对，通常状况下大部分的编程语言能够通用编解码形式，然而对于不应用这两种编码格局的则须要本人编写。CSV没有模式，他只是介于二进制和文本之间的一种非凡状态，每一次数据改变都须要手动改变文件。上面来探讨二进制编码问题。 二进制编码的劣势在于数据体积小并且传输快，然而二进制真的和JSON文本的差别很大么？ 咱们能够看到上面的编码案例： 原始字符串内容如下，如果是传统的编码格局，上面的JSON字符串去掉空格须要80多个字节 在书中的案例中，通过二进制编码的数据仅仅比JSON编码格局放大了10几个字节，比方上面的编码格局，仅仅比下面的原始JSON缩短了10多个字节，是否意味着在较小文本传输的时候优化编码大小的性价比是很低的？ 通过二进制编码框架解决之后，能够精简到32个字节甚至更小，约等于压缩了50%甚至更高的内容。 二进制编码框架定位为了解决二进制编码的性能远不如文本JSON的问题，在数据编码和模式呈现了演进和深入研究。要更好地了解二进制编码框架，咱们须要理解他们的定位。 模式框架的设计了解根本和TCP/IP协定面对的问题相似，在差别不同的利用零碎之间如何实现对立格局通信，并且在不同利用系统升级之后能以最小的老本实现向前兼容。 为了更加透彻的理解Thirft以及一系列数据编码框架的设计定位，咱们来看看Thrift的设计思维： Thrift软件栈分层从下向上别离为：传输层(Transport Layer)、协定层(Protocol Layer)、解决层(Processor Layer)和服务层(Server Layer)。 传输层(Transport Layer)：传输层负责间接从网络中读取和写入数据，它定义了具体的网络传输协定；比如说TCP/IP传输等。协定层(Protocol Layer)：协定层定义了数据传输格局，负责网络传输数据的序列化和反序列化；比如说JSON、XML、二进制数据等。解决层(Processor Layer)：解决层是由具体的IDL（接口描述语言）生成的，封装了具体的底层网络传输和序列化形式，并委托给用户实现的Handler进行解决。服务层(Server Layer)：整合上述组件，提供具体的网络线程/IO服务模型，造成最终的服务。Thrift 和 Protocol BufferApache Thrift 和 Protocol Buffer 基于雷同原理二进制编码，而Protocol 最开始由谷歌开发， Thrift 最后由 Facbook 开发，前面被 Apach 引进并且成为顶级我的项目。（老接盘侠了） Thrift是Facebook于2007年开发的跨语言的rpc服框架，提供多语言的编译性能，并提供多种服务器工作模式；用户通过Thrift的IDL（接口定义语言）来形容接口函数及数据类型，而后通过Thrift的编译环境生成各种语言类型的接口文件，用户能够依据本人的须要采纳不同的语言开发客户端代码和服务器端代码。两者的共同点是都须要应用模式进行编码，所谓模式就是指如果通过语法来形容数据结构，须要依照指定的标准。 另外通过模式定义之后两者都能够通过代码生成器生成相干的对象代码，反对多种编程语言，利用代码生成器生成的代码能够实现对应的编码和解码操作。 在Thirft 介绍一句话能够看到它最为根本的限度： To generate the source from a thrift file run有时候编码框架可能具备多种编码方式，比方Thrift 分为BinaryProtocol和 CompareProtocol。 ...

请点赞关注，你的反对对我意义重大。 Hi，我是小彭。本文已收录到 GitHub · Android-NoteBook 中。这里有 Android 进阶成长常识体系，有气味相投的敌人，关注公众号 [彭旭锐] 带你建设外围竞争力。 前言在日常开发过程中，Unicode & UTF-8 并不是很受关注的常识，但在浏览源码或文章时，呈现频率很高。如果你没有了解分明 Unicode、UTF-8、UTF-16 和 UTF-32 之前的关系，会带来阅读障碍。在这篇文章里，我将带你了解 Unicode 字符集的原理，心愿能帮上忙。 1. 什么是字符编码1.1 什么是字符？字符（Character） 是对文字和符号的总称，例如汉字、拉丁字母、emoji 都是字符。在计算机中，一个字符由 2 局部组成： 1、用户看到的图画2、字符的编码你常常会在很多词语上看到 “编码” 这个单词，对初学者来说很容易混同。明天我列举出 “编码” 常见的 3 层解释，心愿能帮忙你当前在阅读文章时疾速了解作者的意思。 含意 1 - 作为动词： 示意把一个字符转换为一个二进制机器数的过程，这个机器数才是字符在计算机中实在存储/传输的格局。例如把 A 转换为 65(ASCII) 的动作，就是一个编码动作；含意 2 - 作为名词： 示意通过编码动作后失去的那个机器数，对于 A 来说，65(ASCII) 就是 A 的编码(值)，有时会称为编号；含意 3 - 作为名词： 示意把字符转换为机器数的编码方案，例如 ASCII 编码、GBK 编码、UTF-8 编码。1.2 什么是字符集字符集（Character Set） 是多个字符与字符编码组成的零碎，因为历史的起因，已经倒退出多种字符集，例如： 字符集一多起来，就容易呈现兼容问题： 即同一个字符在不同字符集上对应不同的字符编码。 例如，最早的 emoji 在日本的一些手机厂商发明并流行起来，使得 emoji 在不同厂商的设施间无奈兼容。要想正确解析一个字符编码，就须要先晓得它应用的字符编码集，否则用谬误的字符集解读，就会呈现乱码。设想以下，你发送的一个在女朋友的手机上看到的是另一个 emoji，是一件如许可怕的事件。 ...

作者：Ravi Malhotra 2022年5月3日 用于在更大、更高分辨率设施上播放的高清视频内容的增长，推动了对 H.265 等更高效视频编解码器的需要。尽管带宽效率是较旧的 H.264 编解码器的两倍，但 H.265 须要耗费更高的计算资源来提供这种效率。管制老本（例如，带宽应用）当初是视频开发人员提到的头等挑战[1]，这使得 H.265 具备吸引力。然而，如果较低的带宽老本被较高的计算和电力老本所取代，视频开发人员相当于在原地踏步。他们须要的是一个解决方案，该解决方案能够提供 H.265 效率，而仅仅破费较少的计算和电力代价。本博客认为基于 Arm Neoverse 的 Ampere Altra Max 服务器正是视频开发人员编码 H.265 视频流所需的解决方案。 背景介绍在过来的几年里，因为更好的相机和更大、更高分辨率的设施，高分辨率视频内容的产生和生产都在稳步增长。与 H.264 等传统编解码器相比，H.265/HEVC、VP9 或 AV1 等更先进的编解码器在压缩更高分辨率内容方面的效率晋升超过 50%。最近的市场钻研表明，这种增长转化为这些编解码器的使用量的显著减少，其中 H.265 处于当先的地位。 图 1:Bitmovin 2021 对于生产畛域应用的视频编解码器报告（2020 年与 2021） Netflix 和 Amazon Prime 等流媒体服务的风行也推动了对高分辨率视频内容的需要。吸引和留住客户只会减少这种需要。因而，视频上传和接管（带宽需要）以及视频转码和解决（计算需要）在视频解决平台中占据最大份额也就难能可贵了[2]。 图 2：2020 年按利用划分的视频解决平台市场份额 H.265 的改良压缩带来了更高计算复杂度，这可能比 H.264 高出一个数量级（10 倍）。尽管基于云的编码的应用正在增长，但大多数视频编码依然是一项预处理工作[1]。因而，H.265 编码减少的计算需要（资本收入老本）和功耗（经营老本）对大多数视频开发人员来说是一个挑战。因而，在性能更高、能效更高的服务器上进行编码是很重要的。 技术媒体曾经在 SPECrate®2017 Integer 等通用基准上验证了 Ampere Altra Max 绝对于传统架构的性能和能效劣势[3]。Ampere Altra Max 领有128 个 Arm Neoverse N1 内核 @3.0Ghz，性能优于英特尔至强“Ice-Lake”和 AMD EPYC“Milan”CPU，后者的功耗（TDP）要高得多。在这个博客中，咱们展现了 Ampere Altra Max 的这些性能和能效劣势也扩大到了 H.265 等视频编码利用中。 ...

视频编码的目标是为了压缩原始视频，压缩的次要思路是从空间、工夫、编码、视觉等几个次要角度去除冗余信息。因为 H.264 杰出的数据压缩比率和视频品质，成为以后市场上最为风行的编解码规范。而 H.265 是在 H.264 的根底上，保障雷同视频品质的同时，视频流的码率还能够缩小50%。随着H.265编码格局越来越风行，本文将次要介绍 H.265 的编码原理，以下是 H.265 的编码框架流程图。 01 编码构造H.265在编码构造上分为视频编码层（VCL）和网络提取层（NAL）。 VCL：Video Coding Layer，次要包含视频压缩引擎和图像分块的语法定义，原始视频在 VCL 层，被编码成视频数据。简略版本的编码过程如下：将每一帧的图像分块，将块信息增加到码流中；对单元块进行预测编码，帧内预测生成残差，帧间预测进行静止预计和静止弥补；对残差进行变换，对变换系数进行量化、扫描。对量化后的变换系数、静止信息、预测信息等进行熵编码，造成压缩的视频码流输入。NAL：Network Abstraction Layer，次要定义数据的封装格局，把 VCL 产生的视频数据封装成一个个 NAL 单元的数据包，适配不同的网络环境并传输。02 分块从编码程序和构造上讲，H.265首先将一个视频划分成若干个序列，一个序列划分成若干个图像组（GOP），每一个GOP代表一组间断的视频帧。H.265 在对图像做预测编码和变换编码时，会先对图像进行划分，划分形式是四叉树。在划分四叉树时，会将整个视频帧划分成若干个正方形的编码树块（CTB），CTB 能够持续划分成编码块（CB），CB 还能够划分为预测块（PB）和变换块（TB）。因而，H.265对视频的构造划分如下图所示： 同一地位处的一个亮度 CB 和两个色度 CB ，加上一些相应的语法元素，组成一个编码单元（CU）。CU 是决定进行帧内预测、帧间预测、Skip/Merge模式的单元。 同一地位处的一个亮度 CTB 和两个色度 CTB ，加上一些相应的语法元素，和蕴含的 CU ，组成一个编码树单元（CTU）。CTU 相当于 H.264 中的宏块，区别是 CTU 的尺寸是由编码器制订，最大能够反对到 64x64，最小能够反对到 16x16。而宏块的大小固定为 16x16。 一个 CTU 在进行编码时，依照深度优先的程序进行 CU 编码，像数据结构中的四叉树一样，一个大的方块代表父节点，外面有四个小方块别离代表四个子节点。 03 预测视频的实质是由一系列间断的视频帧组成，在单个视频帧外部和多个视频帧之间都存在大量的冗余。从空间的角度看，单个视频帧外部的像素点之间的像素值相差很小。从工夫的角度看，两个间断的视频帧之间也有很多雷同的像素点。预测编码就是基于图像统计个性进行数据压缩的一种办法，利用了图像在工夫和空间上的相关性，通过曾经重建的像素数据预测以后正在编码的像素。 3.1 帧内预测 帧内预测是指用于预测的像素和以后正在编码的像素都在同一个视频帧内，并且个别都在邻近的区域内。因为邻近的像素之间有很强的相关性，像素值个别都十分靠近，产生渐变的概率十分小，差值都是0或者十分小的数。所以，帧内预测编码后传输的是预测值和实在值之间的差值，即0左近的值，叫做预测误差或残差，这样就用较少的比特传输，达到压缩的成果。 H.265帧内预测编码以块为单位，应用相邻曾经重建的块的重建值对正在编码的块进行预测。预测重量分为亮度和色度两个，对应的预测块别离是亮度预测块和色度预测块。为了适应高清视频的内容特色，进步预测精度，H.265采纳了更加丰盛的预测块尺寸和预测模式。 H.265亮度预测块的尺寸在4*4到32*32之间，所有尺寸的预测块都有35种预测模式，这些预测模式能够分为3类：立体（Planar）模式、直流（DC）模式和角度（Angular）模式。 Planar模式：亮度模式0，实用于像素值变换迟缓的区域，例如像素突变的场景。对预测块中的每个像素都应用不同的预测值。预测值等于：该像素在程度和垂直两个方向线性插值的平均值。DC模式：亮度模式1，实用于图像的大面积平坦区域，该模式对预测块中的所有像素都应用雷同的预测值。如果预测块是正方形，预测值等于右边和上边的参考像素的平均值；如果预测块是长方形，预测值等于长的那一边的平均值；角度模式：亮度模式2~34，总共33个预测方向，其中模式10是程度方向，模式26是垂直方向。角度模式每个像素的预测值都是从对应预测方向前曾经重建的像素集的样值进行程度或垂直方向偏移角度预测。 因为黑白视频中，雷同地位的色度信号和亮度信号的特色相似，因而色度预测块和亮度预测块的预测模式也相似。H.265中色度预测块的预测模式有Planar模式、垂直模式、程度模式、DC模式和导出模式5种： Planar模式：色度模式0，和亮度模式0一样。垂直模式：色度模式1，和亮度模式26一样。程度模式：色度模式2，和亮度模式10一样。DC模式：色度模式3，和亮度模式1一样。导出模式：色度模式4，采纳和对应亮度预测块雷同的预测模式。如果对应的亮度预测块模式是0、1、10、26中的一种，则替换为模式34。3.2 帧间预测 ...

简介：相似于“防御性驾驶”对驾驶平安的重要性，防御性编码目标概括起来就一条：将代码品质问题毁灭于萌芽。要做到“防御性编码”，就要求咱们充分认识到代码品质的严肃性，也就是“一旦你感觉这个中央可能出问题，那根本它就会（在某个时刻）出问题”。当然，理论状况比这个更严厉。因为大家的编码教训和格调差别，导致大家的意识边界是大小不一的，那些埋伏在意识边界之外的“危险”更加荫蔽和不可推敲。在意识层面上，咱们当然要摒弃“想当然”和“差不多”的思维，庄重评估这些问题产生的可能性，认真对待这些危险。但如若话题止步于此，那其实还是不足执行层面的指导意义的，激不起半点“涟漪”的。这个文章目标也更多是关注到“实操层面”的疏导 作者 | 字白起源 | 阿里开发者公众号 一 防御性编码的意义相似于“防御性驾驶”对驾驶平安的重要性，防御性编码目标概括起来就一条：将代码品质问题毁灭于萌芽。要做到“防御性编码”，就要求咱们充分认识到代码品质的严肃性，也就是“一旦你感觉这个中央可能出问题，那根本它就会（在某个时刻）出问题”。当然，理论状况比这个更严厉。因为大家的编码教训和格调差别，导致大家的意识边界是大小不一的，那些埋伏在意识边界之外的“危险”更加荫蔽和不可推敲。 在意识层面上，咱们当然要摒弃“想当然”和“差不多”的思维，庄重评估这些问题产生的可能性，认真对待这些危险。但如若话题止步于此，那其实还是不足执行层面的指导意义的，激不起半点“涟漪”的。 这个文章目标也更多是关注到“实操层面”的疏导。 二 如何防御性编码？以下需关注的具体方面更多来自于我的习惯和察看，并且对立用伪代码作问题示例。 欢送大家把本人的“防御性编码心得”在评论区分享进去。 1 并发抵触问题这个问题在理论我的项目中，被谬误地漠视的比例相当高。它的外在表现形式形形色色，但关键点是：“当你的代码被并发调用时，它会怎么体现？” 咱们心里要有个运行时的世界观，代码运行的Context是这样的：多线程 -> 多过程 -> 多机器 -> 多集群。咱们编码时，要充分考虑代码在上述世界观多点并发的可能性，及相应的潜在结果。 举几个具体的问题例子)： 存在共享变量 或者 数据。（不限于堆内存，也可能是缓存、DB、文件等） 例子1： 有线程 A 和线程 B 两个线程，须要更新「同一条」数据，会产生这样的场景：1、线程 A 更新数据库（X = 1）2、线程 B 更新数据库（X = 2）3、线程 B 更新缓存（X = 2）4、线程 A 更新缓存（X = 1）最终 X 的值在缓存中是 1，在数据库中是 2，产生不统一。例子2： // 某个 Spring singleton Bean 'aService' 存在一个调用起源标记，记录调用起源是HSF还是HTTP。// 先 记录起源标记。aService.setSource(source);// 再联合source执行其余逻辑。例如将下面记录的source 和 其余参数 插入数据库.aService.doSomethings(params);如果这个代码被 HSF和 HTTP 同时调用就会产生问题。 ...

在开始之前，让咱们回顾一下万恶之源： 把大象装进冰箱须要几步？应该有很多计算机系的敌人对这个问题印象粗浅吧，它是大部分大学在传授面向对象这门课程时用来抛砖引玉的第一问。 而咱们通常会失去两个答案： 须要三步，先关上冰箱门，而后把大象放进冰箱，而后关上冰箱门。须要三步，冰箱打开门，大象走进冰箱，冰箱关上门。上述两种答案，实质上是思维的不同，第一种答复是站在第一人称的视角来扫视问题，这种思考形式咱们称其为 过程事务脚本 。 而第二种答复则是别离站在不同 事物 的视角上对待问题，这种思考形式咱们称其为 面向对象思维 。 过程事务脚本，其实就是对问题解决流程的列举，益处是有的，例如不须要额定的思考老本，写起来简略，入门门槛低等等等等。但从复杂度和事务倒退的客观规律来看，它不是最合适的。 注：‘事物倒退的客观规律’ 就是指事物往简单、熵增的方向倒退。 为什么这么说，让咱们来看一个理论的问题。 从问题登程假如咱们要开发一个商城零碎，在设计初期，产品给出了上面需要： 用户提交订单后，后盾计算订单商品总金额，保留订单商品条目快照，锁定库存而后生成订单并回显。于是研发部依据需要写出了第一版程序： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // 计算订单总金额 // 保留订单商品条目快照 // 锁定库存 // 创立订单并返回程序上线后，因为用户激增，单体式利用很快便满足不了宏大的用户量的需要，于是产品部要求研发部进行服务拆分，进一步晋升零碎并发申请量，而后第二版程序就进去了： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // + 调用近程服务获取商品数据 // 计算订单总金额 // 保留订单商品条目快照 // - 锁定库存 // + 调用仓储服务锁定库存 // 创立订单并返回忽然有一天，经营一拍大腿，决定搞一个优惠活动： 用户生产时，依据用户会员等级和单笔生产金额进行返利，返利间接补贴进单笔生产订单总金额中，并且容许用户能够应用优惠券叠加计算优惠金额。繁忙的程序猿们再次扛起键盘筹备战斗，于是最新的程序又进去了： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // 调用近程服务获取商品数据 // + 调用近程服务获取用户会员等级权利信息 // 计算订单总金额 // + 计算会员等级优惠及返利 // + 再次计算订单总金额 // + 计算叠加优惠券后的金额 // 保留订单商品条目快照 // 锁定库存 // 调用仓储服务锁定库存 // 创立订单并返回在这之后，脑洞大开的经营时不时会想到一些离奇的创意，研发部门充斥了高兴的空气... ...

阿里云智能编码插件（Alibaba Cloud AI Coding Assistant）是一款AI编程助手，它提供代码智能补全和代码示例搜寻能力，帮忙你更快更高效地写出高质量代码，让你的开发过程既高效又轻松。 点击立刻体验 阿里云智能编码 你是否还在为从天而降的需要焦头烂额？ 你是否还在为写不完的业务代码熬灯苦做？ 我懂你啊，我看到下面这两行字曾经开始PTSD了……）（表情包是家猫，请哂纳） ———————————跑题了，拉回来——————————— 好消息！好消息！阿里云AI智能编码助手 aka Alibaba Cloud AI Coding Assistant（小名儿Cosy）横空出世！ (IntelliJ插件市场中搜两个英文名字都能够找到哦⬆️)只愿能做你漫漫开发长路上踏着七彩祥云的霸王防脱，你就只管沉迷在IDE里，你想要的其余信息都由它来搞定。 阿里云智能编码插件性能介绍1、代码智能补全 基于世界领先的深度学习模型，为你提供智能、精确的行级代码补全，让编码如行云流水般天然和高效。代码补全齐全运行在本地，你能够在任何状况下无忧应用。 理解更多 2、代码示例搜寻 提供API代码示例搜寻性能，让你在面对不相熟的API时，无需跳出到浏览器中，在IDE内即可参考海量高质量的开源API代码示例，为你打造沉迷式编码体验。 理解更多 阿里云智能编码插件产品个性1、晋升编码效率 阿里云智能编码插件所应用的弱小的深度学习模型由海量优质且通过许可的开源代码训练而成，其中蕴含社区积淀多年的最佳实际和编程范式，能够帮你更快更高效地写出更好的代码。 2、沉迷式开发 阿里云智能编码插件能帮忙你在代码编辑器外部搜寻代码示例文档，免于页面切换之苦，沉迷在编码的心流之中。 3、低资源耗费 仅需轻量的系统资源耗费，即可享受弱小的AI引擎带来的智能编码体验。 4、隐衷爱护 用户的隐衷高于一切。代码智能补全所应用的深度学习模型只在你本地的机器上运行，不会分享或向其余设施上传你的代码或个人信息等数据。即便你的设施处于未联网的状态，也不会影响代码智能补全的失常应用。 理解隐衷政策 你兴许会问，“我写个代码罢了，整这么多花里胡哨的干啥？” “代码补全有什么稀奇的，IDE自带的也能补全啊。” nonono，事件并没有这么简略。让我来王婆卖瓜一下子： 首先，Cosy它名字虽短，补进去的代码却很长。 20MB左右的大小能够说是小小的身材大大的能量了www 其次，它可不只有“更懂你的后半句代码”这一个长处。 作为一名一年香且仍然在茁壮成长的新晋小算法，回顾一下这些年的开发过程，总是要免不了接触新的语言新的工具最后那段陌生艰涩的工夫，只能一边开着IDE一边停下开发去找文档读文档找文档读文档找文档读文档…… （小声bb：我这一年从学生时代的Java/Python/C#变成了Golang/Nodejs/Rust，家人们，谁懂_(:_」∠)_而当初你只须要右键选中你不是那么相熟的API，或点击IDE右侧边栏中的【代码示例搜寻】，海量开源代码示例尽收你眼，从此与“在IDE和浏览器之间重复横跳”的日常说拜拜 阿里云智能编码插件Cosy在这条【做你开发过程中的阿拉丁神灯】的幻想长路上也只能算得上是初长成，现诚邀各路Java开发英雄好汉领先来体验，仅需在IntelliJ中装置插件即可～ 点击导航栏IntelliJ IDEA—> Preferences —> Plugins —> Marketplace —> 搜寻Cosy或者Alibaba Cloud AI Coding Assistant均可找到；点击装置后重启IDE即可开始体验～帮忙文档、离线包装置渠道和问题反馈戳这里：https://github.com/alibaba-cloud-toolkit/cosy/wiki/%E5%BF%AB%E9%80%9F%E5%BC%80%E5%A7%8B当然也能够间接回帖或钉钉分割咱们！非Java开发的各位也不必放心，咱们曾经在反对更多语言和IDE的路上全力奔跑了～还请大家只管在回复中留下你对咱们的期待和需要，2、4、8、16、32、64、128、256、512、1024、2048楼（哎呀幻想还是要有的） 阿里云智能编码插件（Alibaba Cloud AI Coding Assistant）是一款AI编程助手，它提供代码智能补全和代码示例搜寻能力，帮忙你更快更高效地写出高质量代码，让你的开发过程既高效又轻松。 点击：装置IntelliJ IDEA插件

2020年如果问什么技术畛域最火？毫无疑问：音视频。2020年近程办公和在线教育的强势倒退，都离不开音视频的身影，视频会议、在线教学、娱乐直播等都是音视频的典型利用场景。 更加丰盛的应用场景更须要咱们思考如何提供更多的可配置能力项，比方分辨率、帧率、码率等，以实现更好的用户体验。本文将次要从“分辨率”开展具体分享。 如何实现自定义编码分辨率咱们先来看看“分辨率”的定义。分辨率：是度量图像内像素数据量多少的一个参数，是掂量一帧图像或视频品质的要害指标。分辨率越高，图像体积（字节数）越大，画质越好。对于一个YUV i420 格局、分辨率 1080p 的视频流来说，一帧图像的体积为 1920x1080x1.5x8/1024/1024≈23.73Mbit，帧率 30，则 1s 的大小是 30x23.73≈711.9Mbit。可见数据量之大，对码率要求之高，所以在理论传输过程中就须要对视频进行压缩编码。因而，视频采集设施采集出的原始数据分辨率咱们称采集分辨率，理论送进编码器的数据分辨率咱们就称之为编码分辨率。 视频画面是否清晰、比例是否适合，这些都会间接影响用户体验。摄像头采集分辨率的抉择是无限的，有时咱们想要的分辨率并不能间接通过摄像头采集到。那么，依据场景配置适合编码分辨率的能力就至关重要了。如何将采集到的视频转换成咱们想要的编码分辨率去发送？这就是咱们明天的次要分享的内容。 WebRTC 是 Google 开源的，功能强大的实时音视频我的项目，市面上大多开发者都是基于 WebRTC 构建实时音视频通信的解决方案。在 WebRTC 中各个模块都有很好的形象解耦解决, 对咱们进行二次开发十分敌对。在咱们构建实时音视频通信解决方案时，须要去理解和学习 WebRTC 的设计思维及代码模块，并具备二次开发和扩大的能力。本文咱们基于 WebRTC Release 72 版本，聊聊如何实现自定义编码分辨率。 首先，咱们思考上面几个问题： 视频数据从采集到编码发送，其 Pipeline 是怎么的？怎么依据设置的编码分辨率抉择适合的采集分辨率？怎么能失去想要的编码分辨率？本文内容也将从以上三点开展具体分享。 视频数据的 Pipeline首先，咱们来理解一下视频数据的 Pipeline。视频数据由 VideoCapturer 产生，VideoCapturer 采集数据后通过 VideoAdapter 解决，而后经由 VideoSource 的 VideoBroadcaster 分发给注册的 VideoSink ，VideoSink 即编码器 Encoder Sink 和本地预览 Preview Sink。 对视频分辨率来说，流程是：将想要的分辨率设置给 VideoCapturer，VideoCapturer 抉择适合的分辨率去采集，原始的采集分辨率数据再通过 VideoAdapter 计算，不合乎预期后再进行缩放裁剪失去编码分辨率的视频数据，将数据再送进编码器编码后发送。 这里就有两个关键性问题： VideoCapturer 如何抉择适合的采集分辨率？VideoAdapter 如何将采集分辨率转换成编码分辨率？如何抉择适合的采集分辨率采集分辨率的抉择WebRTC 中对视频采集形象出一个 Base 类：videocapturer.cc，咱们把形象称为 VideoCapturer，在 VideoCapturer 中设置参数属性，比方视频分辨率、帧率、反对的像素格局等，VideoCapturer 将依据设置的参数，计算出最佳的采集格局，再用这个采集格局去调用各个平台的 VDM（Video Device Module，视频硬件设施模块）。具体的设置如下： ...