Message-ID: <8bfacddaf6c8a94bccbae5c6a83688d42bbf63a9.camel@ndufresne.ca>
Date:   Mon, 29 Apr 2019 20:47:23 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Hans Verkuil <hverkuil@...all.nl>,
        Alexandre Courbot <acourbot@...omium.org>
Cc:     Tomasz Figa <tfiga@...omium.org>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Dafna Hirschfeld <dafna3@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Boris Brezillon <boris.brezillon@...labora.com>,
        kernel mailing list <kernel@...ts.collabora.co.uk>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH v4] media: docs-rst: Document m2m stateless video
 decoder interface

Le lundi 29 avril 2019 à 22:32 +0200, Paul Kocialkowski a écrit :
> > Adding Boris in CC. Boris, do you think that could possibly fit into
> > your todo while working on the H264 accelerator on RK ? If needed I can
> > generate test streams, there is couple of lines of code to remove / add
> > in FFMPEG backend if you want to test this properly, though I'm not
> > able to run this code atm (it requires a working DRM, and I'm having
> > issues with my board in this regard).
> 
> Well, that seems like a task that requires in-depth knowledge about how
> the v4l2 m2m core and the request API work and some familiary with
> it. My feeling is that Boris is pretty new to all of this, so perhaps
> it would be best for him to focus on the rockchip driver alone, which
> is already a significant piece of work on its own.
> 
> It looks like Hans has proposed to come up with something soon, so
> things are looking good for us. Once we have that, I think the next
> area we need to look into is how we need to rework and refine the
> controls. I think it would be good to define common guidelines for
> adapting bitstream descriptions into controls with what the hardware
> needs to know about precisely.
> 
> In spite of that, I would be very interested in knowing what the
> rockchip MPEG-2 and H.264 decoders expect precisely. I'm also

We are still working on that. For now, we believe that the list (and
traces from real stream matches) are according to the standard
"Initialization process" section 8.2.4.2. But they run both P and B
initialization regardless of the type, hence the 3 lists. But the
modification (section 8.4.2.3) are not applied. They also program the 3
lists regardless of the current picture type. This is quite strange.
Tomorrow I'll mark all b0/b1 value as invalid on P slice and the
opposite for B slice to see if that still decodes fine. If that was the
case, it would mean that the current list are complete, but not in the
expected order.

What I'm wondering is if it would be fine to add more information to
the DPB entry so that we could simply implement 8.2.4.2 to re-create
the pre-modification order. It's more doable then trying to reverse the
modifications and would offer a better uAPI in exchange for a very
small overhead.

> interested in learning about Tegra decoders and there are also docs
> about the Hantro G1 (MPEG-2 to H.264) and Hantro G2 (H.265) which are
> well documented in the i.MX8M docs. It's also used on some Atmel
> platforms apparently. So feedback regarding the current controls that
> Maxime and I came up with would be welcome.

Powered by blists - more mailing lists