Hey Wayne, 作为同样搞过嵌入式相机+Android应用开发的人，我来给你唠唠这些问题的实际解决方案和踩过的坑！

一、Android平台能否通过处理原始图像添加水印？ #

完全可以，这也是没有硬件OSD支持时的主流方案，主要有两种落地路径：

• 预览帧回调处理：通过CameraX的ImageAnalysis或者传统Camera2的ImageReader获取原始预览帧（大多是YUV_420_888格式），将其转换为Bitmap后用Canvas绘制日期文字，再把处理后的帧送回预览渲染；也可以直接在Native层操作YUV数据绘制，跳过格式转换的开销。
• 视频流链路插入处理：如果同时在录制视频，可在视频编码前的流处理阶段加水印——对采集到的原始帧做叠加后再交给编码器，这样预览和录制的水印能复用同一逻辑。

二、纯原始图像处理的耗时情况？ #

耗时差异主要取决于分辨率、设备性能和处理方式：

• 低分辨率（720p及以下）：Java层用Canvas绘制水印，单帧耗时大概2-5ms，基本不会影响30fps的预览流畅度。
• 高分辨率（1080p/4K）：Java层转Bitmap再处理的话，单帧可能到10-20ms，低端设备甚至会丢帧；但如果用Native层直接操作YUV帧，或者用RenderScript加速，耗时能降到5-10ms左右，勉强能跟上30fps。
• 和嵌入式硬件OSD对比：硬件OSD是在显示/编码前直接叠加，几乎零CPU占用；纯软件处理必然额外消耗CPU/GPU资源，高负载下可能影响视频编码的稳定性。

三、FFmpeg/GStreamer能帮上忙吗？ #

太能了！这俩是音视频流处理的利器，能把水印处理的开销降到最低：

• FFmpeg：用它的drawtext滤镜可以直接在视频流（包括预览流）上叠加日期水印，关键是支持Android平台的硬件加速（比如利用MediaCodec的硬件解码/编码能力，或者FFmpeg自身的hwaccel模块），大部分处理在硬件完成，CPU占用极低。你可以把采集到的原始帧喂给FFmpeg的滤镜链，处理后再输出到预览或编码器。
• GStreamer：它的textoverlay元素专门用来添加文字水印，同样支持硬件加速的流处理。如果你的应用本来就用GStreamer做视频采集/编码，直接在Pipeline里插入textoverlay节点就行，配置日期格式、位置、字体都很灵活，性能比纯软件处理好很多。

一些实践建议 #

• 如果你的设备有硬件OSD能力，优先考虑通过Android的CameraCharacteristics或者厂商提供的HAL扩展调用硬件OSD，这是最优解；
• 若只能用软件方案，优先在Native层处理YUV帧，或者用RenderScript/OpenCV的加速接口；
• 用FFmpeg/GStreamer时一定要开启硬件加速，否则纯软件滤镜的耗时可能比自己写的代码还高；
• 预览和录制的水印最好复用同一处理逻辑，避免重复计算。

内容的提问来源于stack exchange，提问作者Wayne Chen