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;
IronPort-SDR: TX+avkr6P0SF1qLQvez799JdwigZhiedC4UbYFUElhIxFJ4s4Pebfa3uxfXGAQJxvCiorBDZPb
 Y9j7WoHt6IOya84JpUxsA7oAhfvEgNbT0YUFJ2oZ7EZHhz7FHrZZBSUHYi6FzUNVS43rMPYwEe
 kS28WNAT0jVfU6VypXw+a6gZgNJujC+lTGV+u0nvXFiKWYkEaP8tkhouOmMDbUqKPXkIK9VcJU
 ocCB+tiZdX3/DdNMyDNFuCbi+hGohkr7TCDx5g7fXBLsWjTsDPT5k/CyU5/2j5JEjOOwstC69L
 990=
From:   Benjamin Bara - SKIDATA <Benjamin.Bara@skidata.com>
To:     "p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
        "mchehab@kernel.org" <mchehab@kernel.org>
CC:     "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>
Subject: RE: [PATCH] media: coda: avoid starvation on well-compressed data
Thread-Topic: [PATCH] media: coda: avoid starvation on well-compressed data
Thread-Index: AdZ3sFkqxzglukE+Rf6iMENtrYblXQAAhVYw
Date:   Fri, 21 Aug 2020 11:59:18 +0000
Message-ID: <9444c9375f58436b9e6a0fa3a4088e17@skidata.com>
References: <3b140eaf883b4666985c0be0db8d53e8@skidata.com>
In-Reply-To: <3b140eaf883b4666985c0be0db8d53e8@skidata.com>
Accept-Language: en-US, de-AT
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi!

Our CODA960 MPEG4 decoder (i.MX6) is starving with small "static" videos.
The problem seems to occur when an I frame of size > 512 is followed by
a P frame with size < 256, e.g. reproducible with a single-color video
(or any other video with little movement) and a GoP > 1.

When hunting the problem down, it seems to be related to commit
c3d996fb03c6539771ad778cd66ff5595bfc263a, concretely
the coda_bitstream_can_fetch_past [1] call in coda_fill_bitstream [2].
In the described case, the function returns true, since the I frame reaches
the 512 byte threshold, however the requirement seems to be 2x 256,
therefore the second period has not enough data with the following P frame,
which leads to a CODA PIC_RUN timeout [3] because of starvation.

The patch enqueues another buffer if the queue-tail is below the threshold.
This ensures that the second 256 byte period is filled up for the next run.

However, if the next frame(s) are also below the threshold, the same happen=
s
in reverse order since multiple metas are required to fill the "current" pe=
riod
(see failure log below).
Also in this case buffers are enqueued until the window is filled again.

This should cover all cases without looping through the active metas.

Best regards
Benjamin


[1] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/c=
oda/coda.h#L340
[2] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/c=
oda/coda-bit.c#L355
[3] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/c=
oda/coda-common.c#L1540

*Failure Log*:
[   77.217862] coda 2040000.vpu: 0: active metas:
[   77.217872] coda 2040000.vpu: 0: - payload: 107
[   77.217877] coda 2040000.vpu: 0: - payload: 107
[   77.217882] coda 2040000.vpu: 0: - payload: 107
[   77.217887] coda 2040000.vpu: 0: - payload: 107
[   77.217892] coda 2040000.vpu: 0: - payload: 332
[   77.217896] coda 2040000.vpu: 0: want to queue: payload: 824
[   78.236142] coda 2040000.vpu: CODA PIC_RUN timeout