多媒体/Display认知记录总结

OMX TUNNEL的一种工作模型：

１.对于每个解码器，都有一个码流使它无法工作，视频编码都是YUV420像素格式，硬件输出也只支持这几种格式。 

2. 码流相当于光盘，video codec相当于播放器，从数学的角度讲，它们是同构的的装置，这是一种新的解读。

3.编码与隐含的意义，有一种观点认为，一则编码了的消息与未编码的消息的不同之处在于，前者仅有其自身还不能表示什么，还需要有关编码的知识，学了哥德尔配数，就可以反驳这种观点了，事实上，现实中不存在什么未编码的消息，只有较熟悉的编码编制的消息和用不太熟悉的编码编制的消息之分，如要显露一则消息的含义，就必须用某种机制或同构的方式从编成的编码中把它抽取出来，发现解码的办法可能很困难，可一旦发现了，信息就会像水一样清澈，当编码和解码足够熟悉的时候，它就不显得像编码了，人们于是也就忘了有一个解码机制存在，这样，那则消息就同它的意义完全等同了．

4.经常再ISP的性能指标中看到13M@30 fps,8M@30 fps什么的，前面的数字表示像素分辨率，例如13M表示1300万像素，8M表示800万像素。30 fps表示帧率。

5:1个DAC对应一个声道，Codec作为DAC的容器，可以集成多个DAC.从Codec内部看，就是多少个DAC对应多少个声道, 但文档可能从外面Codec的角度看，例如某款Codec就是2声道；

6：DE没有刷新率，TCON，屏幕才有刷新率，刷新率=vsync中断的频率，刷新率和图像帧率是两码事，图像帧率由片源决定，而刷新率是TCON硬件支配的，帧率上去了，刷新率越大越好，帧率不能超过刷新率，图不变，同样的图刷新多少次，效果是一样的，用户感知不到，

DE显示的每个图层对应一个物理buffer，DE的作用就是将这些物理buffer中的数据，通过像素计算，得到一张输出图层的数据像素，最终输出给屏幕的只有一张图层，这张图层可能没有对应物理buffer，而是直接在线方式输出给屏幕的，

de将图像合成的数据直接送给接口模块（tcon,hdmi,mipi-dsi等）通过不同协议发送出去。

Sunxi DE同一channel只能overlay，而且不同图层输入输出参数必须一样,不同channel之间才能进行透明叠加. pipe应该和channel是同一个概念.

同显：扩展屏和本地屏输出同一幅画面，叫做同显，比如，就像你现在用的电脑一样用多个显示器，一个用VGA，一个用HDMI线连接，然后显示不同的内容就叫做异显，显示一样内容就叫做同显，还比如，HDMI 接口输出和设备自带的屏输出同一个画面，叫做同显，这个和接口没有关系，HDMI可以换成DSI，扩展屏接口可以随便换，只要支持就行。支持同显还是异显，从芯片设计角度，异显需要两个DE，多个DE是支持异显的必要条件，一个DE同时刻只能合成一个显示图层。所以 Organge 所谓的加速不是再g2d的常规操作上，而是用了DE的多图层混合便利，不用CPU直接去修改像素了，这就很弱了。

DE模块和G2D模块其实差不多是同一个ip， DE在线，G2D离线。 DE可以直接将多个图层进行merge然后送tcon显示，即便用了DE的多图层，也只是避免了软件混图，比如，要再某个图中心画一个矩形，多图层就很方便，不需要定位，手动改像素，但是如果只有一个图层的话，就需要CPU首先定位位置，然后修改像素了，  在线的只能在alpha blending和mixer操作有提升

7:视频播放时候的码率，准确的定义是单位时间内VBV(sbm)数据的比特率, 这个和封装格式没有关系.

一般我们通过工具获取到的媒体文件的码率是平均码率还是每个时间点都是这个码率？比如对于一个视频有运动和静止两个场景的情况下，运动场景编码效率低，所以单位时间内的数据量应该要比静止场景下大很多，所以两个场景的码率.应该是有差异的，但通常我们只获取到一个码率.还是说这个码率对应的是解码后的，这样的话每帧数据量是一样的，不论动静，都一样了? 

工具获得的码率是平均码率,所以是有平均码率和瞬时码率这两个概念的

工具有时会给出最大码率，但实时码率是给不出来的。

