Parsing 解码专有HEVC/MP4流

有一次，我失去了主意，希望有一个圣人

我目前正在尝试解码和使用一个IP摄像机的专有视频流，我觉得我非常接近，但我就是找不到最后一块拼图。摄像机设置为1 FPS、CBR和1的I帧间隔以获得最大一致性

概述我目前所做的工作：缓冲数据包，查找摄像头专用协议的标题（35字节），查找另一个/下一个，将中间的所有内容刷新到一个文件中（为了便于发布，这被称为“段”），漂洗，重复

如果我将流设置为非常低的质量，即352*288，具有非常低的比特率，我可以在MPC中打开并播放生成的文件，效果非常好（或者使用FFMPEG将其转换，然后在VLC中播放）

但问题来了：随着视频质量越来越高，在某一点之后，视频开始被破坏。当这种情况发生时，有一件事也开始发生：找到的最大“段”被限制在8183字节（我发现这是一个非常特殊的大小，因为它非常接近2^13）。因此，我决定研究在遇到8176节时实际写入的内容，我发现的内容也确实非常奇特——许多几乎匹配的字节！（这些字节仅为帧的前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（几秒钟后）：

如您所见，在

8000 0000 0126 01af

之前，它们似乎是/by.的某种类型的标题。。什么编辑：此部分似乎包含以下帧的VPS/SPS/PPS

似乎解复用器根本不知道当前帧的数据量比初始8176字节段的数据量多，看看在一个质量设置下，一帧由一个8176字节和一个~2000字节段组成，视频在上三分之二是好的，只在下三分之二开始损坏。当我增加流的比特率时，ofc的“腐败点”会越来越高

你为什么不用合适的照相机

这架照相机实际上很好

那就使用正常的RTSP流吧

还有一个问题是为什么我开始这么做——它只支持UDP上的RTSP，而这个专用协议在TCP上运行，如果有包丢失（存在），RTSP流将开始损坏，我正在努力避免这种情况发生

希望这里有人能帮助我。如果你需要样本文件或任何东西，我很乐意为任何有兴趣尝试帮助我的灵魂提供它们

谢谢

---

编辑：似乎我有什么想法。我刚刚下载了Zond 265（一个HEVC分析器）的试用版，当在其中打开生成的文件时，每一帧都会出现错误，包括“找到了意外的剩余X字节”以及“子集的结束位置一位应等于1”。因此，如果我只取剩余的位，并删除前面的位，那么这两个错误都会消失！（一个新的出现，解码CTU#x：例外）图像显然仍然损坏，因为现在缺少信息，但至少需要解决一些问题。还是不知道下一步该怎么做。

所以我设法解决了我的问题，下面是我所做的。我在一些狡猾的网站上发现了一个DVR软件，它确实支持同样的协议，并设法通过它访问了摄像机。然后我通过它和我的软件记录了这条流，并对两个结果进行了绑定，这就是我最后的点击。事实证明，我从标题中切掉了太多的几个字节（几乎切掉了视频流数据），但并不总是这样。偶尔（在第一帧上），响应头似乎比大多数时间长8字节，这由从00 01 FC开始的视频流表示。因此，通过将我一直切掉的这8个字节添加到流中，或者在这种情况下将它们切掉，我得到了一个未损坏的视频流：）

如果你提供给我一个比特流，我可以仔细查看：-）我实际上已经设法解决了这个问题，但还没有抽出时间更新我的问题，非常感谢！太好了，很高兴你解决了！如果你需要更多与视频相关的帮助，请点击我

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