From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Mirela Rabulea <mirela.rabulea@nxp.com>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>
Cc: dl-linux-imx <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"laurent.pinchart+renesas@ideasonboard.com"
<laurent.pinchart+renesas@ideasonboard.com>,
Aisheng Dong <aisheng.dong@nxp.com>,
Laurentiu Palcu <laurentiu.palcu@nxp.com>,
"paul.kocialkowski@bootlin.com" <paul.kocialkowski@bootlin.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Robert Chiras <robert.chiras@nxp.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"niklas.soderlund+renesas@ragnatech.se"
<niklas.soderlund+renesas@ragnatech.se>,
Daniel Baluta <daniel.baluta@nxp.com>,
Leonard Crestez <leonard.crestez@nxp.com>,
"dafna.hirschfeld@collabora.com" <dafna.hirschfeld@collabora.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Subject: Re: [EXT] Re: [PATCH 0/5] Add V4L2 driver for i.MX8 JPEG Encoder/Decoder
Date: Mon, 11 Nov 2019 14:27:17 -0500 [thread overview]
Message-ID: <a7c72589f55594069160afbf94613d322b55470a.camel@ndufresne.ca> (raw)
In-Reply-To: <ffbc7501-bb56-b5f2-cd43-209f099be594@xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
Le vendredi 08 novembre 2019 à 15:06 +0100, Hans Verkuil a écrit :
> On 11/8/19 2:36 PM, Mirela Rabulea wrote:
> > Hi Hans,
> >
> > On Mi, 2019-11-06 at 17:52 +0100, Hans Verkuil wrote:
> > > test Scaling: OK
> > > The presence of a scaler is suspicious: is the encoder indeed
> > > capable of scaling? I suspect this is a bug.
> >
> > No, it's not capable of scaling. You suspect a bug in the driver or the
> > tests?
>
> Actually, I think that's an outstanding bug in v4l-utils. It doesn't
> correctly handle the m2m case with respect to scaling. I think. I'll
> look into this a bit more.
>
> > > Codec ioctls:
> > > > test VIDIOC_(TRY_)ENCODER_CMD: OK
> > > The presence of this...
> > >
> > > > test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> > > > test VIDIOC_(TRY_)DECODER_CMD: OK
> > > ...and this is also strange for a JPEG codec. These ioctls are
> > > typically only
> > > needed for MPEG/H264/etc. codecs, and not for a simple JPEG codec.
> > >
> > > The same issues are found for the JPEG decoder.
> >
> > I implemented the CMD_STOP for both encoder & decoder, because it was
> > requested by our developer for gstreamer plugin for this codec.
> > The context in which this was requested was for playing MJPEG videos (a
> > concatenation of JPEG frames).
>
> This ioctl makes no sense for JPEG codecs, and in fact jpeg drivers like
> s5p-jpeg or mtk-jpeg do not implement this. This sounds like a gstreamer bug.
> Nicolas, do you know anything about this?
This code was added in generic bits of GStreamer. So we just always do
CMD_STOP to drain the remaining buffers and expect EPIPE later on when
done. We can special case this, but at the same time why ? This could
be buried into the m2m helpers with a default implementation.
If you feel like this is completely wrong and userspace should do more
case-by-case code path for different CODEC handling, then someone will
have to update GStreamer accordingly. This is all moving target at the
spec just got merged.
>
> > > Streaming ioctls:
> > > > test read/write: OK (Not Supported)
> > > > test blocking wait: OK
> > > > fail: v4l2-test-buffers.cpp(254): g_field() ==
> > > > V4L2_FIELD_ANY
> > > The driver shall never return FIELD_ANY. This needs to be FIELD_NONE.
> >
> > Is there a "good example" of a v4l m2m driver that passes these
>
> vim2m. Also drivers/media/platform/mtk-jpeg/ (although I'm not sure when
> it was last tested with v4l2-compliance, so it might be a bit out of date).
>
> > streaming tests? That would save some time on my side.
> > For the FIELD_ANY issue, I got inspired from your commit:
> > ab7afaf3 media: vim2m: add buf_out_validate callback
> > But there's a lot more to go...
> >
> > Thanks,
> > Mirela
> >
>
> Regards,
>
> Hans
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2019-11-11 19:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 15:20 [PATCH 0/5] Add V4L2 driver for i.MX8 JPEG Encoder/Decoder Mirela Rabulea
2019-11-06 15:20 ` [PATCH 1/5] media: v4l: Add packed YUV444 24bpp pixel format Mirela Rabulea
2019-11-06 15:20 ` [PATCH 2/5] firmware: imx: scu-pd: Add power domains for imx-jpeg Mirela Rabulea
2019-12-13 9:49 ` Hans Verkuil
2019-12-13 10:49 ` Daniel Baluta
2019-12-16 9:15 ` Shawn Guo
2019-11-06 15:20 ` [PATCH 3/5] media: dt-bindings: Add bindings for i.MX8QXP/QM JPEG driver Mirela Rabulea
2019-11-13 3:55 ` Rob Herring
2019-11-06 15:20 ` [PATCH 4/5] media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder Mirela Rabulea
2019-11-13 14:00 ` Ezequiel Garcia
2019-11-13 14:59 ` [EXT] " Mirela Rabulea
2019-11-13 15:13 ` Philipp Zabel
2019-11-06 15:20 ` [PATCH 5/5] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes Mirela Rabulea
2019-11-06 15:37 ` [PATCH 0/5] Add V4L2 driver for i.MX8 JPEG Encoder/Decoder Hans Verkuil
2019-11-06 16:45 ` [EXT] " Mirela Rabulea
2019-11-06 16:52 ` Hans Verkuil
2019-11-08 13:36 ` Mirela Rabulea
2019-11-08 14:06 ` Hans Verkuil
2019-11-11 19:27 ` Nicolas Dufresne [this message]
2019-11-15 12:34 ` Mirela Rabulea
2019-11-12 16:17 ` Ezequiel Garcia
2019-11-13 12:52 ` [EXT] " Mirela Rabulea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7c72589f55594069160afbf94613d322b55470a.camel@ndufresne.ca \
--to=nicolas@ndufresne.ca \
--cc=aisheng.dong@nxp.com \
--cc=dafna.hirschfeld@collabora.com \
--cc=daniel.baluta@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurentiu.palcu@nxp.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=mirela.rabulea@nxp.com \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=robert.chiras@nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).