8:V系列能否做车机中控主控?有哪些不足？

  F1C800/F1C100S是可以做车机中控主控的，虽然是后装，经过请教客户后，发现V系列无法做车机中控主控的因素，一个是内部无法支持全格式视频解码，这点我已经考虑到了，但除了这个因素，还有就是V系列不支持TV IN/TV OUT。TV IN接倒车摄像头，tvout作为视频输出，接到其它显示器或者后枕. 原理上具备csi和dsi接口的V系列也可以解决接口问题，但是要外挂cvbs转csi的芯片，增加成本。tvout一般要求同显，不知道DSI能不能实现，转换成CVBS也要增加成本。

9:怎么看出一张图片上的高频部分和低频部分? 下面这张图片是一张数字图像处理领域的注明照片，貌似来自于花花公子,主人公名叫Lenna.

在图片中，高频一般都是纹理，低频都是平坦区域，这里皮肤是低频，帽子上的羽毛高频，和颜色没关系，主要是亮度，所以是灰度变换大的地方是高频，变化小的地方是低频，和颜色本身没有关。增加图像锐度，边缘对比度增加，高频部分比重会增加。图像锐度越大，即边缘越尖锐，细节越清楚，则图像越容易分辨越清晰，也就越不模糊

10:LT6911C芯片

是HDMI1.4转双MIPIDSI/CSI带音频， LT6911C是用于VR /智能电话/显示应用的高性能HDMI1.4到MIPI®DSI/ CSI芯片。

对于MIPI®DSI/ CSI输出，LT6911C具有可配置的单端口或双端口MIPI®DSI/ CSI，具有1个高速时钟通道和1?4个高速数据通道，它们以最大1.5Gb / s / lane的速度运行。 可以支持高达12Gbps的总带宽。 LT6911C支持突发模式DSI视频数据传输，还支持灵活的视频数据映射路径。

 2.特点

 •HDMI1.4接收器

•单/双端口/四端口MIPI®DSI / CSI发送器

11：VLC的使用

12：光栅化技术(rasterization)

移动设备的显示屏由成千上百万个小的，独立的部件组成，它们称为像素,这些像素中每一个都有能力显示几百万中不同颜色范围中的一种颜色。然而，这实际上是一种视觉技巧.大多数显示器并不能真正创造几百万中颜色，所以每个像素通常由三个单独的子组件构成，它们发出红色，绿色和蓝色的光。因为每个像素都非常小，人的眼睛会把红色，绿色以及蓝色的光混合在一起，从而创造出巨量的颜色范围，把足够多的单独的像素放在一起，就能显示出一页文本或者蒙娜丽莎像。

opengl通过光栅化过程把每个点，直线以及三角形分解成大量的小片段，它们可以映射到移动设备显示屏的像素上。从而生成一幅图像。这些片段类似于屏幕上的像素。每一个都包含单一的纯色，为了表示颜色，每个偏度但都有四个分量，俗称四个通道，其中红色，绿色，蓝色用来表示颜色，阿尔法(alpha)分量（通道）用于表示透明度。

例如，opengl把一条直线光栅化为一个片段集合，显示系统通常会把这些片段直接映射到屏幕上的像素。结果一个片段就对应一个像素，然而，并不总是这样的，一个超高分辨率的设备可能需要使用较大的片段，以减少GPU的工作负荷。

13:视频dongle是什么？

视频dongle也叫视频投屏器，产品形态是做成类似于一个U盘大小或者稍大一些的设备，插到电视上（用HDMI口)。因为一般距离不远，通过室内WIFI，手机，平板无线传到设备即可将内容压缩，传递个dongle进行解码，最后通过HDMI接口送给电视输出。

14：F133支持两个DE，所以可以做双屏异显，其中1个DE支持1个UI+1Video channel，另一个DE仅支持1个Video channel，所以总共支持2Video+1UI channel，也就是8个视频图层，4个UI图层。

15:我们通常把一本书看成线性媒体，需要从头到尾顺序阅读，与之相反，超文本系统是非线性读取的，可以利用指向文档中其他部分或者其他文档的链接来进行,世界上所有的文档，都应当是其它文档的注脚，而计算机应该让这些文档之间的联系变得清晰可见，永不间断，这种角度犹如上帝般不可思议，超链接的触手不断延伸，把所有的比特链接起来。

16:ISP从内核获取到参数信息然后经3A库计算，得到配置参数，然后再设回给ISP硬件，这个过程需要一定的时间。会不会有滞后的问题？ 类似于控制系统的超调等等。。。比如参数是根据一个场景获取到的，但计算过程中，场景已经换了，计算的依据仍然是前面的场景，再设回去岂不是就不对了.

会有的，但是算法有针对这种情况进行处理，而且一般delay2~3帧，实际场景变化不大。

