1.概述
1.1 VIO框架演变
从XJ2时期到J5时期,都是采用VAPI接口,到了J6时期,设计了一套HBN接口,但对外还是沿用VAPI接口;
1.2为什么不采用V4L2框架?
V4L2 驱动框架结构庞大,引入后需遵循其严格接口设计,新功能开发成本高;
不利于跨OS平台移植;
2.VPF框架
2.1.为什么设计VPF框架?
J系列接口单一,X系列接口灵活性大,VPF兼容X/J系列的使用需求;
VAPI在通路组合上限制比较大
2.2.概念扩展
2.2.1.VAPI Pipeline 概念

2.2.2.VPF Flow概念

Flow概念是在Pipeline概念上的拓展,增加了通路配置的灵活性;
3.API使用流程区别
3.1.VAPI和HBN API主要接口列表
VAPI | HBN API |
hb_vio_init | hbn_vnode_open |
hb_vio_start_pipeline | hbn_vnode_close |
hb_vio_get_data_conditional | hbn_vnode_set_attr |
hb_vio_get_data | hbn_vnode_get_attr |
hb_vio_free_pymbuf | hbn_vnode_set_attr_ex |
hb_vio_free_ispbuf | hbn_vnode_get_attr_ex |
hb_vio_free_ipubuf | hbn_vnode_set_ochn_attr |
hb_vio_free_gdcbuf | hbn_vnode_set_ochn_attr_ex |
hb_vio_stop_pipeline | hbn_vnode_get_ochn_attr |
hb_vio_deinit | hbn_vnode_set_ichn_attr |
| hbn_vnode_set_ichn_attr_ex |
| hbn_vnode_get_ichn_attr |
| hbn_vnode_enable_ichn |
| hbn_vnode_disable_ichn |
| hbn_vnode_enable_ochn |
| hbn_vnode_disable_ochn |
| hbn_vnode_set_ochn_buf_attr |
| hbn_vnode_start |
| hbn_vnode_stop |
| hbn_vnode_getframe |
| hbn_vnode_getframe_cond |
| hbn_vnode_getframe_group |
| hbn_vnode_getframe_group_cond |
| hbn_vnode_sendframe |
| hbn_vnode_sendframe_async |
| hbn_vnode_releaseframe |
| hbn_vnode_releaseframe_group |
|
|
| hbn_vflow_create |
| hbn_vflow_destroy |
| hbn_vflow_create_cfg |
| hbn_vflow_add_vnode |
| hbn_vflow_bind_vnode |
| hbn_vflow_unbind_vnode |
| hbn_vflow_start |
| hbn_vflow_stop |
| hbn_vflow_get_version |
| hbn_vflow_get_vnode_handle |
3.2.VAPI工作流程
仅支持JSON配置

3.3.HBN API工作流程
JSON配置流程,对齐原有VAPI的使用方式

不使用json配置,直接用接口配置参数的流程

3.现状
API灵活性限制: 虽然VAPI作为对外唯一接口提供了基础功能,但在应对客户高度定制化或非标准化的通路构建需求时,仍显得灵活性不足,往往需要额外的定制化开发支持。
性能优化空间: 性能始终是嵌入式视觉处理的核心关注点。尽管VPF在设计上已尽量减少额外线程开销(主要依赖中断线程),但核心链表操作等框架固有逻辑的开销仍不可忽视,尤其是在处理高分辨率、高帧率数据流时。需要持续进行深度优化。
调试与分析深度: 现有的Sysfs节点和Trace工具提供了基础信息,但在复杂问题的深度诊断、性能瓶颈的细粒度剖析、以及跨IP协同问题的可视化分析方面,工具链的深度和易用性仍有提升空间。
跨平台成熟度: 跨OS平台移植能力是VPF的设计优势之一,但在不同OS(QNX系统)上的成熟度、稳定性验证和性能表现需要持续的投入和优化。