在NALU之后，如果不在附件B字节流中，是否允许额外的空字节？

Question

我们有一个设备，可以创建包含H.264视频数据的MP4文件格式的视频文件。

现在我们注意到，在第一个AVCC块中，在SPS之后有4个空字节(00000000)。(我知道在视频数据中，SPS在技术上是不需要的，但也不是不允许的)在stsd头中，在AVCConfigurationBox中，我们也看到这些额外的空字节。

问题是:这些标准在技术上是允许的吗？我们有一些python代码来检查这个，然后抱怨。那么，我们需要更改设备中的代码还是检查代码？

在附件B字节流中，它们是允许的，但我认为这里不允许。

他们不可能是NALU的一部分，或者他们应该被模仿-阻止到00 0 0 3 00 00。

ffmpeg和vlc一点也不抱怨，但它们可能会更加健壮，以便尽可能多地播放视频文件。

编辑

​

Answer 1

在将代码传递给ffmpeg库之前，由于一些不必要的遗留原因，代码的某些部分进行了64位对齐。

因此，空字节不属于那里，而且肯定不是SPS的一部分。

Answer 2

“我们有一个设备，可以创建包含H.264视频数据的MP4文件格式的视频文件。

两种可能性：

最不可能..。

(1) (1)那些空字节似乎是填充的，使所有32位对齐。通过这种方式，您可以以4字节块(使用一些readInt()命令或类似的)读取SPS。

如果您的长度为52个字节(0x34)，您将得到13个整数/块。

PS:字节也可以是零填充，直到NALU开始在新的行/行。

(例如:如果显示在传统的十六进制数据的“每一行16字节”视图中，则很明显)。

很有可能..。

(2) (2)这4个零字节是SPS的有效字节，因为NALU大小将它们封装在SPS数据中。这将回答您的问题："Are these technically allowed by the standard?" as 是，因为它们是实际SPS数据本身的一部分。您在不知情的情况下用“在stsd标头中，在AVCConfigurationBox__中，”确认了这一点，我们也看到了这些额外的空字节。

..。

“在附件B字节流中，它们是允许的，但我认为这里不允许。”

注意：SPS被称为Codec专用数据，可以存储为附件B或AVCC格式，而不管MP4本身的格式如何(例如:它们可以混合在一些MP4文件中)。

..。

“我们有一些Python检查并抱怨，那么我们需要更改设备中的代码还是检查代码呢？”

我会保留MP4字节的原样(从设备？)把检查边修好。例如，，它实际上对有什么抱怨？如果大小为52个字节，则必须将52个字节作为SPS内容读取。然后，它可以通过跳过+4个字节来确认一个新的NALU (跳过“长度大小”字节，并检查它是否具有用于SEI的0x06、用于关键帧的0x65或用于P/B帧的0x41。

在您的图像中:看起来您有52字节的SPS，然后是4字节的PPS，然后是36字节的SEI。