17:RTMX(real time Mixer),就是de的核心,就是包括几乎所有功能,de最关键的作用就是图像合成,把几个图像数据透明叠加成一张,在这个关键功能之外，还会加入其它功能，比如图像增强.

18:disp_lcd_event_proc是TCON中断处理函数，vsync中断大部分情况就是tcon的中断，它的频率等于屏幕刷新率。

19：关于图形图显模块的工作原理说明:

DE：Display Engine.显示引擎，负责将输入的多图层进行叠加，混合，缩放等等处理的硬件模块

channel:一个硬件通道, 包含若干图层处理单元，可以同时处理若干格式相同的图层.

layer:一个图层处理单元，可以处理一张图像输入图像，按支持的图像格式分为video和UI类型。

alphya:透明度,在混合时决定对应图像的透明度.

overlay:图像叠加，按顺序将图像叠加一起的效果.z序大的靠近观察者，会把z序小的挡住.

blending:图像混合，按alpha比例将图像合成一起的效果.

cover:cover就是用单一颜色覆盖某个区域.

同一channel只能overlay，而且不同图层输入输出参数必须一样,不同channel之间才能进行透明叠加. 

什么是overlay呢？

另外需要注意的一点，在sunxi平台上，overlay还有另一个意思，就是VENC 模块，也就是video encoder模块也声称支持overlay,单它的overlay支持非同DE对overlay的支持，overlay在DE和VE端，虽然同一个描述，但是操作内涵是不同的，DE是独立图层独立buffer，所以overlay不会修改被overlay的图层像素数据，但是VENC 中的overlay则是通过修改像素数据实现的贴图功能，没有独立的buffer管理。

V833 VIPP通道不支持overlay,cover，只支持ORL(Object Rectangle Label,也就是画框).V833 VENC通道支持overlay,cover, 但是不支持ORL，overlay贴图支持支持argb8888、argb1555、argb4444的原图格式。所以对于编码来讲，VIPP，VECN通道正好互补.

3D显示原理，貌似和主控关系很少，主要是支持VE出两路流和DE支持packed输出图，其余的都是HDMI完成的。给2份数据给到DE，读了，写到HDMI

这里支持上下，左右packed方式的3D.

多媒体播放器，解码后送显示render这个环节，每一个YUV帧在DE那边的的显示时间长度，能够保证完全一样的吗？比如A,B,C三个帧，每个帧的显示时间长度，DE完全不管，由应用场景去管，还是说DE硬件会感知并且会控制？

显示时间长度由应用决定。但是显示驱动，只能每隔16.667ms更新一次（1/刷新率），所以显示时间长度不会低于16.667ms。应用层送帧的频率不能超过刷新率，只能慢不能快。一秒60帧的刷新率就相当于每一帧存在的时间是1/60这么长的时间，也就是16.667ms，帧率一般达不到这么快。

channel有视频通道和UI通道之分，视频通道功能强大，可以支持YUV格式和RGB格式，UI通道只支持RGB格式。

20：对于DE输入来讲，不管输入了多少个YUV图层或者UI图层，最终经过RTMX处理之后，只变成了一张图层，就是最终的送显图层， 最终合成的这张图层是在线的，但是可以放到内存中，正常播放状态下都是在线的，没有回写，

在线情况下，合成之后的数据送到输出接口，这个过程软件没有参与的.

那么，DE支持的回写内存功能，包括所有图层吗？UI图层和视频图层的内容都在回写的一张图里面吗？

答：只能回写合成之后的数据，不能回写单独某个图层。

那么，那么回写的这一张图是什么格式？

答：支持好几种，rgb，yuv都行

回写API：

21:V833 VIN能接几个摄像头？

 1:可以接一个并口摄像头和一个mipi摄像头

 2.可以接四个模拟摄像头

 模拟摄像头不经过ISP处理，并口摄像头指的是DVP摄像头，

3.V833 MIPI是几LANE的了解吗，1条时钟lane，最高4条数据lane， 

四个数据lane，可以对应前面四个摄像头吗？ 每个摄像头占用一个 lane？

不可以，

最多只能接一个MIPI摄像头是吧.有没有可能多个摄像头画面交织在一起输出呢？

可以支持4个1080P30fps交织的4路模拟摄像头

这种情况是通过BT656那条通路走，不能走MIPI是吧？

不是，走mipi的vc模式，bt656是并口的。

了解,vc = virtual channel.对否？

是

那还有一个问题，四个摄像头不能是普通摄像头吧？ 否则四个摄像头，四条排线，怎么接到我们的一组MCSI上呢？

需要有硬件来交织，例如tp、ncp等等，外挂芯片。

