Le lundi 04 mai 2020 à 14:01 -0400, Nicolas Dufresne a écrit :
> Le samedi 02 mai 2020 à 19:55 -0300, Ezequiel Garcia a écrit :
> > +Nicolas
> >
> > On Sat, 2020-05-02 at 20:37 +0200, Boris Brezillon wrote:
> > > On Fri, 01 May 2020 13:57:49 -0300
> > > Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote:
> > >
> > > > > > +
> > > > > > +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
> > > > > > +
> > > > > > +.. flat-table:: enum v4l2_vp9_reset_frame_context
> > > > > > + :header-rows: 0
> > > > > > + :stub-columns: 0
> > > > > > + :widths: 1 2
> > > > > > +
> > > > > > + * - ``V4L2_VP9_RESET_FRAME_CTX_NONE``
> > > > > > + - Do not reset any frame context.
> > > > > > + * - ``V4L2_VP9_RESET_FRAME_CTX_NONE_ALT``
> > > > > > + - Do not reset any frame context. This is an alternative value for
> > > > > > + V4L2_VP9_RESET_FRAME_CTX_NONE.
> > > > >
> > > > > Add `` around V4L2_VP9_RESET_FRAME_CTX_NONE.
> > > > >
> > > >
> > > > Hm, now that I look closer, what's the point
> > > > of having the NONE_ALT in our uAPI if it
> > > > has same meaning as NONE?
> > > >
> > > > I think it can be removed.
> > >
> > > The intent was to match the spec so that one can pass the value
> > > extracted from the bitstream directly.
>
> reset_frame_contextspecifies whether the frame context should be reset
> to default values:
> − 0 or 1 means do not reset any frame context
> − 2 resets just the context specified in the frame header
> − 3 resets all cont
>
> But aren't we going too far by making this an emum ? In Microsfot DXVA,
> we pass that value without interpreting it in userspace. For the
> following RKVDEC, it is (suspiciously ?) ignored. Maybe just passing
> over the value would make more sense, less work ?
I have looked deeper. So basically when 2 and 3, that needs to be done
by userspace is set back the associated probs arrays to their default
values (see section 10.5 or the spec).
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vp9d_parser.c#L1021
It seems that for both VAAPI And DXVA, the drivers takes care of that
reset. So I'd like to ask, shall we code these defaults inside the
driver ? I think we do similar things in JPEG side. But if we keep it
the way it is, this should be strictly documented, otherwise anyone
porting from DXVA or VAAPI will be tricked by this.
>
> > > > > I got several smatch warnings:
> > > > >
> > > > > smatch: ERRORS
> > > > > drivers/media/v4l2-core/v4l2-ctrls.c:1880 validate_vp9_frame_decode_params() warn: was && intended here instead of ||?
> > > > >
> > > > > (Commented on this ^^^ one above)
> > > > >
> > > > > drivers/staging/media/rkvdec/rkvdec-vp9.c:426 init_intra_only_probs() error: buffer overflow 'ptr' 9 <= 69
> > > > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1478 rkvdec_vp9_done() error: potentially dereferencing uninitialized 'ctrl'.
> > > > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1483 rkvdec_vp9_done() error: uninitialized symbol 'dec_dst_buf'.
> > > > > drivers/staging/media/rkvdec/rkvdec-vp9.c:941:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
> > > > > drivers/staging/media/rkvdec/rkvdec-vp9.c:1466:40: warning: variable 'fctx' set but not used [-Wunused-but-set-variable]
> > > > >
> > > >
> > > > Oh, I'll run smatch and fix them all.
> > >
> > > Oops!
Attachment:
signature.asc
Description: This is a digitally signed message part
