linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: "Jernej Škrabec" <jernej.skrabec@siol.net>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Hans Verkuil" <hans.verkuil@cisco.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Sakari Ailus" <sakari.ailus@iki.fi>,
	linux-media@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
	kernel@collabora.com,
	"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
	"Ezequiel Garcia" <ezequiel@collabora.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Alexandre Courbot" <acourbot@chromium.org>
Subject: Re: [PATCH RFC 5/6] media: cedrus: Make the slice_params array size limitation more explicit
Date: Tue, 4 Jun 2019 10:12:10 +0200	[thread overview]
Message-ID: <20190604081210.GA9048@ulmo> (raw)
In-Reply-To: <0fbe395c644bfba4830e98d208c143b8a265498a.camel@ndufresne.ca>

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On Mon, Jun 03, 2019 at 07:55:48PM -0400, Nicolas Dufresne wrote:
> Le lundi 03 juin 2019 à 23:48 +0200, Jernej Škrabec a écrit :
> > Dne ponedeljek, 03. junij 2019 ob 13:09:45 CEST je Boris Brezillon napisal(a):
> > > The driver only supports per-slice decoding, and in that mode
> > > decode_params->num_slices must be set to 1 and the slice_params array
> > > should contain only one element.
> > 
> > What Cedrus actually needs to know is if this is first slice in frame or not. I 
> > imagine it resets some stuff internally when first slice is processed.
> > 
> > So if driver won't get all slices of one frame at once, it can't know if this 
> > is first slice in frame or not. I guess we need additional flag for this.
> 
> A first slice of a frame comes with a new timestamp, so you don't need
> a flag for that.

But slices for the same frame will all have the same timestamp, so we
can't use the timestamp to tell the individual slices apart.

I mentioned this in that other thread, but I think it'd be useful to
pass along the number of each of the slices. Drivers can use this in
order to conceal errors when corrupt slices are detected during the
decode operation.

So if we also passed a slice index along with the offset of the slice in
the bitstream, that should give us enough information to achieve both. A
slice with index 0 is obviously going to be the first slice in a frame.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-06-04  8:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 11:09 [PATCH RFC 0/6] media: uapi: h264: First batch of adjusments Boris Brezillon
2019-06-03 11:09 ` [PATCH RFC 1/6] media: uapi: h264: Clarify our expectations regarding NAL header format Boris Brezillon
2019-06-03 11:09 ` [PATCH RFC 2/6] media: uapi: h264: Add the concept of decoding mode Boris Brezillon
2019-06-03 12:30   ` Thierry Reding
2019-06-03 12:51     ` Boris Brezillon
2019-06-03 14:05       ` Thierry Reding
2019-06-03 15:37         ` Boris Brezillon
2019-06-04  8:16           ` Thierry Reding
2019-06-05 20:48             ` Paul Kocialkowski
2019-06-06  6:55               ` Boris Brezillon
2019-06-05 20:55   ` Paul Kocialkowski
2019-06-03 11:09 ` [PATCH RFC 3/6] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists Boris Brezillon
2019-06-03 11:09 ` [PATCH RFC 4/6] media: cedrus: Prepare things to support !compound controls Boris Brezillon
2019-06-05 20:57   ` Paul Kocialkowski
2019-06-06  6:58     ` Boris Brezillon
2019-06-03 11:09 ` [PATCH RFC 5/6] media: cedrus: Make the slice_params array size limitation more explicit Boris Brezillon
2019-06-03 21:48   ` Jernej Škrabec
2019-06-03 23:55     ` Nicolas Dufresne
2019-06-04  8:12       ` Thierry Reding [this message]
2019-06-04  8:28         ` Boris Brezillon
2019-06-04 14:31         ` Nicolas Dufresne
2019-06-05 21:01           ` Paul Kocialkowski
2019-06-06  6:59             ` Boris Brezillon
2019-06-03 11:09 ` [PATCH RFC 6/6] media: cedrus: Add the H264_DECODING_MODE control Boris Brezillon

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=20190604081210.GA9048@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=acourbot@chromium.org \
    --cc=boris.brezillon@collabora.com \
    --cc=ezequiel@collabora.com \
    --cc=hans.verkuil@cisco.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=sakari.ailus@iki.fi \
    --cc=tfiga@chromium.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).