Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Hi Adam,
> >
> > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > you have further question feel free to ask.
> >
> > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > how the Mini handles the power domains, the VPU driver does not need to
> > > handle all the functions, so a new compatible flag is required.
> > >
> > > This is an RFC because I don't have functional video on my system yet,
> > > and I'm hoping there might be people who do and can help test this.
> > > I have only tested this far enough to see they enumerate and appear
> > > as /dev/videoX and /dev/mediaX devices.
> >
> > I will check the patchset, but you need in the mini-variant to disable the G1
> > post processor, because this block was fused out. We didn't make it optional
>
> Thanks for being willing to review this.
>
> > from the start as according to the V1 of the TRM it was there, but that error
> > was corrected in V3.
>
> Thanks for the clarification. It wasn't obvious to me, because in
> some instances the PP looked like it was there and sometimes not
> there. I'll remove the postproc stuff.
>
> >
> > >
> > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > would be more generic plugins that I can use to test. I am hoping some
> > > of the linux-media experts might chime in on how to best test.
> >
> > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > binding of udev).
>
> Thanks for the tip.
>
> >
> > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > debugging as the G1 version is slightly newer on NXP SoC.
>
> For what it's worth the G1 seems to repond cleanly to the inquiries
> from v42-compliance.
> The G2 throws some splat when I run v4l2-compliance, but I am still
> investigating that.
>
> [ 405.456979] ------------[ cut here ]------------
> [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> __alloc_pages+0x5a4/0xbe0
> [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> imx_cpufreq_dt ecc rfkill fuse drm ipv6
> [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> Development Kit (DT)
> [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> [ 405.570917] sp : ffff800012443810
> [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> [ 405.645666] Call trace:
> [ 405.648113] __alloc_pages+0x5a4/0xbe0
> [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> [ 405.656569] dma_direct_alloc+0x70/0x310
> [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> [ 405.718502] invoke_syscall+0x48/0x114
> [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> [ 405.726969] do_el0_svc+0x2c/0x94
> [ 405.730286] el0_svc+0x28/0x80
> [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> [ 405.741287] ---[ end trace 270ed4a899803006 ]---
>
> The H1 encoder seems to hang the system when I run v4l2-compliance on
> it when H1 is set up as I submitted the patch. I tried dropping all
> the encoder formats except the JPEG format, and it doesn't hang any
> more, but it also doesn't really do anything.
> The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> am not sure JPEG is even supported.
If JPEG is not supported, then there is nothing left for mainline in this
regard. The kernel control interface and encoding flow needs to be designed and
specified for encoders like VP8 and H264. Some prototypes and prior-art exist
though, but nothing ever got formalized in the form of a specification.
>
> The log from v4l2-compliance on the H1 with everything except the JPEG
> removed looks like:
>
> root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> v4l2-compliance SHA: not available
> , 64 bits, 64-bit time_t
>
> Segmentation fault
> root@beacon-imx8mm-kit:~#
> Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> : Internal error: Oops: 96000004 [#2] SMP
>
> Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
>
> I want to install Gstreamer, but I don't have functioning DSI video,
> so I am not entirely sure how I will go about testing the decoders
> except by using fakesink
We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
decoders we use fluster, a tool that runs publicly available conformance test.
It will simply decode to disk and compare a checksum of the decoded image
against the compliant checksum (produced by the reference decoders). For you
interested, it uses the new videocodectestsink, which is specialized for
producing or calculating conformance image/checksum.
https://github.com/fluendo/fluster
We have added support for GStreamer stateless decoders already.
>
> If the G1 ends up working with some of the newer Gstreamer stuff, I
> might just submit a formal patch to just enable the G1 for now.
This looks like a good idea indeed.
>
> adam
> >
> > >
> > > Lastly, I didn't update any device tree binding YAML files, because
> > > I know there have been some discussions about the power domains on the
> > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > or if the existing one for te imx8mq should just be modified.
> > >
> > > This will likely require the following series in order to apply correctly:
> > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > >
> > > Adam Ford (5):
> > > media: hantro: Add support for i.MX8M Mini
> > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > >
> > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > >
> >
On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
>
> Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Hi Adam,
> > >
> > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > you have further question feel free to ask.
> > >
> > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > handle all the functions, so a new compatible flag is required.
> > > >
> > > > This is an RFC because I don't have functional video on my system yet,
> > > > and I'm hoping there might be people who do and can help test this.
> > > > I have only tested this far enough to see they enumerate and appear
> > > > as /dev/videoX and /dev/mediaX devices.
> > >
> > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > post processor, because this block was fused out. We didn't make it optional
> >
> > Thanks for being willing to review this.
> >
> > > from the start as according to the V1 of the TRM it was there, but that error
> > > was corrected in V3.
> >
> > Thanks for the clarification. It wasn't obvious to me, because in
> > some instances the PP looked like it was there and sometimes not
> > there. I'll remove the postproc stuff.
> >
> > >
> > > >
> > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > would be more generic plugins that I can use to test. I am hoping some
> > > > of the linux-media experts might chime in on how to best test.
> > >
> > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > binding of udev).
> >
> > Thanks for the tip.
> >
> > >
> > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > debugging as the G1 version is slightly newer on NXP SoC.
> >
> > For what it's worth the G1 seems to repond cleanly to the inquiries
> > from v42-compliance.
> > The G2 throws some splat when I run v4l2-compliance, but I am still
> > investigating that.
> >
> > [ 405.456979] ------------[ cut here ]------------
> > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > __alloc_pages+0x5a4/0xbe0
> > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > Development Kit (DT)
> > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > [ 405.570917] sp : ffff800012443810
> > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > [ 405.645666] Call trace:
> > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > [ 405.656569] dma_direct_alloc+0x70/0x310
> > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > [ 405.718502] invoke_syscall+0x48/0x114
> > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > [ 405.726969] do_el0_svc+0x2c/0x94
> > [ 405.730286] el0_svc+0x28/0x80
> > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> >
> > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > it when H1 is set up as I submitted the patch. I tried dropping all
> > the encoder formats except the JPEG format, and it doesn't hang any
> > more, but it also doesn't really do anything.
> > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > am not sure JPEG is even supported.
>
> If JPEG is not supported, then there is nothing left for mainline in this
> regard. The kernel control interface and encoding flow needs to be designed and
> specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> though, but nothing ever got formalized in the form of a specification.
>
> >
> > The log from v4l2-compliance on the H1 with everything except the JPEG
> > removed looks like:
> >
> > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > v4l2-compliance SHA: not available
> > , 64 bits, 64-bit time_t
> >
> > Segmentation fault
> > root@beacon-imx8mm-kit:~#
> > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > : Internal error: Oops: 96000004 [#2] SMP
> >
> > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> >
> > I want to install Gstreamer, but I don't have functioning DSI video,
> > so I am not entirely sure how I will go about testing the decoders
> > except by using fakesink
>
> We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> decoders we use fluster, a tool that runs publicly available conformance test.
> It will simply decode to disk and compare a checksum of the decoded image
> against the compliant checksum (produced by the reference decoders). For you
> interested, it uses the new videocodectestsink, which is specialized for
> producing or calculating conformance image/checksum.
>
> https://github.com/fluendo/fluster
>
> We have added support for GStreamer stateless decoders already.
>
> >
> > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > might just submit a formal patch to just enable the G1 for now.
>
> This looks like a good idea indeed.
>
> >
> > adam
> > >
> > > >
> > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > I know there have been some discussions about the power domains on the
> > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > or if the existing one for te imx8mq should just be modified.
> > > >
> > > > This will likely require the following series in order to apply correctly:
> > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > >
> > > > Adam Ford (5):
> > > > media: hantro: Add support for i.MX8M Mini
> > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > >
> > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > >
> > >
>
Nicolas and Adam,
For the H1 patches in this series: I've been able to test the IMX8MM
H1 JPEG encode using GStreamer 1.18.5:
$ gst-inspect-1.0 | grep -e "v4l2.*enc"
video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
$ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
host=192.168.1.146 port=5000
viewed on [email protected] via:
$ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
rtpjpegdepay ! jpegdec ! autovideosink
For the G1/G2 patches in the series I don't see any Gstreamer
'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
I have CSI capture and DSI display currently working on
imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
can't efficiently convert to something the JPEG encoder likes without
bayer2rgbneon (a libneon version).
I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
wide range of data formats but I'm not sure how to tap into this as
that hardware is managed by the vivante driver. On the IMX6QDL there
is a separate IPU block that Philipp Zabel wrote a nice mem2mem
csc/scaler driver for but I don't see any equivalent currently for
IMX8MM.
Best regards,
Tim
Le mardi 16 novembre 2021 à 15:23 -0800, Tim Harvey a écrit :
> On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > > you have further question feel free to ask.
> > > >
> > > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > > handle all the functions, so a new compatible flag is required.
> > > > >
> > > > > This is an RFC because I don't have functional video on my system yet,
> > > > > and I'm hoping there might be people who do and can help test this.
> > > > > I have only tested this far enough to see they enumerate and appear
> > > > > as /dev/videoX and /dev/mediaX devices.
> > > >
> > > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > > post processor, because this block was fused out. We didn't make it optional
> > >
> > > Thanks for being willing to review this.
> > >
> > > > from the start as according to the V1 of the TRM it was there, but that error
> > > > was corrected in V3.
> > >
> > > Thanks for the clarification. It wasn't obvious to me, because in
> > > some instances the PP looked like it was there and sometimes not
> > > there. I'll remove the postproc stuff.
> > >
> > > >
> > > > >
> > > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > > would be more generic plugins that I can use to test. I am hoping some
> > > > > of the linux-media experts might chime in on how to best test.
> > > >
> > > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > > binding of udev).
> > >
> > > Thanks for the tip.
> > >
> > > >
> > > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > > debugging as the G1 version is slightly newer on NXP SoC.
> > >
> > > For what it's worth the G1 seems to repond cleanly to the inquiries
> > > from v42-compliance.
> > > The G2 throws some splat when I run v4l2-compliance, but I am still
> > > investigating that.
> > >
> > > [ 405.456979] ------------[ cut here ]------------
> > > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > > __alloc_pages+0x5a4/0xbe0
> > > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > > Development Kit (DT)
> > > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > > [ 405.570917] sp : ffff800012443810
> > > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > > [ 405.645666] Call trace:
> > > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > > [ 405.656569] dma_direct_alloc+0x70/0x310
> > > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > > [ 405.718502] invoke_syscall+0x48/0x114
> > > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > > [ 405.726969] do_el0_svc+0x2c/0x94
> > > [ 405.730286] el0_svc+0x28/0x80
> > > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> > >
> > > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > > it when H1 is set up as I submitted the patch. I tried dropping all
> > > the encoder formats except the JPEG format, and it doesn't hang any
> > > more, but it also doesn't really do anything.
> > > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > > am not sure JPEG is even supported.
> >
> > If JPEG is not supported, then there is nothing left for mainline in this
> > regard. The kernel control interface and encoding flow needs to be designed and
> > specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> > though, but nothing ever got formalized in the form of a specification.
> >
> > >
> > > The log from v4l2-compliance on the H1 with everything except the JPEG
> > > removed looks like:
> > >
> > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > v4l2-compliance SHA: not available
> > > , 64 bits, 64-bit time_t
> > >
> > > Segmentation fault
> > > root@beacon-imx8mm-kit:~#
> > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > : Internal error: Oops: 96000004 [#2] SMP
> > >
> > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> > >
> > > I want to install Gstreamer, but I don't have functioning DSI video,
> > > so I am not entirely sure how I will go about testing the decoders
> > > except by using fakesink
> >
> > We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> > decoders we use fluster, a tool that runs publicly available conformance test.
> > It will simply decode to disk and compare a checksum of the decoded image
> > against the compliant checksum (produced by the reference decoders). For you
> > interested, it uses the new videocodectestsink, which is specialized for
> > producing or calculating conformance image/checksum.
> >
> > https://github.com/fluendo/fluster
> >
> > We have added support for GStreamer stateless decoders already.
> >
> > >
> > > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > > might just submit a formal patch to just enable the G1 for now.
> >
> > This looks like a good idea indeed.
> >
> > >
> > > adam
> > > >
> > > > >
> > > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > > I know there have been some discussions about the power domains on the
> > > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > > or if the existing one for te imx8mq should just be modified.
> > > > >
> > > > > This will likely require the following series in order to apply correctly:
> > > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > > >
> > > > > Adam Ford (5):
> > > > > media: hantro: Add support for i.MX8M Mini
> > > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > > >
> > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > > >
> > > >
> >
>
> Nicolas and Adam,
>
> For the H1 patches in this series: I've been able to test the IMX8MM
> H1 JPEG encode using GStreamer 1.18.5:
> $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
^ v4l2jpegenc
This is just a transcript error ?
> host=192.168.1.146 port=5000
> viewed on [email protected] via:
> $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> rtpjpegdepay ! jpegdec ! autovideosink
>
> For the G1/G2 patches in the series I don't see any Gstreamer
> 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
a single repository. We are very close to 1.20, which will include stable API
support of H264, MPEG2 and VP8 decoding.
>
> I have CSI capture and DSI display currently working on
> imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> can't efficiently convert to something the JPEG encoder likes without
> bayer2rgbneon (a libneon version).
>
> I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> wide range of data formats but I'm not sure how to tap into this as
> that hardware is managed by the vivante driver. On the IMX6QDL there
> is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> csc/scaler driver for but I don't see any equivalent currently for
> IMX8MM.
>
> Best regards,
>
> Tim
On Thu, Nov 18, 2021 at 6:30 AM Nicolas Dufresne <[email protected]> wrote:
>
> Le mardi 16 novembre 2021 à 15:23 -0800, Tim Harvey a écrit :
> > On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > > > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > > > >
> > > > > Hi Adam,
> > > > >
> > > > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > > > you have further question feel free to ask.
> > > > >
> > > > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > > > handle all the functions, so a new compatible flag is required.
> > > > > >
> > > > > > This is an RFC because I don't have functional video on my system yet,
> > > > > > and I'm hoping there might be people who do and can help test this.
> > > > > > I have only tested this far enough to see they enumerate and appear
> > > > > > as /dev/videoX and /dev/mediaX devices.
> > > > >
> > > > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > > > post processor, because this block was fused out. We didn't make it optional
> > > >
> > > > Thanks for being willing to review this.
> > > >
> > > > > from the start as according to the V1 of the TRM it was there, but that error
> > > > > was corrected in V3.
> > > >
> > > > Thanks for the clarification. It wasn't obvious to me, because in
> > > > some instances the PP looked like it was there and sometimes not
> > > > there. I'll remove the postproc stuff.
> > > >
> > > > >
> > > > > >
> > > > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > > > would be more generic plugins that I can use to test. I am hoping some
> > > > > > of the linux-media experts might chime in on how to best test.
> > > > >
> > > > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > > > binding of udev).
> > > >
> > > > Thanks for the tip.
> > > >
> > > > >
> > > > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > > > debugging as the G1 version is slightly newer on NXP SoC.
> > > >
> > > > For what it's worth the G1 seems to repond cleanly to the inquiries
> > > > from v42-compliance.
> > > > The G2 throws some splat when I run v4l2-compliance, but I am still
> > > > investigating that.
> > > >
> > > > [ 405.456979] ------------[ cut here ]------------
> > > > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > > > __alloc_pages+0x5a4/0xbe0
> > > > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > > > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > > > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > > > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > > > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > > > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > > > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > > > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > > > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > > > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > > > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > > > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > > > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > > > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > > > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > > > Development Kit (DT)
> > > > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > > > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > > > [ 405.570917] sp : ffff800012443810
> > > > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > > > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > > > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > > > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > > > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > > > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > > > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > > > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > > > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > > > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > > > [ 405.645666] Call trace:
> > > > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > > > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > > > [ 405.656569] dma_direct_alloc+0x70/0x310
> > > > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > > > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > > > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > > > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > > > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > > > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > > > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > > > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > > > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > > > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > > > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > > > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > > > [ 405.718502] invoke_syscall+0x48/0x114
> > > > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > > > [ 405.726969] do_el0_svc+0x2c/0x94
> > > > [ 405.730286] el0_svc+0x28/0x80
> > > > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > > > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > > > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> > > >
> > > > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > > > it when H1 is set up as I submitted the patch. I tried dropping all
> > > > the encoder formats except the JPEG format, and it doesn't hang any
> > > > more, but it also doesn't really do anything.
> > > > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > > > am not sure JPEG is even supported.
> > >
> > > If JPEG is not supported, then there is nothing left for mainline in this
> > > regard. The kernel control interface and encoding flow needs to be designed and
> > > specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> > > though, but nothing ever got formalized in the form of a specification.
> > >
> > > >
> > > > The log from v4l2-compliance on the H1 with everything except the JPEG
> > > > removed looks like:
> > > >
> > > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > > v4l2-compliance SHA: not available
> > > > , 64 bits, 64-bit time_t
> > > >
> > > > Segmentation fault
> > > > root@beacon-imx8mm-kit:~#
> > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > : Internal error: Oops: 96000004 [#2] SMP
> > > >
> > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> > > >
> > > > I want to install Gstreamer, but I don't have functioning DSI video,
> > > > so I am not entirely sure how I will go about testing the decoders
> > > > except by using fakesink
> > >
> > > We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> > > decoders we use fluster, a tool that runs publicly available conformance test.
> > > It will simply decode to disk and compare a checksum of the decoded image
> > > against the compliant checksum (produced by the reference decoders). For you
> > > interested, it uses the new videocodectestsink, which is specialized for
> > > producing or calculating conformance image/checksum.
> > >
> > > https://github.com/fluendo/fluster
> > >
> > > We have added support for GStreamer stateless decoders already.
> > >
> > > >
> > > > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > > > might just submit a formal patch to just enable the G1 for now.
> > >
> > > This looks like a good idea indeed.
> > >
> > > >
> > > > adam
> > > > >
> > > > > >
> > > > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > > > I know there have been some discussions about the power domains on the
> > > > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > > > or if the existing one for te imx8mq should just be modified.
> > > > > >
> > > > > > This will likely require the following series in order to apply correctly:
> > > > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > > > >
> > > > > > Adam Ford (5):
> > > > > > media: hantro: Add support for i.MX8M Mini
> > > > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > > > >
> > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > > > >
> > > > >
> > >
> >
> > Nicolas and Adam,
> >
> > For the H1 patches in this series: I've been able to test the IMX8MM
> > H1 JPEG encode using GStreamer 1.18.5:
> > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> ^ v4l2jpegenc
>
> This is just a transcript error ?
Nicolas,
No! Thanks for catching my mistake. I was testing with software encode... ooops!
'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
the board so likely a power-domain issue there?
>
> > host=192.168.1.146 port=5000
> > viewed on [email protected] via:
> > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > rtpjpegdepay ! jpegdec ! autovideosink
> >
> > For the G1/G2 patches in the series I don't see any Gstreamer
> > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
>
> Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> a single repository. We are very close to 1.20, which will include stable API
> support of H264, MPEG2 and VP8 decoding.
>
Ok, let me see if I can navigate through the build process and I'll
get back to you.
Thanks,
Tim
> >
> > I have CSI capture and DSI display currently working on
> > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > can't efficiently convert to something the JPEG encoder likes without
> > bayer2rgbneon (a libneon version).
> >
> > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > wide range of data formats but I'm not sure how to tap into this as
> > that hardware is managed by the vivante driver. On the IMX6QDL there
> > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > csc/scaler driver for but I don't see any equivalent currently for
> > IMX8MM.
> >
> > Best regards,
> >
> > Tim
>
On Thu, Nov 18, 2021 at 10:20 AM Tim Harvey <[email protected]> wrote:
>
> On Thu, Nov 18, 2021 at 6:30 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le mardi 16 novembre 2021 à 15:23 -0800, Tim Harvey a écrit :
> > > On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
> > > >
> > > > Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > > > > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > > > > you have further question feel free to ask.
> > > > > >
> > > > > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > > > > handle all the functions, so a new compatible flag is required.
> > > > > > >
> > > > > > > This is an RFC because I don't have functional video on my system yet,
> > > > > > > and I'm hoping there might be people who do and can help test this.
> > > > > > > I have only tested this far enough to see they enumerate and appear
> > > > > > > as /dev/videoX and /dev/mediaX devices.
> > > > > >
> > > > > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > > > > post processor, because this block was fused out. We didn't make it optional
> > > > >
> > > > > Thanks for being willing to review this.
> > > > >
> > > > > > from the start as according to the V1 of the TRM it was there, but that error
> > > > > > was corrected in V3.
> > > > >
> > > > > Thanks for the clarification. It wasn't obvious to me, because in
> > > > > some instances the PP looked like it was there and sometimes not
> > > > > there. I'll remove the postproc stuff.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > > > > would be more generic plugins that I can use to test. I am hoping some
> > > > > > > of the linux-media experts might chime in on how to best test.
> > > > > >
> > > > > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > > > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > > > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > > > > binding of udev).
> > > > >
> > > > > Thanks for the tip.
> > > > >
> > > > > >
> > > > > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > > > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > > > > debugging as the G1 version is slightly newer on NXP SoC.
> > > > >
> > > > > For what it's worth the G1 seems to repond cleanly to the inquiries
> > > > > from v42-compliance.
> > > > > The G2 throws some splat when I run v4l2-compliance, but I am still
> > > > > investigating that.
> > > > >
> > > > > [ 405.456979] ------------[ cut here ]------------
> > > > > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > > > > __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > > > > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > > > > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > > > > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > > > > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > > > > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > > > > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > > > > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > > > > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > > > > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > > > > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > > > > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > > > > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > > > > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > > > > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > > > > Development Kit (DT)
> > > > > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > [ 405.570917] sp : ffff800012443810
> > > > > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > > > > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > > > > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > > > > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > > > > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > > > > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > > > > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > > > > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > > > > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > > > > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > > > > [ 405.645666] Call trace:
> > > > > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > [ 405.656569] dma_direct_alloc+0x70/0x310
> > > > > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > > > > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > > > > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > > > > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > > > > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > > > > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > > > > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > > > > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > > > > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > > > > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > > > > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > > > > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > > > > [ 405.718502] invoke_syscall+0x48/0x114
> > > > > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > > > > [ 405.726969] do_el0_svc+0x2c/0x94
> > > > > [ 405.730286] el0_svc+0x28/0x80
> > > > > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > > > > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > > > > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> > > > >
> > > > > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > > > > it when H1 is set up as I submitted the patch. I tried dropping all
> > > > > the encoder formats except the JPEG format, and it doesn't hang any
> > > > > more, but it also doesn't really do anything.
> > > > > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > > > > am not sure JPEG is even supported.
> > > >
> > > > If JPEG is not supported, then there is nothing left for mainline in this
> > > > regard. The kernel control interface and encoding flow needs to be designed and
> > > > specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> > > > though, but nothing ever got formalized in the form of a specification.
> > > >
> > > > >
> > > > > The log from v4l2-compliance on the H1 with everything except the JPEG
> > > > > removed looks like:
> > > > >
> > > > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > > > v4l2-compliance SHA: not available
> > > > > , 64 bits, 64-bit time_t
> > > > >
> > > > > Segmentation fault
> > > > > root@beacon-imx8mm-kit:~#
> > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > : Internal error: Oops: 96000004 [#2] SMP
> > > > >
> > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> > > > >
> > > > > I want to install Gstreamer, but I don't have functioning DSI video,
> > > > > so I am not entirely sure how I will go about testing the decoders
> > > > > except by using fakesink
> > > >
> > > > We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> > > > decoders we use fluster, a tool that runs publicly available conformance test.
> > > > It will simply decode to disk and compare a checksum of the decoded image
> > > > against the compliant checksum (produced by the reference decoders). For you
> > > > interested, it uses the new videocodectestsink, which is specialized for
> > > > producing or calculating conformance image/checksum.
> > > >
> > > > https://github.com/fluendo/fluster
> > > >
> > > > We have added support for GStreamer stateless decoders already.
> > > >
> > > > >
> > > > > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > > > > might just submit a formal patch to just enable the G1 for now.
> > > >
> > > > This looks like a good idea indeed.
> > > >
> > > > >
> > > > > adam
> > > > > >
> > > > > > >
> > > > > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > > > > I know there have been some discussions about the power domains on the
> > > > > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > > > > or if the existing one for te imx8mq should just be modified.
> > > > > > >
> > > > > > > This will likely require the following series in order to apply correctly:
> > > > > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > > > > >
> > > > > > > Adam Ford (5):
> > > > > > > media: hantro: Add support for i.MX8M Mini
> > > > > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > > > > >
> > > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > > > > >
> > > > > >
> > > >
> > >
> > > Nicolas and Adam,
> > >
> > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > H1 JPEG encode using GStreamer 1.18.5:
> > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > ^ v4l2jpegenc
> >
> > This is just a transcript error ?
>
> Nicolas,
>
> No! Thanks for catching my mistake. I was testing with software encode... ooops!
>
> 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> the board so likely a power-domain issue there?
The v4l2-compliance tests fail on the h1 decoder with a hang, but I
think we're writing to registers which are not documented in the Mini
TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
feature, but some of the registers state JPEG, but because some of the
registers written for the H1 are not documented in the TRM. If those
registers are restricted or not in this SoC, I am concerned that it
might be related. I'll try to run some more tests this weekend to
check on the status of the power-domain stuff.
>
> >
> > > host=192.168.1.146 port=5000
> > > viewed on [email protected] via:
> > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > rtpjpegdepay ! jpegdec ! autovideosink
> > >
> > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> >
> > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > a single repository. We are very close to 1.20, which will include stable API
> > support of H264, MPEG2 and VP8 decoding.
> >
>
> Ok, let me see if I can navigate through the build process and I'll
> get back to you.
>
> Thanks,
>
> Tim
>
> > >
> > > I have CSI capture and DSI display currently working on
> > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > can't efficiently convert to something the JPEG encoder likes without
> > > bayer2rgbneon (a libneon version).
> > >
> > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > wide range of data formats but I'm not sure how to tap into this as
> > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > csc/scaler driver for but I don't see any equivalent currently for
> > > IMX8MM.
> > >
> > > Best regards,
> > >
> > > Tim
> >
Hi Adam, Tim,
[...]
> > > > Nicolas and Adam,
> > > >
> > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > ^ v4l2jpegenc
> > >
> > > This is just a transcript error ?
> >
> > Nicolas,
> >
> > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> >
> > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > the board so likely a power-domain issue there?
>
> The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> think we're writing to registers which are not documented in the Mini
> TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> feature, but some of the registers state JPEG, but because some of the
> registers written for the H1 are not documented in the TRM. If those
> registers are restricted or not in this SoC, I am concerned that it
> might be related. I'll try to run some more tests this weekend to
> check on the status of the power-domain stuff.
To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
PROF/profile is on or off). If your board hang while reading this, you likely
didn't get the power bit right.
IMX8 has an undocumented control block thing that we have been fighting with in
imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
on NXP solution to be submitted (they asked us to wait, still waiting =)).
> >
> > >
> > > > host=192.168.1.146 port=5000
> > > > viewed on [email protected] via:
> > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > >
> > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > >
> > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > a single repository. We are very close to 1.20, which will include stable API
> > > support of H264, MPEG2 and VP8 decoding.
> > >
> >
> > Ok, let me see if I can navigate through the build process and I'll
> > get back to you.
> >
> > Thanks,
> >
> > Tim
> >
> > > >
> > > > I have CSI capture and DSI display currently working on
> > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > can't efficiently convert to something the JPEG encoder likes without
> > > > bayer2rgbneon (a libneon version).
> > > >
> > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > wide range of data formats but I'm not sure how to tap into this as
> > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > IMX8MM.
> > > >
> > > > Best regards,
> > > >
> > > > Tim
> > >
On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
>
> Hi Adam, Tim,
>
> [...]
> > > > > Nicolas and Adam,
> > > > >
> > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > ^ v4l2jpegenc
> > > >
> > > > This is just a transcript error ?
> > >
> > > Nicolas,
> > >
> > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > >
> > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > the board so likely a power-domain issue there?
> >
> > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > think we're writing to registers which are not documented in the Mini
> > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > feature, but some of the registers state JPEG, but because some of the
> > registers written for the H1 are not documented in the TRM. If those
> > registers are restricted or not in this SoC, I am concerned that it
> > might be related. I'll try to run some more tests this weekend to
> > check on the status of the power-domain stuff.
>
> To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> PROF/profile is on or off). If your board hang while reading this, you likely
> didn't get the power bit right.
>
> IMX8 has an undocumented control block thing that we have been fighting with in
> imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> on NXP solution to be submitted (they asked us to wait, still waiting =)).
Nicolas,
Thanks for the suggestion to read offset FC. There was an attempt
made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
power-domains with the GPC driver. Unfortunately, it does appear to
hang, so it might not be operating correctly.
Lucas,
Do you have any idea of stuff I can try to see if the power domain is
coming online correctly?
[ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
[ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
[ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
[ 10.728927] vpu: set fuse bits to enable
[ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
[ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
[ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
[ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
[ 11.004726] hantro-vpu 38300000.video-codec: registered
nxp,imx8mm-vpu-dec as /dev/video0
[ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
[ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
[ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
[ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
[ 11.139634] hantro-vpu 38310000.video-codec: registered
nxp,imx8mm-vpu-g2-dec as /dev/video1
[ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
[ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
[ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
[ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
[ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
<hang>
adam
>
> > >
> > > >
> > > > > host=192.168.1.146 port=5000
> > > > > viewed on [email protected] via:
> > > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > > >
> > > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > > >
> > > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > > a single repository. We are very close to 1.20, which will include stable API
> > > > support of H264, MPEG2 and VP8 decoding.
> > > >
> > >
> > > Ok, let me see if I can navigate through the build process and I'll
> > > get back to you.
> > >
> > > Thanks,
> > >
> > > Tim
> > >
> > > > >
> > > > > I have CSI capture and DSI display currently working on
> > > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > > can't efficiently convert to something the JPEG encoder likes without
> > > > > bayer2rgbneon (a libneon version).
> > > > >
> > > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > > wide range of data formats but I'm not sure how to tap into this as
> > > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > > IMX8MM.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Tim
> > > >
>
On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
>
> On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Hi Adam, Tim,
> >
> > [...]
> > > > > > Nicolas and Adam,
> > > > > >
> > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > ^ v4l2jpegenc
> > > > >
> > > > > This is just a transcript error ?
> > > >
> > > > Nicolas,
> > > >
> > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > >
> > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > the board so likely a power-domain issue there?
> > >
> > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > think we're writing to registers which are not documented in the Mini
> > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > feature, but some of the registers state JPEG, but because some of the
> > > registers written for the H1 are not documented in the TRM. If those
> > > registers are restricted or not in this SoC, I am concerned that it
> > > might be related. I'll try to run some more tests this weekend to
> > > check on the status of the power-domain stuff.
> >
> > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > PROF/profile is on or off). If your board hang while reading this, you likely
> > didn't get the power bit right.
> >
> > IMX8 has an undocumented control block thing that we have been fighting with in
> > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > on NXP solution to be submitted (they asked us to wait, still waiting =)).
>
> Nicolas,
>
> Thanks for the suggestion to read offset FC. There was an attempt
> made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> power-domains with the GPC driver. Unfortunately, it does appear to
> hang, so it might not be operating correctly.
>
> Lucas,
>
> Do you have any idea of stuff I can try to see if the power domain is
> coming online correctly?
>
> [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> [ 10.728927] vpu: set fuse bits to enable
> [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> [ 11.004726] hantro-vpu 38300000.video-codec: registered
> nxp,imx8mm-vpu-dec as /dev/video0
> [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> [ 11.139634] hantro-vpu 38310000.video-codec: registered
> nxp,imx8mm-vpu-g2-dec as /dev/video1
> [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
>
> <hang>
>
> adam
>
Nicolas, Tim, and Lucas,
I think I have the hanging resolved in the power domains, and I'll be
pushing the fix to the GPCv2.
For the H1 Encoder, I added some debugging code to read the offset
0xfc and print some data based on the findings of that VPU-h1 offset.
I basically check the various bits per the TRM to see if they are set
and print some splat to indicate whether or not the function is
supported.
[ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
[ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
[ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
[ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
[ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
supported by HW
[ 8.934067] hantro-vpu 38320000.video-codec: registered
nxp,imx8mm-vpu-h1-enc as /dev/video2
Unfortunately, JPEG is not listed as supported. :-(
However, the hanging stops occurring, so I'll be posting a patch to
update the GPCv2 code. I can reduce sone device tree duplication, and
the G2 throws some splat, but that will be a separate discussion.
I can also run v4l2-compliance on the H1 node, and it responds without hanging.
root@beacon-imx8mm-kit:~# v4l2-compliance -d2
v4l2-compliance SHA: not available
, 64 bits, 64-bit time_t
Compliance test for hantro-vpu device /dev/video2:
Driver Info:
Driver name : hantro-vpu
Card type : nxp,imx8mm-vpu-h1-enc
Bus info : platform: hantro-vpu
Driver version : 5.16.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
< snip>
Total for hantro-vpu device /dev/video2: 46, Succeeded: 46, Failed: 0,
Warnings: 0
I'll do an RFCv2 on the Hantro G1 and G2 with the H1 removed based on
the updated GPCv2 code I'll be pushing shortly, but at least the
system doesn't hang, so I'm fairly confident the power domains are
working better now even if we cannot support the JPEG.
adam
> >
> > > >
> > > > >
> > > > > > host=192.168.1.146 port=5000
> > > > > > viewed on [email protected] via:
> > > > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > > > >
> > > > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > > > >
> > > > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > > > a single repository. We are very close to 1.20, which will include stable API
> > > > > support of H264, MPEG2 and VP8 decoding.
> > > > >
> > > >
> > > > Ok, let me see if I can navigate through the build process and I'll
> > > > get back to you.
> > > >
> > > > Thanks,
> > > >
> > > > Tim
> > > >
> > > > > >
> > > > > > I have CSI capture and DSI display currently working on
> > > > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > > > can't efficiently convert to something the JPEG encoder likes without
> > > > > > bayer2rgbneon (a libneon version).
> > > > > >
> > > > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > > > wide range of data formats but I'm not sure how to tap into this as
> > > > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > > > IMX8MM.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Tim
> > > > >
> >
On Sat, Nov 20, 2021 at 7:36 AM Adam Ford <[email protected]> wrote:
>
> On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
> >
> > On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Hi Adam, Tim,
> > >
> > > [...]
> > > > > > > Nicolas and Adam,
> > > > > > >
> > > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > > ^ v4l2jpegenc
> > > > > >
> > > > > > This is just a transcript error ?
> > > > >
> > > > > Nicolas,
> > > > >
> > > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > > >
> > > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > > the board so likely a power-domain issue there?
> > > >
> > > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > > think we're writing to registers which are not documented in the Mini
> > > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > > feature, but some of the registers state JPEG, but because some of the
> > > > registers written for the H1 are not documented in the TRM. If those
> > > > registers are restricted or not in this SoC, I am concerned that it
> > > > might be related. I'll try to run some more tests this weekend to
> > > > check on the status of the power-domain stuff.
> > >
> > > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > > PROF/profile is on or off). If your board hang while reading this, you likely
> > > didn't get the power bit right.
> > >
> > > IMX8 has an undocumented control block thing that we have been fighting with in
> > > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > > on NXP solution to be submitted (they asked us to wait, still waiting =)).
> >
> > Nicolas,
> >
> > Thanks for the suggestion to read offset FC. There was an attempt
> > made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> > power-domains with the GPC driver. Unfortunately, it does appear to
> > hang, so it might not be operating correctly.
> >
> > Lucas,
> >
> > Do you have any idea of stuff I can try to see if the power domain is
> > coming online correctly?
> >
> > [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> > [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> > [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> > [ 10.728927] vpu: set fuse bits to enable
> > [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> > [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> > [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> > [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> > [ 11.004726] hantro-vpu 38300000.video-codec: registered
> > nxp,imx8mm-vpu-dec as /dev/video0
> > [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> > [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> > [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> > [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> > [ 11.139634] hantro-vpu 38310000.video-codec: registered
> > nxp,imx8mm-vpu-g2-dec as /dev/video1
> > [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> > [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> > [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> > [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> > [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> >
> > <hang>
> >
> > adam
> >
>
> Nicolas, Tim, and Lucas,
>
> I think I have the hanging resolved in the power domains, and I'll be
> pushing the fix to the GPCv2.
>
> For the H1 Encoder, I added some debugging code to read the offset
> 0xfc and print some data based on the findings of that VPU-h1 offset.
> I basically check the various bits per the TRM to see if they are set
> and print some splat to indicate whether or not the function is
> supported.
>
> [ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> [ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
> [ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
> [ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
> [ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
> supported by HW
> [ 8.934067] hantro-vpu 38320000.video-codec: registered
> nxp,imx8mm-vpu-h1-enc as /dev/video2
>
> Unfortunately, JPEG is not listed as supported. :-(
Adam,
Well not having JPEG encode support is unfortunate, and unexpected. Do
we not have hantro support yet for VP8/H264 encode?
I haven't quite figured out how to build a modern mono-repo gstreamer
on the ubuntu 20.04 rootfs I'm using so I haven't been able to test
VPU encode/decode properly. I'll keep working on it when I'm back in
the office the following week.
Best regards,
Tim
>
> However, the hanging stops occurring, so I'll be posting a patch to
> update the GPCv2 code. I can reduce sone device tree duplication, and
> the G2 throws some splat, but that will be a separate discussion.
>
> I can also run v4l2-compliance on the H1 node, and it responds without hanging.
>
> root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> v4l2-compliance SHA: not available
> , 64 bits, 64-bit time_t
>
> Compliance test for hantro-vpu device /dev/video2:
>
> Driver Info:
> Driver name : hantro-vpu
> Card type : nxp,imx8mm-vpu-h1-enc
> Bus info : platform: hantro-vpu
> Driver version : 5.16.0
> Capabilities : 0x84204000
> Video Memory-to-Memory Multiplanar
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04204000
> Video Memory-to-Memory Multiplanar
>
> < snip>
>
> Total for hantro-vpu device /dev/video2: 46, Succeeded: 46, Failed: 0,
> Warnings: 0
>
> I'll do an RFCv2 on the Hantro G1 and G2 with the H1 removed based on
> the updated GPCv2 code I'll be pushing shortly, but at least the
> system doesn't hang, so I'm fairly confident the power domains are
> working better now even if we cannot support the JPEG.
>
> adam
>
> > >
> > > > >
> > > > > >
> > > > > > > host=192.168.1.146 port=5000
> > > > > > > viewed on [email protected] via:
> > > > > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > > > > >
> > > > > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > > > > >
> > > > > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > > > > a single repository. We are very close to 1.20, which will include stable API
> > > > > > support of H264, MPEG2 and VP8 decoding.
> > > > > >
> > > > >
> > > > > Ok, let me see if I can navigate through the build process and I'll
> > > > > get back to you.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Tim
> > > > >
> > > > > > >
> > > > > > > I have CSI capture and DSI display currently working on
> > > > > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > > > > can't efficiently convert to something the JPEG encoder likes without
> > > > > > > bayer2rgbneon (a libneon version).
> > > > > > >
> > > > > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > > > > wide range of data formats but I'm not sure how to tap into this as
> > > > > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > > > > IMX8MM.
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > Tim
> > > > > >
> > >
On Thu, Nov 18, 2021 at 8:20 AM Tim Harvey <[email protected]> wrote:
>
> On Thu, Nov 18, 2021 at 6:30 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le mardi 16 novembre 2021 à 15:23 -0800, Tim Harvey a écrit :
> > > On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
> > > >
> > > > Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > > > > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > > > > you have further question feel free to ask.
> > > > > >
> > > > > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > > > > handle all the functions, so a new compatible flag is required.
> > > > > > >
> > > > > > > This is an RFC because I don't have functional video on my system yet,
> > > > > > > and I'm hoping there might be people who do and can help test this.
> > > > > > > I have only tested this far enough to see they enumerate and appear
> > > > > > > as /dev/videoX and /dev/mediaX devices.
> > > > > >
> > > > > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > > > > post processor, because this block was fused out. We didn't make it optional
> > > > >
> > > > > Thanks for being willing to review this.
> > > > >
> > > > > > from the start as according to the V1 of the TRM it was there, but that error
> > > > > > was corrected in V3.
> > > > >
> > > > > Thanks for the clarification. It wasn't obvious to me, because in
> > > > > some instances the PP looked like it was there and sometimes not
> > > > > there. I'll remove the postproc stuff.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > > > > would be more generic plugins that I can use to test. I am hoping some
> > > > > > > of the linux-media experts might chime in on how to best test.
> > > > > >
> > > > > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > > > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > > > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > > > > binding of udev).
> > > > >
> > > > > Thanks for the tip.
> > > > >
> > > > > >
> > > > > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > > > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > > > > debugging as the G1 version is slightly newer on NXP SoC.
> > > > >
> > > > > For what it's worth the G1 seems to repond cleanly to the inquiries
> > > > > from v42-compliance.
> > > > > The G2 throws some splat when I run v4l2-compliance, but I am still
> > > > > investigating that.
> > > > >
> > > > > [ 405.456979] ------------[ cut here ]------------
> > > > > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > > > > __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > > > > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > > > > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > > > > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > > > > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > > > > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > > > > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > > > > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > > > > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > > > > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > > > > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > > > > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > > > > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > > > > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > > > > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > > > > Development Kit (DT)
> > > > > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > [ 405.570917] sp : ffff800012443810
> > > > > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > > > > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > > > > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > > > > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > > > > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > > > > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > > > > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > > > > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > > > > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > > > > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > > > > [ 405.645666] Call trace:
> > > > > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > > > > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > [ 405.656569] dma_direct_alloc+0x70/0x310
> > > > > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > > > > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > > > > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > > > > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > > > > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > > > > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > > > > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > > > > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > > > > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > > > > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > > > > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > > > > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > > > > [ 405.718502] invoke_syscall+0x48/0x114
> > > > > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > > > > [ 405.726969] do_el0_svc+0x2c/0x94
> > > > > [ 405.730286] el0_svc+0x28/0x80
> > > > > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > > > > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > > > > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> > > > >
> > > > > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > > > > it when H1 is set up as I submitted the patch. I tried dropping all
> > > > > the encoder formats except the JPEG format, and it doesn't hang any
> > > > > more, but it also doesn't really do anything.
> > > > > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > > > > am not sure JPEG is even supported.
> > > >
> > > > If JPEG is not supported, then there is nothing left for mainline in this
> > > > regard. The kernel control interface and encoding flow needs to be designed and
> > > > specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> > > > though, but nothing ever got formalized in the form of a specification.
> > > >
> > > > >
> > > > > The log from v4l2-compliance on the H1 with everything except the JPEG
> > > > > removed looks like:
> > > > >
> > > > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > > > v4l2-compliance SHA: not available
> > > > > , 64 bits, 64-bit time_t
> > > > >
> > > > > Segmentation fault
> > > > > root@beacon-imx8mm-kit:~#
> > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > : Internal error: Oops: 96000004 [#2] SMP
> > > > >
> > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> > > > >
> > > > > I want to install Gstreamer, but I don't have functioning DSI video,
> > > > > so I am not entirely sure how I will go about testing the decoders
> > > > > except by using fakesink
> > > >
> > > > We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> > > > decoders we use fluster, a tool that runs publicly available conformance test.
> > > > It will simply decode to disk and compare a checksum of the decoded image
> > > > against the compliant checksum (produced by the reference decoders). For you
> > > > interested, it uses the new videocodectestsink, which is specialized for
> > > > producing or calculating conformance image/checksum.
> > > >
> > > > https://github.com/fluendo/fluster
> > > >
> > > > We have added support for GStreamer stateless decoders already.
> > > >
> > > > >
> > > > > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > > > > might just submit a formal patch to just enable the G1 for now.
> > > >
> > > > This looks like a good idea indeed.
> > > >
> > > > >
> > > > > adam
> > > > > >
> > > > > > >
> > > > > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > > > > I know there have been some discussions about the power domains on the
> > > > > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > > > > or if the existing one for te imx8mq should just be modified.
> > > > > > >
> > > > > > > This will likely require the following series in order to apply correctly:
> > > > > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > > > > >
> > > > > > > Adam Ford (5):
> > > > > > > media: hantro: Add support for i.MX8M Mini
> > > > > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > > > > >
> > > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > > > > >
> > > > > >
> > > >
> > >
> > > Nicolas and Adam,
> > >
> > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > H1 JPEG encode using GStreamer 1.18.5:
> > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > ^ v4l2jpegenc
> >
> > This is just a transcript error ?
>
> Nicolas,
>
> No! Thanks for catching my mistake. I was testing with software encode... ooops!
>
> 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> the board so likely a power-domain issue there?
>
> >
> > > host=192.168.1.146 port=5000
> > > viewed on [email protected] via:
> > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > rtpjpegdepay ! jpegdec ! autovideosink
> > >
> > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> >
> > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > a single repository. We are very close to 1.20, which will include stable API
> > support of H264, MPEG2 and VP8 decoding.
> >
>
> Ok, let me see if I can navigate through the build process and I'll
> get back to you.
Nicolas,
I've built gstreamer 1.19.3 from git and still don't see any decoder elements:
[gst-main] root@focal-venice:~# dmesg | grep -i hantro
[ 8.048311] hantro_vpu: module is from the staging directory, the
quality is unknown, you have been warned.
[ 8.069029] hantro-vpu 38300000.video-codec: registered
nxp,imx8mm-vpu-dec as /dev/video0
[ 8.070164] hantro-vpu 38310000.video-codec: registered
nxp,imx8mm-vpu-g2-dec as /dev/video1
[ 8.072553] hantro_vpu: module is from the staging directory, the
quality is unknown, you have been warned.
[ 8.074205] hantro-vpu 38320000.video-codec: registered
nxp,imx8mm-vpu-h1-enc as /dev/video2
[ 8.088548] hantro_vpu: module is from the staging directory, the
quality is unknown, you have been warned.
[gst-main] root@focal-venice:~# ls -l /lib/firmware/vpu
total 604
-rwxr-xr-x 1 root root 522024 Nov 23 00:02 vpu_fw_imx8_dec.bin
-rwxr-xr-x 1 root root 91920 Nov 23 00:02 vpu_fw_imx8_enc.bin
[gst-main] root@focal-venice:~# cat /sys/class/video4linux/video*/name
nxp,imx8mm-vpu-dec
nxp,imx8mm-vpu-g2-dec
nxp,imx8mm-vpu-h1-enc
[gst-main] root@focal-venice:~# gst-inspect-1.0 --version
gst-inspect-1.0 version 1.19.3
GStreamer 1.19.3 (GIT)
Unknown package origin
[gst-main] root@focal-venice:~# gst-inspect-1.0 | grep v4l2
video4linux2: v4l2deviceprovider (GstDeviceProviderFactory)
video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
video4linux2: v4l2radio: Radio (video4linux2) Tuner
video4linux2: v4l2sink: Video (video4linux2) Sink
video4linux2: v4l2src: Video (video4linux2) Source
The v4l2jpegenc encoder element is there because I haven't disabled it
from Adam's patch yet.
Is there some debugging you want me to add to gstreamer?
Thanks,
Tim
Le lundi 22 novembre 2021 à 09:25 -0800, Tim Harvey a écrit :
> On Sat, Nov 20, 2021 at 7:36 AM Adam Ford <[email protected]> wrote:
> >
> > On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
> > >
> > > On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> > > >
> > > > Hi Adam, Tim,
> > > >
> > > > [...]
> > > > > > > > Nicolas and Adam,
> > > > > > > >
> > > > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > > > ^ v4l2jpegenc
> > > > > > >
> > > > > > > This is just a transcript error ?
> > > > > >
> > > > > > Nicolas,
> > > > > >
> > > > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > > > >
> > > > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > > > the board so likely a power-domain issue there?
> > > > >
> > > > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > > > think we're writing to registers which are not documented in the Mini
> > > > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > > > feature, but some of the registers state JPEG, but because some of the
> > > > > registers written for the H1 are not documented in the TRM. If those
> > > > > registers are restricted or not in this SoC, I am concerned that it
> > > > > might be related. I'll try to run some more tests this weekend to
> > > > > check on the status of the power-domain stuff.
> > > >
> > > > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > > > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > > > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > > > PROF/profile is on or off). If your board hang while reading this, you likely
> > > > didn't get the power bit right.
> > > >
> > > > IMX8 has an undocumented control block thing that we have been fighting with in
> > > > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > > > on NXP solution to be submitted (they asked us to wait, still waiting =)).
> > >
> > > Nicolas,
> > >
> > > Thanks for the suggestion to read offset FC. There was an attempt
> > > made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> > > power-domains with the GPC driver. Unfortunately, it does appear to
> > > hang, so it might not be operating correctly.
> > >
> > > Lucas,
> > >
> > > Do you have any idea of stuff I can try to see if the power domain is
> > > coming online correctly?
> > >
> > > [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> > > [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> > > [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> > > [ 10.728927] vpu: set fuse bits to enable
> > > [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> > > [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> > > [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> > > [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> > > [ 11.004726] hantro-vpu 38300000.video-codec: registered
> > > nxp,imx8mm-vpu-dec as /dev/video0
> > > [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> > > [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> > > [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> > > [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> > > [ 11.139634] hantro-vpu 38310000.video-codec: registered
> > > nxp,imx8mm-vpu-g2-dec as /dev/video1
> > > [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> > > [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> > > [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> > > [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> > > [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > >
> > > <hang>
> > >
> > > adam
> > >
> >
> > Nicolas, Tim, and Lucas,
> >
> > I think I have the hanging resolved in the power domains, and I'll be
> > pushing the fix to the GPCv2.
> >
> > For the H1 Encoder, I added some debugging code to read the offset
> > 0xfc and print some data based on the findings of that VPU-h1 offset.
> > I basically check the various bits per the TRM to see if they are set
> > and print some splat to indicate whether or not the function is
> > supported.
> >
> > [ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > [ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
> > [ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
> > [ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
> > [ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
> > supported by HW
> > [ 8.934067] hantro-vpu 38320000.video-codec: registered
> > nxp,imx8mm-vpu-h1-enc as /dev/video2
> >
> > Unfortunately, JPEG is not listed as supported. :-(
>
> Adam,
>
> Well not having JPEG encode support is unfortunate, and unexpected. Do
> we not have hantro support yet for VP8/H264 encode?
There is no mainline support yet. You can derive from RK3288 support using Google ChromeOS method (a v4l2 plugins that simulate in userspace a stateful encoder):
- libv4l plugins / https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
- Kernel Driver / https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/
>
> I haven't quite figured out how to build a modern mono-repo gstreamer
> on the ubuntu 20.04 rootfs I'm using so I haven't been able to test
> VPU encode/decode properly. I'll keep working on it when I'm back in
> the office the following week.
Did a quick test to make sure there isn't any ubuntu specific blockers, here's a
dirty script that produce a minimal GStreamer, there was really nothing special
compare to other meson projects. Note that I use --wrap-mode=nofallback to avoid
letting GStreamer complete it's feature-set by downloading the planet. This
already build quite a lot and could likely be made smaller by avoid plugins-good
build-dep call, but then you need to check for v4l2odecs and video4linux devs
(mostly gudev a glib udev binding).
# Install ubuntu
podman run -it --rm ubuntu:20.04
sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
apt update
apt build-dep gstreamer1.0-plugins-good
apt install git python3-pip flex bison
# Need a newer meson
pip3 install --user meson
export PATH=$PATH:~/.local/bin
# Build GStreamer
git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
cd gstreamer
meson setup build --wrap-mode=nofallback
ninja -C build
# Run in-place
./gst-env.py
gst-inspect-1.0 v4l2codecs
gst-inspect 1.0 video4linux2
>
> Best regards,
>
> Tim
>
> >
> > However, the hanging stops occurring, so I'll be posting a patch to
> > update the GPCv2 code. I can reduce sone device tree duplication, and
> > the G2 throws some splat, but that will be a separate discussion.
> >
> > I can also run v4l2-compliance on the H1 node, and it responds without hanging.
> >
> > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > v4l2-compliance SHA: not available
> > , 64 bits, 64-bit time_t
> >
> > Compliance test for hantro-vpu device /dev/video2:
> >
> > Driver Info:
> > Driver name : hantro-vpu
> > Card type : nxp,imx8mm-vpu-h1-enc
> > Bus info : platform: hantro-vpu
> > Driver version : 5.16.0
> > Capabilities : 0x84204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04204000
> > Video Memory-to-Memory Multiplanar
> >
> > < snip>
> >
> > Total for hantro-vpu device /dev/video2: 46, Succeeded: 46, Failed: 0,
> > Warnings: 0
> >
> > I'll do an RFCv2 on the Hantro G1 and G2 with the H1 removed based on
> > the updated GPCv2 code I'll be pushing shortly, but at least the
> > system doesn't hang, so I'm fairly confident the power domains are
> > working better now even if we cannot support the JPEG.
> >
> > adam
> >
> > > >
> > > > > >
> > > > > > >
> > > > > > > > host=192.168.1.146 port=5000
> > > > > > > > viewed on [email protected] via:
> > > > > > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > > > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > > > > > >
> > > > > > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > > > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > > > > > >
> > > > > > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > > > > > a single repository. We are very close to 1.20, which will include stable API
> > > > > > > support of H264, MPEG2 and VP8 decoding.
> > > > > > >
> > > > > >
> > > > > > Ok, let me see if I can navigate through the build process and I'll
> > > > > > get back to you.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Tim
> > > > > >
> > > > > > > >
> > > > > > > > I have CSI capture and DSI display currently working on
> > > > > > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > > > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > > > > > can't efficiently convert to something the JPEG encoder likes without
> > > > > > > > bayer2rgbneon (a libneon version).
> > > > > > > >
> > > > > > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > > > > > wide range of data formats but I'm not sure how to tap into this as
> > > > > > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > > > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > > > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > > > > > IMX8MM.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > >
> > > > > > > > Tim
> > > > > > >
> > > >
Le lundi 22 novembre 2021 à 16:06 -0800, Tim Harvey a écrit :
> On Thu, Nov 18, 2021 at 8:20 AM Tim Harvey <[email protected]> wrote:
> >
> > On Thu, Nov 18, 2021 at 6:30 AM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Le mardi 16 novembre 2021 à 15:23 -0800, Tim Harvey a écrit :
> > > > On Tue, Nov 9, 2021 at 7:57 AM Nicolas Dufresne <[email protected]> wrote:
> > > > >
> > > > > Le lundi 08 novembre 2021 à 10:33 -0600, Adam Ford a écrit :
> > > > > > On Mon, Nov 8, 2021 at 7:59 AM Nicolas Dufresne <[email protected]> wrote:
> > > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > thanks for you work, I'll try and reply about the GStreamer questions below, if
> > > > > > > you have further question feel free to ask.
> > > > > > >
> > > > > > > Le samedi 06 novembre 2021 à 13:37 -0500, Adam Ford a écrit :
> > > > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear
> > > > > > > > to be related to the video decoders used on the i.MX8MQ, but because of
> > > > > > > > how the Mini handles the power domains, the VPU driver does not need to
> > > > > > > > handle all the functions, so a new compatible flag is required.
> > > > > > > >
> > > > > > > > This is an RFC because I don't have functional video on my system yet,
> > > > > > > > and I'm hoping there might be people who do and can help test this.
> > > > > > > > I have only tested this far enough to see they enumerate and appear
> > > > > > > > as /dev/videoX and /dev/mediaX devices.
> > > > > > >
> > > > > > > I will check the patchset, but you need in the mini-variant to disable the G1
> > > > > > > post processor, because this block was fused out. We didn't make it optional
> > > > > >
> > > > > > Thanks for being willing to review this.
> > > > > >
> > > > > > > from the start as according to the V1 of the TRM it was there, but that error
> > > > > > > was corrected in V3.
> > > > > >
> > > > > > Thanks for the clarification. It wasn't obvious to me, because in
> > > > > > some instances the PP looked like it was there and sometimes not
> > > > > > there. I'll remove the postproc stuff.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > I am also curious to know if/what gstreamer plugins are necessary. In
> > > > > > > > NXP's custom kernel, there are IMX-specific plugins, and I was hoping there
> > > > > > > > would be more generic plugins that I can use to test. I am hoping some
> > > > > > > > of the linux-media experts might chime in on how to best test.
> > > > > > >
> > > > > > > I will recommend using GStreamer 1.19.3 or main branch (GStreamer is now a
> > > > > > > single git repo). You will then be able to test Hantro G1 decoding of MPEG2,
> > > > > > > H264 and VP8. Remember that the related plugin depends on libgudev (a glib
> > > > > > > binding of udev).
> > > > > >
> > > > > > Thanks for the tip.
> > > > > >
> > > > > > >
> > > > > > > For the encoder, I believe only JPEG maybe supported, since this is all there is
> > > > > > > mainline for RK3288 (and perhaps other RK). But this will need testing and
> > > > > > > debugging as the G1 version is slightly newer on NXP SoC.
> > > > > >
> > > > > > For what it's worth the G1 seems to repond cleanly to the inquiries
> > > > > > from v42-compliance.
> > > > > > The G2 throws some splat when I run v4l2-compliance, but I am still
> > > > > > investigating that.
> > > > > >
> > > > > > [ 405.456979] ------------[ cut here ]------------
> > > > > > [ 405.464173] WARNING: CPU: 0 PID: 563 at mm/page_alloc.c:5344
> > > > > > __alloc_pages+0x5a4/0xbe0
> > > > > > [ 405.472104] Modules linked in: 8021q garp mrp stp llc caam_jr
> > > > > > caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes
> > > > > > imx7_media_csi(C) crct10dif_ce imx_media_common(C)
> > > > > > snd_soc_fsl_asoc_card imx7_mipi_csis(C) snd_soc_imx_audmux
> > > > > > snd_soc_simple_card_utils fsl_imx8_ddr_perf imx8m_ddrc brcmfmac
> > > > > > brcmutil hantro_vpu(C) v4l2_h264 v4l2_mem2mem videobuf2_vmalloc
> > > > > > videobuf2_dma_contig videobuf2_memops cfg80211 ov5640 videobuf2_v4l2
> > > > > > v4l2_fwnode v4l2_async videobuf2_common videodev etnaviv gpu_sched
> > > > > > hci_uart mc btqca btbcm snd_soc_wm8962 at24 spi_imx rtc_pcf85363
> > > > > > rtc_snvs clk_bd718x7 spi_bitbang snvs_pwrkey snd_soc_fsl_sai
> > > > > > imx_pcm_dma caam error bluetooth imx8mm_thermal ecdh_generic
> > > > > > imx_cpufreq_dt ecc rfkill fuse drm ipv6
> > > > > > [ 405.535835] CPU: 0 PID: 563 Comm: v4l2-compliance Tainted: G D
> > > > > > C 5.15.0-next-20211105-00010-g4bb8e8a25d3c-dirty #28
> > > > > > [ 405.547401] Hardware name: Beacon EmbeddedWorks i.MX8M Mini
> > > > > > Development Kit (DT)
> > > > > > [ 405.554797] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > [ 405.561762] pc : __alloc_pages+0x5a4/0xbe0
> > > > > > [ 405.565861] lr : __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > > [ 405.570917] sp : ffff800012443810
> > > > > > [ 405.574232] x29: ffff800012443810 x28: 0000000000000000 x27: ffff000005288220
> > > > > > [ 405.581375] x26: 0000000000000034 x25: 0000000000000000 x24: ffff000000259010
> > > > > > [ 405.588517] x23: ffff80001011ab7c x22: ffff000000259010 x21: 00000000ffffffff
> > > > > > [ 405.595659] x20: 0000000000000cc1 x19: 0000000000000000 x18: 0000000000000000
> > > > > > [ 405.602803] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > > > > > [ 405.609947] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
> > > > > > [ 405.617090] x11: ffff80001241d000 x10: ffff00000528833a x9 : ffff00000528832a
> > > > > > [ 405.624232] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000cc0
> > > > > > [ 405.631378] x5 : 00000000bfffffff x4 : ffff000009e30dc0 x3 : 0000000000000000
> > > > > > [ 405.638520] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000cc1
> > > > > > [ 405.645666] Call trace:
> > > > > > [ 405.648113] __alloc_pages+0x5a4/0xbe0
> > > > > > [ 405.651862] __dma_direct_alloc_pages+0x17c/0x1e0
> > > > > > [ 405.656569] dma_direct_alloc+0x70/0x310
> > > > > > [ 405.660494] dma_alloc_attrs+0x7c/0xe4
> > > > > > [ 405.664246] hantro_hevc_get_ref_buf+0x15c/0x184 [hantro_vpu]
> > > > > > [ 405.670021] hantro_g2_hevc_dec_run+0x3b8/0x1910 [hantro_vpu]
> > > > > > [ 405.675791] device_run+0xac/0x110 [hantro_vpu]
> > > > > > [ 405.680345] v4l2_m2m_try_run+0xac/0x1b0 [v4l2_mem2mem]
> > > > > > [ 405.685598] v4l2_m2m_ioctl_streamon+0x84/0xa0 [v4l2_mem2mem]
> > > > > > [ 405.691366] v4l_streamon+0x28/0x34 [videodev]
> > > > > > [ 405.695877] __video_do_ioctl+0x178/0x3dc [videodev]
> > > > > > [ 405.700897] video_usercopy+0x368/0x6dc [videodev]
> > > > > > [ 405.705745] video_ioctl2+0x1c/0x30 [videodev]
> > > > > > [ 405.710246] v4l2_ioctl+0x44/0x64 [videodev]
> > > > > > [ 405.714574] __arm64_sys_ioctl+0xac/0xf0
> > > > > > [ 405.718502] invoke_syscall+0x48/0x114
> > > > > > [ 405.722258] el0_svc_common.constprop.0+0xd4/0xfc
> > > > > > [ 405.726969] do_el0_svc+0x2c/0x94
> > > > > > [ 405.730286] el0_svc+0x28/0x80
> > > > > > [ 405.733348] el0t_64_sync_handler+0xa8/0x130
> > > > > > [ 405.737619] el0t_64_sync+0x1a0/0x1a4
> > > > > > [ 405.741287] ---[ end trace 270ed4a899803006 ]---
> > > > > >
> > > > > > The H1 encoder seems to hang the system when I run v4l2-compliance on
> > > > > > it when H1 is set up as I submitted the patch. I tried dropping all
> > > > > > the encoder formats except the JPEG format, and it doesn't hang any
> > > > > > more, but it also doesn't really do anything.
> > > > > > The datasheet only references VPU_H1 as supporting VP8 and H.264, so I
> > > > > > am not sure JPEG is even supported.
> > > > >
> > > > > If JPEG is not supported, then there is nothing left for mainline in this
> > > > > regard. The kernel control interface and encoding flow needs to be designed and
> > > > > specified for encoders like VP8 and H264. Some prototypes and prior-art exist
> > > > > though, but nothing ever got formalized in the form of a specification.
> > > > >
> > > > > >
> > > > > > The log from v4l2-compliance on the H1 with everything except the JPEG
> > > > > > removed looks like:
> > > > > >
> > > > > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > > > > v4l2-compliance SHA: not available
> > > > > > , 64 bits, 64-bit time_t
> > > > > >
> > > > > > Segmentation fault
> > > > > > root@beacon-imx8mm-kit:~#
> > > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > > : Internal error: Oops: 96000004 [#2] SMP
> > > > > >
> > > > > > Message from syslogd@ at Thu Jan 1 00:05:07 1970 ...
> > > > > > : Code: 52800001 aa1403e0 d2801802 95c31ab9 (b9400aa1)
> > > > > >
> > > > > > I want to install Gstreamer, but I don't have functioning DSI video,
> > > > > > so I am not entirely sure how I will go about testing the decoders
> > > > > > except by using fakesink
> > > > >
> > > > > We too don't have an mainline DSI to test the CODECs on recent NXP SoC. For
> > > > > decoders we use fluster, a tool that runs publicly available conformance test.
> > > > > It will simply decode to disk and compare a checksum of the decoded image
> > > > > against the compliant checksum (produced by the reference decoders). For you
> > > > > interested, it uses the new videocodectestsink, which is specialized for
> > > > > producing or calculating conformance image/checksum.
> > > > >
> > > > > https://github.com/fluendo/fluster
> > > > >
> > > > > We have added support for GStreamer stateless decoders already.
> > > > >
> > > > > >
> > > > > > If the G1 ends up working with some of the newer Gstreamer stuff, I
> > > > > > might just submit a formal patch to just enable the G1 for now.
> > > > >
> > > > > This looks like a good idea indeed.
> > > > >
> > > > > >
> > > > > > adam
> > > > > > >
> > > > > > > >
> > > > > > > > Lastly, I didn't update any device tree binding YAML files, because
> > > > > > > > I know there have been some discussions about the power domains on the
> > > > > > > > imx8mq, and I wasn't sure if the imx8mm should get a separate YAML file
> > > > > > > > or if the existing one for te imx8mq should just be modified.
> > > > > > > >
> > > > > > > > This will likely require the following series in order to apply correctly:
> > > > > > > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=576407
> > > > > > > >
> > > > > > > > Adam Ford (5):
> > > > > > > > media: hantro: Add support for i.MX8M Mini
> > > > > > > > arm64: dts: imx8mm: Enable VPU-G1 and VPU-G2
> > > > > > > > media: hantro: Rename ROCKCHIP_VPU_ENC_FMT to HANTRO_VPU_ENC_FMT
> > > > > > > > media: hantro: Add H1 encoder support on i.MX8M Mini
> > > > > > > > arm64: dts: imx8mm: Enable Hantro H1 Encoder
> > > > > > > >
> > > > > > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 61 ++++++++
> > > > > > > > drivers/staging/media/hantro/hantro_drv.c | 3 +
> > > > > > > > drivers/staging/media/hantro/hantro_hw.h | 19 ++-
> > > > > > > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 143 ++++++++++++++++++
> > > > > > > > .../staging/media/hantro/rockchip_vpu_hw.c | 26 ++--
> > > > > > > > 5 files changed, 231 insertions(+), 21 deletions(-)
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > > > Nicolas and Adam,
> > > >
> > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > ^ v4l2jpegenc
> > >
> > > This is just a transcript error ?
> >
> > Nicolas,
> >
> > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> >
> > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > the board so likely a power-domain issue there?
> >
> > >
> > > > host=192.168.1.146 port=5000
> > > > viewed on [email protected] via:
> > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > >
> > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > >
> > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > a single repository. We are very close to 1.20, which will include stable API
> > > support of H264, MPEG2 and VP8 decoding.
> > >
> >
> > Ok, let me see if I can navigate through the build process and I'll
> > get back to you.
>
> Nicolas,
>
> I've built gstreamer 1.19.3 from git and still don't see any decoder elements:
>
> [gst-main] root@focal-venice:~# dmesg | grep -i hantro
> [ 8.048311] hantro_vpu: module is from the staging directory, the
> quality is unknown, you have been warned.
> [ 8.069029] hantro-vpu 38300000.video-codec: registered
> nxp,imx8mm-vpu-dec as /dev/video0
> [ 8.070164] hantro-vpu 38310000.video-codec: registered
> nxp,imx8mm-vpu-g2-dec as /dev/video1
> [ 8.072553] hantro_vpu: module is from the staging directory, the
> quality is unknown, you have been warned.
> [ 8.074205] hantro-vpu 38320000.video-codec: registered
> nxp,imx8mm-vpu-h1-enc as /dev/video2
> [ 8.088548] hantro_vpu: module is from the staging directory, the
> quality is unknown, you have been warned.
> [gst-main] root@focal-venice:~# ls -l /lib/firmware/vpu
> total 604
> -rwxr-xr-x 1 root root 522024 Nov 23 00:02 vpu_fw_imx8_dec.bin
> -rwxr-xr-x 1 root root 91920 Nov 23 00:02 vpu_fw_imx8_enc.bin
> [gst-main] root@focal-venice:~# cat /sys/class/video4linux/video*/name
> nxp,imx8mm-vpu-dec
> nxp,imx8mm-vpu-g2-dec
> nxp,imx8mm-vpu-h1-enc
> [gst-main] root@focal-venice:~# gst-inspect-1.0 --version
> gst-inspect-1.0 version 1.19.3
> GStreamer 1.19.3 (GIT)
> Unknown package origin
> [gst-main] root@focal-venice:~# gst-inspect-1.0 | grep v4l2
> video4linux2: v4l2deviceprovider (GstDeviceProviderFactory)
> video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> video4linux2: v4l2radio: Radio (video4linux2) Tuner
> video4linux2: v4l2sink: Video (video4linux2) Sink
> video4linux2: v4l2src: Video (video4linux2) Source
>
> The v4l2jpegenc encoder element is there because I haven't disabled it
> from Adam's patch yet.
>
> Is there some debugging you want me to add to gstreamer?
See my instructions on your previous comment giving instructions to build
gstreamer on ubuntu 20.04 (and verify that the two plugins needed are there),
you likely are missing v4l2codecs plugin deps (like gudev).
>
> Thanks,
>
> Tim
On Tue, Nov 23, 2021 at 2:07 PM Nicolas Dufresne <[email protected]> wrote:
>
> Le lundi 22 novembre 2021 à 09:25 -0800, Tim Harvey a écrit :
> > On Sat, Nov 20, 2021 at 7:36 AM Adam Ford <[email protected]> wrote:
> > >
> > > On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
> > > >
> > > > On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> > > > >
> > > > > Hi Adam, Tim,
> > > > >
> > > > > [...]
> > > > > > > > > Nicolas and Adam,
> > > > > > > > >
> > > > > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > > > > ^ v4l2jpegenc
> > > > > > > >
> > > > > > > > This is just a transcript error ?
> > > > > > >
> > > > > > > Nicolas,
> > > > > > >
> > > > > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > > > > >
> > > > > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > > > > the board so likely a power-domain issue there?
> > > > > >
> > > > > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > > > > think we're writing to registers which are not documented in the Mini
> > > > > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > > > > feature, but some of the registers state JPEG, but because some of the
> > > > > > registers written for the H1 are not documented in the TRM. If those
> > > > > > registers are restricted or not in this SoC, I am concerned that it
> > > > > > might be related. I'll try to run some more tests this weekend to
> > > > > > check on the status of the power-domain stuff.
> > > > >
> > > > > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > > > > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > > > > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > > > > PROF/profile is on or off). If your board hang while reading this, you likely
> > > > > didn't get the power bit right.
> > > > >
> > > > > IMX8 has an undocumented control block thing that we have been fighting with in
> > > > > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > > > > on NXP solution to be submitted (they asked us to wait, still waiting =)).
> > > >
> > > > Nicolas,
> > > >
> > > > Thanks for the suggestion to read offset FC. There was an attempt
> > > > made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> > > > power-domains with the GPC driver. Unfortunately, it does appear to
> > > > hang, so it might not be operating correctly.
> > > >
> > > > Lucas,
> > > >
> > > > Do you have any idea of stuff I can try to see if the power domain is
> > > > coming online correctly?
> > > >
> > > > [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> > > > [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> > > > [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> > > > [ 10.728927] vpu: set fuse bits to enable
> > > > [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> > > > [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> > > > [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> > > > [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> > > > [ 11.004726] hantro-vpu 38300000.video-codec: registered
> > > > nxp,imx8mm-vpu-dec as /dev/video0
> > > > [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> > > > [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> > > > [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> > > > [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> > > > [ 11.139634] hantro-vpu 38310000.video-codec: registered
> > > > nxp,imx8mm-vpu-g2-dec as /dev/video1
> > > > [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> > > > [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> > > > [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> > > > [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> > > > [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > >
> > > > <hang>
> > > >
> > > > adam
> > > >
> > >
> > > Nicolas, Tim, and Lucas,
> > >
> > > I think I have the hanging resolved in the power domains, and I'll be
> > > pushing the fix to the GPCv2.
> > >
> > > For the H1 Encoder, I added some debugging code to read the offset
> > > 0xfc and print some data based on the findings of that VPU-h1 offset.
> > > I basically check the various bits per the TRM to see if they are set
> > > and print some splat to indicate whether or not the function is
> > > supported.
> > >
> > > [ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > [ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
> > > [ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
> > > [ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
> > > [ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
> > > supported by HW
> > > [ 8.934067] hantro-vpu 38320000.video-codec: registered
> > > nxp,imx8mm-vpu-h1-enc as /dev/video2
> > >
> > > Unfortunately, JPEG is not listed as supported. :-(
> >
> > Adam,
> >
> > Well not having JPEG encode support is unfortunate, and unexpected. Do
> > we not have hantro support yet for VP8/H264 encode?
>
> There is no mainline support yet. You can derive from RK3288 support using Google ChromeOS method (a v4l2 plugins that simulate in userspace a stateful encoder):
>
> - libv4l plugins / https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
> - Kernel Driver / https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/
>
> >
> > I haven't quite figured out how to build a modern mono-repo gstreamer
> > on the ubuntu 20.04 rootfs I'm using so I haven't been able to test
> > VPU encode/decode properly. I'll keep working on it when I'm back in
> > the office the following week.
>
> Did a quick test to make sure there isn't any ubuntu specific blockers, here's a
> dirty script that produce a minimal GStreamer, there was really nothing special
> compare to other meson projects. Note that I use --wrap-mode=nofallback to avoid
> letting GStreamer complete it's feature-set by downloading the planet. This
> already build quite a lot and could likely be made smaller by avoid plugins-good
> build-dep call, but then you need to check for v4l2odecs and video4linux devs
> (mostly gudev a glib udev binding).
>
> # Install ubuntu
> podman run -it --rm ubuntu:20.04
> sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
> apt update
> apt build-dep gstreamer1.0-plugins-good
> apt install git python3-pip flex bison
>
> # Need a newer meson
> pip3 install --user meson
> export PATH=$PATH:~/.local/bin
>
> # Build GStreamer
> git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
> cd gstreamer
> meson setup build --wrap-mode=nofallback
> ninja -C build
>
> # Run in-place
> ./gst-env.py
> gst-inspect-1.0 v4l2codecs
> gst-inspect 1.0 video4linux2
>
Thanks for the suggestions.
I downloaded what's in the master repo:
[gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 v4l2codecs
** (gst-plugin-scanner:7317): CRITICAL **: 10:29:51.847: can't find
gi.repository.Gst
Plugin Details:
Name v4l2codecs
Description V4L2 CODEC Accelerators plugin
Filename
/root/gstreamer/builddir/subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so
Version 1.19.3.1
License LGPL
Source module gst-plugins-bad
Binary package GStreamer Bad Plug-ins git
Origin URL Unknown package origin
v4l2slh264dec: V4L2 Stateless H.264 Video Decoder
v4l2slmpeg2dec: V4L2 Stateless Mpeg2 Video Decoder
v4l2slvp8alphadecodebin: VP8 Alpha Decoder
v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder
4 features:
+-- 4 elements
[gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 video4linux2
Plugin Details:
Name video4linux2
Description elements for Video 4 Linux
Filename
/root/gstreamer/builddir/subprojects/gst-plugins-good/sys/v4l2/libgstvideo4linux2.so
Version 1.19.3.1
License LGPL
Source module gst-plugins-good
Binary package GStreamer Good Plug-ins git
Origin URL Unknown package origin
v4l2deviceprovider: Video (video4linux2) Device Provider
v4l2jpegenc: V4L2 JPEG Encoder
v4l2radio: Radio (video4linux2) Tuner
v4l2sink: Video (video4linux2) Sink
v4l2src: Video (video4linux2) Source
5 features:
+-- 4 elements
+-- 1 device providers
I still have the H1 encoder enabled, but I know JPEG isn't supported,
so I'm going to attempt to do some decoding and pipe to fakesink since
I don't have a functional display yet.
gst-launch-1.0 -ev filesrc location=trailer_1080p_h264_mp3.avi !
decodebin3 ! fakesink
Redistribute latency...
/GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:src:
caps = video/x-raw, format=(string)NV12, width=(int)1920,
height=(int)1080, interlace-mode=(string)progressive,
multiview-mode=(string)mono,
multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
/GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0:
caps = video/x-raw, format=(string)NV12, width=(int)1920,
height=(int)1080, interlace-mode=(string)progressive,
multiview-mode=(string)mono,
multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
/GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0.GstProxyPad:proxypad6:
caps = video/x-raw, format=(string)NV12, width=(int)1920,
height=(int)1080, interlace-mode=(string)progressive,
multiview-mode=(string)mono,
multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
/GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/GstMultiQueue:multiqueue0:
min-interleave-time = 300000000
Redistribute latency...
/GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:sink:
caps = video/x-h264, variant=(string)itu, framerate=(fraction)25/1,
width=(int)1920, height=(int)1080, chroma-format=(string)4:2:0,
bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8,
parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au,
profile=(string)high, level=(string)4,
codec_data=(buffer)01640028ffe1001a67640028acd940780227e584000003000400000300c83c60c65801000668ebe3cb22c0
New clock: GstSystemClock
And it appears to stream, because the counter increases. I haven't
checked the CPU utilization, but the fact that it shows v4l2slh264dec
is good.
Is there a way to know if/how the decoder is using the proper VPU? I
assume if it wasn't using the proper one, it would fail, but was just
curious.
I think I'll redo the patch without the RFC and without the H1 encoder
unless anyone has any objections. I know I need to rebase on
linux-next anyway because the patches don't apply cleanly. Is there a
specific branch I should use? I don't know if this goes through
Shawn's IMX tree or the media tree (or a combination)
adam
adam
> >
> > Best regards,
> >
> > Tim
> >
> > >
> > > However, the hanging stops occurring, so I'll be posting a patch to
> > > update the GPCv2 code. I can reduce sone device tree duplication, and
> > > the G2 throws some splat, but that will be a separate discussion.
> > >
> > > I can also run v4l2-compliance on the H1 node, and it responds without hanging.
> > >
> > > root@beacon-imx8mm-kit:~# v4l2-compliance -d2
> > > v4l2-compliance SHA: not available
> > > , 64 bits, 64-bit time_t
> > >
> > > Compliance test for hantro-vpu device /dev/video2:
> > >
> > > Driver Info:
> > > Driver name : hantro-vpu
> > > Card type : nxp,imx8mm-vpu-h1-enc
> > > Bus info : platform: hantro-vpu
> > > Driver version : 5.16.0
> > > Capabilities : 0x84204000
> > > Video Memory-to-Memory Multiplanar
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps : 0x04204000
> > > Video Memory-to-Memory Multiplanar
> > >
> > > < snip>
> > >
> > > Total for hantro-vpu device /dev/video2: 46, Succeeded: 46, Failed: 0,
> > > Warnings: 0
> > >
> > > I'll do an RFCv2 on the Hantro G1 and G2 with the H1 removed based on
> > > the updated GPCv2 code I'll be pushing shortly, but at least the
> > > system doesn't hang, so I'm fairly confident the power domains are
> > > working better now even if we cannot support the JPEG.
> > >
> > > adam
> > >
> > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > host=192.168.1.146 port=5000
> > > > > > > > > viewed on [email protected] via:
> > > > > > > > > $ gst-launch-1.0 udpsrc port=5000 ! application/x-rtp,payload=96 !
> > > > > > > > > rtpjpegdepay ! jpegdec ! autovideosink
> > > > > > > > >
> > > > > > > > > For the G1/G2 patches in the series I don't see any Gstreamer
> > > > > > > > > 'v4l2.*dec' elements. Perhaps I need a newer version of Gstreamer.
> > > > > > > >
> > > > > > > > Most likely yes, I suggest building gstreamer/ branch "main", GStreamer has now
> > > > > > > > a single repository. We are very close to 1.20, which will include stable API
> > > > > > > > support of H264, MPEG2 and VP8 decoding.
> > > > > > > >
> > > > > > >
> > > > > > > Ok, let me see if I can navigate through the build process and I'll
> > > > > > > get back to you.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Tim
> > > > > > >
> > > > > > > > >
> > > > > > > > > I have CSI capture and DSI display currently working on
> > > > > > > > > imx8mm-venice-gw73xx-0x that I can play with. The CSI sensor only
> > > > > > > > > supports RAW8/RAW10 (and gstreamer currently only supports RAW8) and I
> > > > > > > > > can't efficiently convert to something the JPEG encoder likes without
> > > > > > > > > bayer2rgbneon (a libneon version).
> > > > > > > > >
> > > > > > > > > I see from the IMX8MMRM that the 2D GPU supports scaling etc with a
> > > > > > > > > wide range of data formats but I'm not sure how to tap into this as
> > > > > > > > > that hardware is managed by the vivante driver. On the IMX6QDL there
> > > > > > > > > is a separate IPU block that Philipp Zabel wrote a nice mem2mem
> > > > > > > > > csc/scaler driver for but I don't see any equivalent currently for
> > > > > > > > > IMX8MM.
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Tim
> > > > > > > >
> > > > >
>
On Mon, 29 Nov 2021 at 13:48, Adam Ford <[email protected]> wrote:
>
> On Tue, Nov 23, 2021 at 2:07 PM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le lundi 22 novembre 2021 à 09:25 -0800, Tim Harvey a écrit :
> > > On Sat, Nov 20, 2021 at 7:36 AM Adam Ford <[email protected]> wrote:
> > > >
> > > > On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
> > > > >
> > > > > On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> > > > > >
> > > > > > Hi Adam, Tim,
> > > > > >
> > > > > > [...]
> > > > > > > > > > Nicolas and Adam,
> > > > > > > > > >
> > > > > > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > > > > > ^ v4l2jpegenc
> > > > > > > > >
> > > > > > > > > This is just a transcript error ?
> > > > > > > >
> > > > > > > > Nicolas,
> > > > > > > >
> > > > > > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > > > > > >
> > > > > > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > > > > > the board so likely a power-domain issue there?
> > > > > > >
> > > > > > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > > > > > think we're writing to registers which are not documented in the Mini
> > > > > > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > > > > > feature, but some of the registers state JPEG, but because some of the
> > > > > > > registers written for the H1 are not documented in the TRM. If those
> > > > > > > registers are restricted or not in this SoC, I am concerned that it
> > > > > > > might be related. I'll try to run some more tests this weekend to
> > > > > > > check on the status of the power-domain stuff.
> > > > > >
> > > > > > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > > > > > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > > > > > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > > > > > PROF/profile is on or off). If your board hang while reading this, you likely
> > > > > > didn't get the power bit right.
> > > > > >
> > > > > > IMX8 has an undocumented control block thing that we have been fighting with in
> > > > > > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > > > > > on NXP solution to be submitted (they asked us to wait, still waiting =)).
> > > > >
> > > > > Nicolas,
> > > > >
> > > > > Thanks for the suggestion to read offset FC. There was an attempt
> > > > > made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> > > > > power-domains with the GPC driver. Unfortunately, it does appear to
> > > > > hang, so it might not be operating correctly.
> > > > >
> > > > > Lucas,
> > > > >
> > > > > Do you have any idea of stuff I can try to see if the power domain is
> > > > > coming online correctly?
> > > > >
> > > > > [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> > > > > [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> > > > > [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> > > > > [ 10.728927] vpu: set fuse bits to enable
> > > > > [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> > > > > [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> > > > > [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> > > > > [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> > > > > [ 11.004726] hantro-vpu 38300000.video-codec: registered
> > > > > nxp,imx8mm-vpu-dec as /dev/video0
> > > > > [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> > > > > [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> > > > > [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> > > > > [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> > > > > [ 11.139634] hantro-vpu 38310000.video-codec: registered
> > > > > nxp,imx8mm-vpu-g2-dec as /dev/video1
> > > > > [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> > > > > [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> > > > > [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> > > > > [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> > > > > [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > > >
> > > > > <hang>
> > > > >
> > > > > adam
> > > > >
> > > >
> > > > Nicolas, Tim, and Lucas,
> > > >
> > > > I think I have the hanging resolved in the power domains, and I'll be
> > > > pushing the fix to the GPCv2.
> > > >
> > > > For the H1 Encoder, I added some debugging code to read the offset
> > > > 0xfc and print some data based on the findings of that VPU-h1 offset.
> > > > I basically check the various bits per the TRM to see if they are set
> > > > and print some splat to indicate whether or not the function is
> > > > supported.
> > > >
> > > > [ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > > [ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
> > > > [ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
> > > > [ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
> > > > [ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
> > > > supported by HW
> > > > [ 8.934067] hantro-vpu 38320000.video-codec: registered
> > > > nxp,imx8mm-vpu-h1-enc as /dev/video2
> > > >
> > > > Unfortunately, JPEG is not listed as supported. :-(
> > >
> > > Adam,
> > >
> > > Well not having JPEG encode support is unfortunate, and unexpected. Do
> > > we not have hantro support yet for VP8/H264 encode?
> >
> > There is no mainline support yet. You can derive from RK3288 support using Google ChromeOS method (a v4l2 plugins that simulate in userspace a stateful encoder):
> >
> > - libv4l plugins / https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
> > - Kernel Driver / https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/
> >
> > >
> > > I haven't quite figured out how to build a modern mono-repo gstreamer
> > > on the ubuntu 20.04 rootfs I'm using so I haven't been able to test
> > > VPU encode/decode properly. I'll keep working on it when I'm back in
> > > the office the following week.
> >
> > Did a quick test to make sure there isn't any ubuntu specific blockers, here's a
> > dirty script that produce a minimal GStreamer, there was really nothing special
> > compare to other meson projects. Note that I use --wrap-mode=nofallback to avoid
> > letting GStreamer complete it's feature-set by downloading the planet. This
> > already build quite a lot and could likely be made smaller by avoid plugins-good
> > build-dep call, but then you need to check for v4l2odecs and video4linux devs
> > (mostly gudev a glib udev binding).
> >
> > # Install ubuntu
> > podman run -it --rm ubuntu:20.04
> > sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
> > apt update
> > apt build-dep gstreamer1.0-plugins-good
> > apt install git python3-pip flex bison
> >
> > # Need a newer meson
> > pip3 install --user meson
> > export PATH=$PATH:~/.local/bin
> >
> > # Build GStreamer
> > git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
> > cd gstreamer
> > meson setup build --wrap-mode=nofallback
> > ninja -C build
> >
> > # Run in-place
> > ./gst-env.py
> > gst-inspect-1.0 v4l2codecs
> > gst-inspect 1.0 video4linux2
> >
> Thanks for the suggestions.
>
> I downloaded what's in the master repo:
>
> [gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 v4l2codecs
>
> ** (gst-plugin-scanner:7317): CRITICAL **: 10:29:51.847: can't find
> gi.repository.Gst
> Plugin Details:
> Name v4l2codecs
> Description V4L2 CODEC Accelerators plugin
> Filename
> /root/gstreamer/builddir/subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so
> Version 1.19.3.1
> License LGPL
> Source module gst-plugins-bad
> Binary package GStreamer Bad Plug-ins git
> Origin URL Unknown package origin
>
> v4l2slh264dec: V4L2 Stateless H.264 Video Decoder
> v4l2slmpeg2dec: V4L2 Stateless Mpeg2 Video Decoder
> v4l2slvp8alphadecodebin: VP8 Alpha Decoder
> v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder
>
> 4 features:
> +-- 4 elements
>
> [gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 video4linux2
> Plugin Details:
> Name video4linux2
> Description elements for Video 4 Linux
> Filename
> /root/gstreamer/builddir/subprojects/gst-plugins-good/sys/v4l2/libgstvideo4linux2.so
> Version 1.19.3.1
> License LGPL
> Source module gst-plugins-good
> Binary package GStreamer Good Plug-ins git
> Origin URL Unknown package origin
>
> v4l2deviceprovider: Video (video4linux2) Device Provider
> v4l2jpegenc: V4L2 JPEG Encoder
> v4l2radio: Radio (video4linux2) Tuner
> v4l2sink: Video (video4linux2) Sink
> v4l2src: Video (video4linux2) Source
>
> 5 features:
> +-- 4 elements
> +-- 1 device providers
>
> I still have the H1 encoder enabled, but I know JPEG isn't supported,
> so I'm going to attempt to do some decoding and pipe to fakesink since
> I don't have a functional display yet.
>
> gst-launch-1.0 -ev filesrc location=trailer_1080p_h264_mp3.avi !
> decodebin3 ! fakesink
>
> Redistribute latency...
> /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:src:
> caps = video/x-raw, format=(string)NV12, width=(int)1920,
> height=(int)1080, interlace-mode=(string)progressive,
> multiview-mode=(string)mono,
> multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0:
> caps = video/x-raw, format=(string)NV12, width=(int)1920,
> height=(int)1080, interlace-mode=(string)progressive,
> multiview-mode=(string)mono,
> multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0.GstProxyPad:proxypad6:
> caps = video/x-raw, format=(string)NV12, width=(int)1920,
> height=(int)1080, interlace-mode=(string)progressive,
> multiview-mode=(string)mono,
> multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/GstMultiQueue:multiqueue0:
> min-interleave-time = 300000000
> Redistribute latency...
> /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:sink:
> caps = video/x-h264, variant=(string)itu, framerate=(fraction)25/1,
> width=(int)1920, height=(int)1080, chroma-format=(string)4:2:0,
> bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8,
> parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au,
> profile=(string)high, level=(string)4,
> codec_data=(buffer)01640028ffe1001a67640028acd940780227e584000003000400000300c83c60c65801000668ebe3cb22c0
> New clock: GstSystemClock
>
> And it appears to stream, because the counter increases. I haven't
> checked the CPU utilization, but the fact that it shows v4l2slh264dec
> is good.
>
> Is there a way to know if/how the decoder is using the proper VPU? I
> assume if it wasn't using the proper one, it would fail, but was just
> curious.
>
A few ways. You can check /proc/interrupts, which should have
VPU activity.
Or enable debug messages for the module,
using the debug hantro parameter. V4L2 has debug messages
that you can enable, see /sys/class/video4linux/video0/dev_debug.
Instead of fakesink you can output to pngenc/jpegenc and check the output
is visually correct. If at all possible, the proper way is to use Fluster,
and report the score you get:
https://github.com/fluendo/fluster
It should be easy to use.
> I think I'll redo the patch without the RFC and without the H1 encoder
> unless anyone has any objections. I know I need to rebase on
> linux-next anyway because the patches don't apply cleanly. Is there a
> specific branch I should use? I don't know if this goes through
> Shawn's IMX tree or the media tree (or a combination)
>
You should rebase on media's master branch:
https://git.linuxtv.org/media_tree.git/log/
Thanks,
Ezequiel
On Mon, Nov 29, 2021 at 10:54 AM Ezequiel Garcia
<[email protected]> wrote:
>
> On Mon, 29 Nov 2021 at 13:48, Adam Ford <[email protected]> wrote:
> >
> > On Tue, Nov 23, 2021 at 2:07 PM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Le lundi 22 novembre 2021 à 09:25 -0800, Tim Harvey a écrit :
> > > > On Sat, Nov 20, 2021 at 7:36 AM Adam Ford <[email protected]> wrote:
> > > > >
> > > > > On Fri, Nov 19, 2021 at 5:37 PM Adam Ford <[email protected]> wrote:
> > > > > >
> > > > > > On Fri, Nov 19, 2021 at 10:29 AM Nicolas Dufresne <[email protected]> wrote:
> > > > > > >
> > > > > > > Hi Adam, Tim,
> > > > > > >
> > > > > > > [...]
> > > > > > > > > > > Nicolas and Adam,
> > > > > > > > > > >
> > > > > > > > > > > For the H1 patches in this series: I've been able to test the IMX8MM
> > > > > > > > > > > H1 JPEG encode using GStreamer 1.18.5:
> > > > > > > > > > > $ gst-inspect-1.0 | grep -e "v4l2.*enc"
> > > > > > > > > > > video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
> > > > > > > > > > > $ gst-launch-1.0 videotestsrc ! jpegenc ! rtpjpegpay ! udpsink
> > > > > > > > > > ^ v4l2jpegenc
> > > > > > > > > >
> > > > > > > > > > This is just a transcript error ?
> > > > > > > > >
> > > > > > > > > Nicolas,
> > > > > > > > >
> > > > > > > > > No! Thanks for catching my mistake. I was testing with software encode... ooops!
> > > > > > > > >
> > > > > > > > > 'gst-launch-1.0 videotestsrc ! v4l2jpegenc ! fakesink' actually hangs
> > > > > > > > > the board so likely a power-domain issue there?
> > > > > > > >
> > > > > > > > The v4l2-compliance tests fail on the h1 decoder with a hang, but I
> > > > > > > > think we're writing to registers which are not documented in the Mini
> > > > > > > > TRM. The Mini TRM doesn't explicitly show the JPEG encoding as a
> > > > > > > > feature, but some of the registers state JPEG, but because some of the
> > > > > > > > registers written for the H1 are not documented in the TRM. If those
> > > > > > > > registers are restricted or not in this SoC, I am concerned that it
> > > > > > > > might be related. I'll try to run some more tests this weekend to
> > > > > > > > check on the status of the power-domain stuff.
> > > > > > >
> > > > > > > To verify if the HW support JPEG encoding you can read SWREG63 bit 25. This is
> > > > > > > in the TRM, just not labelled properly. To mimic the decoding side, would be "HW
> > > > > > > synthesis config register X" with the bit labelled SW_ENC_JPEG_PROF (but
> > > > > > > PROF/profile is on or off). If your board hang while reading this, you likely
> > > > > > > didn't get the power bit right.
> > > > > > >
> > > > > > > IMX8 has an undocumented control block thing that we have been fighting with in
> > > > > > > imx8q, perhaps that's your issue. Few driver was proposed, we are still pending
> > > > > > > on NXP solution to be submitted (they asked us to wait, still waiting =)).
> > > > > >
> > > > > > Nicolas,
> > > > > >
> > > > > > Thanks for the suggestion to read offset FC. There was an attempt
> > > > > > made by Lucas Stach to develop a VPU blk-ctrl driver to coordinate the
> > > > > > power-domains with the GPC driver. Unfortunately, it does appear to
> > > > > > hang, so it might not be operating correctly.
> > > > > >
> > > > > > Lucas,
> > > > > >
> > > > > > Do you have any idea of stuff I can try to see if the power domain is
> > > > > > coming online correctly?
> > > > > >
> > > > > > [ 10.434727] imx-pgc imx-pgc-domain.6: request the vpumix domain to power up
> > > > > > [ 10.463647] imx-pgc imx-pgc-domain.6: request the vpumix ADB400 to power up
> > > > > > [ 10.517155] imx-pgc imx-pgc-domain.6: genpd vpumix success
> > > > > > [ 10.728927] vpu: set fuse bits to enable
> > > > > > [ 10.825500] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g1 GPC domain
> > > > > > [ 10.878986] imx-pgc imx-pgc-domain.7: request the vpu-g1 domain to power up
> > > > > > [ 10.932429] imx-pgc imx-pgc-domain.7: genpd vpu-g1 success
> > > > > > [ 10.971988] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g1 success
> > > > > > [ 11.004726] hantro-vpu 38300000.video-codec: registered
> > > > > > nxp,imx8mm-vpu-dec as /dev/video0
> > > > > > [ 11.040760] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-g2 GPC domain
> > > > > > [ 11.066181] imx-pgc imx-pgc-domain.8: request the vpu-g2 domain to power up
> > > > > > [ 11.087887] imx-pgc imx-pgc-domain.8: genpd vpu-g2 success
> > > > > > [ 11.113808] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-g2 success
> > > > > > [ 11.139634] hantro-vpu 38310000.video-codec: registered
> > > > > > nxp,imx8mm-vpu-g2-dec as /dev/video1
> > > > > > [ 11.156463] imx8m-blk-ctrl 38330000.blk-ctrl: power vpublk-h1 GPC domain
> > > > > > [ 11.170817] imx-pgc imx-pgc-domain.9: request the vpu-h1 domain to power up
> > > > > > [ 11.232990] imx-pgc imx-pgc-domain.9: genpd vpu-h1 success
> > > > > > [ 11.252546] imx8m-blk-ctrl 38330000.blk-ctrl: genpd vpublk-h1 success
> > > > > > [ 11.266152] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > > > >
> > > > > > <hang>
> > > > > >
> > > > > > adam
> > > > > >
> > > > >
> > > > > Nicolas, Tim, and Lucas,
> > > > >
> > > > > I think I have the hanging resolved in the power domains, and I'll be
> > > > > pushing the fix to the GPCv2.
> > > > >
> > > > > For the H1 Encoder, I added some debugging code to read the offset
> > > > > 0xfc and print some data based on the findings of that VPU-h1 offset.
> > > > > I basically check the various bits per the TRM to see if they are set
> > > > > and print some splat to indicate whether or not the function is
> > > > > supported.
> > > > >
> > > > > [ 8.861865] hantro-vpu 38320000.video-codec: Checking vpu->enc_base + 0xfc
> > > > > [ 8.870594] hantro-vpu 38320000.video-codec: Stabilization supported by HW
> > > > > [ 8.889341] hantro-vpu 38320000.video-codec: VP8 encoding supported by HW
> > > > > [ 8.899386] hantro-vpu 38320000.video-codec: H.264 encoding supported by HW
> > > > > [ 8.918171] hantro-vpu 38320000.video-codec: RGB to YUV conversion
> > > > > supported by HW
> > > > > [ 8.934067] hantro-vpu 38320000.video-codec: registered
> > > > > nxp,imx8mm-vpu-h1-enc as /dev/video2
> > > > >
> > > > > Unfortunately, JPEG is not listed as supported. :-(
> > > >
> > > > Adam,
> > > >
> > > > Well not having JPEG encode support is unfortunate, and unexpected. Do
> > > > we not have hantro support yet for VP8/H264 encode?
> > >
> > > There is no mainline support yet. You can derive from RK3288 support using Google ChromeOS method (a v4l2 plugins that simulate in userspace a stateful encoder):
> > >
> > > - libv4l plugins / https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
> > > - Kernel Driver / https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/
> > >
> > > >
> > > > I haven't quite figured out how to build a modern mono-repo gstreamer
> > > > on the ubuntu 20.04 rootfs I'm using so I haven't been able to test
> > > > VPU encode/decode properly. I'll keep working on it when I'm back in
> > > > the office the following week.
> > >
> > > Did a quick test to make sure there isn't any ubuntu specific blockers, here's a
> > > dirty script that produce a minimal GStreamer, there was really nothing special
> > > compare to other meson projects. Note that I use --wrap-mode=nofallback to avoid
> > > letting GStreamer complete it's feature-set by downloading the planet. This
> > > already build quite a lot and could likely be made smaller by avoid plugins-good
> > > build-dep call, but then you need to check for v4l2odecs and video4linux devs
> > > (mostly gudev a glib udev binding).
> > >
> > > # Install ubuntu
> > > podman run -it --rm ubuntu:20.04
> > > sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
> > > apt update
> > > apt build-dep gstreamer1.0-plugins-good
> > > apt install git python3-pip flex bison
> > >
> > > # Need a newer meson
> > > pip3 install --user meson
> > > export PATH=$PATH:~/.local/bin
> > >
> > > # Build GStreamer
> > > git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git
> > > cd gstreamer
> > > meson setup build --wrap-mode=nofallback
> > > ninja -C build
> > >
> > > # Run in-place
> > > ./gst-env.py
> > > gst-inspect-1.0 v4l2codecs
> > > gst-inspect 1.0 video4linux2
> > >
> > Thanks for the suggestions.
> >
> > I downloaded what's in the master repo:
> >
> > [gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 v4l2codecs
> >
> > ** (gst-plugin-scanner:7317): CRITICAL **: 10:29:51.847: can't find
> > gi.repository.Gst
> > Plugin Details:
> > Name v4l2codecs
> > Description V4L2 CODEC Accelerators plugin
> > Filename
> > /root/gstreamer/builddir/subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so
> > Version 1.19.3.1
> > License LGPL
> > Source module gst-plugins-bad
> > Binary package GStreamer Bad Plug-ins git
> > Origin URL Unknown package origin
> >
> > v4l2slh264dec: V4L2 Stateless H.264 Video Decoder
> > v4l2slmpeg2dec: V4L2 Stateless Mpeg2 Video Decoder
> > v4l2slvp8alphadecodebin: VP8 Alpha Decoder
> > v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder
> >
> > 4 features:
> > +-- 4 elements
> >
> > [gst-main] root@localhost:~/gstreamer# gst-inspect-1.0 video4linux2
> > Plugin Details:
> > Name video4linux2
> > Description elements for Video 4 Linux
> > Filename
> > /root/gstreamer/builddir/subprojects/gst-plugins-good/sys/v4l2/libgstvideo4linux2.so
> > Version 1.19.3.1
> > License LGPL
> > Source module gst-plugins-good
> > Binary package GStreamer Good Plug-ins git
> > Origin URL Unknown package origin
> >
> > v4l2deviceprovider: Video (video4linux2) Device Provider
> > v4l2jpegenc: V4L2 JPEG Encoder
> > v4l2radio: Radio (video4linux2) Tuner
> > v4l2sink: Video (video4linux2) Sink
> > v4l2src: Video (video4linux2) Source
> >
> > 5 features:
> > +-- 4 elements
> > +-- 1 device providers
> >
> > I still have the H1 encoder enabled, but I know JPEG isn't supported,
> > so I'm going to attempt to do some decoding and pipe to fakesink since
> > I don't have a functional display yet.
> >
> > gst-launch-1.0 -ev filesrc location=trailer_1080p_h264_mp3.avi !
> > decodebin3 ! fakesink
> >
> > Redistribute latency...
> > /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:src:
> > caps = video/x-raw, format=(string)NV12, width=(int)1920,
> > height=(int)1080, interlace-mode=(string)progressive,
> > multiview-mode=(string)mono,
> > multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> > pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> > /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0:
> > caps = video/x-raw, format=(string)NV12, width=(int)1920,
> > height=(int)1080, interlace-mode=(string)progressive,
> > multiview-mode=(string)mono,
> > multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> > pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> > /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0.GstGhostPad:video_0.GstProxyPad:proxypad6:
> > caps = video/x-raw, format=(string)NV12, width=(int)1920,
> > height=(int)1080, interlace-mode=(string)progressive,
> > multiview-mode=(string)mono,
> > multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono,
> > pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)25/1
> > /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/GstMultiQueue:multiqueue0:
> > min-interleave-time = 300000000
> > Redistribute latency...
> > /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/v4l2slh264dec:v4l2slh264dec0.GstPad:sink:
> > caps = video/x-h264, variant=(string)itu, framerate=(fraction)25/1,
> > width=(int)1920, height=(int)1080, chroma-format=(string)4:2:0,
> > bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8,
> > parsed=(boolean)true, stream-format=(string)avc, alignment=(string)au,
> > profile=(string)high, level=(string)4,
> > codec_data=(buffer)01640028ffe1001a67640028acd940780227e584000003000400000300c83c60c65801000668ebe3cb22c0
> > New clock: GstSystemClock
> >
> > And it appears to stream, because the counter increases. I haven't
> > checked the CPU utilization, but the fact that it shows v4l2slh264dec
> > is good.
> >
> > Is there a way to know if/how the decoder is using the proper VPU? I
> > assume if it wasn't using the proper one, it would fail, but was just
> > curious.
> >
>
> A few ways. You can check /proc/interrupts, which should have
> VPU activity.
>
> Or enable debug messages for the module,
> using the debug hantro parameter. V4L2 has debug messages
> that you can enable, see /sys/class/video4linux/video0/dev_debug.
>
> Instead of fakesink you can output to pngenc/jpegenc and check the output
> is visually correct. If at all possible, the proper way is to use Fluster,
> and report the score you get:
>
> https://github.com/fluendo/fluster
>
I ran fluster on the VP8 decoder, but only 55/61 passed.
****************************************************************************************************
Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0
Using 4 parallel job(s)
****************************************************************************************************
[TEST SUITE ] (DECODER ) TEST VECTOR
... RESULT
----------------------------------------------------------------------
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-004 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-001 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-002 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-003 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-005 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-006 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-007 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-008 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-011 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-009 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-012 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-013 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-014 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-010 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-016 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-017 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-018 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-01-intra-1400
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-01-intra-1416
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-01-intra-1417
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-01-intra-1411
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-02-inter-1402
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-02-inter-1412
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-02-inter-1424
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-01 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-02 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-03 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-04 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1401 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-02-inter-1418
... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1403 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1407 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1408 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1409 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1413 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1415 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1425 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1426 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1427 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1432 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1435 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1436 ... Fail
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-00-comprehensive-015 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1441 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1437 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-04-partitions-1404 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1442 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-04-partitions-1405 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-04-partitions-1406 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1428 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1429 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1431 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1410 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-03-segmentation-1414 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1430 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1433 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1438 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1434 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1439 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1440 ... Success
[VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0)
vp80-05-sharpness-1443 ... Success
=======================================================================
FAIL: vp80-03-segmentation-01 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: 'db954c077b7a3f34a448ceaacf8f525c' !=
'8bbb396a9bdf8afa250d3b2e45e6b367'
- db954c077b7a3f34a448ceaacf8f525c
+ 8bbb396a9bdf8afa250d3b2e45e6b367
: vp80-03-segmentation-01
=======================================================================
FAIL: vp80-03-segmentation-02 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: '4d2d65efeee1c83772c33a13446bd1a4' !=
'1b2061d4a74549228769f8e292bcb15f'
- 4d2d65efeee1c83772c33a13446bd1a4
+ 1b2061d4a74549228769f8e292bcb15f
: vp80-03-segmentation-02
=======================================================================
FAIL: vp80-03-segmentation-03 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: '73d864433691f8db43257b88495ac8c3' !=
'fd1eb6ebd7100995bad11042a9bea048'
- 73d864433691f8db43257b88495ac8c3
+ fd1eb6ebd7100995bad11042a9bea048
: vp80-03-segmentation-03
=======================================================================
FAIL: vp80-03-segmentation-04 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: '7f846c8bd7cdfe61f8542f382f9d8eeb' !=
'0c27a47c4fd8bbfce173d005bef8be6a'
- 7f846c8bd7cdfe61f8542f382f9d8eeb
+ 0c27a47c4fd8bbfce173d005bef8be6a
: vp80-03-segmentation-04
=======================================================================
FAIL: vp80-03-segmentation-1425 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: '96ffacf0c3eae59b58252be24a60e9b2' !=
'83e8a322e8ab23e60ba16430aacad827'
- 96ffacf0c3eae59b58252be24a60e9b2
+ 83e8a322e8ab23e60ba16430aacad827
: vp80-03-segmentation-1425
=======================================================================
FAIL: vp80-03-segmentation-1436 (GStreamer-VP8-V4L2SL-Gst1.0.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/gstreamer/fluster/fluster/test.py", line 104, in _test
self.assertEqual(
AssertionError: 'bfd17a557ee1ba347c755a18ce5a64a6' !=
'5bca61a733c1936205f82de1492a1b2b'
- bfd17a557ee1ba347c755a18ce5a64a6
+ 5bca61a733c1936205f82de1492a1b2b
: vp80-03-segmentation-1436
Ran 55/61 tests successfully in 12.104 secs
I am not that familiar with this tool, but I assume failures are bad.
However these look like Python errors and not gst errors.
The H264 decoder resulted in:
Ran 85/135 tests successfully in 57.821 secs
I can provide the splat if you want. Those looked like gst errors,
because most of the error messages state the gst-launch-1.0 returned
non-zero exit status 1.
> It should be easy to use.
It was.
>
> > I think I'll redo the patch without the RFC and without the H1 encoder
> > unless anyone has any objections. I know I need to rebase on
> > linux-next anyway because the patches don't apply cleanly. Is there a
> > specific branch I should use? I don't know if this goes through
> > Shawn's IMX tree or the media tree (or a combination)
> >
>
> You should rebase on media's master branch:
>
> https://git.linuxtv.org/media_tree.git/log/
I'll submit the patch with a cover letter with the results of the VP8
and H264 fluster test in the cover letter. Is there a stateless
decoder for the VP9 decoder? gst-inspect only shows the following
v4l2codecs.
v4l2slh264dec: V4L2 Stateless H.264 Video Decoder
v4l2slmpeg2dec: V4L2 Stateless Mpeg2 Video Decoder
v4l2slvp8alphadecodebin: VP8 Alpha Decoder
v4l2slvp8dec: V4L2 Stateless VP8 Video Decoder
thanks for all your help. Hopefully we can get this integrated soon.
adam
>
> Thanks,
> Ezequiel