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



  • 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的都是同样的问题,可以播放,但是视频的尺寸不对。


  • @btlmx 我根据“h264-demo-pynq”里面的H264.py写了个sdk程序,发出来的udp增加了SPS、PPS、Slice Head,但是vlc播放不了,还想给您请教请教^.^![0_1603042600941_udp.jpg](Uploading 100%)



  • 图片传不上来,我从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_