2021-11-06 18:38:27

by Adam Ford

[permalink] [raw]
Subject: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

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.

The i.MX8MM also has a Hantro video encoder which appears to be similar
to what's already supported in some Rockchip devices. As part of the
series, some of the video format names are re-named to be more generic.

The VPUs appear as media devices:

Media device information
------------------------
driver hantro-vpu
model hantro-vpu
serial
bus info platform: hantro-vpu
hw revision 0x0
driver version 5.15.0

Device topology
- entity 1: nxp,imx8mm-vpu-dec-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Source
-> "nxp,imx8mm-vpu-dec-proc":0 [ENABLED,IMMUTABLE]

- entity 3: nxp,imx8mm-vpu-dec-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "nxp,imx8mm-vpu-dec-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "nxp,imx8mm-vpu-dec-sink":0 [ENABLED,IMMUTABLE]

- entity 6: nxp,imx8mm-vpu-dec-sink (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "nxp,imx8mm-vpu-dec-proc":1 [ENABLED,IMMUTABLE]



Media device information
------------------------
driver hantro-vpu
model hantro-vpu
serial
bus info platform: hantro-vpu
hw revision 0x0
driver version 5.15.0

Device topology
- entity 1: nxp,imx8mm-vpu-g2-dec-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video2
pad0: Source
-> "nxp,imx8mm-vpu-g2-dec-proc":0 [ENABLED,IMMUTABLE]

- entity 3: nxp,imx8mm-vpu-g2-dec-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "nxp,imx8mm-vpu-g2-dec-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "nxp,imx8mm-vpu-g2-dec-sink":0 [ENABLED,IMMUTABLE]

- entity 6: nxp,imx8mm-vpu-g2-dec-sink (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video2
pad0: Sink
<- "nxp,imx8mm-vpu-g2-dec-proc":1 [ENABLED,IMMUTABLE]



Media device information
------------------------
driver hantro-vpu
model hantro-vpu
serial
bus info platform: hantro-vpu
hw revision 0x0
driver version 5.15.0

Device topology
- entity 1: nxp,imx8mm-vpu-h1-enc-source (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Source
-> "nxp,imx8mm-vpu-h1-enc-proc":0 [ENABLED,IMMUTABLE]

- entity 3: nxp,imx8mm-vpu-h1-enc-proc (2 pads, 2 links)
type Node subtype Unknown flags 0
pad0: Sink
<- "nxp,imx8mm-vpu-h1-enc-source":0 [ENABLED,IMMUTABLE]
pad1: Source
-> "nxp,imx8mm-vpu-h1-enc-sink":0 [ENABLED,IMMUTABLE]

- entity 6: nxp,imx8mm-vpu-h1-enc-sink (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Sink
<- "nxp,imx8mm-vpu-h1-enc-proc":1 [ENABLED,IMMUTABLE]

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 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.

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(-)

--
2.32.0



2021-11-29 21:24:32

by Tim Harvey

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
>
> 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,

What deps did you install in order to get v4l2codecs building? I
installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
(not sure if I needed to re-configure somehow) but there is still
nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
how to find out what dependencies are needed or what may be missing.

Best regards,

Tim

2021-11-29 22:37:39

by Adam Ford

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Mon, Nov 29, 2021 at 1:36 PM Tim Harvey <[email protected]> wrote:
>
> On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> >
> > 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,
>
> What deps did you install in order to get v4l2codecs building? I
> installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> (not sure if I needed to re-configure somehow) but there is still
> nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> how to find out what dependencies are needed or what may be missing.

Instead of building just a limited release of gstreamer, I had to
build the whole thing.

meson builddir
ninja -C builddir -j2

running with -j4 ran the imx8mm out of memory and slowed to a crawl to
the point where it didn't finish even after building overnight.

With that, I was able to execute gst-env.py to run streamer without
installing it. In that environment, I was able to run fluster to get
the results I published.

adam
>
> Best regards,
>
> Tim

2021-11-30 14:00:49

by Ezequiel Garcia

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Hi Tim,

On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
>
> On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
..
> >
>
> Adam,
>
> What deps did you install in order to get v4l2codecs building? I
> installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> (not sure if I needed to re-configure somehow) but there is still
> nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> how to find out what dependencies are needed or what may be missing.
>

At least in my case (Centps-derivative), this is what I've done:

...
gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
pkgconfig and cmake)

Installed gudev ... and then:

...
gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
...
gst-plugins-bad 1.19.3.1

Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
audiovisualizers, autoconvert, bayer,
camerabin, codecalpha, coloreffects,
debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
festival, fieldanalysis, freeverb, frei0r,
gaudieffects, gdp, geometrictransform,
id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
rfbsrc, midi, mpegpsdemux,
mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
removesilence, rist, rtmp2, rtpmanagerbad,
sdpelem, segmentclip, siren, smooth,
speed, subenc, switchbin, timecode, transcode, videofiltersbad,
videoframe_audiolevel, videoparsersbad,
videosignal, vmnc, y4mdec, decklink, dvb,
fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp

GStreamer current master build fails. It's a known issue which will be
fixed today:

[...]
[8/9] Compiling C object
subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
-Isubprojects/gst-plugins-bad/sys/v4l2codecs
-I../subprojects/gst-plugins-bad/sys/v4l2codecs
-Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
-Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
-Isubprojects/gstreamer -I../subprojects/gstreamer
-Isubprojects/gst-plugins-bad/gst-libs
-I../subprojects/gst-plugins-bad/gst-libs
-Isubprojects/gst-plugins-base/gst-libs
-I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
-I../subprojects/orc -Isubprojects/gstreamer/gst
-Isubprojects/gst-plugins-base/gst-libs/gst/video
-Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
-Isubprojects/gst-plugins-base/gst-libs/gst/audio
-Isubprojects/gst-plugins-base/gst-libs/gst/tag
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/gudev-1.0 -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
-fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
-Wdeclaration-after-statement -Wold-style-definition
-Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
-Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
-Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
-MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
-MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
-o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
-c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
error: unknown type name ‘grefcount’
grefcount ref_count;
^~~~~~~~~
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
warning: implicit declaration of function ‘g_ref_count_init’; did you
mean ‘g_cond_init’? [-Wimplicit-function-declaration]
g_ref_count_init (&pic_data->ref_count);
^~~~~~~~~~~~~~~~
g_cond_init
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
warning: implicit declaration of function ‘g_ref_count_inc’; did you
mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
g_ref_count_inc (&data->ref_count);
^~~~~~~~~~~~~~~
g_strv_contains
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
warning: implicit declaration of function ‘g_ref_count_dec’
[-Wimplicit-function-declaration]
if (g_ref_count_dec (&data->ref_count)) {
^~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.

Hope this helps get you started!
Ezequiel

2021-11-30 19:28:56

by Tim Harvey

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
<[email protected]> wrote:
>
> Hi Tim,
>
> On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> >
> > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> ..
> > >
> >
> > Adam,
> >
> > What deps did you install in order to get v4l2codecs building? I
> > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > (not sure if I needed to re-configure somehow) but there is still
> > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > how to find out what dependencies are needed or what may be missing.
> >
>
> At least in my case (Centps-derivative), this is what I've done:
>
> ...
> gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> pkgconfig and cmake)
>
> Installed gudev ... and then:
>
> ...
> gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> ...
> gst-plugins-bad 1.19.3.1
>
> Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> audiovisualizers, autoconvert, bayer,
> camerabin, codecalpha, coloreffects,
> debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> festival, fieldanalysis, freeverb, frei0r,
> gaudieffects, gdp, geometrictransform,
> id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> rfbsrc, midi, mpegpsdemux,
> mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> removesilence, rist, rtmp2, rtpmanagerbad,
> sdpelem, segmentclip, siren, smooth,
> speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> videoframe_audiolevel, videoparsersbad,
> videosignal, vmnc, y4mdec, decklink, dvb,
> fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
>
> GStreamer current master build fails. It's a known issue which will be
> fixed today:
>
> [...]
> [8/9] Compiling C object
> subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> -Isubprojects/gstreamer -I../subprojects/gstreamer
> -Isubprojects/gst-plugins-bad/gst-libs
> -I../subprojects/gst-plugins-bad/gst-libs
> -Isubprojects/gst-plugins-base/gst-libs
> -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> -I../subprojects/orc -Isubprojects/gstreamer/gst
> -Isubprojects/gst-plugins-base/gst-libs/gst/video
> -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> -Wdeclaration-after-statement -Wold-style-definition
> -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> error: unknown type name ‘grefcount’
> grefcount ref_count;
> ^~~~~~~~~
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> warning: implicit declaration of function ‘g_ref_count_init’; did you
> mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> g_ref_count_init (&pic_data->ref_count);
> ^~~~~~~~~~~~~~~~
> g_cond_init
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> warning: implicit declaration of function ‘g_ref_count_inc’; did you
> mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> g_ref_count_inc (&data->ref_count);
> ^~~~~~~~~~~~~~~
> g_strv_contains
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> warning: implicit declaration of function ‘g_ref_count_dec’
> [-Wimplicit-function-declaration]
> if (g_ref_count_dec (&data->ref_count)) {
> ^~~~~~~~~~~~~~~
> ninja: build stopped: subcommand failed.
>
> Hope this helps get you started!
> Ezequiel

Ezequiel and Nicolas,

Thanks - I did manage to get gstreamer 1.19.3 built successfully with
v4l2codecs finally by getting the correct dependencies. I've attempted
to software encode from another system and decode/display on the IMX8M
Mini but thus far have not been successful.

I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
and these all can output video/x-raw NV12/YUY2 which kmssink should
accept so I'm attempting the following :

# vp8 encode from x86
gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
# vp8 decode on [email protected] which has a 800x480 display
[gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
v4l2slvp8dec ! kmssink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
/GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
/GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
application/x-rtp, media=(string)video, clock-rate=(int)90000,
encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
a-framerate=(string)30
New clock: GstSystemClock
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
application/x-rtp, media=(string)video, clock-rate=(int)90000,
encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
a-framerate=(string)30
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
profile=(string)0
ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
data stream error.
Additional debug info:
../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:02.076839644
Setting pipeline to NULL ...
Freeing pipeline ...

I'm getting the same thing when trying to use h264.

I've never quite been able to grasp how to debug GStreamer's
negotiation issues. If I end with fakesink it appears to decode so it
must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
I still get the negotiation error.

What interrupts should I be seeing in /proc/interrupts? I don't see
anything vpu/hantro related there.

I also want to make sure I have a basic understanding of the vpu
drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
familiar with has a vpu that is supported by the GStreamer video4linux
plugin which shows the following (on GStreamer 1.16.2):
v4l2jpegenc: V4L2 JPEG Encoder
v4l2jpegdec: V4L2 JPEG Decoder
v4l2h264enc: V4L2 H.264 Encoder
v4l2mpeg4enc: V4L2 MPEG4 Encoder
v4l2mpeg4dec: V4L2 MPEG4 Decoder
v4l2mpeg2dec: V4L2 MPEG2 Decoder
v4l2h264dec: V4L2 H264 Decoder
The IMX6Q/DL also has an IPU that has an M2M driver that provides the
following for scaling/colorspace conversion:
v4l2convert: V4L2 Video Converter

I believe what I'm reading is that the IMX8M Mini Hantro codecs are
'stateful' where more software is required to drive them and is
supported by the newer v4l2codecs plugin. I haven't been able to
understand what kernel version/requirements the v4l2codecs plugin
users/requires.

I'm also trying to understand how we can get scaling/colorspace
conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
way to utilize scaling/colorspace conversion from the 2D GPU bound to
the etnaviv driver?

Best regards,

Tim

2021-11-30 20:33:18

by Adam Ford

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Tue, Nov 30, 2021 at 1:28 PM Tim Harvey <[email protected]> wrote:
>
> On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> <[email protected]> wrote:
> >
> > Hi Tim,
> >
> > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > >
> > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > ..
> > > >
> > >
> > > Adam,
> > >
> > > What deps did you install in order to get v4l2codecs building? I
> > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > (not sure if I needed to re-configure somehow) but there is still
> > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > how to find out what dependencies are needed or what may be missing.
> > >
> >
> > At least in my case (Centps-derivative), this is what I've done:
> >
> > ...
> > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > pkgconfig and cmake)
> >
> > Installed gudev ... and then:
> >
> > ...
> > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > ...
> > gst-plugins-bad 1.19.3.1
> >
> > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > audiovisualizers, autoconvert, bayer,
> > camerabin, codecalpha, coloreffects,
> > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > festival, fieldanalysis, freeverb, frei0r,
> > gaudieffects, gdp, geometrictransform,
> > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > rfbsrc, midi, mpegpsdemux,
> > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > removesilence, rist, rtmp2, rtpmanagerbad,
> > sdpelem, segmentclip, siren, smooth,
> > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > videoframe_audiolevel, videoparsersbad,
> > videosignal, vmnc, y4mdec, decklink, dvb,
> > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> >
> > GStreamer current master build fails. It's a known issue which will be
> > fixed today:
> >
> > [...]
> > [8/9] Compiling C object
> > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > -Isubprojects/gst-plugins-bad/gst-libs
> > -I../subprojects/gst-plugins-bad/gst-libs
> > -Isubprojects/gst-plugins-base/gst-libs
> > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > -Wdeclaration-after-statement -Wold-style-definition
> > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > error: unknown type name ‘grefcount’
> > grefcount ref_count;
> > ^~~~~~~~~
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > g_ref_count_init (&pic_data->ref_count);
> > ^~~~~~~~~~~~~~~~
> > g_cond_init
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > g_ref_count_inc (&data->ref_count);
> > ^~~~~~~~~~~~~~~
> > g_strv_contains
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > warning: implicit declaration of function ‘g_ref_count_dec’
> > [-Wimplicit-function-declaration]
> > if (g_ref_count_dec (&data->ref_count)) {
> > ^~~~~~~~~~~~~~~
> > ninja: build stopped: subcommand failed.
> >
> > Hope this helps get you started!
> > Ezequiel
>
> Ezequiel and Nicolas,
>
> Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> v4l2codecs finally by getting the correct dependencies. I've attempted
> to software encode from another system and decode/display on the IMX8M
> Mini but thus far have not been successful.

I will post a V2 last today with the Mini's post-processing removed.
Someone, I apologize that I forget who, mentioned it was fused out of
the Mini, so the testing I've been doing was with that removed and I
removed the H1 encoder since the Mini doesn't support JPEG encoding.

I don't understand the YAML very well, and I'm struggling with the
dt-bindings which is the main reason I havne't submitted a formal
patch yet.

To date, I have only tested with v4l2-compliance and with the fluster
app that was recommended.

>
> I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> and these all can output video/x-raw NV12/YUY2 which kmssink should
> accept so I'm attempting the following :
>
> # vp8 encode from x86
> gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> # vp8 decode on [email protected] which has a 800x480 display
> [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> v4l2slvp8dec ! kmssink
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> a-framerate=(string)30
> New clock: GstSystemClock
> /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> a-framerate=(string)30
> /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> profile=(string)0
> ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> data stream error.
> Additional debug info:
> ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> streaming stopped, reason not-negotiated (-4)
> Execution ended after 0:00:02.076839644
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> I'm getting the same thing when trying to use h264.
>
> I've never quite been able to grasp how to debug GStreamer's
> negotiation issues. If I end with fakesink it appears to decode so it
> must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> I still get the negotiation error.
>
> What interrupts should I be seeing in /proc/interrupts? I don't see
> anything vpu/hantro related there.

I don't have my Mini with me right now, but with my current patch set
that I mentioned above, I am able to see the interrupts for the
video-codec@38300000 increase each time I run a test with fluster.


>
> I also want to make sure I have a basic understanding of the vpu
> drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> familiar with has a vpu that is supported by the GStreamer video4linux
> plugin which shows the following (on GStreamer 1.16.2):
> v4l2jpegenc: V4L2 JPEG Encoder
> v4l2jpegdec: V4L2 JPEG Decoder
> v4l2h264enc: V4L2 H.264 Encoder
> v4l2mpeg4enc: V4L2 MPEG4 Encoder
> v4l2mpeg4dec: V4L2 MPEG4 Decoder
> v4l2mpeg2dec: V4L2 MPEG2 Decoder
> v4l2h264dec: V4L2 H264 Decoder
> The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> following for scaling/colorspace conversion:
> v4l2convert: V4L2 Video Converter
>
> I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> 'stateful' where more software is required to drive them and is
> supported by the newer v4l2codecs plugin. I haven't been able to
> understand what kernel version/requirements the v4l2codecs plugin
> users/requires.
>
> I'm also trying to understand how we can get scaling/colorspace
> conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> way to utilize scaling/colorspace conversion from the 2D GPU bound to
> the etnaviv driver?
>
> Best regards,
>
> Tim

2021-12-03 04:34:25

by Nicolas Dufresne

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le mardi 30 novembre 2021 à 11:28 -0800, Tim Harvey a écrit :
> On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> <[email protected]> wrote:
> >
> > Hi Tim,
> >
> > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > >
> > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > ..
> > > >
> > >
> > > Adam,
> > >
> > > What deps did you install in order to get v4l2codecs building? I
> > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > (not sure if I needed to re-configure somehow) but there is still
> > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > how to find out what dependencies are needed or what may be missing.
> > >
> >
> > At least in my case (Centps-derivative), this is what I've done:
> >
> > ...
> > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > pkgconfig and cmake)
> >
> > Installed gudev ... and then:
> >
> > ...
> > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > ...
> > gst-plugins-bad 1.19.3.1
> >
> > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > audiovisualizers, autoconvert, bayer,
> > camerabin, codecalpha, coloreffects,
> > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > festival, fieldanalysis, freeverb, frei0r,
> > gaudieffects, gdp, geometrictransform,
> > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > rfbsrc, midi, mpegpsdemux,
> > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > removesilence, rist, rtmp2, rtpmanagerbad,
> > sdpelem, segmentclip, siren, smooth,
> > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > videoframe_audiolevel, videoparsersbad,
> > videosignal, vmnc, y4mdec, decklink, dvb,
> > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> >
> > GStreamer current master build fails. It's a known issue which will be
> > fixed today:
> >
> > [...]
> > [8/9] Compiling C object
> > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > -Isubprojects/gst-plugins-bad/gst-libs
> > -I../subprojects/gst-plugins-bad/gst-libs
> > -Isubprojects/gst-plugins-base/gst-libs
> > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > -Wdeclaration-after-statement -Wold-style-definition
> > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > error: unknown type name ‘grefcount’
> > grefcount ref_count;
> > ^~~~~~~~~
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > g_ref_count_init (&pic_data->ref_count);
> > ^~~~~~~~~~~~~~~~
> > g_cond_init
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > g_ref_count_inc (&data->ref_count);
> > ^~~~~~~~~~~~~~~
> > g_strv_contains
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > warning: implicit declaration of function ‘g_ref_count_dec’
> > [-Wimplicit-function-declaration]
> > if (g_ref_count_dec (&data->ref_count)) {
> > ^~~~~~~~~~~~~~~
> > ninja: build stopped: subcommand failed.
> >
> > Hope this helps get you started!
> > Ezequiel
>
> Ezequiel and Nicolas,
>
> Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> v4l2codecs finally by getting the correct dependencies. I've attempted
> to software encode from another system and decode/display on the IMX8M
> Mini but thus far have not been successful.
>
> I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> and these all can output video/x-raw NV12/YUY2 which kmssink should
> accept so I'm attempting the following :
>
> # vp8 encode from x86
> gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> # vp8 decode on [email protected] which has a 800x480 display
> [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> v4l2slvp8dec ! kmssink
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> a-framerate=(string)30
> New clock: GstSystemClock
> /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> application/x-rtp, media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> a-framerate=(string)30
> /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> profile=(string)0
> ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> data stream error.
> Additional debug info:
> ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> streaming stopped, reason not-negotiated (-4)
> Execution ended after 0:00:02.076839644
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> I'm getting the same thing when trying to use h264.
>
> I've never quite been able to grasp how to debug GStreamer's
> negotiation issues. If I end with fakesink it appears to decode so it
> must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> I still get the negotiation error.
>
> What interrupts should I be seeing in /proc/interrupts? I don't see
> anything vpu/hantro related there.
>
> I also want to make sure I have a basic understanding of the vpu
> drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> familiar with has a vpu that is supported by the GStreamer video4linux
> plugin which shows the following (on GStreamer 1.16.2):
> v4l2jpegenc: V4L2 JPEG Encoder
> v4l2jpegdec: V4L2 JPEG Decoder
> v4l2h264enc: V4L2 H.264 Encoder
> v4l2mpeg4enc: V4L2 MPEG4 Encoder
> v4l2mpeg4dec: V4L2 MPEG4 Decoder
> v4l2mpeg2dec: V4L2 MPEG2 Decoder
> v4l2h264dec: V4L2 H264 Decoder
> The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> following for scaling/colorspace conversion:
> v4l2convert: V4L2 Video Converter
>
> I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> 'stateful' where more software is required to drive them and is

'stateless'. the rest is right.

> supported by the newer v4l2codecs plugin. I haven't been able to
> understand what kernel version/requirements the v4l2codecs plugin
> users/requires.

After H264 debacle with 5.9, 5.10 and 5.11 API break and GStreamer not getting
enough release to support all of these we started merging support for CODECs
only when the stable uAPI land. I made an exception for VP9 as it is already
applied in the media tree and didn't want to miss 1.20 release.

So to answer you question, it depends on when the CODEC uAPI landed.

>
> I'm also trying to understand how we can get scaling/colorspace
> conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> way to utilize scaling/colorspace conversion from the 2D GPU bound to
> the etnaviv driver?

The concept of the mini, is that you would be using th encoder for anything that
isn't going to the display. So they only integrated the Hantro PP on the
encoder. Unfortunately, you'll have to be patient for mainline stateless encoder
support, we barely scratch the surface of this subject, but its being worked on.
Unlike the IMX8MQ, you don't have the option to output YUYV (packed yuv 4:2:2)
which would satisfy the 2D GPU support hoold to the DMABuf import path.

When the display driver gets ready and upstream (it's been only 2-3 years now),
you'll get linear NV12 support along with G2 compression support (this one is
not supported by the GPU, so it will be tricky to expose in userland). I don't
think the display support 4L4 tiles, but you GPU most likely can do with the
right shared and texelFetch() or vulkan equivalent if that exist on that target.

>
> Best regards,
>
> Tim

regards,
Nicolas


2021-12-03 16:47:13

by Tim Harvey

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Thu, Dec 2, 2021 at 8:34 PM Nicolas Dufresne <[email protected]> wrote:
>
> Le mardi 30 novembre 2021 à 11:28 -0800, Tim Harvey a écrit :
> > On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> > <[email protected]> wrote:
> > >
> > > Hi Tim,
> > >
> > > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > > >
> > > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > > ..
> > > > >
> > > >
> > > > Adam,
> > > >
> > > > What deps did you install in order to get v4l2codecs building? I
> > > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > > (not sure if I needed to re-configure somehow) but there is still
> > > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > > how to find out what dependencies are needed or what may be missing.
> > > >
> > >
> > > At least in my case (Centps-derivative), this is what I've done:
> > >
> > > ...
> > > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > > pkgconfig and cmake)
> > >
> > > Installed gudev ... and then:
> > >
> > > ...
> > > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > > ...
> > > gst-plugins-bad 1.19.3.1
> > >
> > > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > > audiovisualizers, autoconvert, bayer,
> > > camerabin, codecalpha, coloreffects,
> > > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > > festival, fieldanalysis, freeverb, frei0r,
> > > gaudieffects, gdp, geometrictransform,
> > > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > > rfbsrc, midi, mpegpsdemux,
> > > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > > removesilence, rist, rtmp2, rtpmanagerbad,
> > > sdpelem, segmentclip, siren, smooth,
> > > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > > videoframe_audiolevel, videoparsersbad,
> > > videosignal, vmnc, y4mdec, decklink, dvb,
> > > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> > >
> > > GStreamer current master build fails. It's a known issue which will be
> > > fixed today:
> > >
> > > [...]
> > > [8/9] Compiling C object
> > > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > > -Isubprojects/gst-plugins-bad/gst-libs
> > > -I../subprojects/gst-plugins-bad/gst-libs
> > > -Isubprojects/gst-plugins-base/gst-libs
> > > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > > -Wdeclaration-after-statement -Wold-style-definition
> > > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > > error: unknown type name ‘grefcount’
> > > grefcount ref_count;
> > > ^~~~~~~~~
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > > g_ref_count_init (&pic_data->ref_count);
> > > ^~~~~~~~~~~~~~~~
> > > g_cond_init
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > > g_ref_count_inc (&data->ref_count);
> > > ^~~~~~~~~~~~~~~
> > > g_strv_contains
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > > warning: implicit declaration of function ‘g_ref_count_dec’
> > > [-Wimplicit-function-declaration]
> > > if (g_ref_count_dec (&data->ref_count)) {
> > > ^~~~~~~~~~~~~~~
> > > ninja: build stopped: subcommand failed.
> > >
> > > Hope this helps get you started!
> > > Ezequiel
> >
> > Ezequiel and Nicolas,
> >
> > Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> > v4l2codecs finally by getting the correct dependencies. I've attempted
> > to software encode from another system and decode/display on the IMX8M
> > Mini but thus far have not been successful.
> >
> > I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> > and these all can output video/x-raw NV12/YUY2 which kmssink should
> > accept so I'm attempting the following :
> >
> > # vp8 encode from x86
> > gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> > vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> > # vp8 decode on [email protected] which has a 800x480 display
> > [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> > udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> > clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> > ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> > seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> > v4l2slvp8dec ! kmssink
> > Setting pipeline to PAUSED ...
> > Pipeline is live and does not need PREROLL ...
> > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> > Pipeline is PREROLLED ...
> > Setting pipeline to PLAYING ...
> > /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > a-framerate=(string)30
> > New clock: GstSystemClock
> > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > a-framerate=(string)30
> > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> > video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> > profile=(string)0
> > ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> > data stream error.
> > Additional debug info:
> > ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> > gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> > streaming stopped, reason not-negotiated (-4)
> > Execution ended after 0:00:02.076839644
> > Setting pipeline to NULL ...
> > Freeing pipeline ...
> >
> > I'm getting the same thing when trying to use h264.
> >
> > I've never quite been able to grasp how to debug GStreamer's
> > negotiation issues. If I end with fakesink it appears to decode so it
> > must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> > using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> > I still get the negotiation error.
> >
> > What interrupts should I be seeing in /proc/interrupts? I don't see
> > anything vpu/hantro related there.
> >
> > I also want to make sure I have a basic understanding of the vpu
> > drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> > familiar with has a vpu that is supported by the GStreamer video4linux
> > plugin which shows the following (on GStreamer 1.16.2):
> > v4l2jpegenc: V4L2 JPEG Encoder
> > v4l2jpegdec: V4L2 JPEG Decoder
> > v4l2h264enc: V4L2 H.264 Encoder
> > v4l2mpeg4enc: V4L2 MPEG4 Encoder
> > v4l2mpeg4dec: V4L2 MPEG4 Decoder
> > v4l2mpeg2dec: V4L2 MPEG2 Decoder
> > v4l2h264dec: V4L2 H264 Decoder
> > The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> > following for scaling/colorspace conversion:
> > v4l2convert: V4L2 Video Converter
> >
> > I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> > 'stateful' where more software is required to drive them and is
>
> 'stateless'. the rest is right.
>
> > supported by the newer v4l2codecs plugin. I haven't been able to
> > understand what kernel version/requirements the v4l2codecs plugin
> > users/requires.
>
> After H264 debacle with 5.9, 5.10 and 5.11 API break and GStreamer not getting
> enough release to support all of these we started merging support for CODECs
> only when the stable uAPI land. I made an exception for VP9 as it is already
> applied in the media tree and didn't want to miss 1.20 release.
>
> So to answer you question, it depends on when the CODEC uAPI landed.
>

Ok, thanks for the explanation.

> >
> > I'm also trying to understand how we can get scaling/colorspace
> > conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> > way to utilize scaling/colorspace conversion from the 2D GPU bound to
> > the etnaviv driver?
>
> The concept of the mini, is that you would be using th encoder for anything that
> isn't going to the display. So they only integrated the Hantro PP on the
> encoder. Unfortunately, you'll have to be patient for mainline stateless encoder
> support, we barely scratch the surface of this subject, but its being worked on.

After some searching for Hantro PP I see that the IMXMQ (IMX8M
Dual/QuadLite/Quad) mentions Hantro PP. From the IMX8MDQLQRM section
14.1.2.1 Decoder Features:
<quote>
Video post-processing features
- Frame rotation 90 degrees left/right
- Frame mirroring horizontally/vertically
- Frame cropping
- Frame conversion from YCbCr formats to 16-bit or 32-bit RGB formats
- Frame scaling with maximum up-scaling factor of 3
- Two rectangular or alpha blending masks for output frame

The post-processing features can be used in pipeline with the
decoder. The postprocessing features can also be used as stand-alone,
without performing any decoding
</quote>

The above is under the VPU_G1 section and the same is not mentioned
for VPU_G2 and the IMX8MQ doesn't have encode support. Where do you
see that the IMX8MM has the Hantro PP on the H1? I know the TRM's lack
a lot of info so perhaps you know more about the internals than what
the TRM states.

I also found on a forum
(https://community.nxp.com/t5/i-MX-Processors/imx8mq-Hantro-G1-scaling/m-p/1285343)
that NXP's BSP doesn't use the Hantro for scaling (and likely not csc
either) and they use the GPU instead. I'm still unclear if/how you
could tap into the 2D GPU to use its scaling/conversion if it's bound
to the etnaviv driver.

> Unlike the IMX8MQ, you don't have the option to output YUYV (packed yuv 4:2:2)
> which would satisfy the 2D GPU support hoold to the DMABuf import path.
>
> When the display driver gets ready and upstream (it's been only 2-3 years now),
> you'll get linear NV12 support along with G2 compression support (this one is
> not supported by the GPU, so it will be tricky to expose in userland). I don't
> think the display support 4L4 tiles, but you GPU most likely can do with the
> right shared and texelFetch() or vulkan equivalent if that exist on that target.

Do you mean the Samsung Exynos DRM driver (which doesn't yet have
support for IMX8MM) or drivers/gpu/drm/mxsfb?

I'm currently using a pretty old patchset that adds IMX8MM support to
the drm/exynos driver. I'm way out of my realm when talking about
GPU/VPU and display drivers.

Best regards,

Tim

2021-12-03 19:37:35

by Nicolas Dufresne

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le vendredi 03 décembre 2021 à 08:46 -0800, Tim Harvey a écrit :
> On Thu, Dec 2, 2021 at 8:34 PM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le mardi 30 novembre 2021 à 11:28 -0800, Tim Harvey a écrit :
> > > On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> > > <[email protected]> wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > > > >
> > > > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > > > ..
> > > > > >
> > > > >
> > > > > Adam,
> > > > >
> > > > > What deps did you install in order to get v4l2codecs building? I
> > > > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > > > (not sure if I needed to re-configure somehow) but there is still
> > > > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > > > how to find out what dependencies are needed or what may be missing.
> > > > >
> > > >
> > > > At least in my case (Centps-derivative), this is what I've done:
> > > >
> > > > ...
> > > > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > > > pkgconfig and cmake)
> > > >
> > > > Installed gudev ... and then:
> > > >
> > > > ...
> > > > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > > > ...
> > > > gst-plugins-bad 1.19.3.1
> > > >
> > > > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > > > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > > > audiovisualizers, autoconvert, bayer,
> > > > camerabin, codecalpha, coloreffects,
> > > > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > > > festival, fieldanalysis, freeverb, frei0r,
> > > > gaudieffects, gdp, geometrictransform,
> > > > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > > > rfbsrc, midi, mpegpsdemux,
> > > > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > > > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > > > removesilence, rist, rtmp2, rtpmanagerbad,
> > > > sdpelem, segmentclip, siren, smooth,
> > > > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > > > videoframe_audiolevel, videoparsersbad,
> > > > videosignal, vmnc, y4mdec, decklink, dvb,
> > > > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> > > >
> > > > GStreamer current master build fails. It's a known issue which will be
> > > > fixed today:
> > > >
> > > > [...]
> > > > [8/9] Compiling C object
> > > > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > > > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > > > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > > > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > > > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > > > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > > > -Isubprojects/gst-plugins-bad/gst-libs
> > > > -I../subprojects/gst-plugins-bad/gst-libs
> > > > -Isubprojects/gst-plugins-base/gst-libs
> > > > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > > > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > > > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > > > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > > > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > > > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > > > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > > > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > > > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > > > -Wdeclaration-after-statement -Wold-style-definition
> > > > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > > > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > > > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > > > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > > > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > > > error: unknown type name ‘grefcount’
> > > > grefcount ref_count;
> > > > ^~~~~~~~~
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > > > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > > > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > > > g_ref_count_init (&pic_data->ref_count);
> > > > ^~~~~~~~~~~~~~~~
> > > > g_cond_init
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > > > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > > > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > > > g_ref_count_inc (&data->ref_count);
> > > > ^~~~~~~~~~~~~~~
> > > > g_strv_contains
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > > > warning: implicit declaration of function ‘g_ref_count_dec’
> > > > [-Wimplicit-function-declaration]
> > > > if (g_ref_count_dec (&data->ref_count)) {
> > > > ^~~~~~~~~~~~~~~
> > > > ninja: build stopped: subcommand failed.
> > > >
> > > > Hope this helps get you started!
> > > > Ezequiel
> > >
> > > Ezequiel and Nicolas,
> > >
> > > Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> > > v4l2codecs finally by getting the correct dependencies. I've attempted
> > > to software encode from another system and decode/display on the IMX8M
> > > Mini but thus far have not been successful.
> > >
> > > I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> > > and these all can output video/x-raw NV12/YUY2 which kmssink should
> > > accept so I'm attempting the following :
> > >
> > > # vp8 encode from x86
> > > gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> > > vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> > > # vp8 decode on [email protected] which has a 800x480 display
> > > [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> > > udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> > > clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> > > ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> > > seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> > > v4l2slvp8dec ! kmssink
> > > Setting pipeline to PAUSED ...
> > > Pipeline is live and does not need PREROLL ...
> > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> > > Pipeline is PREROLLED ...
> > > Setting pipeline to PLAYING ...
> > > /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > a-framerate=(string)30
> > > New clock: GstSystemClock
> > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > a-framerate=(string)30
> > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> > > video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> > > profile=(string)0
> > > ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> > > data stream error.
> > > Additional debug info:
> > > ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> > > gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> > > streaming stopped, reason not-negotiated (-4)
> > > Execution ended after 0:00:02.076839644
> > > Setting pipeline to NULL ...
> > > Freeing pipeline ...
> > >
> > > I'm getting the same thing when trying to use h264.
> > >
> > > I've never quite been able to grasp how to debug GStreamer's
> > > negotiation issues. If I end with fakesink it appears to decode so it
> > > must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> > > using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> > > I still get the negotiation error.
> > >
> > > What interrupts should I be seeing in /proc/interrupts? I don't see
> > > anything vpu/hantro related there.
> > >
> > > I also want to make sure I have a basic understanding of the vpu
> > > drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> > > familiar with has a vpu that is supported by the GStreamer video4linux
> > > plugin which shows the following (on GStreamer 1.16.2):
> > > v4l2jpegenc: V4L2 JPEG Encoder
> > > v4l2jpegdec: V4L2 JPEG Decoder
> > > v4l2h264enc: V4L2 H.264 Encoder
> > > v4l2mpeg4enc: V4L2 MPEG4 Encoder
> > > v4l2mpeg4dec: V4L2 MPEG4 Decoder
> > > v4l2mpeg2dec: V4L2 MPEG2 Decoder
> > > v4l2h264dec: V4L2 H264 Decoder
> > > The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> > > following for scaling/colorspace conversion:
> > > v4l2convert: V4L2 Video Converter
> > >
> > > I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> > > 'stateful' where more software is required to drive them and is
> >
> > 'stateless'. the rest is right.
> >
> > > supported by the newer v4l2codecs plugin. I haven't been able to
> > > understand what kernel version/requirements the v4l2codecs plugin
> > > users/requires.
> >
> > After H264 debacle with 5.9, 5.10 and 5.11 API break and GStreamer not getting
> > enough release to support all of these we started merging support for CODECs
> > only when the stable uAPI land. I made an exception for VP9 as it is already
> > applied in the media tree and didn't want to miss 1.20 release.
> >
> > So to answer you question, it depends on when the CODEC uAPI landed.
> >
>
> Ok, thanks for the explanation.
>
> > >
> > > I'm also trying to understand how we can get scaling/colorspace
> > > conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> > > way to utilize scaling/colorspace conversion from the 2D GPU bound to
> > > the etnaviv driver?
> >
> > The concept of the mini, is that you would be using th encoder for anything that
> > isn't going to the display. So they only integrated the Hantro PP on the
> > encoder. Unfortunately, you'll have to be patient for mainline stateless encoder
> > support, we barely scratch the surface of this subject, but its being worked on.
>
> After some searching for Hantro PP I see that the IMXMQ (IMX8M
> Dual/QuadLite/Quad) mentions Hantro PP. From the IMX8MDQLQRM section
> 14.1.2.1 Decoder Features:
> <quote>
> Video post-processing features
> - Frame rotation 90 degrees left/right
> - Frame mirroring horizontally/vertically
> - Frame cropping
> - Frame conversion from YCbCr formats to 16-bit or 32-bit RGB formats
> - Frame scaling with maximum up-scaling factor of 3
> - Two rectangular or alpha blending masks for output frame
>
> The post-processing features can be used in pipeline with the
> decoder. The postprocessing features can also be used as stand-alone,
> without performing any decoding
> </quote>
>
> The above is under the VPU_G1 section and the same is not mentioned
> for VPU_G2 and the IMX8MQ doesn't have encode support. Where do you
> see that the IMX8MM has the Hantro PP on the H1? I know the TRM's lack
> a lot of info so perhaps you know more about the internals than what
> the TRM states.

I've got told that by someone with contacts at NXP recently (in IRC). I haven't
verified it though, it just made sense for the targeted use of th mini. Hantro
G1 driver does not yet expose an M2M for the standalone mode of the PP, but
shall be possible. Decode an PP cannot run concurrently though, so concurrent PP
and decode will have big impact on performance.

The G2 PP is different, but I *think* its always there. It's not doing much,
linear NV12 (detiling from 4x4 linear tiles), and can scale down by factor of 2,
4 an 8. If there is more feature I'm not aware.

>
> I also found on a forum
> (https://community.nxp.com/t5/i-MX-Processors/imx8mq-Hantro-G1-scaling/m-p/1285343)
> that NXP's BSP doesn't use the Hantro for scaling (and likely not csc
> either) and they use the GPU instead. I'm still unclear if/how you
> could tap into the 2D GPU to use its scaling/conversion if it's bound
> to the etnaviv driver.
>
> > Unlike the IMX8MQ, you don't have the option to output YUYV (packed yuv 4:2:2)
> > which would satisfy the 2D GPU support hoold to the DMABuf import path.

As I'm saying above, you can't, there is no NV12 support in that 2D GPU from
what I was old by Etnaviv folks, only YUYV (4:2:2 packed). Shaders is the only
option.

> >
> > When the display driver gets ready and upstream (it's been only 2-3 years now),
> > you'll get linear NV12 support along with G2 compression support (this one is
> > not supported by the GPU, so it will be tricky to expose in userland). I don't
> > think the display support 4L4 tiles, but you GPU most likely can do with the
> > right shared and texelFetch() or vulkan equivalent if that exist on that target.
>
> Do you mean the Samsung Exynos DRM driver (which doesn't yet have
> support for IMX8MM) or drivers/gpu/drm/mxsfb?
>
> I'm currently using a pretty old patchset that adds IMX8MM support to
> the drm/exynos driver. I'm way out of my realm when talking about
> GPU/VPU and display drivers.

Didn't know the mini was using Samsung display controller. Didn't even know that
chip could exist outside of Exynos chips. On imx8mq, they have a NXP display
chip and it is new. Downstream driver exist, and upstream driver is being worked
on.

>
> Best regards,
>
> Tim


2021-12-06 09:20:55

by Lucas Stach

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Am Freitag, dem 03.12.2021 um 14:37 -0500 schrieb Nicolas Dufresne:
> Le vendredi 03 décembre 2021 à 08:46 -0800, Tim Harvey a écrit :
> > On Thu, Dec 2, 2021 at 8:34 PM Nicolas Dufresne <[email protected]> wrote:
> > >
> > > Le mardi 30 novembre 2021 à 11:28 -0800, Tim Harvey a écrit :
> > > > On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> > > > <[email protected]> wrote:
> > > > >
> > > > > Hi Tim,
> > > > >
> > > > > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > > > > >
> > > > > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > > > > ..
> > > > > > >
> > > > > >
> > > > > > Adam,
> > > > > >
> > > > > > What deps did you install in order to get v4l2codecs building? I
> > > > > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > > > > (not sure if I needed to re-configure somehow) but there is still
> > > > > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > > > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > > > > how to find out what dependencies are needed or what may be missing.
> > > > > >
> > > > >
> > > > > At least in my case (Centps-derivative), this is what I've done:
> > > > >
> > > > > ...
> > > > > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > > > > pkgconfig and cmake)
> > > > >
> > > > > Installed gudev ... and then:
> > > > >
> > > > > ...
> > > > > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > > > > ...
> > > > > gst-plugins-bad 1.19.3.1
> > > > >
> > > > > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > > > > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > > > > audiovisualizers, autoconvert, bayer,
> > > > > camerabin, codecalpha, coloreffects,
> > > > > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > > > > festival, fieldanalysis, freeverb, frei0r,
> > > > > gaudieffects, gdp, geometrictransform,
> > > > > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > > > > rfbsrc, midi, mpegpsdemux,
> > > > > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > > > > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > > > > removesilence, rist, rtmp2, rtpmanagerbad,
> > > > > sdpelem, segmentclip, siren, smooth,
> > > > > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > > > > videoframe_audiolevel, videoparsersbad,
> > > > > videosignal, vmnc, y4mdec, decklink, dvb,
> > > > > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> > > > >
> > > > > GStreamer current master build fails. It's a known issue which will be
> > > > > fixed today:
> > > > >
> > > > > [...]
> > > > > [8/9] Compiling C object
> > > > > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > > > > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > > > > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > > > > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > > > > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > > > > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > > > > -Isubprojects/gst-plugins-bad/gst-libs
> > > > > -I../subprojects/gst-plugins-bad/gst-libs
> > > > > -Isubprojects/gst-plugins-base/gst-libs
> > > > > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > > > > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > > > > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > > > > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > > > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > > > > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > > > > -Wdeclaration-after-statement -Wold-style-definition
> > > > > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > > > > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > > > > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > > > > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > > > > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > > > > error: unknown type name ‘grefcount’
> > > > > grefcount ref_count;
> > > > > ^~~~~~~~~
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > > > > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > > > > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > > > > g_ref_count_init (&pic_data->ref_count);
> > > > > ^~~~~~~~~~~~~~~~
> > > > > g_cond_init
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > > > > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > > > > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > > > > g_ref_count_inc (&data->ref_count);
> > > > > ^~~~~~~~~~~~~~~
> > > > > g_strv_contains
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > > > > warning: implicit declaration of function ‘g_ref_count_dec’
> > > > > [-Wimplicit-function-declaration]
> > > > > if (g_ref_count_dec (&data->ref_count)) {
> > > > > ^~~~~~~~~~~~~~~
> > > > > ninja: build stopped: subcommand failed.
> > > > >
> > > > > Hope this helps get you started!
> > > > > Ezequiel
> > > >
> > > > Ezequiel and Nicolas,
> > > >
> > > > Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> > > > v4l2codecs finally by getting the correct dependencies. I've attempted
> > > > to software encode from another system and decode/display on the IMX8M
> > > > Mini but thus far have not been successful.
> > > >
> > > > I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> > > > and these all can output video/x-raw NV12/YUY2 which kmssink should
> > > > accept so I'm attempting the following :
> > > >
> > > > # vp8 encode from x86
> > > > gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> > > > vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> > > > # vp8 decode on [email protected] which has a 800x480 display
> > > > [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> > > > udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> > > > clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> > > > ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> > > > seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> > > > v4l2slvp8dec ! kmssink
> > > > Setting pipeline to PAUSED ...
> > > > Pipeline is live and does not need PREROLL ...
> > > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> > > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> > > > Pipeline is PREROLLED ...
> > > > Setting pipeline to PLAYING ...
> > > > /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> > > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > > a-framerate=(string)30
> > > > New clock: GstSystemClock
> > > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> > > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > > a-framerate=(string)30
> > > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> > > > video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> > > > profile=(string)0
> > > > ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> > > > data stream error.
> > > > Additional debug info:
> > > > ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> > > > gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> > > > streaming stopped, reason not-negotiated (-4)
> > > > Execution ended after 0:00:02.076839644
> > > > Setting pipeline to NULL ...
> > > > Freeing pipeline ...
> > > >
> > > > I'm getting the same thing when trying to use h264.
> > > >
> > > > I've never quite been able to grasp how to debug GStreamer's
> > > > negotiation issues. If I end with fakesink it appears to decode so it
> > > > must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> > > > using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> > > > I still get the negotiation error.
> > > >
> > > > What interrupts should I be seeing in /proc/interrupts? I don't see
> > > > anything vpu/hantro related there.
> > > >
> > > > I also want to make sure I have a basic understanding of the vpu
> > > > drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> > > > familiar with has a vpu that is supported by the GStreamer video4linux
> > > > plugin which shows the following (on GStreamer 1.16.2):
> > > > v4l2jpegenc: V4L2 JPEG Encoder
> > > > v4l2jpegdec: V4L2 JPEG Decoder
> > > > v4l2h264enc: V4L2 H.264 Encoder
> > > > v4l2mpeg4enc: V4L2 MPEG4 Encoder
> > > > v4l2mpeg4dec: V4L2 MPEG4 Decoder
> > > > v4l2mpeg2dec: V4L2 MPEG2 Decoder
> > > > v4l2h264dec: V4L2 H264 Decoder
> > > > The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> > > > following for scaling/colorspace conversion:
> > > > v4l2convert: V4L2 Video Converter
> > > >
> > > > I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> > > > 'stateful' where more software is required to drive them and is
> > >
> > > 'stateless'. the rest is right.
> > >
> > > > supported by the newer v4l2codecs plugin. I haven't been able to
> > > > understand what kernel version/requirements the v4l2codecs plugin
> > > > users/requires.
> > >
> > > After H264 debacle with 5.9, 5.10 and 5.11 API break and GStreamer not getting
> > > enough release to support all of these we started merging support for CODECs
> > > only when the stable uAPI land. I made an exception for VP9 as it is already
> > > applied in the media tree and didn't want to miss 1.20 release.
> > >
> > > So to answer you question, it depends on when the CODEC uAPI landed.
> > >
> >
> > Ok, thanks for the explanation.
> >
> > > >
> > > > I'm also trying to understand how we can get scaling/colorspace
> > > > conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> > > > way to utilize scaling/colorspace conversion from the 2D GPU bound to
> > > > the etnaviv driver?
> > >
> > > The concept of the mini, is that you would be using th encoder for anything that
> > > isn't going to the display. So they only integrated the Hantro PP on the
> > > encoder. Unfortunately, you'll have to be patient for mainline stateless encoder
> > > support, we barely scratch the surface of this subject, but its being worked on.
> >
> > After some searching for Hantro PP I see that the IMXMQ (IMX8M
> > Dual/QuadLite/Quad) mentions Hantro PP. From the IMX8MDQLQRM section
> > 14.1.2.1 Decoder Features:
> > <quote>
> > Video post-processing features
> > - Frame rotation 90 degrees left/right
> > - Frame mirroring horizontally/vertically
> > - Frame cropping
> > - Frame conversion from YCbCr formats to 16-bit or 32-bit RGB formats
> > - Frame scaling with maximum up-scaling factor of 3
> > - Two rectangular or alpha blending masks for output frame
> >
> > The post-processing features can be used in pipeline with the
> > decoder. The postprocessing features can also be used as stand-alone,
> > without performing any decoding
> > </quote>
> >
> > The above is under the VPU_G1 section and the same is not mentioned
> > for VPU_G2 and the IMX8MQ doesn't have encode support. Where do you
> > see that the IMX8MM has the Hantro PP on the H1? I know the TRM's lack
> > a lot of info so perhaps you know more about the internals than what
> > the TRM states.
>
> I've got told that by someone with contacts at NXP recently (in IRC). I haven't
> verified it though, it just made sense for the targeted use of th mini. Hantro
> G1 driver does not yet expose an M2M for the standalone mode of the PP, but
> shall be possible. Decode an PP cannot run concurrently though, so concurrent PP
> and decode will have big impact on performance.
>
> The G2 PP is different, but I *think* its always there. It's not doing much,
> linear NV12 (detiling from 4x4 linear tiles), and can scale down by factor of 2,
> 4 an 8. If there is more feature I'm not aware.
>
> >
> > I also found on a forum
> > (https://community.nxp.com/t5/i-MX-Processors/imx8mq-Hantro-G1-scaling/m-p/1285343)
> > that NXP's BSP doesn't use the Hantro for scaling (and likely not csc
> > either) and they use the GPU instead. I'm still unclear if/how you
> > could tap into the 2D GPU to use its scaling/conversion if it's bound
> > to the etnaviv driver.
> >
> > > Unlike the IMX8MQ, you don't have the option to output YUYV (packed yuv 4:2:2)
> > > which would satisfy the 2D GPU support hoold to the DMABuf import path.
>
> As I'm saying above, you can't, there is no NV12 support in that 2D GPU from
> what I was old by Etnaviv folks, only YUYV (4:2:2 packed). Shaders is the only
> option.
>
That's not correct. The 3D GPU can sample directly from YUYV, so it's
the optimal zero-copy format if you are going to use the video with the
3D GPU. Most of the 2D GPU cores (and I think the one of the 8MM is no
exception) can handle planar formats, some of them only at reduced rate
of 1 Pixel/clock, instead of the usual 2 Pixels/clock.
> > >
> > > When the display driver gets ready and upstream (it's been only 2-3 years now),
> > > you'll get linear NV12 support along with G2 compression support (this one is
> > > not supported by the GPU, so it will be tricky to expose in userland). I don't
> > > think the display support 4L4 tiles, but you GPU most likely can do with the
> > > right shared and texelFetch() or vulkan equivalent if that exist on that target.
> >
> > Do you mean the Samsung Exynos DRM driver (which doesn't yet have
> > support for IMX8MM) or drivers/gpu/drm/mxsfb?
> >
> > I'm currently using a pretty old patchset that adds IMX8MM support to
> > the drm/exynos driver. I'm way out of my realm when talking about
> > GPU/VPU and display drivers.
>
> Didn't know the mini was using Samsung display controller. Didn't even know that
> chip could exist outside of Exynos chips. On imx8mq, they have a NXP display
> chip and it is new. Downstream driver exist, and upstream driver is being worked
> on.

The display controller on the 8MM is derived from the existing simple
eLCDIF controllers found on earlier i.MX SoCs. 8MQ is the only one with
the very capable DCSS display controller. In fact the 8MQ DCSS is
upstream, what is missing is the Cadence eDP/HDMI bridge driver. The
MIPI-DSI controller and PHY on the 8MM is Samsung IP.

Regards,
Lucas


2021-12-06 20:46:18

by Nicolas Dufresne

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le lundi 06 décembre 2021 à 10:20 +0100, Lucas Stach a écrit :
> Am Freitag, dem 03.12.2021 um 14:37 -0500 schrieb Nicolas Dufresne:
> > Le vendredi 03 décembre 2021 à 08:46 -0800, Tim Harvey a écrit :
> > > On Thu, Dec 2, 2021 at 8:34 PM Nicolas Dufresne <[email protected]> wrote:
> > > >
> > > > Le mardi 30 novembre 2021 à 11:28 -0800, Tim Harvey a écrit :
> > > > > On Tue, Nov 30, 2021 at 6:00 AM Ezequiel Garcia
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > Hi Tim,
> > > > > >
> > > > > > On Mon, 29 Nov 2021 at 16:36, Tim Harvey <[email protected]> wrote:
> > > > > > >
> > > > > > > On Mon, Nov 29, 2021 at 10:59 AM Adam Ford <[email protected]> wrote:
> > > > > > ..
> > > > > > > >
> > > > > > >
> > > > > > > Adam,
> > > > > > >
> > > > > > > What deps did you install in order to get v4l2codecs building? I
> > > > > > > installed libgudev-1.0-dev based on Nicolas' suggestion and rebuilt
> > > > > > > (not sure if I needed to re-configure somehow) but there is still
> > > > > > > nothing in build/subprojects/gst-plugins-bad/sys/v4l2codecs/. A 'meson
> > > > > > > configure' tells me that v4l2codecs is set to 'auto' but I'm not sure
> > > > > > > how to find out what dependencies are needed or what may be missing.
> > > > > > >
> > > > > >
> > > > > > At least in my case (Centps-derivative), this is what I've done:
> > > > > >
> > > > > > ...
> > > > > > gst-plugins-bad| Run-time dependency gudev-1.0 found: NO (tried
> > > > > > pkgconfig and cmake)
> > > > > >
> > > > > > Installed gudev ... and then:
> > > > > >
> > > > > > ...
> > > > > > gst-plugins-bad| Dependency gudev-1.0 found: YES 232 (cached)
> > > > > > ...
> > > > > > gst-plugins-bad 1.19.3.1
> > > > > >
> > > > > > Plugins : accurip, adpcmdec, adpcmenc, aiff, asfmux,
> > > > > > audiobuffersplit, audiofxbad, audiomixmatrix, audiolatency,
> > > > > > audiovisualizers, autoconvert, bayer,
> > > > > > camerabin, codecalpha, coloreffects,
> > > > > > debugutilsbad, dvbsubenc, dvbsuboverlay, dvdspu, faceoverlay,
> > > > > > festival, fieldanalysis, freeverb, frei0r,
> > > > > > gaudieffects, gdp, geometrictransform,
> > > > > > id3tag, inter, interlace, ivfparse, ivtc, jp2kdecimator, jpegformat,
> > > > > > rfbsrc, midi, mpegpsdemux,
> > > > > > mpegpsmux, mpegtsdemux, mpegtsmux, mxf,
> > > > > > netsim, rtponvif, pcapparse, pnm, proxy, legacyrawparse,
> > > > > > removesilence, rist, rtmp2, rtpmanagerbad,
> > > > > > sdpelem, segmentclip, siren, smooth,
> > > > > > speed, subenc, switchbin, timecode, transcode, videofiltersbad,
> > > > > > videoframe_audiolevel, videoparsersbad,
> > > > > > videosignal, vmnc, y4mdec, decklink, dvb,
> > > > > > fbdevsink, ipcpipeline, nvcodec, shm, v4l2codecs, hls, sctp
> > > > > >
> > > > > > GStreamer current master build fails. It's a known issue which will be
> > > > > > fixed today:
> > > > > >
> > > > > > [...]
> > > > > > [8/9] Compiling C object
> > > > > > subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > > FAILED: subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > > cc -Isubprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p
> > > > > > -Isubprojects/gst-plugins-bad/sys/v4l2codecs
> > > > > > -I../subprojects/gst-plugins-bad/sys/v4l2codecs
> > > > > > -Isubprojects/gst-plugins-bad -I../subprojects/gst-plugins-bad
> > > > > > -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs
> > > > > > -Isubprojects/gstreamer -I../subprojects/gstreamer
> > > > > > -Isubprojects/gst-plugins-bad/gst-libs
> > > > > > -I../subprojects/gst-plugins-bad/gst-libs
> > > > > > -Isubprojects/gst-plugins-base/gst-libs
> > > > > > -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/orc
> > > > > > -I../subprojects/orc -Isubprojects/gstreamer/gst
> > > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/video
> > > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/pbutils
> > > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/audio
> > > > > > -Isubprojects/gst-plugins-base/gst-libs/gst/tag
> > > > > > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > > > > > -I/usr/include/gudev-1.0 -fdiagnostics-color=always
> > > > > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fvisibility=hidden
> > > > > > -fno-strict-aliasing -DG_DISABLE_DEPRECATED -Wmissing-prototypes
> > > > > > -Wdeclaration-after-statement -Wold-style-definition
> > > > > > -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat
> > > > > > -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress
> > > > > > -Wno-multichar -Wvla -Wpointer-arith -fPIC -pthread -DHAVE_CONFIG_H
> > > > > > -MD -MQ subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > > -MF subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o.d
> > > > > > -o subprojects/gst-plugins-bad/sys/v4l2codecs/libgstv4l2codecs.so.p/gstv4l2codecvp9dec.c.o
> > > > > > -c ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3:
> > > > > > error: unknown type name ‘grefcount’
> > > > > > grefcount ref_count;
> > > > > > ^~~~~~~~~
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_new’:
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3:
> > > > > > warning: implicit declaration of function ‘g_ref_count_init’; did you
> > > > > > mean ‘g_cond_init’? [-Wimplicit-function-declaration]
> > > > > > g_ref_count_init (&pic_data->ref_count);
> > > > > > ^~~~~~~~~~~~~~~~
> > > > > > g_cond_init
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_ref’:
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3:
> > > > > > warning: implicit declaration of function ‘g_ref_count_inc’; did you
> > > > > > mean ‘g_strv_contains’? [-Wimplicit-function-declaration]
> > > > > > g_ref_count_inc (&data->ref_count);
> > > > > > ^~~~~~~~~~~~~~~
> > > > > > g_strv_contains
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In
> > > > > > function ‘gst_v4l2_codec_vp9_dec_picture_data_unref’:
> > > > > > ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7:
> > > > > > warning: implicit declaration of function ‘g_ref_count_dec’
> > > > > > [-Wimplicit-function-declaration]
> > > > > > if (g_ref_count_dec (&data->ref_count)) {
> > > > > > ^~~~~~~~~~~~~~~
> > > > > > ninja: build stopped: subcommand failed.
> > > > > >
> > > > > > Hope this helps get you started!
> > > > > > Ezequiel
> > > > >
> > > > > Ezequiel and Nicolas,
> > > > >
> > > > > Thanks - I did manage to get gstreamer 1.19.3 built successfully with
> > > > > v4l2codecs finally by getting the correct dependencies. I've attempted
> > > > > to software encode from another system and decode/display on the IMX8M
> > > > > Mini but thus far have not been successful.
> > > > >
> > > > > I see that v4l2codecs plugin v4l2slh264dec/v4l2slmpeg2dec/v4l2slvp8dec
> > > > > and these all can output video/x-raw NV12/YUY2 which kmssink should
> > > > > accept so I'm attempting the following :
> > > > >
> > > > > # vp8 encode from x86
> > > > > gst-launch-1.0 -v videotestsrc ! video/x-raw,width=800,height=480 !
> > > > > vp8enc ! rtpvp8pay ! udpsink host=172.24.33.15 port=9001
> > > > > # vp8 decode on [email protected] which has a 800x480 display
> > > > > [gst-main] root@focal-venice:~/gstreamer/build# gst-launch-1.0 -v
> > > > > udpsrc port=9001 caps = "application/x-rtp, media=(string)video,
> > > > > clock-rate=(int)90000, encoding-name=(string)VP8, payload=(int)96,
> > > > > ssrc=(uint)2745262155, timestamp-offset=(uint)2515032683,
> > > > > seqnum-offset=(uint)19579, a-framerate=(string)30" ! rtpvp8depay !
> > > > > v4l2slvp8dec ! kmssink
> > > > > Setting pipeline to PAUSED ...
> > > > > Pipeline is live and does not need PREROLL ...
> > > > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
> > > > > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
> > > > > Pipeline is PREROLLED ...
> > > > > Setting pipeline to PLAYING ...
> > > > > /GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps =
> > > > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > > > a-framerate=(string)30
> > > > > New clock: GstSystemClock
> > > > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps =
> > > > > application/x-rtp, media=(string)video, clock-rate=(int)90000,
> > > > > encoding-name=(string)VP8, payload=(int)96, ssrc=(uint)2745262155,
> > > > > timestamp-offset=(uint)2515032683, seqnum-offset=(uint)19579,
> > > > > a-framerate=(string)30
> > > > > /GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps =
> > > > > video/x-vp8, framerate=(fraction)0/1, height=(int)480, width=(int)800,
> > > > > profile=(string)0
> > > > > ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Internal
> > > > > data stream error.
> > > > > Additional debug info:
> > > > > ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127):
> > > > > gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> > > > > streaming stopped, reason not-negotiated (-4)
> > > > > Execution ended after 0:00:02.076839644
> > > > > Setting pipeline to NULL ...
> > > > > Freeing pipeline ...
> > > > >
> > > > > I'm getting the same thing when trying to use h264.
> > > > >
> > > > > I've never quite been able to grasp how to debug GStreamer's
> > > > > negotiation issues. If I end with fakesink it appears to decode so it
> > > > > must be the v4l2slvp8dec to kmssink. I tried forcing the pixel format
> > > > > using 'v4l2slvp8dec ! "video/x-raw,format=(string)NV12" ! kmssink' but
> > > > > I still get the negotiation error.
> > > > >
> > > > > What interrupts should I be seeing in /proc/interrupts? I don't see
> > > > > anything vpu/hantro related there.
> > > > >
> > > > > I also want to make sure I have a basic understanding of the vpu
> > > > > drivers and usersapce on the IMX8M Mini. The IMX6Q/DL that I'm more
> > > > > familiar with has a vpu that is supported by the GStreamer video4linux
> > > > > plugin which shows the following (on GStreamer 1.16.2):
> > > > > v4l2jpegenc: V4L2 JPEG Encoder
> > > > > v4l2jpegdec: V4L2 JPEG Decoder
> > > > > v4l2h264enc: V4L2 H.264 Encoder
> > > > > v4l2mpeg4enc: V4L2 MPEG4 Encoder
> > > > > v4l2mpeg4dec: V4L2 MPEG4 Decoder
> > > > > v4l2mpeg2dec: V4L2 MPEG2 Decoder
> > > > > v4l2h264dec: V4L2 H264 Decoder
> > > > > The IMX6Q/DL also has an IPU that has an M2M driver that provides the
> > > > > following for scaling/colorspace conversion:
> > > > > v4l2convert: V4L2 Video Converter
> > > > >
> > > > > I believe what I'm reading is that the IMX8M Mini Hantro codecs are
> > > > > 'stateful' where more software is required to drive them and is
> > > >
> > > > 'stateless'. the rest is right.
> > > >
> > > > > supported by the newer v4l2codecs plugin. I haven't been able to
> > > > > understand what kernel version/requirements the v4l2codecs plugin
> > > > > users/requires.
> > > >
> > > > After H264 debacle with 5.9, 5.10 and 5.11 API break and GStreamer not getting
> > > > enough release to support all of these we started merging support for CODECs
> > > > only when the stable uAPI land. I made an exception for VP9 as it is already
> > > > applied in the media tree and didn't want to miss 1.20 release.
> > > >
> > > > So to answer you question, it depends on when the CODEC uAPI landed.
> > > >
> > >
> > > Ok, thanks for the explanation.
> > >
> > > > >
> > > > > I'm also trying to understand how we can get scaling/colorspace
> > > > > conversion on the IMX8M Mini. The IMX8M lacks an IPU... is there some
> > > > > way to utilize scaling/colorspace conversion from the 2D GPU bound to
> > > > > the etnaviv driver?
> > > >
> > > > The concept of the mini, is that you would be using th encoder for anything that
> > > > isn't going to the display. So they only integrated the Hantro PP on the
> > > > encoder. Unfortunately, you'll have to be patient for mainline stateless encoder
> > > > support, we barely scratch the surface of this subject, but its being worked on.
> > >
> > > After some searching for Hantro PP I see that the IMXMQ (IMX8M
> > > Dual/QuadLite/Quad) mentions Hantro PP. From the IMX8MDQLQRM section
> > > 14.1.2.1 Decoder Features:
> > > <quote>
> > > Video post-processing features
> > > - Frame rotation 90 degrees left/right
> > > - Frame mirroring horizontally/vertically
> > > - Frame cropping
> > > - Frame conversion from YCbCr formats to 16-bit or 32-bit RGB formats
> > > - Frame scaling with maximum up-scaling factor of 3
> > > - Two rectangular or alpha blending masks for output frame
> > >
> > > The post-processing features can be used in pipeline with the
> > > decoder. The postprocessing features can also be used as stand-alone,
> > > without performing any decoding
> > > </quote>
> > >
> > > The above is under the VPU_G1 section and the same is not mentioned
> > > for VPU_G2 and the IMX8MQ doesn't have encode support. Where do you
> > > see that the IMX8MM has the Hantro PP on the H1? I know the TRM's lack
> > > a lot of info so perhaps you know more about the internals than what
> > > the TRM states.
> >
> > I've got told that by someone with contacts at NXP recently (in IRC). I haven't
> > verified it though, it just made sense for the targeted use of th mini. Hantro
> > G1 driver does not yet expose an M2M for the standalone mode of the PP, but
> > shall be possible. Decode an PP cannot run concurrently though, so concurrent PP
> > and decode will have big impact on performance.
> >
> > The G2 PP is different, but I *think* its always there. It's not doing much,
> > linear NV12 (detiling from 4x4 linear tiles), and can scale down by factor of 2,
> > 4 an 8. If there is more feature I'm not aware.
> >
> > >
> > > I also found on a forum
> > > (https://community.nxp.com/t5/i-MX-Processors/imx8mq-Hantro-G1-scaling/m-p/1285343)
> > > that NXP's BSP doesn't use the Hantro for scaling (and likely not csc
> > > either) and they use the GPU instead. I'm still unclear if/how you
> > > could tap into the 2D GPU to use its scaling/conversion if it's bound
> > > to the etnaviv driver.
> > >
> > > > Unlike the IMX8MQ, you don't have the option to output YUYV (packed yuv 4:2:2)
> > > > which would satisfy the 2D GPU support hoold to the DMABuf import path.
> >
> > As I'm saying above, you can't, there is no NV12 support in that 2D GPU from
> > what I was old by Etnaviv folks, only YUYV (4:2:2 packed). Shaders is the only
> > option.
> >
> That's not correct. The 3D GPU can sample directly from YUYV, so it's
> the optimal zero-copy format if you are going to use the video with the
> 3D GPU. Most of the 2D GPU cores (and I think the one of the 8MM is no
> exception) can handle planar formats, some of them only at reduced rate
> of 1 Pixel/clock, instead of the usual 2 Pixels/clock.

Isn't that enough to disqualify that as "optimal" ?

> > > >
> > > > When the display driver gets ready and upstream (it's been only 2-3 years now),
> > > > you'll get linear NV12 support along with G2 compression support (this one is
> > > > not supported by the GPU, so it will be tricky to expose in userland). I don't
> > > > think the display support 4L4 tiles, but you GPU most likely can do with the
> > > > right shared and texelFetch() or vulkan equivalent if that exist on that target.
> > >
> > > Do you mean the Samsung Exynos DRM driver (which doesn't yet have
> > > support for IMX8MM) or drivers/gpu/drm/mxsfb?
> > >
> > > I'm currently using a pretty old patchset that adds IMX8MM support to
> > > the drm/exynos driver. I'm way out of my realm when talking about
> > > GPU/VPU and display drivers.
> >
> > Didn't know the mini was using Samsung display controller. Didn't even know that
> > chip could exist outside of Exynos chips. On imx8mq, they have a NXP display
> > chip and it is new. Downstream driver exist, and upstream driver is being worked
> > on.
>
> The display controller on the 8MM is derived from the existing simple
> eLCDIF controllers found on earlier i.MX SoCs. 8MQ is the only one with
> the very capable DCSS display controller. In fact the 8MQ DCSS is
> upstream, what is missing is the Cadence eDP/HDMI bridge driver. The
> MIPI-DSI controller and PHY on the 8MM is Samsung IP.

Thanks for clarification.

>
> Regards,
> Lucas
>


2021-12-17 04:49:10

by Ezequiel Garcia

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Hi Adam,

>
> I will post a V2 last today with the Mini's post-processing removed.
> Someone, I apologize that I forget who, mentioned it was fused out of
> the Mini, so the testing I've been doing was with that removed and I
> removed the H1 encoder since the Mini doesn't support JPEG encoding.
>
[...]

Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
post-processor features for G1 and G2.

Have you checked the fuse and synth registers to see if they throw
any useful information about the hardware? For instance,
comparing PP fuse register (SWREG99) and
Synthesis configuration register post-processor (SWREG100)
in both 8MQ and 8MM could be useful.

As I mentioned on my previous mail, even if G1 PP is disabled
on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
which in our hantro driver jargon is a "post-processed" format :-)

Thanks,
Ezequiel

2021-12-17 13:15:15

by Adam Ford

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
<[email protected]> wrote:
>
> Hi Adam,
>
> >
> > I will post a V2 last today with the Mini's post-processing removed.
> > Someone, I apologize that I forget who, mentioned it was fused out of
> > the Mini, so the testing I've been doing was with that removed and I
> > removed the H1 encoder since the Mini doesn't support JPEG encoding.
> >
> [...]
>
> Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
> post-processor features for G1 and G2.
>
> Have you checked the fuse and synth registers to see if they throw
> any useful information about the hardware? For instance,
> comparing PP fuse register (SWREG99) and
> Synthesis configuration register post-processor (SWREG100)
> in both 8MQ and 8MM could be useful.
>
> As I mentioned on my previous mail, even if G1 PP is disabled
> on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
> which in our hantro driver jargon is a "post-processed" format :-)

You're likely right. I was going on memory from an e-mail from
Nicloas Defresne who wrote:

"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
from the start as according to the V1 of the TRM it was there, but that error
was corrected in V3."

In my head I assumed the G2 was affected as well, but when I double
checked his email, and based on the above statement, the G2
post-processing is probably there, so I'll run some tests with the G2
post-processing enabled. I'll also double check those registers on
both to confirm what they read. I am not sure when I'll have time
because I leave for London next week, and I won't return until early
January, but I'll do what I can.

adam
>
> Thanks,
> Ezequiel

2021-12-17 17:13:47

by Nicolas Dufresne

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le vendredi 17 décembre 2021 à 07:15 -0600, Adam Ford a écrit :
> On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
> <[email protected]> wrote:
> >
> > Hi Adam,
> >
> > >
> > > I will post a V2 last today with the Mini's post-processing removed.
> > > Someone, I apologize that I forget who, mentioned it was fused out of
> > > the Mini, so the testing I've been doing was with that removed and I
> > > removed the H1 encoder since the Mini doesn't support JPEG encoding.
> > >
> > [...]
> >
> > Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
> > post-processor features for G1 and G2.
> >
> > Have you checked the fuse and synth registers to see if they throw
> > any useful information about the hardware? For instance,
> > comparing PP fuse register (SWREG99) and
> > Synthesis configuration register post-processor (SWREG100)
> > in both 8MQ and 8MM could be useful.
> >
> > As I mentioned on my previous mail, even if G1 PP is disabled
> > on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
> > which in our hantro driver jargon is a "post-processed" format :-)
>
> You're likely right. I was going on memory from an e-mail from
> Nicloas Defresne who wrote:
>
> "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
> from the start as according to the V1 of the TRM it was there, but that error
> was corrected in V3."
>
> In my head I assumed the G2 was affected as well, but when I double
> checked his email, and based on the above statement, the G2
> post-processing is probably there, so I'll run some tests with the G2
> post-processing enabled. I'll also double check those registers on
> both to confirm what they read. I am not sure when I'll have time
> because I leave for London next week, and I won't return until early
> January, but I'll do what I can.

Sorry if this was a bit ambiguous, indeed I meant the G1 only. I've learned
later that the design of the Mini is that there is a good pre-processor in the
H1 block (encoder), so for the targeted use-cases this shall be sufficient for
most users (the output of the G1 is suitable for GPU and Display already, so the
post processor is not strictly needed).

regards,
Nicolas

>
> adam
> >
> > Thanks,
> > Ezequiel


2021-12-17 17:27:15

by Tim Harvey

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Fri, Dec 17, 2021 at 9:13 AM Nicolas Dufresne <[email protected]> wrote:
>
> Le vendredi 17 décembre 2021 à 07:15 -0600, Adam Ford a écrit :
> > On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
> > <[email protected]> wrote:
> > >
> > > Hi Adam,
> > >
> > > >
> > > > I will post a V2 last today with the Mini's post-processing removed.
> > > > Someone, I apologize that I forget who, mentioned it was fused out of
> > > > the Mini, so the testing I've been doing was with that removed and I
> > > > removed the H1 encoder since the Mini doesn't support JPEG encoding.
> > > >
> > > [...]
> > >
> > > Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
> > > post-processor features for G1 and G2.
> > >
> > > Have you checked the fuse and synth registers to see if they throw
> > > any useful information about the hardware? For instance,
> > > comparing PP fuse register (SWREG99) and
> > > Synthesis configuration register post-processor (SWREG100)
> > > in both 8MQ and 8MM could be useful.
> > >
> > > As I mentioned on my previous mail, even if G1 PP is disabled
> > > on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
> > > which in our hantro driver jargon is a "post-processed" format :-)
> >
> > You're likely right. I was going on memory from an e-mail from
> > Nicloas Defresne who wrote:
> >
> > "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
> > from the start as according to the V1 of the TRM it was there, but that error
> > was corrected in V3."
> >
> > In my head I assumed the G2 was affected as well, but when I double
> > checked his email, and based on the above statement, the G2
> > post-processing is probably there, so I'll run some tests with the G2
> > post-processing enabled. I'll also double check those registers on
> > both to confirm what they read. I am not sure when I'll have time
> > because I leave for London next week, and I won't return until early
> > January, but I'll do what I can.
>
> Sorry if this was a bit ambiguous, indeed I meant the G1 only. I've learned
> later that the design of the Mini is that there is a good pre-processor in the
> H1 block (encoder), so for the targeted use-cases this shall be sufficient for
> most users (the output of the G1 is suitable for GPU and Display already, so the
> post processor is not strictly needed).
>

Nicolas,

Does this mean that if the IMX8MM G2 may be able to output a wider
array of pixel formats and that the H1 encoder may be able to accept a
wider array of pixel formats? Is this code already in place in the
hantro driver and it just needs to be enabled if the IMX8MM can handle
it or is there code to be written?

I'm not clear if anyone is working on IMX8MM VPU H1 support. You had
mentioned that some support [1] and [2] can be derived from the RK3288
using the Google ChromeOS method (a v4l2 plugin that simulates in
userspace a stateful encoder). I'm not sure if this is worth pursuing
if others are working on stateless encode support in kernel and
gstreamer.

Best Regards,

Tim
[1] libv4l plugins /
https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
[2] Kernel Driver /
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/

2021-12-17 17:52:57

by Nicolas Dufresne

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

Le vendredi 17 décembre 2021 à 09:26 -0800, Tim Harvey a écrit :
> On Fri, Dec 17, 2021 at 9:13 AM Nicolas Dufresne <[email protected]> wrote:
> >
> > Le vendredi 17 décembre 2021 à 07:15 -0600, Adam Ford a écrit :
> > > On Thu, Dec 16, 2021 at 10:49 PM Ezequiel Garcia
> > > <[email protected]> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > >
> > > > > I will post a V2 last today with the Mini's post-processing removed.
> > > > > Someone, I apologize that I forget who, mentioned it was fused out of
> > > > > the Mini, so the testing I've been doing was with that removed and I
> > > > > removed the H1 encoder since the Mini doesn't support JPEG encoding.
> > > > >
> > > > [...]
> > > >
> > > > Resurrecting this thread here. IMX8MMRM Rev. 0, 02/2019 mentions
> > > > post-processor features for G1 and G2.
> > > >
> > > > Have you checked the fuse and synth registers to see if they throw
> > > > any useful information about the hardware? For instance,
> > > > comparing PP fuse register (SWREG99) and
> > > > Synthesis configuration register post-processor (SWREG100)
> > > > in both 8MQ and 8MM could be useful.
> > > >
> > > > As I mentioned on my previous mail, even if G1 PP is disabled
> > > > on the Mini, I would imagine the G2 can do linear NV12 (aka raster-scan)
> > > > which in our hantro driver jargon is a "post-processed" format :-)
> > >
> > > You're likely right. I was going on memory from an e-mail from
> > > Nicloas Defresne who wrote:
> > >
> > > "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
> > > from the start as according to the V1 of the TRM it was there, but that error
> > > was corrected in V3."
> > >
> > > In my head I assumed the G2 was affected as well, but when I double
> > > checked his email, and based on the above statement, the G2
> > > post-processing is probably there, so I'll run some tests with the G2
> > > post-processing enabled. I'll also double check those registers on
> > > both to confirm what they read. I am not sure when I'll have time
> > > because I leave for London next week, and I won't return until early
> > > January, but I'll do what I can.
> >
> > Sorry if this was a bit ambiguous, indeed I meant the G1 only. I've learned
> > later that the design of the Mini is that there is a good pre-processor in the
> > H1 block (encoder), so for the targeted use-cases this shall be sufficient for
> > most users (the output of the G1 is suitable for GPU and Display already, so the
> > post processor is not strictly needed).
> >
>
> Nicolas,
>
> Does this mean that if the IMX8MM G2 may be able to output a wider
> array of pixel formats and that the H1 encoder may be able to accept a
> wider array of pixel formats? Is this code already in place in the

No since the G2 post processor does not have a color converter (it is very
limited). In term of format, this is pretty much identical, produces linear or
tiled. The difference is that G1 supports the two layout natively, not the G2.

> hantro driver and it just needs to be enabled if the IMX8MM can handle
> it or is there code to be written?
>
> I'm not clear if anyone is working on IMX8MM VPU H1 support. You had
> mentioned that some support [1] and [2] can be derived from the RK3288
> using the Google ChromeOS method (a v4l2 plugin that simulates in
> userspace a stateful encoder). I'm not sure if this is worth pursuing
> if others are working on stateless encode support in kernel and
> gstreamer.

My colleagues started last week the project of crafting mainline stateless
encoder uAPI. This is too early. In older project, we have had good success with
the emulated stateful encoder. It is of course quite limited, but works in
gstreamer, ffmpeg and chromium. It is also likely safer compared to the vendor
provided driver.

p.s. From my knowledge, there is virtually no difference between the H1 on
RK3288 and IMX8MM/P, but we've learn from G1 that there could effectively have
more of less features.

>
> Best Regards,
>
> Tim
> [1] libv4l plugins /
> https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/refs/heads/master
> [2] Kernel Driver /
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/media/platform/rockchip-vpu/


2021-12-20 03:13:55

by Chen-Yu Tsai

[permalink] [raw]
Subject: Re: [RFC 0/5] arm64: imx8mm: Enable Hantro VPUs

On Sat, Dec 18, 2021 at 1:52 AM Nicolas Dufresne <[email protected]> wrote:
> Le vendredi 17 décembre 2021 à 09:26 -0800, Tim Harvey a écrit :
> > I'm not clear if anyone is working on IMX8MM VPU H1 support. You had
> > mentioned that some support [1] and [2] can be derived from the RK3288
> > using the Google ChromeOS method (a v4l2 plugin that simulates in
> > userspace a stateful encoder). I'm not sure if this is worth pursuing
> > if others are working on stateless encode support in kernel and
> > gstreamer.
>
> My colleagues started last week the project of crafting mainline stateless
> encoder uAPI. This is too early. In older project, we have had good success with
> the emulated stateful encoder. It is of course quite limited, but works in
> gstreamer, ffmpeg and chromium. It is also likely safer compared to the vendor
> provided driver.

If people still want to play with the old emulated stateful encoder, there
is a forward-ported version in the ChromeOS v5.10 kernel now. Note that
RK3288 (H1) support is untested. Also, RK3288 and RK3399 require different
versions of the userspace plugin. And the RK3288 version might require some
updates to add SELECTION API support.


ChenYu