[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR01MB55741EE09532A7C60CD05B71E23F0@AM6PR01MB5574.eurprd01.prod.exchangelabs.com>
Date: Fri, 18 Sep 2020 08:35:38 +0000
From: Benjamin Bara - SKIDATA <Benjamin.Bara@...data.com>
To: "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"mchehab@...nel.org" <mchehab@...nel.org>
CC: "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>
Subject: RE: [PATCH] media: coda: avoid starvation on well-compressed data
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.
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
Powered by blists - more mailing lists