driverdev-devel.linuxdriverproject.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: "Boris Brezillon" <boris.brezillon@collabora.com>,
	"Jernej Škrabec" <jernej.skrabec@siol.net>
Cc: devel@driverdev.osuosl.org, acourbot@chromium.org,
	pawel@osciak.com, jonas@kwiboo.se, gregkh@linuxfoundation.org,
	wens@csie.org, mripard@kernel.org, tfiga@chromium.org,
	paul.kocialkowski@bootlin.com, kyungmin.park@samsung.com,
	linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, hverkuil-cisco@xs4all.nl,
	mchehab@kernel.org, ezequiel@collabora.com,
	linux-kernel@vger.kernel.org, m.szyprowski@samsung.com
Subject: Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
Date: Fri, 30 Aug 2019 13:19:42 -0400	[thread overview]
Message-ID: <3580d4f1549c405173f061c5e2ece3c8f2cfa7e4.camel@ndufresne.ca> (raw)
In-Reply-To: <20190830074806.78a2b8b4@collabora.com>


[-- Attachment #1.1: Type: text/plain, Size: 3560 bytes --]

Le vendredi 30 août 2019 à 07:48 +0200, Boris Brezillon a écrit :
> On Thu, 29 Aug 2019 21:04:28 +0200
> Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> 
> > Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon 
> > napisal(a):
> > > Hi Jernej,
> > > 
> > > On Thu, 22 Aug 2019 21:44:57 +0200
> > > 
> > > Jernej Skrabec <jernej.skrabec@siol.net> wrote:  
> > > > When codec supports multiple slices in one frame, VPU has to know when
> > > > first slice of each frame is being processed, presumably to correctly
> > > > clear/set data in auxiliary buffers.
> > > > 
> > > > Add first_slice field to cedrus_run structure and set it according to
> > > > timestamps of capture and output buffers. If timestamps are different,
> > > > it's first slice and viceversa.
> > > > 
> > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > > ---
> > > > 
> > > >  drivers/staging/media/sunxi/cedrus/cedrus.h     | 1 +
> > > >  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > > >  2 files changed, 3 insertions(+)
> > > > 
> > > > 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 {
> > > > 
> > > >  struct cedrus_run {
> > > >  
> > > >  	struct vb2_v4l2_buffer	*src;
> > > >  	struct vb2_v4l2_buffer	*dst;
> > > > 
> > > > +	bool first_slice;
> > > > 
> > > >  	union {
> > > >  	
> > > >  		struct cedrus_h264_run	h264;
> > > > 
> > > > 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)
> > > > 
> > > >  	run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > >  	run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > > > 
> > > > +	run.first_slice =
> > > > +		run.src->vb2_buf.timestamp != run.dst-  
> > > vb2_buf.timestamp;
> > > 
> > > 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).  
> > 
> > I looked in all VPU documentation available to me (which isn't much) and there 
> > is no indication if ASO is supported or not. Do you have any sample video with 
> > out-of-order slices? It's my understanding that this is uncommon.
> 
> 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.
> 
> > If it's 
> > supported, I would leave code as-is.
> 
> 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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

       reply	other threads:[~2019-08-30 17:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190822194500.2071-1-jernej.skrabec@siol.net>
     [not found] ` <20190822194500.2071-6-jernej.skrabec@siol.net>
     [not found]   ` <20190826202831.311c7c20@collabora.com>
     [not found]     ` <3132748.mYbjOY1tKM@jernej-laptop>
     [not found]       ` <20190830074806.78a2b8b4@collabora.com>
2019-08-30 17:19         ` Nicolas Dufresne [this message]
     [not found] ` <20190822194500.2071-8-jernej.skrabec@siol.net>
     [not found]   ` <f105990c-e059-6bdd-433f-074388e3a2dc@xs4all.nl>
2019-09-04 23:14     ` [PATCH 7/8] media: cedrus: Add support for holding capture buffer Jernej Škrabec

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=3580d4f1549c405173f061c5e2ece3c8f2cfa7e4.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=acourbot@chromium.org \
    --cc=boris.brezillon@collabora.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=ezequiel@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=pawel@osciak.com \
    --cc=tfiga@chromium.org \
    --cc=wens@csie.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).