外挂对片的方式可以连接四个摄像头，通过MIPI virtual channel发送给SOC.

 关于摄像头接口有三种：

 1).我们常用的电脑摄像头接口是USB接口，而常见的智能手机上的摄像头是MIPI接口，还有一部分的摄像头（比如说某些支持DVP接口的硬件）是DVP接口；通俗的讲，USB是串行通用串行总线（Universal Serial Bus）的简称，而MIPI是移 动行业处理器接口（Mobile Industry Processor Interface），DVP是数字视频端口（digital video port）的简称，CSI是相机串行接口（CMOS Sensor Interface）的简称。

 2).DVP总线PCLK极限约在96M左右，而且走线长度不能过长，所有DVP最大速率最好控制在72M以下，PCB layout较容易画；MIPI总线速率lvds接口耦合，走线必须差分等长，并且需要保护，故对PCB走线以及阻抗控制要求高一点（一般来讲差分阻抗要求在85欧姆~125欧姆之间）。

3).DVP是并口，需要PCLK、VSYNC、HSYNC、D[0：11]——可以是8/10/12bit数据，具体情况要看ISP或baseband是否支持；MIPI是LVDS低压差分串口，只需要要CLKP/N、DATAP/N——最大支持4-lane，一般2-lane可以搞定。MIPI接口比DVP的接口信号线少，由于是低压差分信号，产生的干扰小，抗干扰能力也强。最重要的是DVP接口在信号完整性方面受限制，速率也受限制。500W还可以勉强用DVP，800W及以上都采用MIPI接口。

22：音频信息在多媒体数据中非常重要，从某种角度来讲，它是最简单的一种多媒体数据，音频信息和图像信息之间存在一些不容忽视的显著差异，例如，在视频流中，为了加快视频的播放速度，我们可以酌情丢弃一些视频帧，但是在音频信息中，我们却不可以这样做，因为这样做会丢失整个声音信息的语义。

23:回声消除

24:ISP整定工具原理 adb forward命令

25：关于显示

现实中最重要的资源是图层，以V833为例，V833支持1个DE同显，这个DE设备支持3个显示通道（在硬件层面，1个通道就是一个专用DMA），通道0，1为视频图层通道，通道2为UI图层通道，每个显示通道包含4个图层，通道0，1的图层都支持缩放(scaler).通道2的图层不支持缩放，图层由DE， channel, layer  萨格索引唯一确定，(DE:0/1,Channel:0/1/2/3,layer id: 0/1/2/3).

对于系统来说，12个layer可以看作从0-11线性排布的。视频图层的0-3,4-7 layer属性要保持一致。

请教你一个关于DE带宽的问题，DE VI 图层支持 scaler，方案在启用scaler的时候，与不做scaler对比，对系统的带宽要求有变化吗？变大，还是变小。

趋向变小或不变

                                   scaler是在线的是吗？中间不回写内存？

不会写，只有读带宽。

26：关于V833显示

DE0channel 0四个图层缩放显示在同一个屏上,有点像闭路电视的监控显示屏

