From: Jernej Skrabec <jernej.skrabec@gmail.com>
To: mripard@kernel.org, paul.kocialkowski@bootlin.com
Cc: mchehab@kernel.org, gregkh@linuxfoundation.org, wens@csie.org,
samuel@sholland.org, hverkuil-cisco@xs4all.nl,
linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
Jernej Skrabec <jernej.skrabec@gmail.com>
Subject: [PATCH 0/2] media: cedrus: h264/h265: Improve aux buffer management
Date: Wed, 19 Oct 2022 19:45:49 +0200 [thread overview]
Message-ID: <20221019174551.2695149-1-jernej.skrabec@gmail.com> (raw)
Current handling of mv col aux buffers in h264 and h265 code is not
optimal. In h264 case, it allocates pool for worst case possible which
basically never happens with typical videos. This also prevents it from
working well on very memory constrained devices, where CMA pool is very
small. In h265 case, number of buffers in a pool is equal to number of
capture buffers allocated before streaming is started. If any capture
buffer is allocated afterwards, Cedrus gets bogus pointers. This might
cause memory corruption.
Solution is the same in both cases. Instead of using memory pool, do
individual allocations later, right before aux buffer is first used.
Such approach allocates just right amount of buffers of optimal size.
Proposed solution frees aux buffers in streaming off callback, which
is first possible occasion. I can move this to .buf_cleanup too, if you
think that it's more appropriate.
Finally, h265 patch can be considered as a fix (prevents overwriting
random memory). If deemed appropriate, fixes tag can be added.
Let me know what you think.
Best regards,
Jernej
Jernej Skrabec (2):
media: cedrus: h265: Associate mv col buffers with buffer
media: cedrus: h264: Optimize mv col buffer allocation
drivers/staging/media/sunxi/cedrus/cedrus.h | 16 +--
.../staging/media/sunxi/cedrus/cedrus_h264.c | 118 +++++++++---------
.../staging/media/sunxi/cedrus/cedrus_h265.c | 63 +++++-----
3 files changed, 99 insertions(+), 98 deletions(-)
--
2.38.0
next reply other threads:[~2022-10-19 17:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 17:45 Jernej Skrabec [this message]
2022-10-19 17:45 ` [PATCH 1/2] media: cedrus: h265: Associate mv col buffers with buffer Jernej Skrabec
2022-10-19 17:45 ` [PATCH 2/2] media: cedrus: h264: Optimize mv col buffer allocation Jernej Skrabec
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=20221019174551.2695149-1-jernej.skrabec@gmail.com \
--to=jernej.skrabec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-sunxi@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=mripard@kernel.org \
--cc=paul.kocialkowski@bootlin.com \
--cc=samuel@sholland.org \
--cc=wens@csie.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®