Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <3580d4f1549c405173f061c5e2ece3c8f2cfa7e4.camel@ndufresne.ca>
Subject: Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Boris Brezillon <boris.brezillon@collabora.com>,
        Jernej =?UTF-8?Q?=C5=A0krabec?= <jernej.skrabec@siol.net>
Cc:     mchehab@kernel.org, hverkuil-cisco@xs4all.nl,
        paul.kocialkowski@bootlin.com, mripard@kernel.org,
        pawel@osciak.com, m.szyprowski@samsung.com,
        kyungmin.park@samsung.com, tfiga@chromium.org, wens@csie.org,
        acourbot@chromium.org, gregkh@linuxfoundation.org,
        linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
        devel@driverdev.osuosl.org, linux-arm-kernel@lists.infradead.org,
        ezequiel@collabora.com, jonas@kwiboo.se
Date:   Fri, 30 Aug 2019 13:19:42 -0400
In-Reply-To: <20190830074806.78a2b8b4@collabora.com>
References: <20190822194500.2071-1-jernej.skrabec@siol.net>
         <20190822194500.2071-6-jernej.skrabec@siol.net>
         <20190826202831.311c7c20@collabora.com> <3132748.mYbjOY1tKM@jernej-laptop>
         <20190830074806.78a2b8b4@collabora.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
        boundary="=-0LtRcsKKEiURq7JtFoDE"
User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) 
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--=-0LtRcsKKEiURq7JtFoDE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le vendredi 30 ao=C3=BBt 2019 =C3=A0 07:48 +0200, Boris Brezillon a =C3=A9c=
rit :
> On Thu, 29 Aug 2019 21:04:28 +0200
> Jernej =C5=A0krabec <jernej.skrabec@siol.net> wrote:
>=20
> > Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon=20
> > napisal(a):
> > > Hi Jernej,
> > >=20
> > > On Thu, 22 Aug 2019 21:44:57 +0200
> > >=20
> > > Jernej Skrabec <jernej.skrabec@siol.net> wrote: =20
> > > > When codec supports multiple slices in one frame, VPU has to know w=
hen
> > > > first slice of each frame is being processed, presumably to correct=
ly
> > > > clear/set data in auxiliary buffers.
> > > >=20
> > > > Add first_slice field to cedrus_run structure and set it according =
to
> > > > timestamps of capture and output buffers. If timestamps are differe=
nt,
> > > > it's first slice and viceversa.
> > > >=20
> > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > > ---
> > > >=20
> > > >  drivers/staging/media/sunxi/cedrus/cedrus.h     | 1 +
> > > >  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > > >  2 files changed, 3 insertions(+)
> > > >=20
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > > > 2f017a651848..32cb38e541c6 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> > > >=20
> > > >  struct cedrus_run {
> > > > =20
> > > >  	struct vb2_v4l2_buffer	*src;
> > > >  	struct vb2_v4l2_buffer	*dst;
> > > >=20
> > > > +	bool first_slice;
> > > >=20
> > > >  	union {
> > > >  =09
> > > >  		struct cedrus_h264_run	h264;
> > > >=20
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > > > 56ca4c9ad01c..d7b54accfe83 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> > > >=20
> > > >  	run.src =3D v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > >  	run.dst =3D v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > > >=20
> > > > +	run.first_slice =3D
> > > > +		run.src->vb2_buf.timestamp !=3D run.dst- =20
> > > vb2_buf.timestamp;
> > >=20
> > > Can't we use slice->first_mb_in_slice to determine if a slice is the
> > > first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> > > support ASO). =20
> >=20
> > I looked in all VPU documentation available to me (which isn't much) an=
d there=20
> > is no indication if ASO is supported or not. Do you have any sample vid=
eo with=20
> > out-of-order slices? It's my understanding that this is uncommon.
>=20
> I'm not entirely sure, but my understanding was that it might be used
> when streaming over network where some packets might be lost and
> re-emitted later on.
>=20
> > If it's=20
> > supported, I would leave code as-is.
>=20
> I remember seeing the ASO acronym mentioned in the hantro G1 spec, but
> at the same time we're doing frame-based decoding, so I guess the HW
> block expects slices to be ordered in that case. Honestly I don't know,
> so let's keep the code as-is.

We had an ASO interrupt when we tried to do slice decoding rather then
frame. I believe on Hantro, the way to do ASO is to actually re-order
in software.

ASO is a feature of baseline profile use to reduce latency. As an
example, VA-API does not support baseline profile (only constrained-
baseline, which excludes ASO).

Nicolas


--=-0LtRcsKKEiURq7JtFoDE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQSScpfJiL+hb5vvd45xUwItrAaoHAUCXWlarwAKCRBxUwItrAao
HBNPAJ9N2BBAFQLk5dhvhHq+DkURXWdFXQCcDJNUwgnp0u1Q8T6rWaMoTSg5Kck=
=hsiz
-----END PGP SIGNATURE-----

--=-0LtRcsKKEiURq7JtFoDE--