H264 ENCODER RTL V2.0发现bug，应该是编码器IP的bug，原因如下：

[btlmx]

H264 ENCODER RTL V2.0发现bug，应该是编码器IP的bug，原因如下：

（1）验证了416x240，用JM86解码，解码出来的yuv数据跟IP自带的C model编码出来的重构数据一致，认为C model没有问题，并未验证其他格式的视频；

      验证了RTL仿真出来的码流加上SPS、PPS、Slice Head后，也就是构成NAL数据包后，跟C model编码出来的.264文件一致；

     上板验证了RTL编码出来的码流加上SPS、PPS、Slice Head后，也就是构成NAL数据包后，跟C model编码出来的.264文件一致；

（2）后面 验证了1080P RTL仿真出来的码流加上SPS、PPS、Slice Head后，也就是构成NAL数据包后，跟C model编码出来的.264文件一致，并可以被Elecard StreamEye Tool（H.264播放与分析工具）播放及识别；SPS、PPS、Slice Head都能正确识别。

     但未注意到被编码流播放的码流（也就是解码后）的实际尺寸是1920x1106及SPS参数里面的图像高度参数是70[1136]而不是67[1088]；

     后面用解码器IP不能解码编码器编码的1080P才注 意到这个问题；后面用JM86解码后发现跟  Elecard StreamEye Tool播放的图像一致（1920x1106），而不是 （1920x1080）。后面试了720P的，640x360的都是同样的问题，可以播放，但是视频的尺寸不对。

[johu]

@btlmx 我根据“h264-demo-pynq”里面的H264.py写了个sdk程序，发出来的udp增加了SPS、PPS、Slice Head，但是vlc播放不了，还想给您请教请教^.^

[johu]

图片传不上来，我从uart打印了包头。请您看看，这是udp里面的数据头部，每4个字节一组。

1..2..3..4..00650621 cnt:187 :0xF8E223600x0080F838
SPS: 80E0FC8F_00914B50_00000000_6742C028_9A7403C0_113F2C20_00000300_20000006_51E30654_
PPS: 80E0FC90_00914B50_00000000_68CE0489_C8000000_
padding + BS[0..3] 8060FC91_00914B50_00000000_1C888020_01000000_
m: 0 + BS[x..x] 8060FC92_00914B50_00000000_1C088020_01000000_
last + BS[0..3] 80E0FE74_00914B50_00000000_1C488020_01000000_