Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <3b140eaf883b4666985c0be0db8d53e8@skidata.com> <9444c9375f58436b9e6a0fa3a4088e17@skidata.com>
 <AM6PR01MB55741EE09532A7C60CD05B71E23F0@AM6PR01MB5574.eurprd01.prod.exchangelabs.com>
In-Reply-To: <AM6PR01MB55741EE09532A7C60CD05B71E23F0@AM6PR01MB5574.eurprd01.prod.exchangelabs.com>
From:   Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date:   Mon, 28 Sep 2020 17:06:24 -0300
Message-ID: <CAAEAJfDnC5=iomoNivrwKt5th866qMKPY0Tw9i_PfKqsFTm69Q@mail.gmail.com>
Subject: Re: [PATCH] media: coda: avoid starvation on well-compressed data
To:     Benjamin Bara - SKIDATA <Benjamin.Bara@skidata.com>
Cc:     "p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Richard Leitner - SKIDATA <Richard.Leitner@skidata.com>,
        "l.stach@pengutronix.de" <l.stach@pengutronix.de>,
        Chris Healy <cphealy@gmail.com>,
        Nicolas Dufresne <nicolas.dufresne@collabora.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Benjamin,

On Fri, 18 Sep 2020 at 05:35, Benjamin Bara - SKIDATA
<Benjamin.Bara@skidata.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
>