AD&VideoIn

本文详细介绍了音视频采集芯片AD的工作原理及常见型号,如nextchip和Tecpoint系列。AD芯片主要负责音频和视频信号的采集、I2C控制以及Port口输出。内容还涉及到VI(Video Input)模块的功能,包括视频数据接收、接口模式配置以及与AD芯片的匹配设置。同时,讨论了帧率、分辨率和数据量如何影响VI通道的选择,确保不超过Bt656的最大数据承载能力。

AD指的是采集芯片,模拟信号转数字信号的音视频采集芯片,简称AD芯片。

常见的nextchip厂家:6124 6134 6134C 6158C等

Tecpoint厂家:tp2826 tp2827 tp2827c tp2828 tp2829 等

 

我们先来看下AD芯片,主要包括音频采集,视频采集,I2C控制线,Port口输出, 音频输出等

 

上图为AD的原理图,通常我们称dvr的AD芯片为rx,r指的是receive端,模拟相机端把信号调制到高频来达到尽可能避免传输过程中信号被污染,在rx端,简单的说,AD就是把信号解调制后,复原到tx发送之前的数据信号。模拟信号尽可能保留源信号的把它转换成数据信号,然后通过bt656或者bt1120协议传给主控芯片的输入

视频输入(VI)模块实现的功能:将芯片外的视频数据通过ITU-R BT656/601/1120 接口或Digital Camera 接口接收,存入到指定的内存区域。

 

VI_DEV_ATTR_S stViDevAttr;

typedef struct hiVI_DEV_ATTR_S

{

    VI_INTF_MODE_E      enIntfMode;         /* Interface mode */

    VI_WORK_MODE_E      enWorkMode;         /*1-, 2-, or 4-channel multiplexed work mode */

    HI_U32              au32CompMask[2];    /* Component mask */

   VI_CLK_EDGE_E       enClkEdge;          /* Clock edge mode (sampling on the rising or falling,double edge) */

   HI_S32              s32AdChnId[4];      /* AD channel ID. Typically, the default value -1 is recommended */

    /* The below members must be configured in BT.601 mode or DC mode and are invalid in other modes */

    VI_DATA_YUV_SEQ_E   enDataSeq;          /* Input data sequence (only the YUV format is supported) */

    VI_SYNC_CFG_S       stSynCfg;           /* Sync timing. This member must be configured in BT.601 mode or DC mode */

    VI_DATA_PATH_E      enDataPath;         /* ISP enable or bypass */

    VI_DATA_TYPE_E      enInputDataType;    /* RGB: CSC-709 or CSC-601, PT YUV444 disable; YUV: default yuv CSC coef PT YUV444 enable. */

    HI_BOOL             bDataRev;           /* Data reverse */

} VI_DEV_ATTR_S;

以上的属性信息需要跟AD的工作设置相匹配,它其实对应的是硬件波形以及布线时的一些物理特性

比如enWorkMode,设置为4mux,则AD的port口设置也需要相应设置为4mux

enClkEdge上升沿还是下降沿数据采样,则AD也要设置为上升或者下降沿发出数据

bDataRev,这个是用于控制bt656数据线反序(D7D6D5..D1D0)时需要设置,否则可能出现vi中断为0

 

具体使用方案:

Hi3521A VI 有4 个设备和16 个物理通道,每个设备默认与对应的4 个通道绑定,其绑

定关系如图3-5 下:

在dvr平台,一个viDEV对应着AD上的一个port口输出。目前dvr AD芯片都是支持1路视频输入,有2个或者4个port输出,所以在vi的dev端,最多正好可以解析出四路vi chn来,从而保障采集数据够传输的过来。而选择1路/2路/4路也不是随意设置的,决定它的参数是数据量。

 

25fps 720P PAL 数据宽度(3960)* 行数(m750)* 帧率(25)= 74250000 = 74.25 MHz

30fps 720P NTSC 数据宽度(3300)* 行数(750)* 帧率(30)= 74250000 = 74.25 MHz

