1.1.2、检测开发板
(4)SecureCRT监视打开，开发板开机，自动挂载到/home/aston/rootfs中
(5)自动加入/mnt中，执行./sample_venc即可
(6)在vlc中输入地址，即可浏览实时画面
菜单栏：媒体->打开网络串流->网络，输入：rtsp://192.168.1.10:554/stream_chn0.h264
勾选：显示更多选项。在正在缓冲中设置为300（原来是1000）
uboot的环境变量参数
1.12.4、各种常见flash的简单讲解
(1)买到的flash芯片，其实是内部的flash存储颗粒+外部封装的控制器来构成的。
(2)像EMMC、SD、MMC、SPIFLASH、NANDFLASH等差异都在于控制器。
(3)SPIFLASh的优势就是接口简单，主芯片只需要支持SPI接口就可以外接。很多MCU或者CPU在需要外扩一个8M/16M/32M/64M这么大级别的外部存储器时，选择SPIFLASH是很好的。
(4)NANDFLASH其实控制器是最老的，像EMMC、SD等都比NANDFlash要更新一些，更好一些。
1.3.视频设备开发的技术流
视频从产生到被消费的整个流程
(1)基本认知：视频是由单帧图像以每秒x帧的速率连续组成的，单帧图像类似位图。
(2)原始视频产生：镜头和sensor
(3)图像处理：ISP（image signal processing）
(4)视频编码压缩：h.264/h.265压缩算法，运算，内置DSP进行压缩运算的。
(5)视频流传输：网络传输、http/rtsp等
(6)视频存储：打包成MP4等格式存储，等待调阅
(7)视频回放：解码+播放
HI3518E方案系统整体架构介绍
硬件上
(1)HI3518E单芯片提供：CPU+DSP+内置64MB DDR + ETHERNET MAC
(2)外置SPIFlash用来存放程序（uboot、kernel、rootfs、app）
(3)SDcard扩展提供用户数据区
(4)板载ethernet PHY和USB HOST扩展WIFI提供联网能力
(5)sensor接口（并行数据通道+I2C控制通道）提供主板和sensor链接
(6)串口作为调试口和linux系统控制台
软件上
(1)SPIFlash分区烧录uboot.bin、zImage、rootfs，并设置合理的环境变量使系统启动。
(2)sensor、ethernet等硬件均需要驱动支持
(3)app实现视频采集、编码压缩、网络传输等核心工作
(4)各种专业工作（譬如利用内置DSP实现h.264编码压缩）都由海思开发好并以ko的形式提供，有API文档参考，app编写者在sample的帮助下逐步实现自定义的功能。
SDK中源码包部分的配置编译分解 海思开发环境搭建，编译整个osdrv
海思SDK包编译配置过程
①编译
进入osdrv目录。
先执行distclean命令，确保SDK命令是干净的
make OSDRV_CROSS=arm-hisiv300-linux CHIP=hi3518ev200 distclean
执行make all，编译整个osdrv目录
make OSDRV_CROSS=arm-hisiv300-linux CHIP=hi3518ev200 all
出现错误：
①/bin/sh: 1: pushd: not found
因为pushd命令需要在bash的环境中执行，所以需要修改系统默认shell为bash
步骤1.which sh，定位至/bin/sh
步骤2.ls -l /bin/sh，结果发现sh指向dash
步骤3.sudo rm /bin/sh 删除原来的
步骤4.sudo ln -s /bin/bash /bin/sh 创建所需链接文件
步骤5.ls -l /bin/sh，结果表明sh指向bash
②make[2]: arm-hisiv300-linux-gcc: Command not found
交叉编译工具链未安装。
发布包提供两种编译工具链
①arm-hisiv300-linux 基于 ulibc 的工具链（精简）－－－我们选择的
②arm-hisiv400-linux 基于 glibc 的工具链（完整）
解决：找到arm-hisiv300-linux工具包----解压----安装执行make----进入工具链的挂载目录发现很多arm-hisiv300-linux-uclibcgnueabi-xxx编译工具链----将该目录导入到环境变量中去（一劳永逸：vi ~/.bashrc，在文件末尾追加export PATH=/opt/hisi-linux/x86-arm/arm-hisiv300-linux/target/bin:$PATH并source ~/.bashrc）
新问题：一、file file arm-hisiv300-linux-uclibcgnueabi-gcc →→ELF 32-bit LSB executable说明工具链是32位，而ubuntu是64位的→需要安装32位兼容包
①联网
②sudo aptitude install lib32z1
③sudo aptitude install lib32stdc++6-4.8-dbg
二、工具包中的文件名和makefile中使用的名字不一样
①手动一个一个创建符号链接文件
②修改makefile-----工作量大且容易出问题×××××
三、交叉工具链的安装位置不稳妥，如果进行了make distclean会被清理掉，最好放到外面，不会被轻易清理掉而事实上工具包arm-hisiv300-linux中
脚本文件cross.install.v300专门用于安装交叉编译工具链→安装至一个原本就包含在环境变量区域的位置（1不会被轻易清理掉，2期间会自动创建符号链接文件）
【32位兼容包还是要安装的，还是要导入到环境变量中去的】验证交叉工具链是否安装：
arm-hisiv300-linux-gcc -v
出现了gcc version 4.8.3 20131202 (prerelease) (Hisilicon_v300)说明安装成功
③"mkimage" command not found - U-Boot images will not be built
解决方法1：mkimage起始生成并放在其他位置→搬过来即可
步骤1，cd osdrv/opensource/uboot/u-boot-2010.06
步骤2，ls 【可以看到里面uboot.bin已经生成了】
步骤3，cd tools 【里面有mkimage.c和mkimage】
步骤4，file mkimage 【写x86-64位的架构，ubuntu16.0.04也是x86-64架构，因此可以在当前虚拟机上运行】
步骤5，sudo cp mkimage /usr/local/bin(移动到PATH指定路径即可)
步骤6，cd …/…/
步骤7，ls 【发现里面要u-boot-2010.06文件夹和u-boot-2010.06.tgz压缩包】
步骤8，mki[连续按TabTab键] 【发现补全mkimage，说明已经成功解决了】
解决方法2： 安装依赖包
步骤1， ping www.baidu.com 确保虚拟机能上网
步骤2，sudo apt-get install u-boot-tools
④compr_zlib.c:39:18: fatal error: zlib.h: No such file or directory
解决：sudo aptitude install zlib1g-dev
整个osdrv是提供了zlib的，只是因为已经编译了zlib没有部署它。所以要做的就是部署zlib，把osdrv/tools/pc/zlib/tmp/lib下的全部库复制到osdrv/tools/pc/jffs2_tool/tmp/lib/，和把osdrv/tools/pc/zlib/tmp/zlib-1.2.7下的zlib.h, zconf.h复制到osdrv/tools/pc/jffs2_tool/tmp/include/；在次编译就可以完成jffs2的根文件系统。
⑤serve_image.c:32:18: error: storage size of ‘hints’ isn’t known
在于ubuntu操作系统版本太高,而SDK使用的mtd-utils版本太低导致
解决：修改操作系统头文件/usr/include/netdb.h,将此宏__USE_XOPEN2K注释,如下图(注意#ifdef与#endif是一一对应的)
步骤1，sudo vi /usr/include/netdb.h
步骤2，:set nu 【显示行号】
步骤3，/__USE_XOPEN2K 【搜索】
步骤4，将第79行的#if defined __USE_XOPEN2K || defined __USE_XOPEN_EXTENDED和相应的第82行的#endif用//注释掉
步骤5，/__USE_XOPEN2K 【搜索】
步骤6，第565行的#ifdef __USE_XOPEN2K和第681行的的#endif用//注释掉 【用:681命令跳转到681行】
https://blog.csdn.net/wytzsjzly/article/details/82951747
http://blog.csdn.net/mtbiao/article/details/77052659
https://blog.csdn.net/qq_39436605/article/details/97373183
原因：在于ubuntu操作系统版本太高，而SDK使用的mtd-utils版本太低导致(device/hisilicon/bigfish/sdk/tools/linux/utils/mtd-utils/mtd-utils-1.5.0)，正常情况下，ubuntu12.04.04下支持mtd-utils-1.5.0，但是ubuntu16.04版本兼容不是很好，但是16.04支持mtd-utils-2.0.0版本
3种方法：
方法1、下载 mtd-utils-2.0.0 版本对 SDK 中的 mtd-utils 进行替换
1、 wget ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-2.0.0.tar.bz2
将下载好的 mtd-utils-2.0.0.tar.bz2 解包，进入文件夹，运行
./configure --prefix=
2、并修改makefile
修改 osdrv/tools/pc/jffs2_tool/Makefile
CC := gcc
BUILD_DIR := $(PREFIX)/tmp
ZLIB := $(shell pwd)/../zlib
ZLIB_INSTALL := $(PREFIX)/../zlib
ZLIB_DIR := $(ZLIB_INSTALL)/tmp
STRIP := strip
MTD_UTILS := mtd-utils-2.0.0 #需要修改的地方
# this lib should be install to host
LZO := lzo-2.09
TARGETS := mkfs.jffs2
方法2、把宏注释掉
方法3.当然是修改操作系统的内核版本咯，可以通过如下命令更换操作系统内核版本：
至此，我们就可以编译得到u-boot和kernel，jffs2的rootfs。
编译完后，uboot、kernel、jffs2的镜像在pub目录下。
②烧录和分区表
第一使用烧录工具对spi flash进行烧录。
第二使用海思官方提供的烧录工具进行烧录。
运行Hi_tool来烧录uboot
flash分区
(1)因为嵌入式系统为了简化，没有使用分区表来自动管理flash，所以都是事先定死的。所以在部署一个嵌入式系统前都要人为的定下一个分区
(2)原则：
①每个分区要足够放镜像；
②尽量留一点扩展余地。
③在满足1和2情况下你随便搞。
分区表：
BootLoader 1M 0x0-0x00100000
kernel 3M 0x00100000-0x00400000
rootfs 12M 0x00400000-0x01000000
裸机烧录uboot
裸机烧录一个设备有2种方案：
1是用外部烧录器来烧录板载flash（外部烧录器烧录SPIFLASH时和HI3518E没有关系，有时候经常SPIFLASH先单独通过烧录器和支架来烧录好镜像，然后再把烧录过镜像的SPIFLASH焊接到板子上。现在很多烧录器也可以在板子上直接烧了）；
2是通过主芯片提供的isp下载的机制来间接烧录板载flash。
①用烧录工具对spi flash进行烧录。
②用海思官方提供的烧录工具进行烧录。
1.14.1、烧录kernel
(1)SDRAM地址范围：80000000-83FFFFFF
(2)tftp得能通能下载，才能烧录。ip设置是：本地192.168.1.10，serverp是141
1.14.2、烧录rootfs
1.14.3、uboot的各环境变量介绍和设置
(1)网络地址：ipaddr 192.168.1.10， serverip 192.168.1.141
tftp更新并重新烧写uboot的命令序列：
前提：DDR地址为0x80000000-0x83FFFFFF
1.tftp更新并重新烧录uboot的命令序列：
mw.b 0x82000000 ff 0x100000//擦除ddr中以0x82000000起，1M大小
tftp 0x82000000 u-boot-hi3518ev200.bin //tftp下载uboot /sudo chmod -R 777 tftpboot/
sf probe 0 //选择spi flash （数字是表示第几块flash）
sf erase 0x0 0x100000 //擦除spi flash中以0x0起，1M大小
sf write 0x82000000 0x0 0x100000 // 从ddr中0x82000000烧录到flash
2.tftp更新并重新烧写kernel的命令序列：
mw.b 0x82000000 ff 0x300000
tftp 0x82000000 uImage_hi3518ev200
sf probe 0
sf erase 0x100000 0x300000 //0x100000起始位置，0x300000大小
sf write 0x82000000 0x100000 0x300000
tftp更新并重新烧写rootfs的命令序列：
mw.b 0x82000000 ff 0xc00000//把ddr中12M空间写为ff
tftp 0x82000000 rootfs_hi3518ev200_64k.jffs2
sf probe 0
sf erase 0x400000 0xc00000//这句擦除flash的命令，实质是向flash中写ff
sf write 0x82000000 0x400000 0xc00000
【所以要保证flash和ddr中的擦除大小要一致，不然会在flash中校验出现错误。】
设置启动参数
附2：正确的bootcmd和bootargs对应的设置命令：
set bootcmd ‘sf probe 0;sf read 0x82000000 0x100000 0x300000;bootm 0x82000000’
set bootargs mem=32M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:1024K(boot),3072K(kernel),12288K(rootfs)
注意：
root=/dev/mtdblock2代表我们rootfs在第三个分区
mem=32M，我们的内存是64M，而分配给kernel的只有32M，剩下的是给海思mpp（专门用于处理视频相关的）使用。
部署开发环境（最好在etc/profil中写代码）
kernel设置网络
在etc/profile中写入：
ifconfig lo 127.0.0.1
ifconfigeth0 192.168.1.10
保存。
挂载nfs
①在cmdline下输入下列命令挂载nfs服务器：（仅限本次，重启后失效）
②在etc/profile中添加自动挂载主机nfs服务器
mount-t nfs -o nolock 192.168.1.141:/home/aston/rootfs(挂载源自) (挂载至)/mnt
其中/home/aston/rootfs 是ubuntu中的地址
/mnt是开发板中rootfs的地址
海思官方：ko（模块）和lib中的静动态库。
ko的使用，在ko文件夹中有一个load3518e，执行：
./load3518e-i -sensor ar0130 -osmem 32 -total 64
传参分别指定了sensor，osmem(linux kernel)的大小，total整体的大小。
【在etc/profile中写一劳永逸，但需要先cd进入ko文件夹】
小总结：在profile中要去添加做的是分别①配置网络，②挂载nfs服务器，③安装ko模块。
再完成了这些操作后，可以重新制作一份rootfs，命令：
osdrv/pub/bin/pc/mkfs.jffs2-d osdrv/pub/rootfs_uclibc -l -e 0x10000 -o
osdrv/pub/rootfs_uclibc_64k.jffs2
命令中使用的工具是相对路径。
官方默认制作rootfs是不会带.so的–每次都要自己手动把.so文件放进去
一劳永逸：官方生成rootfs的过程中会生成一个tgz 解压 然后cp *.so→放进去→手工制作jffs文件系统
当然也可以再这个rootfs中etc/profile中设置网络+挂载nfs+load3518e
sample的编译和测试
阅读readme文件
①配置编译依赖于MPP header files in /mpp/include and library files in mpp/lib.
②mpp – Makefile.param //定义mpp所需变量
|—sample—Makefile.param //定义sample所需变量
|— vio/venc/…—Makefile # Sample compilation script
venc自己的makefile需要mpp的Makefile.param和sample的Makefile.param
③Sample代码运行依赖media driver
execute the load3518e script in the mpp/ko to load a specified module.
④选择指定的sensor，下面是没有修改之前的状态:
#SENSOR_TYPE ?= APTINA_AR0130_DC_720P_30FPS
SENSOR_TYPE ?= SONY_IMX122_DC_1080P_30FPS
【chip：默认的chip和我们使用的chip不一致→也要改】
编译venc实例代码：
①execute the load3518e script in the mpp/ko to load a specified module.
②修改|—sample—Makefile.param配置为当前的sensor和chip
③makefile→sample_venc.c
sample/venc的测试
(1)nfs方式运行sample
(2)得到录像文件xx.h264
(3)导出xx.h264到windows下用vlc播放器播放验证
再运行sample_venc右边选择6种输出格式—windows下用vlc播放
sample和venc等关系
(2)每一个例程面向一个典型应用，common是通用性主体函数，我们只分析venc
(3)基本的架构是：venc中的main调用venc中的功能函数，再调用common中的功能函数，再调用mpp中的API，再调用HI3518E内部的硬件单元。
sample_venc的大体分析
(1)从main入手，main的传参分析
(2)几个基本概念：
H.264 H.265 MJPEG 视频编码规范标准
1080P（1920×1080）、720P（1280×720）、VGA（640*480）、D1 视频分辨率（清晰度）
fps（frame per second） 帧率
图像像素格式深度理解
颜色的三个关键：亮度、色度、饱和度
rawRGB和图像采集过程
(1)图像采集的过程：光照在成像物体被反射->镜头汇聚->Sensor光电转换->ADC为rawRGB
(2)sensor上每个像素只采集某一种特定颜色的光的强度→sensor每个像素只能为R或G或B
(3)rawRGB和RGB都是用来描述图像的
rawRGB→计算→RGB
(4)因为图像颜色本身有一定连贯性，而且人眼是非理想的，因此图像采集和再显示给人这整个构成中
有三个要素：分辨率（单位英寸中所包含的像素点数）、pitch（相邻像素点之间的距离）、观看距离
(5)如果是视频，质量好坏还要加上帧率framerate
(6)图像的表达、压缩、修整等相关技术，就发生在rawRGB进来以后的各个环节
媒体处理软件平台(Media Process Platform,简称 MPP)
应用程序启动 MPP 业务前，必须完成 MPP 系统初始化工作。
同理，应用程序退出MPP 业务后，也要完成 MPP 系统去初始化工作，释放资源。
2.8.1、整个main流程分析
2.8.2、MPP系统初始化详解
(1) 媒体处理软件平台(Media Process Platform,简称 MPP)
(2)MPP系统为什么要初始化
(3)MPP系统初始化为什么要在最前面
(4)MPP系统怎样进行初始化
(5)MPP系统初始化尤其注意API调用的顺序
HiMPP IPC V2.0 媒体处理软件开发参考.pdf
视频缓存池
(1)视频的本质是多帧图片，图片的本质是RGB或rawRGB数据，要占用一段连续内存
(2)视频的裁剪、缩放、修正处理等各种操作，本质上就是对内存中的数据进行运算
(3)视频缓存池(VB, video buffer)就是一段很大，又被合理划分和管理的内存，用来做视频数据的暂存和运算场地
(4)公共视频缓存池的公共2字，可以理解为全局变量，也就是各个模块都能访问的一段内存
(5)看似视频缓存块在各个模块之间流转，实际上并没有内存复制，而是指针在传递
(6)视频缓存池的内存由MPP来维护，我们在系统启动时就把整个SDRAM分成了2部分：系统部分（由linux kernel来维护管理）和mpp部分（由mpp系统来维护管理）
SDRAM范围：80000000-83FFFFFF =64K
linux内存：0x80000000-0x81FFFFFF MMZ内存：0x82000000-0x83FFFFFF
(7)缓存池需要几个，每个中包含几个缓存块，每个缓存块多大，都是可以由用户程序设置好参数，然后调用MPP的相应API来向MPP申请分配的。
VB_CONF_S 缓冲池结构体
typedef struct hiVB_CONF_S
{
HI_U32 u32MaxPoolCnt; /* max count of pools, (0,VB_MAX_POOLS] */
struct hiVB_CPOOL_S
{
HI_U32 u32BlkSize; 缓冲块大小
HI_U32 u32BlkCnt; 缓冲块数量
HI_CHAR acMmzName[MAX_MMZ_NAME_LEN]; 缓冲池名字
}astCommPool[VB_MAX_COMM_POOLS]; 缓冲池
} VB_CONF_S;
(2)HI_S32 HI_MPI_VB_SetConf (const VB_CONF_S *pstVbConf); 设置（填充）缓冲池结构体 告诉了VB但还没有开始用
(3)HI_MPI_VB_Init 真正执行了操作 即实例化了的缓冲池结构体投入使用
视频输入（VI）模块
VI可通过ITU-R BT656/601/1120 接口或 Digital Camera接口、 MIPI Rx(含 MIPI 接口、 LVDS 接口和 HISPI 接口)接收视频数据。
MIPI：移动产业处理器接口（Mobile Industry Processor Interface 简称MIPI）是为移动应用处理器制定的开放标准和一个规范。
LVDS：Low Voltage Differential Signaling，是一种低压差分信号技术接口。它是为克服以TTL电平方式传输宽带高码率数据时功耗大、EMI电磁干扰大等缺点而研制的一种数字视频信号传输方式,SubLVDS则是LVDS的发展.
VI部分的作用：
①对接收到的原始视频图像数据进行裁剪(Crop)等处理,
②实现一路原始视频图像输入,输出一路视频图像功能.
VI内部单元工作流程
摄像机通过镜头(lens)聚焦光线,将光信号投射到 sensor 的感光区域,sensor经过光电转换，将 Bayer 格式的原始图像送给 ISP(Image Signal Processing 图像信号处理) 经过算法处理，输出 RGB 空间域的图像给后端的视频采集单元。在这个过程中，ISP 通过运行在其上的 firmware 对 lens 和 sensor 进行相应控制，进而完成自动光圈、自动曝光、自动白平衡等功能。其中，firmware 的运转靠视频采集单元的中断驱动。
ISP控制结构:
VIU视频采集单元
VIU视频采集单元负责接收ISP传过来的视频图像,经过视频输入设备Dev0的加工,通过物理通道Chn0发送给接收者,也可通过扩展通道,进行缩放后发送出去.
视频输入设备Dev0:
Hi3516A/Hi3518EV200/Hi3519V100 芯片只有一个 VI 设备，即 Dev0。 Dev0 支持BT.656、 BT.601、 DC、 MIPI Rx（MIPI、 LVDS、 HISPI 接口）输入。 Dev0 不支持非连续 pixel clock 时序。
视频物理通道Chn0:
Hi3516A/Hi3518EV200/Hi3519V100 VI 硬件单元仅包含 1 个 VI 视频物理通道，即Chn0。
不存在次通道，但支持扩展通道。
视频扩展通道ext_ChnN:
扩展通道是物理通道的扩展，主要实现缩放功能，其数据来源于物理通道，
Hi3516A/Hi3518EV200/Hi3519V100 最多支持 16 个扩展通道。
对齐宏：CEILING_2_POWER宏的作用
#define CEILING_2_POWER(x,a) ( ((x) + ((a) - 1) ) & ( ~((a) - 1) ) )
返回：参数2的倍数，且该倍数是最小的大于参数1的。
比如（1280,64对齐） 将1280向上变大直至能够被64整除
2.11_12.VI部分详解2_3
(1)常用Sensor的接口有三种：MIPI、LVDS、DC
(2)WDR宽动态
(3)isp就是image signal process，图像信号处理。
(4)HI3518E内部的ISP单元是隶属于VI模块的。VI模块就包含3大部分：
第一部分是和Sensor对接的部分，
第二部分就是ISP，
第三部分就是VI dev和channel
VPSS（Video Process Sub-System）
VPSS支持对一幅输入图像进行统一预处理，如去噪、去隔行等，然后再对各通道分别进行缩放、锐化等处理，最后输出多种不同分辨率的图像。
sample中：VI的dev中有一个chn
VI的dev对应VPSS中的grp
VPSS中一个grp对应3个chn
基本概念
GROUP:
vi/vdec等发送数据→vpss的某个group中
①各 GROUP 分时复用 VPSS 硬件
②每一group对应多个通道channel，通道数目视方案实现有所不同
③不同芯片group数量上限不同，各 GROUP 分时复用 VPSS 硬件。
④与前面的VI相对应，接受前者的数据
⑤在线模式下只能有一个；离线模式下最大可用数VPSS_MAX_GRP_NUM
CHANNEL：VPSS 组的通道
与后面的模块相交接，每一个channel将数据交给后面的模块
比如channel0 送到VO channel1 送到VENC, 可以认为是个一分多
①4个物理通道：缩放、裁剪等功能。
VPSS 硬件提供多个物理通道
②8个扩展通道：
１.缩放功能
２.它通过绑定物理通道，将物理通道输出作为自己的输入，
把图像缩放成用户设置的目标分辨率输出。
每个通道都有自己的特性
FRC：帧率控制，分为 2 种： group 帧率控制和 chn 帧率控制。
− Group 帧率控制：用于控制各 group 对输入图像的接收，只离线方案。
− Chn 帧率控制：用于控制各个物理通道图像的处理，应用在离线和在线方案中。
Crop：裁剪，分为 3 种： group 的裁剪和物理通道的裁剪以及扩展通道的裁剪。
− Group 的裁剪， VPSS 对输入图像进行裁剪。
− 物理通道的裁剪， VPSS 对各个物理通道的输出图像进行裁剪。
− 扩展通道的裁剪， VPSS 调用 VGS 对扩展通道的输出图像进行裁剪。
通过调用 SYS 模块的绑定接口，可与 VI 和 VO/VENC/IVE 等模块进行绑定，其中前者为 VPSS 的输入源，后者为 VPSS 的接收者。用户可通过提供的 MPI 接口对 GROUP进行管理。每个 GROUP 仅可与一个输入源绑定。 GROUP 的物理通道有两种工作模式： AUTO 和 USER，两种模式间可动态切换。默认的工作模式为 AUTO，此模式下各通道仅可与一个接收者绑定。若想使用 USER 模式，则需调用 MPI 接口进行设置，同时指定所需图像的大小和格式，此模式下各通道可与多个接收者绑定。需要特别注意的是， USER 模式主要用于对同一通道图像进行多路编码的场景，此模式下播放控制不生效，因此预览和回放场景下不建议使用 USER 模式。
工作模式：有auto和user两种模式。
Hi3516A/Hi3518EV200/Hi3519V100 仅支持 USER 工作模式，
VI-VPSS 离线情况下开启了低功耗模式,
vpss 模块硬件不工作的时候时钟是关闭的，
读写 vpss 的寄存器可能导致挂死，因此最好不要做此操作。
离线模式：是指 VI 写出数据到 DDR，然后与之绑定的模块从 DDR 读取数据（LDC畸变矫正只能在离线模式中运行，除非自己在VPSS后在使用算法完成LDC，个人理解未证实）。
在线模式：在线是指 VI 与 VPSS 之间的在线数据流传输，在此模式下 VI 不会写出到 DDR，而是直接把数据流送给VPSS。（更快捷）
所以在线模式只能等到VPSS处理完之后分多个通道输出多个流。
默认：线模式，是因为在load脚本中设置的。
在load3518e（装载驱动的脚本）中，有这么一句代码：
insmod hi3518e_sys.ko vi_vpss_online=$b_arg_online
//b_arg_online=0表离线模式 b_arg_online=1表在线模式
通道支持接收 YUV 格式图像输入，支持格式为 Semi-planar YUV 4:2:0 或 Semi-planar YUV 4:2:2，
其中H.264/H.265 只支持 Semi-planar YUV 4:2:0，
JPEG/MJPEG 支持 Semi planar YUV 4:2:0 或 Semi-planar YUV 4:2:2。
另外，Hi3518EV200 能够支持单分量入（仅Y 分量，即黑白输入）。
通道模块接收外部原始图像数据，而不关心图像数据是来自哪个外部模块。
svc是H.264的补充编码标准。
CBR固定码率。
VBR可变码率，保证编码质量。
FIX Qp，固定Qp值。
Qp值越高，码率越低，质量越差。
Qp值越低，码率越高，质量越高。