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帧开始.一旦你得到下一个我帧-首先清除你的缓冲区。如果您收到一个示例请求--将您的H.264缓冲区发送到H.264解码器，然后将来自解码器的最后一个帧作为示例请求发送到视频库。我可能会在一个线程上运行RTP接收器和缓冲区生成器，在另一个线程上运行库请求接收器。您必须对缓冲区执行某种锁定。在解码过程中，无法清除缓冲区。