来自 IP 摄像机的“实时采样”（非流式传输）

Question

我正在编写一个 C++ 计算机视觉应用程序，该应用程序具有采样 IP 摄像机的视频，不播放其流。澄清一下，来自 IP 摄像头的流媒体提供了一个时间压缩的视频流，定义为时间点的开始和结束点，通常表示为 h264。相反，采样摄像机正在“现在”请求单个图像。如果图像请求发生得足够快以至于 h264 或类似文件更有效，则使用该压缩，但永远不要在当前图像请求之前及时将“旧图像”传递给库客户端。

基本上，视频库需要提供视频采样接口，而不是视频流接口。如果两次请求视频样本的时间间隔为 5 分钟，则返回的视频图像是最近生成的图像。

根据我几年来对 h264、IP 视频流和使用 libavcodec 编写应用程序的理解，满足这些要求的最有效方法是双线程架构。一个线程的工作是不断消耗来自 IP 摄像机的帧，而第二个线程的工作是接受 来自第一个线程的帧，并且仅在库客户端从相机请求图像时才将最新的视频帧提供给库客户端。满足库要求的关键是与库客户端应用程序分开运行的视频消费线程。第一个线程需要旋转消耗帧，以保持相机通信健康并为库客户端维护最新帧。

如果使用一个线程尝试这些要求，并且视频样本之间的时间为 5 分钟（甚至 5 秒），则视频流可能已从 IP 摄像机中消失，因为该流未被消耗，但如果流如果仍然存在，接收软件将不得不“流过并丢弃”相机可能积压的任何帧。

基本上，这种“采样”行为不是 IP 摄像机的正常预期行为，也不是一般的视频流。没有使用图片捕获接口，为了支持这种行为，软件需要一个“旋转线程”来消耗帧，以便在库客户端请求时可以使用最近生成的帧。支持视频采样接口的视频流没有“模式”或“实时配置文件”。需要在软件中创建它，使用与主应用程序分开运行的“视频帧消耗线程”。这是正确的想法，还是我在某个地方错了？

Answer 1

假设大多数 IP 摄像机都支持 RTP。我会使用 Live555 之类的库来接收您相机的 H.264 流。然后我会轻轻解析 H.264 流以识别流中的帧类型和帧边界。我会缓冲一组帧 (GOP) - 从 I 帧开始。一旦你得到下一个 I 帧 - 首先清除你的缓冲区。 如果您收到样本请求 - 将您的 H.264 缓冲区发送到 H.264 解码器，然后将来自解码器的最后一帧作为样本请求发送到视频库。 我可能会在一个线程上运行 RTP 接收器和缓冲区生产者，而在另一个线程上运行库请求接收器。您必须对缓冲区进行某种锁定。解码过程中不能清除缓冲区。