50fps 720P PAL 数据宽度(3960)* 行数(750)* 帧率(50)= 148500000 = 148.5 MHz

60fps 720P NTSC 数据宽度(3300)* 行数(750)* 帧率(60)= 148500000 = 148.5 MHz

25fps 1080P PAL 数据宽度(5280)* 行数(1125)* 帧率(25)= 148500000 = 148.5 MHz

30fps 1080P NTSC 数据宽度(4400)* 行数(1125)* 帧率(30)= 148500000 = 148.5 MHz

Bt656的频率目前主流最高支持297M的单沿或者148.5M的双沿,这就决定了一个bt656的总数据量,无论1路还是4路绑定,其数据量都需要小于或者等于一个Bt656所能承载的总数据量。

<think>Hmm, the user is asking about the meaning of "header2" specifically in the context of "ad". Looking back at the conversation history, I provided a detailed explanation earlier about HTTP headers, but the user seems to be referring to something more specific now. Let me analyze this carefully. The term "header2" isn't a standard term in HTTP protocols - in fact, none of the references mention it. The user might be referring to either: 1) A custom header named "Header2" used in their advertising technology stack 2) The second header in some AD-related message structure 3) Or potentially confusing it with HTTP/2 headers which are binary framed Given the AD context, this is likely about digital advertising systems. In programmatic advertising, headers often carry crucial information like: - User identifiers (Header1 might be device ID, Header2 could be user ID) - Auction parameters - Privacy consent flags (CCPA/GDPR) The references mention Contact headers in SIP protocols, but that seems unrelated. Since the user insists on "header2", I should focus on common advertising scenarios. Perhaps they're working with AD exchange protocols where headers are sequentially numbered. I recall that in OpenRTB specifications, there's no "header2" but there are tiered headers for things like: - Header-level bidding parameters - Multi-header impression tracking Without more context, the safest approach is to explain possible interpretations while asking for clarification. The user sounds technical based on previous HTTP questions, so I should maintain that level of detail while avoiding HTTP rabbit holes since this appears to be AD-specific terminology. </think>关于"header2"在广告(AD)系统中的含义,需要结合具体上下文分析: ### 可能含义分析 1. **自定义广告头字段** - 在程序化广告中,`header2`可能是自定义的HTTP请求头字段 - 常见用途: * 传递竞价信息:`Header2: bid=${price};adslot=728x90` * 用户标识传递:`Header2: device_id=AA-BB-CC;user_tier=premium` * 广告实验分组:`Header2: exp_group=video_ad_v3` 2. **协议规范中的字段** 根据RFC规范: ```http GET /ad/impression HTTP/1.1 Host: ad.example.com Header1: value1 Header2: value2 # 可能指二级头域 ``` - 常用于分层传递信息: * `Header1`:基础设备信息 * `Header2`:扩展广告参数 3. **特定广告系统中的命名** - 在Google Ad Manager等平台中可能表示: * 第二优先级头信息(当Header1空间不足时) * A/B测试的第二实验组标识 * 加密广告数据的第二段密文 ### 建议确认方向 1. **查看技术文档** - 参考所用广告SDK的官方文档(如Google Ads API、Facebook Marketing API) 2. **检查协议示例** ```http POST /ad/auction HTTP/2 X-Header1: 1920x1080 X-Header2: cpm=5.2&format=video # 典型广告参数结构 ``` 3. **调试日志分析** 若在开发中遇到,建议检查: ```python print(request.headers['Header2']) # Python示例 console.log(request.getHeader("Header2")); // JavaScript ``` > ⚠️ 注意:该命名非常规标准字段,需结合具体广告平台确认。 *** ### 相关问题 1. HTTP头部在程序化广告竞价中如何传递出价信息? 2. 如何自定义HTTP头字段传递广告投放参数? 3. 主流广告平台(如Google Ads、TikTok Ads)的特殊头字段有哪些差异? 4. 广告系统中常见的加密头字段如何实现用户隐私保护? 建议提供更多上下文(如技术栈或具体场景),以便精确解析`header2`的含义[^1][^2][^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值