想知道是否有人对h.264字节码流有任何见解：
ffmpeg命令行是：
fmpeg\" -s 320x240 -f avfoundation -r 30.00 -i \"0:none\" -c:v libx264 -preset ultrafast -tune zerolatency -x264opts crf=20:vbv-maxrate=3000:vbv-bufsize=100:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1 -b:v 1000 -an -f mpegts -threads 8 -profile:v baseline -level 3.0 -pix_fmt yuv420p udp://127.0.0.1:5564"
理论上，h.264中的基本流应该是这样的：（ view image ）
http://artsmesh.io/file/bde333e59dca5b1861afb09faa9a7b792cf38ece6676392495cd02944452bbbc.jpg
因此关键是从H.264流生成单独的NALU。所以我们应该得到这样的比特流：（ view image ）。 http://artsmesh.io/file/ce09393a8f2fb0074864aa7ae8df9e04b1c24c704859deb889e85fe3e313d573.png
我们需要获得真实的NALU类型：0x1F＆amp; NALU类型。因此0x27等于0x67。
通常情况下，我们应该只有这些NALU类型（在0x1F＆amp; NALU类型的操作之后）：
1：非IDR图片的切片。 （P帧）
5：IDR图片的切片。 （我的框架）
6：补充增强信息。 （SEI）
7：序列参数集。 （SPS参数）
8：图片参数集。 （PPS参数）“，
9：访问单元分隔符。
但是我从udp获得的内容与第一个UDP数据包相似： http://artsmesh.io/file/92680df9bbdfdc2beb0c67b43e04f0520ef54351c709ef1fce5e5a74cff20a88.jpg
在这个UDP数据报中，有些东西没有意义，在0x00000001起始码头后，NALU类型为0xff，第二个为0xf0，两者都有在h.264中未定义。
所以我很难找到h.264流无法正常工作的原因。
在相同的UDP数据包（或相同的流媒体会话）中，起始码头始终是四个字节0x0000 0001还是三个字节0x000001，这是真的吗？
答案 0 :(得分：2)
这不是原始h.264流。这是一个传输流。一些0x000001来自PES头，而不是AVC有效载荷的一部分。 https://en.wikipedia.org/wiki/MPEG_transport_stream
此外，3个和4个字节的起始码可以在同一个ES中混合使用。原因在我的回答Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream
中有所说明
