画质增强概述-3.3-AI增强实践之服务形态

low-level 视觉任务输入输出一般都是RGB数据，那么在生产环境，除非在移动端增强后直接显示，否则基本是需要对数据进行压缩，然后存储或者传输。服务端的增强服务，多数是把增强服务封装为ffmpeg 的一个 video filter 来使用更方便一些

3.3.1 video-enh c sdk

首先是将推理模块封装成 c SDK，该SDK中包含 opencv 和推理引擎 TensorRT 的调用，不过经过封装后，暴露的接口建议是纯C接口，因为 ffmpeg 不支持 c++ 风格的头文件，相对而言，c 风格接口适应性更广些

接口参数除了模型文件外，重要的参数是可以指定GPU-ID，因为生产环境中常见是多卡服务器，可指定GPU-ID非常重要

3.3.2 ffmpeg video filter 实现

利用 video-enh c sdk 来实现一个 video filter 是比较简单的事情，网上的资料比较多

稍微值得说一下的是，对 low-level 视觉任务，ffmpeg 的多slice 模式效果可能不会太好，slice 边缘容易出现比较显著的虚线

3.3.3 python-app

从服务化的角度看，单纯 ffmpeg 是不够的，对大文件增强，一般需要分段处理，然后再合成，比如我在8卡服务器上，处理的视频时长是80分钟，那我自然希望可以把视频分为8段，每段独占一个GPU 并行处理，这时候首先是ffmpeg可以指定gpu-id运行，另外，最好有个python 脚本来自动做切片、增强处理后再合并等操作，这就是 python-app 脚本的意义

3.3.4 docker 镜像

再往上，实际上发布服务的话，通过 docker 镜像是最理想的方式，这是因为AI增强服务的环境依赖及兼容性是个很麻烦的问题，几个核心依赖包括：os和驱动相关的linux、显卡驱动、cuda；开发相关的 c/c++ 编译环境(gcc/cmake等)、python(pytorch及相关包)；核心组件如ffmpeg、opencv、tensorRT等等，这些依赖的兼容性坑是比较多的，毕竟是不同的组织在维护，因此，发布的时候采用docker镜像是个好办法