linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Jernej Škrabec" <jernej.skrabec@gmail.com>
To: mripard@kernel.org, paul.kocialkowski@bootlin.com,
	Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: mchehab@kernel.org, gregkh@linuxfoundation.org, wens@csie.org,
	samuel@sholland.org, hverkuil-cisco@xs4all.nl,
	ezequiel@vanguardiasur.com.ar, linux-media@vger.kernel.org,
	linux-staging@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH] media: cedrus: hevc: Add check for invalid timestamp
Date: Mon, 18 Jul 2022 19:57:49 +0200	[thread overview]
Message-ID: <4725382.GXAFRqVoOG@kista> (raw)
In-Reply-To: <d58e8624e9703e5dbbc54908aa142d10ef7f5a22.camel@collabora.com>

Dne ponedeljek, 18. julij 2022 ob 19:41:48 CEST je Nicolas Dufresne 
napisal(a):
> Le lundi 18 juillet 2022 à 18:56 +0200, Jernej Skrabec a écrit :
> > Not all DPB entries will be used most of the time. Unused entries will
> > thus have invalid timestamps. They will produce negative buffer index
> > which is not specifically handled. This works just by chance in current
> > code. It will even produce bogus pointer, but since it's not used, it
> > won't do any harm.
> > 
> > Let's fix that brittle design by skipping writing DPB entry altogether
> > if timestamp is invalid.
> > 
> > Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > ---
> > 
> >  drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index
> > 1afc6797d806..687f87598f78 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > @@ -147,6 +147,9 @@ static void cedrus_h265_frame_info_write_dpb(struct
> > cedrus_ctx *ctx,> 
> >  			dpb[i].pic_order_cnt_val
> >  		
> >  		};
> > 
> > +		if (buffer_index < 0)
> > +			continue;
> 
> When I compare to other codecs, when the buffer_index does not exist, the
> addr 0 is being programmed into the HW. With this implementation is is left
> to whatever it was set for the previous decode operation. I think its is
> nicer done the other way.

It's done the same way as it's done in vendor lib. As I stated in commit 
message, actual values don't matter for unused entries. If it is used by 
accident, HW reaction on all zero pointers can only be worse than using old, 
but valid entry.

Due to no real documentation and Allwinner unwillingness to share details, 
we'll probably never know what's best response for each error. Some things can 
be deduced from vendor code, but not all.

I would rather not complicate this fix, especially since it's candidate for 
backporting.

Best regards,
Jernej

> 
> > +
> > 
> >  		cedrus_h265_frame_info_write_single(ctx, i, 
dpb[i].field_pic,
> >  		
> >  						    
pic_order_cnt,
> >  						    
buffer_index);



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-07-18 17:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-18 16:56 [PATCH] media: cedrus: hevc: Add check for invalid timestamp Jernej Skrabec
2022-07-18 17:41 ` Nicolas Dufresne
2022-07-18 17:57   ` Jernej Škrabec [this message]
2022-07-18 19:37     ` Nicolas Dufresne
2022-07-18 20:34       ` Jernej Škrabec
2022-07-18 21:49         ` Ezequiel Garcia
2022-08-18 18:46           ` Nicolas Dufresne

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=4725382.GXAFRqVoOG@kista \
    --to=jernej.skrabec@gmail.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=samuel@sholland.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).