linux-kernel - Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <69347bdc0065b395f44673fea19e2b798c90fbc3.camel@ndufresne.ca>
Date:   Thu, 14 Feb 2019 11:19:15 -0500
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Tomasz Figa <tfiga@...omium.org>, Hans Verkuil <hverkuil@...all.nl>
Cc:     Philipp Zabel <p.zabel@...gutronix.de>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Vikash Garodia <vgarodia@...eaurora.org>,
        Alexandre Courbot <acourbot@...omium.org>,
        Malathi Gottam <mgottam@...eaurora.org>
Subject: Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful
 codec API

Le jeudi 14 février 2019 à 11:43 +0900, Tomasz Figa a écrit :
> > > > No, I exactly meant the OUTPUT queue. The behavior of s5p-mfc in case
> > > > of the format not being detected yet is to waits for any pending
> > > > bitstream buffers to be processed by the decoder before returning an
> > > > error.
> > > > 
> > > > See https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L329
> > > 
> > > It blocks?! That shouldn't happen. Totally against the spec.
> > > 
> > 
> > Yeah and that's what this patch tries to implement in venus as well
> > and is seemingly required for compatibility with gstreamer...
> > 
> 
> Hans, Nicolas, any thoughts?

Thinking about this, if CODA managed to make it work without this, and
without the source change event, we should probably study more this
code and propose to do this instead of blocking (which is the ugly but
easy solution). I'm sure it was a bit of juggle to pass the information
correctly from input to output, but that would bring "compatibility"
with un-ported userspace. If we had a codec specific framework (making
a wish here), we could handle that for the codec, a bit like the code
that emulates CROP on top of G/S_SELECTION.

Meanwhile, I'm trying to get some time allocated to implement the event
in GStreamer, as this would be sufficient argument to say that newly
introduce drivers don't need to care, you just need newer userspace.
For Venus it's a bit difficult, since they have customers using
GStreamer already, and it's quite common to run newer kernel with much
older userspace (and expect the userspace to keep working).

Nicolas