From: bod@kernel.org
To: David Heidelberg <david@ixit.cz>
Cc: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
Bryan O'Donoghue <bod@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: venus: vdec: Start capture after a seek that streams CAPTURE first
Date: Fri, 09 Oct 2026 10:16:14 +0100 [thread overview]
Message-ID: <179153737482.2596899.8050983650709172841.b4-reply@b4> (raw)
In-Reply-To: <20260928-venus-vdec-eos-v1-2-6e9eb3ce9849@ixit.cz>
On 2026-09-28 23:40 +0200, David Heidelberg wrote:
> After both queues are streamed off, the decoder sits in
> VENUS_DEC_STATE_SEEK. vdec_start_capture() does nothing while OUTPUT is
> not streaming, and when OUTPUT is streamed on again, the SEEK path only
> queues the DPB buffers if the capture side was already started. So an
> application that streams on CAPTURE before OUTPUT gets a decoder that
> never receives DPB or capture buffers: the firmware consumes the
> bitstream and no frame is ever returned.
>
> The stateful decoder interface does not require either order, and
> GStreamer restarts with CAPTURE first. Finish the capture start from the
> OUTPUT SEEK path when the CAPTURE queue is already streaming, the same
> way vdec_start_capture() does in VENUS_DEC_STATE_DECODING.
>
> Assisted-by: LLM
> Signed-off-by: David Heidelberg <david@ixit.cz>
This one is certainly missing at least a Fixes:
---
bod
prev parent reply other threads:[~2026-10-09 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 21:40 [PATCH 0/2] media: venus: vdec: fix drain and restart on SDM845 David Heidelberg via B4 Relay
2026-09-28 21:40 ` [PATCH 1/2] media: venus: vdec: signal EOS with a real buffer David Heidelberg via B4 Relay
2026-10-09 9:15 ` bod
2026-10-16 13:34 ` David Heidelberg
2026-10-16 13:36 ` Bryan O'Donoghue
2026-09-28 21:40 ` [PATCH 2/2] media: venus: vdec: Start capture after a seek that streams CAPTURE first David Heidelberg via B4 Relay
2026-10-09 9:16 ` bod [this message]
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=179153737482.2596899.8050983650709172841.b4-reply@b4 \
--to=bod@kernel.org \
--cc=david@ixit.cz \
--cc=dikshita.agarwal@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=mchehab@kernel.org \
--cc=stanimir.varbanov@linaro.org \
--cc=vikash.garodia@oss.qualcomm.com \
/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®