在那个时候我只是个主意而希望成为圣人的时候。
我目前正在尝试解码和使用IP摄像机的专有视频流，我觉得自己已经很接近了，但是我找不到谜题的最后一部分。相机设置为1 FPS，CBR和I帧间隔1，以实现最大一致性。
我当前所做的操作概述：缓冲数据包，查找相机专有协议的标头（35字节），查找另一个/下一个，将两者之间的所有内容刷新到一个文件中（为了方便起见，这是称为“段”），冲洗，然后重复。
如果将流设置为非常低的质量，即352 * 288且具有非常低的比特率，则可以在MPC中完全打开并播放生成的文件（或者将其转换为FFMPEG，然后在VLC中播放）。
但是问题来了：通过不断提高视频质量，在某一点之后，视频开始损坏。发生这种情况时，也开始发生一件事：找到的最大“段”的上限为8183字节（我发现非常小的大小，非常接近2 ^ 13）。因此，我决定研究一下遇到8176节时实际写入的内容，而且我发现的内容似乎也确实很特殊-许多几乎匹配的字节！ （这些字节仅用于帧的 first 8176段）
示例1：
0000 0001 4001 0c01 ffff 0160 0000 0300 b000 0003 0000 0300 3cac 0900 0000 0142 0101 0160 0000 0300 b000 0003 0000 0300 3ca0 0b08 0485 8dae 4932 fcdc 0404 0402 0000 0001 4401 c0f2 f03c 9000 0000 014e 01e5 04cc cc00 0080 0000 0001 2601 af1b 686f 315f 8bcd 7007
示例2（几秒钟后）：
0000 0001 4001 0c01 ffff 0160 0000 0300 b000 0003 0000 0300 3cac 0900 0000 0142 0101 0160 0000 0300 b000 0003 0000 0300 3ca0 0b08 0485 8dae 4932 fcdc 0404 0402 0000 0001 4401 c0f2 f03c 9000 0000 014e 01e5 049b 9b00 0080 0000 0001 2601 af17 68c3 3d14 cf63 2cab
如您所见，直到8000 0000 0126 01af为止，它们似乎都是/ by ..某种形式的标题。 编辑：似乎此部分包含随后下一帧的VPS / SPS / PPS。
解复用器似乎几乎没有冒犯的想法，即当前帧比初始8176字节段有更多数据，请看一帧由一帧8176和一个〜2000字节段组成的质量设置在较高的三分之二上很好，并且仅在较低的一端开始损坏。随着我增加流的比特率，这种“腐败点”的作用越来越高。
您为什么不使用适当的相机？！
这台相机真的很好。
然后只使用其正常的RTSP流？
关于为什么我甚至开始执行此操作的问题-当此专有协议在TCP上运行时，它仅支持UDP上的RTSP，并且如果有数据包丢失（存在），RTSP流将开始损坏，我公务员试图没有发生。
希望这里有人可以帮助我。如果您需要样本文件或其他任何文件，我很乐意为有兴趣尝试帮助我的任何人提供它们。
谢谢！
编辑：好像我可能在做某事。我刚刚下载了Zond 265的试用版（HEVC分析器），并且在其中打开生成的文件时，每一帧均出现错误，并且“发现未预期的剩余X字节”以及“ end_of_subset_one_bit应等于1” ”。因此，如果我只剩下那些剩余的位并删除它前面的那个位，那么这些错误都会消失！ （出现了一个新错误，请对CTU #x进行解码：异常）图像显然仍然被破坏，因为现在缺少信息，但至少可以解决该问题。仍然不知道下一步将是什么。
答案 0 :(得分：1)
所以我设法解决了我的问题，这就是我所做的。我在一些狡猾的网站上找到了DVR软件，该软件确实支持相同的协议，并且可以通过它访问摄像机。然后，我记录了流，同时记录了流和软件的流，并绑定了两个结果，这才使我获得了最终的点击。原来，我从标头中切出了几个字节（切成视频流数据）太多了，但并非总是如此。有时（并且在第一帧）响应头似乎比大多数时间长8个字节，这由以00 00 01 FC开头的视频流指示。因此，通过将我一直切下来的这8个字节添加到流中，或者在这种情况下将其剪切掉，我得到的视频流不会损坏：）