linux-kernel - Re: [PATCH] media: coda: avoid starvation on well-compressed data

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: <CAAEAJfDnC5=iomoNivrwKt5th866qMKPY0Tw9i_PfKqsFTm69Q@mail.gmail.com>
Date:   Mon, 28 Sep 2020 17:06:24 -0300
From:   Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To:     Benjamin Bara - SKIDATA <Benjamin.Bara@...data.com>
Cc:     "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Richard Leitner - SKIDATA <Richard.Leitner@...data.com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        Chris Healy <cphealy@...il.com>,
        Nicolas Dufresne <nicolas.dufresne@...labora.com>
Subject: Re: [PATCH] media: coda: avoid starvation on well-compressed data

Hi Benjamin,

On Fri, 18 Sep 2020 at 05:35, Benjamin Bara - SKIDATA
<Benjamin.Bara@...data.com> wrote:
>
> Hi all,
>
> there are still cases where the decoder starves.
> Also, the failure log at the bottom contradicts with the 2x256 bytes assumption.
> When I increase the threshold to 512 bytes, the respective video (and all my other tests) work.
>
> Is it possible that the limitation is 2x512 bytes or is there another "limitation",
> beside the "two window" one, which is "accidentally fulfilled" with this approach?
>
> What do you think about the approach in the patch; is it possible to get it mainline?
> Any help, feedback, hints or suggestions would be really appreciated!
>
> I will do some additional testing to see if the 2x512 threshold finally catches the problem.
> When I'm done, I will provide a second version of the patch.
>

Thanks for the report. I'm seeing a similar behavior and have been doing
some experiments with your patch, and trying different solutions as well.

My colleague Nicolas pointed out to me that crafting a video
with serie of black frames in QCIF resolution, would trigger the timeout:

gst-launch-1.0 videotestsrc pattern=black num-buffers=300 !
video/x-raw,format=I420,width=176,height=120 ! avenc_mpeg2video !
mpegvideoparse ! mpegtsmux ! filesink location=black-qcif-10s.ts

We are still doing some tests to see if we can come up with a proper
solution. I will keep you posted.

If you have some (public) bitstream that are known to timeout,
and that you could share with me, that would be nice, so I could
have a more complete set of samples.

Thanks,
Ezequiel

> Many thanks & best regards
> Benjamin
>
> *Failure Log:*
> [  108.108711] coda 2040000.vpu: 0: active metas:
> [  108.108716] coda 2040000.vpu: 0: - payload: 4240
> [  108.108721] coda 2040000.vpu: 0: - payload: 900
> [  108.108726] coda 2040000.vpu: 0: - payload: 170
> [  108.108730] coda 2040000.vpu: 0: - payload: 403
> [  108.108734] coda 2040000.vpu: 0: want to queue: payload: 405
> [  109.057738] coda 2040000.vpu: CODA PIC_RUN timeout
>