[EXT] Re: [PATCH v12 00/13] amphion video decoder/encoder driver

Ming Qian ming.qian at nxp.com
Thu Nov 25 22:31:56 PST 2021


> -----Original Message-----
> From: Nicolas Dufresne [mailto:nicolas at ndufresne.ca]
> Sent: Thursday, November 25, 2021 11:36 PM
> To: Ming Qian <ming.qian at nxp.com>; mchehab at kernel.org;
> shawnguo at kernel.org; robh+dt at kernel.org; s.hauer at pengutronix.de
> Cc: hverkuil-cisco at xs4all.nl; kernel at pengutronix.de; festevam at gmail.com;
> dl-linux-imx <linux-imx at nxp.com>; Aisheng Dong <aisheng.dong at nxp.com>;
> linux-media at vger.kernel.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v12 00/13] amphion video decoder/encoder
> driver
> 
> Caution: EXT Email
> 
> Le jeudi 25 novembre 2021 à 05:25 +0000, Ming Qian a écrit :
> > For test [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0)
> > VPSSPSPPS_A_MainConcept_1, The vpu report an unsupported message to
> driver, so driver report pollerr to gstreamer.
> > But this stream can be decoded using the amphion vpu when I test it
> > using our unit test, I checked the difference, there are many vps, sps
> > and pps at the beginning, gstreamer will skip the first vpu and two
> > pps, totally skip 56 bytes. It leds to vpu can't decode And our unit test won't
> skip anthing, so the vpu can decode the stream.
> 
> This specific test triggers a bug in GStreamer HEVC parser, I'm aware of this
> one, and it is on my todo to fix (just not as trivial as it looks like, the VCL nal
> detection code was implemented wrong and that ended up leaking into the
> rest of the design). This specific test will of course be marked and skipped for CI
> test that uses GStreamer.
> 
> regards,
> Nicolas

Hi Nicolas,

    For the h264 decoder test, If I test with our unit test tool, the result is 124/135 tests successfully,
But only 75/135 tests successfully when test using gstreamer.
    There are 49 tests with different results, and all of the 49 test streams are interlaced stream.
The amphion vpu will output the interlaced frame directly, it won't merge the interlaced two parts into one progressive frame.
     And the gstreamer tiled unpack function(unpack_NV12_TILED) won't handle the interlaced case, so the output frame is abnormal, and led to test fail.
     I think it should be a hardware limitation of the amphion vpu. And maybe the gstreamer videoconvert can handle it.
The interlaced list is as below:
[JVT-AVC_V1] cabac_mot_fld0_full
[JVT-AVC_V1] cabac_mot_mbaff0_full
[JVT-AVC_V1] cabac_mot_picaff0_full
[JVT-AVC_V1] CABREF3_Sand_D
[JVT-AVC_V1] CAFI1_SVA_C
[JVT-AVC_V1] CAMA1_Sony_C
[JVT-AVC_V1] CAMA1_TOSHIBA_B
[JVT-AVC_V1] CAMA3_Sand_E
[JVT-AVC_V1] CAMACI3_Sony_C
[JVT-AVC_V1] CAMANL1_TOSHIBA_B
[JVT-AVC_V1] CAMANL2_TOSHIBA_B
[JVT-AVC_V1] CAMANL3_Sand_E
[JVT-AVC_V1] CAMASL3_Sony_B
[JVT-AVC_V1] CAMP_MOT_MBAFF_L30
[JVT-AVC_V1] CAMP_MOT_MBAFF_L31
[JVT-AVC_V1] CANLMA2_Sony_C
[JVT-AVC_V1] CANLMA3_Sony_C
[JVT-AVC_V1] CAPA1_TOSHIBA_B
[JVT-AVC_V1] CAPAMA3_Sand_F
[JVT-AVC_V1] cavlc_mot_fld0_full_B
[JVT-AVC_V1] cavlc_mot_mbaff0_full_B
[JVT-AVC_V1] cavlc_mot_picaff0_full_B
[JVT-AVC_V1] CVCANLMA2_Sony_C
[JVT-AVC_V1] CVFI1_Sony_D
[JVT-AVC_V1] CVFI1_SVA_C
[JVT-AVC_V1] CVFI2_Sony_H
[JVT-AVC_V1] CVFI2_SVA_C
[JVT-AVC_V1] CVMA1_Sony_D
[JVT-AVC_V1] CVMA1_TOSHIBA_B
[JVT-AVC_V1] CVMANL1_TOSHIBA_B
[JVT-AVC_V1] CVMANL2_TOSHIBA_B
[JVT-AVC_V1] CVMAPAQP3_Sony_E
[JVT-AVC_V1] CVMAQP2_Sony_G
[JVT-AVC_V1] CVMAQP3_Sony_D
[JVT-AVC_V1] CVMP_MOT_FLD_L30_B
[JVT-AVC_V1] CVMP_MOT_FRM_L31_B
[JVT-AVC_V1] CVNLFI1_Sony_C
[JVT-AVC_V1] CVNLFI2_Sony_H
[JVT-AVC_V1] CVPA1_TOSHIBA_B
[JVT-AVC_V1] FI1_Sony_E
[JVT-AVC_V1] MR6_BT_B
[JVT-AVC_V1] MR7_BT_B
[JVT-AVC_V1] MR8_BT_B
[JVT-AVC_V1] MR9_BT_B
[JVT-AVC_V1] Sharp_MP_Field_1_B
[JVT-AVC_V1] Sharp_MP_Field_2_B
[JVT-AVC_V1] Sharp_MP_Field_3_B
[JVT-AVC_V1] Sharp_MP_PAFF_1r2
[JVT-AVC_V1] Sharp_MP_PAFF_2r



More information about the linux-arm-kernel mailing list