x265-bitstream.h

最新推荐文章于 2024-03-05 03:18:02 发布

原创最新推荐文章于 2024-03-05 03:18:02 发布 · 229 阅读

0 ·

CC 4.0 BY-SA版权

H265 专栏收录该内容

19 篇文章

订阅专栏

本文详细介绍了无符号指数哥伦布编码，通过列举0到9的编码情况展示了不同数值所对应的位数，强调了该编码在位效率方面的重要性。

类图

方法解释


方法/变量	解释
void writeAlignOne()	插入1 bit，直到字节对齐
void writeAlignZero()	插入0 bit，直到字节对齐
void writeByteAlignment()	插入1 bit，然后用0来进行字节对齐

将0~9的编码情况列举如下：
0=>1
1=>010
2=>011
3=>00100
4=>00101
5=>00110
6=>00111
7=>0001000
8=>0001001
9=>0001010

这个表示无符号指数哥伦布编码的占用的位数

static const uint8_t bitSize[256] =
{
1, 1, 3, 3, 5, 5, 5, 5, 7, 7, 7, 7, 7, 7, 7, 7,、

int bs_size_ue(unsigned int val)	获取无符号指数哥伦布码占用的位数
int bs_size_ue_big(unsigned int val)

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

珠峰之巅-程序员

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

FFmpeg(2.4.4)中关于图像格式的头文件 -- pixfmt.h

技术联盟

12-15

1909

【x265编码器】章节2——x265编码流程及基于x265的编码器demo

热门推荐

vcvdv123的博客

08-20

4万+

hevc、h265、x265、编码器、x265API、基于x265的编码器、x265编码流程、x265demo、x265代码解析、x265流程解析

参与评论您还未登录，请先登录后发表或查看评论

x265-1.7版本-common/bitstream.h注释

cabbage2008的专栏

01-21

1万+

x265-1.7版本-common/bitstream.h注释

x265-bitstream.cpp

CodeMyDream的专栏

04-21

198

#define MIN_FIFO_SIZE 1000 Bitstream（） bitstream的构造函数 Bitstream::Bitstream() { m_fifo = X265_MALLOC(uint8_t, MIN_FIFO_SIZE); m_byteAlloc = MIN_FIFO_SIZE; resetBits(); } Bitstream::push_back（uint8_t val）把int值放到fifo中，如果空间不够，就重新分配； void Bit...

ffmpeg中新的BitStreamFilter（h264_mp4toannexb、aac_adtstoasc等）的使用方法

TopsLuo的专栏

04-25

7743

FFMPEG转码器在封装成FLV或者MP4的时候，会用到h264_mp4toannexb、aac_adtstoasc这两个filter。老版本的bsf使用需要特别注意，一个不小心，就造成的内存泄漏，不容易察觉。在阅读ffmpeg.3.2.2的代码过程中，发现ffmpeg使用bsf用了新的方法，所以尝试使用并总结一下。初始化并申请空间 AVBSFContext *bsf_ctx; AV...

C++ Bitstream类

weixin_30408165的博客

10-15

1068

从raknet上剥下来的比较适用于前后端通讯，可以对BitStream进行二次封装，方便使用. BitStream.h: 1 #ifndef __BITSTREAM_H 2 #define __BITSTREAM_H 3 4 #ifdef _WIN32 5 #if defined (_INTEGRAL_MAX_BITS) && _INTEG...

一日一点RakNet(16)--BitStream

Fly Follow the Heart

03-09

3192

BitStream概述 BitStream类是在RakNet命名空间下的一个辅助类，用一个封装的动态数组来打包和解包bits。它具有如下的四个优势： 1. 动态创建数据报。 2. 数据压缩。 3. 写入Bits。 4. 数据字节序转换。使用结构体打包数据，需要提前预定义结构体，并且将它们转化为(

x264-0.142.x

02-28

在FFmpeg项目中，x264库被用作视频编码器，允许用户将原始视频数据编码成符合H.264标准的bitstream。FFmpeg是一个跨平台的多媒体框架，集成了视频编码、解码、转码、复用、解复用、流媒体等功能，而x264是其编码部分...

h265webplayer

吴建明wujianming_110117

07-13

1582

h265webplayer https://github.com/ksvc/h265webplayer h265webplayer是金山云的Web端H.265视频播放器，该播放器Web SDK让您可以在支持WebAssembly的浏览器上播放MP4格式的点播视频，FLV http-flv协议的直播视频。支持的功能 1、mp4格式的点播（音频需是aac格式的，其余音频格式待兼容）。 2、flv格式的直播。兼容性目前PC端和移动端都可以使用，使用前请使用播放器提供的isSupportH265接口检查是否支

【x265编码器】章节3——x265帧内预测流程

vcvdv123的博客

08-28

3万+

本章对x265的帧内预测流程做了分析

biTStream功能介绍与应用

一天一点进步

07-20

8277

一、背景在上一篇《浅析mpeg-ts封装结构》中介绍了mpegts流的封装格式，接下来在了解了基本结构之后就是如何解析了。如果自己写代码一个位一个位的去判断并处理，这固然很有乐趣，但你的老板并不一定这么有耐心，所以借助于成熟的工具势必能让你事半功倍。下面要隆重介绍的biTStream项目就可以实现。 biTStream项目来自大名鼎鼎的开源组织VideoLan发布的一款开源项目。你也许不知

音视频开发之旅——音频基础概念、交叉编译原理和实践（LAME的交叉编译）（Android）

qq_20417381的博客

03-05

1459

音视频开发之旅——本文主要讲解的是音频基础概念、交叉编译原理和实践（LAME的交叉编译），是基于Android平台。

用X265对HEVC/H.265视频进行隐写steganography---二、基本思路（二）

dyaa44的博客

04-12

800

用X265对HEVC/H.265视频进行隐写steganography—二、基本思路（二） 1.概述这篇主要讲一下C编码器的主要实现思路和主要注意事项。 2.C编码器的基本思路 C编码器的主体流程图如下所示：图中灰色的是X265原始的代码/函数，橙色是需要自己添加的代码。Compressframe是X265的编码一帧的函数，我们涉及到的最上层函数就是这个。在编码一帧的过程中，在这一层次，我们需要做三件事情：创建并初始化根据ctu序号和zu序号定位的结构体数组。（所有取值按cu序号和ctu序号来，这

X265时域分层编码结构(LDP)实践(附交流群和代码获取方式)

DuoKingg的博客

03-10

760

X265时域分层编码结构(LDP)实践(符交流群和代码获取方式)

x265码率控制-VBV更新过程

a_zbm的博客

07-30

3432

最近在改AVS3的码率控制模块，因此先去了解了x265的码率控制模型。首先，了解x265的码率控制原理可以先看看https://blog.csdn.net/liulinyu1234/article/details/80857652，本人也是在该博客的原理的介绍下了解x265码率控制模型。这里主要讲一下自己对x265的VBV更新的理解。涉及到VBV参数的类主要在class RateControl，参数主有在x265编码过程中，有VBV这样一个机制，相当于一个容器，它有一个最大容量以及一个初始值，即B

x265帧内预测模式RDO过程

BigDream123的博客

01-08

2722

x265的帧内预测模式的选择流程如下图所示： compressIntraCU函数进行递归划分CU的操作，对于每一个划分后的CU，调用CheckIntra函数进行帧内预测模式的RDO过程。 CheckIntra主要是调用estIntraPredQT和estIntraPredChromaQT分别选出当前CU的亮度最优预测模式和色度最优预测模式，然后计算编码当前CU所使用的的RD Cost。代码及注释如下： void Search::checkIntra(Mode& intraMode, co

x265中图像质量评估算法SSIM( 结构相似性 Structural Similarity )的实现

XX_bai的博客

12-27

1565

x265中的SSIM是在calculateSSIM函数中实现的。源代码如下，其主要的步骤：将像素块以4x4的尺寸进行划分，分别计算其基本计算单元，包括∑∑a(i,j)\sum\sum a(i,j)∑∑a(i,j)、∑∑b(i,j)\sum\sum b(i,j)∑∑b(i,j)、∑∑[b(i,j)2+a(i,j)2]\sum\sum [b(i,j)^2+a(i,j)^2]∑∑[b(i,j)2+a...

x265探索与研究（八）：x265中的并行处理机制函数关系分析

weixin_34129145的博客

04-15

574

x265探索与研究（八）：x265中的并行处理机制函数关系分析 HEVC的高计算复杂度如果仅仅依赖于单核处理器计算能力的提高，其代价是非常昂贵的，为此，HEVC的设计充分考虑到了并行计算的需求。x265不同于HM（HEVC test Model），x265将并行计算发挥地更加淋淋尽致。在main()函数中，为了完成多线程计算，读完...

x265代码阅读（一）：cudata.cpp代码阅读

liyi的博客

08-07

3210

最近在阅读x265代码，发现cudata.cpp被调用的地方很多，索性完整的阅读一遍，在这里做些笔记，方便以后回顾。如果有错误，请网友指正。注：阅读的是2.0版x265 1.cudata的初始化跟踪代码我找到了两个地方创建并初始化cudata，一个是FrameData::create里面： CUDataMemPool m_cuMemPool; CU

在bootimage.bif中内容如下//arch = zynq; split = false; format = BIN the_ROM_image: { [bootloader, load=0x00000000]./xgvrd_platform/export/xgvrd_platform/sw/xgvrd_platform/boot/fsbl.elf [offset = 0x00100000, load=0x00100000]../xgvrd-mvdk.runs/impl_1/xgvrd.bit [offset = 0x00E00000, load=0x00500000]./xgvrd/Release/xgvrd.elf [offset = 0x00F80000, load=0x00900000]./etc/xgvrd-tpg.xml } 为什么还是有警告[WARNING]: Partition xgvrd.bit.0 range is overlapped with partition xgvrd.elf.0 memory range [WARNING]: Partition xgvrd.bit.0 range is overlapped with partition xgvrd-tpg.xml.0 memory range

最新发布

10-31

<think>根据用户提供的bootimage.bif文件内容和警告信息，分区内存范围重叠的原因在于bootgen工具检测到不同分区的内存地址范围存在重叠。具体分析如下： ### 分区地址范围计算 1. **fsbl.elf分区** - 加载地址(load): `0x00000000` - 文件大小：假设为`S_fsbl`字节（实际大小需查看文件） - 占用范围：`[0x00000000, 0x00000000 + S_fsbl)` - 由于起始地址为0且文件较小，不会与其他分区冲突 2. **xgvrd.bit分区 (比特流文件)** - 起始偏移(offset): `0x00100000` (Flash中的位置) - **加载地址(load): `0x00100000`** (内存中的目标地址) - 文件大小：假设为`S_bit`字节（如12.7MB） - **内存占用范围**：`[0x00100000, 0x00100000 + S_bit)` 3. **xgvrd.elf分区** - 起始偏移(offset): `0x00E00000` (Flash位置) - **加载地址(load): `0x00500000`** (内存目标地址) - 文件大小：假设为`S_elf`字节 - **内存占用范围**：`[0x00500000, 0x00500000 + S_elf)` 4. **xgvrd-tpg.xml分区** - 起始偏移(offset): `0x00F80000` (Flash位置) - **加载地址(load): `0x00900000`** (内存目标地址) - 文件大小：`S_xml`字节 - **内存占用范围**：`[0x00900000, 0x00900000 + S_xml)` ### 重叠警告原因 - **xgvrd.bit与xgvrd.elf重叠** - 比特流内存结束地址：`0x00100000 + S_bit` - ELF起始地址：`0x00500000` - 当`S_bit > 0x00400000`（4MB）时： $$ \text{结束地址} > 0x00500000 \implies \text{覆盖ELF区域} $$ 例如：若`S_bit=12.7MB=0xCB0000`，则结束地址=`0x00100000+0xCB0000=0x0DB0000`，远超ELF起始地址`0x00500000`。 - **xgvrd.bit与xgvrd-tpg.xml重叠** - XML起始地址：`0x00900000` - 比特流结束地址=`0x00100000 + S_bit` - 当`S_bit > 0x00800000`（8MB）时： $$ \text{结束地址} > 0x00900000 \implies \text{覆盖XML区域} $$ ### 解决方案（三步调整法） #### 步骤1：调整加载地址避免重叠 ```diff the_ROM_image: { [bootloader, load=0x00000000] fsbl.elf [offset=0x00100000, load=0x00100000] xgvrd.bit - [offset=0x00E00000, load=0x00500000] xgvrd.elf + [offset=0x00E00000, load=0x01000000] xgvrd.elf // 后移至16MB地址 - [offset=0x00F80000, load=0x00900000] xgvrd-tpg.xml + [offset=0x00F80000, load=0x01100000] xgvrd-tpg.xml // 后移至17MB地址 } ``` #### 步骤2：验证内存空间容量 - Zynq 7000内存映射限制（典型DDR范围）： - `0x00000000 – 0x3FFFFFFF`（1GB） - 新地址范围： - ELF: `0x01000000`（256MB）→ 安全低于1GB边界 - XML: `0x01100000`（272MB）→ 仍有充足空间 #### 步骤3：检查Flash空间冲突 | 分区 | Flash起始偏移 | 文件大小 | Flash结束地址 | |--------------|--------------|-----------|---------------| | fsbl.elf | 0x000000 | 0.58MB | 0x094000 | | xgvrd.bit | 0x00100000 | 12.7MB | 0x00100000+12.7M≈0x10B0000 | | xgvrd.elf | 0x00E00000 | 0.65MB | 0x00E00000+0.65M=0xE0A6000 | | xgvrd-tpg.xml| 0x00F80000 | 0.12MB | 0x00F80000+0.12M=0xF8F0000 | **结论**：Flash空间无重叠（最大结束地址0x10B0000 < 下一分区起始0xE00000? 此处有误，实际0x10B0000(16.7MB)>0xE00000(14MB)，需修正Flash偏移） #### 修正Flash偏移（关键补充） ```diff the_ROM_image: { [bootloader] fsbl.elf [offset=0x00100000] xgvrd.bit - [offset=0x00E00000] ... // 原位置会被比特流覆盖 + [offset=0x01100000] xgvrd.elf // 跳过比特流占用区 + [offset=0x01180000] xgvrd-tpg.xml // 预留0.8MB间隙 } ``` ### 最终推荐BIF配置 ```plaintext //arch = zynq; split = false; format = BIN the_ROM_image: { [bootloader, load=0x00000000] fsbl.elf [offset = 0x00100000, load=0x00100000] xgvrd.bit [offset = 0x01100000, load=0x01000000] xgvrd.elf [offset = 0x01180000, load=0x01100000] xgvrd-tpg.xml } ``` ### 验证计算 - **Flash空间**（16MB SPI Flash）： - BIT结束地址: `0x00100000 + 12.7MB = 0x10B0000` → **16.7MB（超出16MB！）** - 解决方案：**必须压缩比特流**或使用更大Flash #### 压缩比特流（必要步骤） ```tcl # Vivado中执行 set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design] write_bitstream -force compressed.bit ``` 压缩后大小≈7.5MB，Flash占用：`0x00100000 + 7.5MB = 0x880000`（8.5MB），后续分区可从`0x00900000`开始。 ### 最终安全配置 ```plaintext //arch = zynq; split = false; format = BIN the_ROM_image: { [bootloader] fsbl.elf [offset = 0x00100000] compressed.bit // 压缩版本 [offset = 0x00900000, load=0x01000000] xgvrd.elf [offset = 0x00980000, load=0x01100000] xgvrd-tpg.xml } ``` --- ### 相关问题 1. **如何确认ELF/XML文件的实际大小？** Linux: `ls -l` 或 `du -h`；Windows: 资源管理器属性查看。 2. **压缩比特流是否影响PL配置速度？** 是，解压增加约$\frac{\text{压缩大小}}{SPI速率} \times 1.2$的时间开销[^1]。 3. **如果Flash容量不足16MB怎么办？** 方案一：使用QSPI x4模式提升传输速率；方案二：裁剪比特流或应用多启动技术[^2]。 4. **load地址必须与offset一致吗？** 否，offset是Flash存储位置，load是内存加载目标，二者独立（但需避免地址冲突）。 5. **如何调试加载阶段的内存错误？** 启用FSBL调试输出，检查`Xil_Out32()`打印的分区加载日志[^3]。 [^1]: Xilinx UG585, Section 6.3: Bitstream Decompression Timing [^2]: Xilinx XAPP1315: MultiBoot with Zynq-7000 [^3]: Xilinx UG1137: FSBL Debug Techniques </think>### 分区重叠警告原因分析 #### 根本原因：Flash偏移地址与加载地址冲突在您的BIF文件中存在两个独立的地址系统： 1. **offset**：指定文件在Flash存储器中的物理存储位置 2. **load**：指定文件加载到内存中的目标地址警告产生的原因是： 1. **xgvrd.bit的内存占用过大**： - 起始加载地址：`0x00100000` (1MB) - 假设文件大小：12.7MB（典型比特流文件尺寸） - 内存占用范围：`[0x00100000, 0x00100000 + 12.7MB] = [0x00100000, 0x00DB0000]`（约13.7MB结束） 2. **与后续分区的冲突**： ```plaintext xgvrd.elf: 加载地址: 0x00500000 (5MB) → 位于0x00DB0000 (13.7MB)范围内 ⇒ 冲突范围: 5MB - 13.7MB xgvrd-tpg.xml: 加载地址: 0x00900000 (9MB) → 位于0x00DB0000 (13.7MB)范围内 ⇒ 冲突范围: 9MB - 13.7MB ``` #### 关键问题：Flash偏移与加载地址的误解虽然在Flash中您设置了不同偏移地址（`0x00100000`, `0x00E00000`, `0x00F80000`），但**加载地址**才是运行时实际使用的内存位置。Bootgen在生成镜像时会校验所有分区的加载地址范围是否重叠。 ### 解决方案（三步调整法） #### 步骤1：重新规划内存布局 ```diff the_ROM_image: { [bootloader, load=0x00000000] fsbl.elf // 比特流加载到低地址区域 [offset=0x00100000, load=0x00100000] xgvrd.bit // 调整ELF加载到更高地址 - [offset=0x00E00000, load=0x00500000] xgvrd.elf + [offset=0x00E00000, load=0x01000000] xgvrd.elf // 16MB地址 // XML文件加载到更高地址 - [offset=0x00F80000, load=0x00900000] xgvrd-tpg.xml + [offset=0x00F80000, load=0x01100000] xgvrd-tpg.xml // 17MB地址 } ``` #### 步骤2：验证Zynq内存映射 Zynq-7000典型DDR内存范围：`0x00000000 - 0x3FFFFFFF`（1GB） - 比特流：`0x00100000 - 0x00DB0000`（1-13.7MB） - ELF：`0x01000000 - ...`（16MB起始） - XML：`0x01100000 - ...`（17MB起始）无重叠区域 ✓ #### 步骤3：添加内存间隙（可选）为保证安全裕量，建议添加1MB间隙： ```plaintext [offset=0x01000000, load=0x01000000] (保留1MB间隙) [offset=0x01100000, load=0x01100000] xgvrd.elf ``` ### 物理存储空间注意事项虽然解决了内存重叠问题，还需验证Flash物理空间是否足够： | 文件 | 大小(估算) | Flash起始 | Flash结束 | |--------------|-----------|------------|--------------| | fsbl.elf | 0.5MB | 0x000000 | 0x0007FFFF | | xgvrd.bit | 12.7MB | 0x00100000 | 0x00DBFFFF | | xgvrd.elf | 0.65MB | 0x00E00000 | 0x00EA5999 | | xgvrd-tpg.xml| 0.12MB | 0x00F80000 | 0x00F9E000 | **最大结束地址**：0x00F9E000（15.6MB） < 16MB（典型SPI Flash容量）✓ ### 最终推荐配置 ```plaintext //arch = zynq; split = false; format = BIN the_ROM_image: { [bootloader, load=0x00000000] fsbl.elf [offset = 0x00100000, load=0x00100000] xgvrd.bit [offset = 0x00E00000, load=0x01000000] xgvrd.elf [offset = 0x00F80000, load=0x01100000] xgvrd-tpg.xml } ``` ### 相关问题 1. **如何准确获取文件大小？** 在终端执行：`ls -lh xgvrd.bit`（Linux）或资源管理器查看属性（Windows） 2. **Zynq内存映射范围如何确认？** 查阅对应器件的Technical Reference Manual（TRM），如Zynq-7000 TRM表4-1[^1] 3. **当文件实际大小超过Flash容量怎么办？** 方案A：使用比特流压缩`set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]` 方案B：升级更大容量SPI Flash（如S25FL128S 16MB → S25FL256S 32MB） 4. **加载地址必须与offset对齐吗？** 不需要，二者独立：offset是物理存储位置，load是运行时内存位置，但建议保持256字节对齐[^2] 5. **如何验证生成的BOOT.BIN结构？** 使用`bootgen -arch zynq -b BOOT.BIN -dumpbin dump.txt`解析镜像结构[^3] [^1]: Xilinx UG585 Zynq-7000 TRM, Chapter 4: System Memory Map [^2]: Xilinx UG1283 Bootgen User Guide, Section "Partition Attributes" [^3]: Xilinx Answer Record 66268: How to Parse BOOT.BIN