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
Date: Fri, 21 Aug 2020 11:59:18 +0000 [thread overview]
Message-ID: <9444c9375f58436b9e6a0fa3a4088e17@skidata.com> (raw)
In-Reply-To: <3b140eaf883b4666985c0be0db8d53e8@skidata.com>
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 happens
in reverse order since multiple metas are required to fill the "current" period
(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/coda/coda.h#L340
[2] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/coda/coda-bit.c#L355
[3] https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/coda/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
next prev parent reply other threads:[~2020-08-21 12:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 11:58 [PATCH] media: coda: avoid starvation on well-compressed data Benjamin Bara - SKIDATA
2020-08-21 11:59 ` Benjamin Bara - SKIDATA [this message]
2020-09-18 8:35 ` Benjamin Bara - SKIDATA
2020-09-28 20:06 ` Ezequiel Garcia
2020-10-06 14:56 ` Benjamin Bara - SKIDATA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9444c9375f58436b9e6a0fa3a4088e17@skidata.com \
--to=benjamin.bara@skidata.com \
--cc=Richard.Leitner@skidata.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.