我正在从树莓派上的相机读取H.264流。我正在尝试通过websockets将其传递给Broadway以在网页中呈现。
该流包含NAL单元，我在[0,0,0,1]起始前缀代码上将其分块，以分别发送和解码NAL单元。我认为效果很好，但Broadway无法解码最终得到的结果。
但是，进入the parsing code I've based this on，似乎期望第5个字节（紧跟在起始前缀代码之后）是：
0x65-I帧
0x41-P帧
0x67-SPS帧
0x68-PPS帧
我在其他地方也看到过很多提及。我遇到的所有单元似乎都以（按顺序）开头：
0x27 0x64（第一个单元）
0x28 0xEE（第二单元）
0x25 0x88（第三个单元，然后间歇地打开）
0x21 0x9A（流中的每个其他单元）
这些标头在H.264流中是什么意思？他们对我需要做些什么以符合百老汇的期望提出建议吗？
（如果完整的代码有助于更好地理解这一点，请参见https://github.com/pimterry/pi-cam/tree/d801de9b）
最佳答案
这是一条红鲱鱼：对我来说，这里的实际问题是，一些现有的丢帧逻辑意味着我没有在流中的前几帧中通过百老汇，并且它无法渲染。重新播放所有新连接的SPS和PPS框架并确保它们从未被丢弃，这很好地解决了此问题。
我也弄清楚了这些字节是什么，这有所帮助，并且可能对其他人有用以供参考：
Hex Binary NAL type Meaning
0x65 = 11 00101 = type 5 Coded slice of an IDR picture (I-frame)
0x41 = 10 00001 = type 1 Coded slice of a non-IDR picture (P-frame)
0x27 = 01 00111 = type 7 Sequence parameter set (B-frame)
0x28 = 01 01000 = type 8 Picture parameter set (B-frame)
0x25 = 01 00101 = type 5 Coded slice of an IDR picture (B-frame)
0x21 = 01 00001 = type 1 Coded slice of a non-IDR picture (B-frame)
尤其要感谢Jaromanda X-NAL单元文章[here]和nal_ref_idc文章使解决这一问题变得更加容易。
关于javascript - H.264解码无法解析异常帧头，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43507254/