CAVLC测试

        第一种方法,将设计植入FPGA,FPGA被置于一块验证板上,其输入是由码流发生仪产生的H.264码流,通过FPGA里面的处理,将输出显示于可视设备上从而观察解码的正确性。这种方法的优点在于其与硬件有着极大的关联性,由于设计本身已经被植入硬件,因此可以在很大程度上说明硬件上的一些现象,并且输出的图像给测试者很直观的感觉;同时,本方法也有很多缺点,首先,对于以ASIC为最终目标的设计来说,在FPGA上的验证并不能够说明问题,因为ASIC对时序的要求会更加的严格,其次,本文中只给出了parsing过程的设计与实现,在其它模块缺失的情况下,系统是不可能进行完全的解码的,也就是说,这种验证受到所有模块的制约,只有在所有模块都实现的基础上,才能开始对所有模块进行验证,最后,也是最大的一个缺点,就是这种平台的搭建根本不适合于调试,在含有数百个语法元素的parsing解析过程中,任何一个语法元素的解析出现了错误,后面的所有解析都会完全错误,但是在上述的平台下,我们所能看到的,只是最后的显示结果不对,但是到底问题出在什么地方?到底是什么问题?我们并不知道。于是我们采用了相对简便的第二种方法,用程序读入测试向量(而非用码流仪产生),然后用仿真工具进行功能和时序仿真,仿真仅仅对parsing过程进行,然后对输出结果进行证。

        在图4-1中,原始的YUV文件先被JM的编码器编码为标准的264压缩流,然后再被解码器解码成可显示的YUV,同时,考虑到参考的完整性,解码器会将parsing过程的输出写入一个Trace file内,这个文件正是我们所需要的,只要将压缩流流过我们的设计,然后将输出同Trace file做比较,就可以知道我们的设计是否正确。在前面说过,为了增加覆盖率,我们需要不只一个码流,实际上,由于H.264的复杂性,我们可能需要很多不同类型的码流才能达到完全覆盖,而产生这些许多不同类型的码流,我们可以利用JM提供的功能改变其编码的方式。在JM的编码器中,会调用一个名为encode.cfg的配置文件作为其编码的参数,将配置文件内的数据读入作为一些指标,而encode.cfg里的各行则是这些指标的具体化,比如说,我们可以通过改变ProfileIDC来改变其编码的级别,可以选择baseline,也可以选择main或extended。

阅读更多
个人分类: h.264
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