首先，请原谅我对这一领域的完全了解。前段时间，我有几本非常便宜的wifi ip摄像机，希望在我的本地网络上使用。不幸的是，事实证明，制造商（zmodo）大约在一年前推出了他们自己的流协议，并取消了先前型号中存在的rtsp端口。制造商提供的应用程序仅基于云，这让我感到不安。幸运的是，人们一直在尝试解决此问题的方法，并且在使用较旧的模型方面相当成功。所以我试图看看自己能做什么。
从本质上讲，摄像机在端口8000上侦听12字节长的命令。这些命令之一触发数据流。数据看起来有点像以00dc或01dc开头的AVI块序列。就像在AVI中一样，这些标签后面紧跟一个4字节的大小（我们称其为S）和24个字节，它们看起来像一个时间戳（但也可能包含更多信息）。 00dc或01dc标签之间的总字节数比S正好多32个字节。因此，我们有类似的内容
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... S bytes of data that seems encrypted...
30 31 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 00 00 00 01 61 .... S - 5 bytes of data...
第二种类型的块（以01dc为前缀）似乎包含未加密的B帧或P帧NAL单元（如果我的基本理解是正确的话），但是我的问题是关于第一种类型的。第一种类型可能包含I帧，但是我找不到NAL分隔符或类型字节。此外，实际数据的S字节的前32个字节对于每个单元都是相同的，即我有
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 32 constant bytes ... S-32 bytes of data
相机还提供了一个128位密钥，我自然假定该密钥用于流加密（尽管它可以用于云身份验证或TLS或谁知道）。所以我的问题是，根据您的经验，最接近哪个（加密）h.264版本？知道32个常量字节是什么吗？
编辑：我不确定关键帧是否已加密，我只是在推测。实际上，它们似乎在末尾包含大面积的恒定字节（尽管字节从一个单位更改为另一个单位，即e4 e4 .... e4变为一个单位，然后93 93 .... 93，这排除了我认为的AES）< / p>