图层配置，如果用同一个通道的话，输出画面大小(scaler后的大小）要完全一样，否则无法共用一个通道。

接下来：1,2画面用channel0, 3,4画面用channel1.

图层配置：

接下来，channel 0 scanler输出 240*320.channel1 scanler输出 120*160，得到以下输出。从这个输出也可以看到，此屏幕为竖屏切割，非横屏。

图层配置：

27：VE framebuffer分配多少个是收到什么控制的？固定的吗？

除了一些固定的，还会根据参考帧的个数。

参考帧个数一般分布是多少个。

两三个吧，四五个算比较多的了。

28:I帧的宏块全部是帧内预测，没有帧间预测是吧。P/B帧编码过程，会 尝试 帧内、帧间 两种预测方法，比较选出较优的作为最终的预测模式. 

所以，就是二选一是吧，不能两个都要.

对。

28：adb forward on melis.

最开始弄这个功能，是为了把录音数据传输给PC.只是借用usb进行数据传输，PC端跑个python脚本(进行本地socket通信)获取数据，跟声卡没有任何关系,如果在linux，就会直接用UAC gadget功能了,这才是对接了音频那一套接口功能.

29：melis上的fb0， fb1设置没有起作用，没有用到framebuffer，没有fbdev，在Linux上，framebuffer一定是rgb格式的？ YUV视频不可以直接渲染到fb上面。

30：YUV Sensor：YUV Sensor输出的格式是YUV，图像的处理效果使用sensor内部的ISP，BB端接收到的YUV格式数据后只能进行格式的转换，效果方面不进行处理，由于Sensor内部的ISP处理能力有限，且YUV Sensor的数据量比较大(YUV422格式1个pixel占据两个bytes)，所以YUV Sensor的size都比较小，常见的YUV sensor都在5MB以下。
        Raw Sensor：Raw Sensor输出的格式为Raw，图像的处理效果使用BB端的ISP，BB端接受到Raw data进行一系列的图像处理(OB, Shading, AWB, Gamma, EE, ANR等)，效果方面是由BB进行控制，需要针对不同的模组进行效果调试，Raw sensor是目前的主流，数据量比YUV Sensor小（RAW10格式的sensor 1个pixel占用10bit）,使用平台ISP处理，能支持较大的size。
        YUV  sensor 又叫soc senor , 和 RAW  sensor 的区别为 ISP  是在 模组内部，还是BB 上；YUV是一种压缩后的图像数据格式，包含很多具体的格式类型，包含很多具体的格式类型，摄像头对应的是YCBCr( 8bits,4:2:2,Interpolated color)。

31.DE做dzoom的过程

何为dzoom? dzoom的过程是保持图片中心点不变，逐渐放大做zoom in的过程，效果类似于电影拍摄过程中由远及近的拉近镜头，但是保持画面中心处的物体不变。

只需要不断调整几个参数，DE也可以做出这种效果:

DE中， 图层 Frame Buffer 有两个与 size 有关的参数，分别是 size 与 crop。Size 表示 buffer 的完整尺寸，crop 则表示 buffer 中需要显示裁减区。完整的图像以 size 标识，而 矩形框住的部分为裁减区，以 crop 标识，在屏幕上只能看到 crop 标识的部分，其余部分是隐藏 的，不能在屏幕上显示出来。

Screen_win 为 crop 部分 buffer 在屏幕上显示的位置。如果不需要进行缩放的话，crop 和 screen_win 的 width,height 是相等的，如果需要缩放，需要用 scaler_mode 的图层来显 示，也就是YUV图层，crop 和 screen_win 的 width,height 可以不等。这个时候，DE会自动进行缩放。

disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=0, size=<0,0>, crop=<0,0,0,0>,frame=<0,0>, en=0 addr[0x0,0x0,0x0> alpha=<0,0>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=0, size=<0,0>, crop=<0,0,0,0>,frame=<0,0>, en=0 addr[0x0,0x0,0x0> alpha=<0,0>
CedarXNativeRenderer.cpp       W  <CedarXNativeRenderer:159> [1080]!=display_height[1440]
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=0, size=<0,0>, crop=<0,0,0,0>,frame=<0,0>, en=0 addr[0x0,0x0,0x0> alpha=<0,0>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=0, size=<0,0>, crop=<0,0,0,0>,frame=<0,0>, en=0 addr[0x0,0x0,0x0> alpha=<0,0>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<0,0,1920,1440>,frame=<480,640>, en=1 addr[0x4181c000,0x41a1a000,0x0> alpha=<0,128>
VideoRender_Component.c        W  <VideoRender_ComponentThread:2228> Be careful! resolution has changed! oldSize[0,0][1920x1440],newSize[80,48][1760x1320]
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<80,48,1760,1320>,frame=<480,640>, en=1 addr[0x4181c000,0x41a1a000,0x0> alpha=<0,128>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<80,48,1760,1320>,frame=<480,640>, en=1 addr[0x41b19000,0x41d17000,0x0> alpha=<0,128>
VideoRender_Component.c        W  <VideoRender_ComponentThread:2228> Be careful! resolution has changed! oldSize[80,48][1760x1320],newSize[160,88][1600x1200]
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<160,88,1600,1200>,frame=<480,640>, en=1 addr[0x41b19000,0x41d17000,0x0> alpha=<0,128>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<160,88,1600,1200>,frame=<480,640>, en=1 addr[0x41e16000,0x42014000,0x0> alpha=<0,128>
VideoRender_Component.c        W  <VideoRender_ComponentThread:2228> Be careful! resolution has changed! oldSize[160,88][1600x1200],newSize[208,120][1504x1128]
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<208,120,1504,1128>,frame=<480,640>, en=1 addr[0x41e16000,0x42014000,0x0> alpha=<0,128>
disp_mgr_set_layer_config line 1228, layer:ch0, layer0, format=77, size=<1920,1080>, crop=<208,120,1504,1128>,frame=<480,640>, en=1 addr[0x42113000,0x42311000,0x0> alpha=<0,128>
VideoRender_Component.c        W  <VideoRender_Com