[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJMMOfN-6fgN0VohA5ViwVXmNWtA13ycfZFoO4ys9_CLes0feA@mail.gmail.com>
Date: Tue, 7 Feb 2023 12:15:48 +0100
From: Michał Krawczyk <mk@...ihalf.com>
To: Vikash Garodia <vgarodia@....qualcomm.com>
Cc: Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
"Vikash Garodia (QUIC)" <quic_vgarodia@...cinc.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mw@...ihalf.com" <mw@...ihalf.com>
Subject: Re: [PATCH v2] media: venus: dec: Fix handling of the start cmd
wt., 7 lut 2023 o 10:54 Vikash Garodia <vgarodia@....qualcomm.com> napisał(a):
> I have reviewed the patch, and the drain sequence handling looks good to me.
> Could you share some details on the test client which you are using to catch this issue ?
Hi Vikash,
Thank you for looking at the code!
I've been testing it using the Chromium implementation of the V4L2
codec [1]. Meanwhile, we were running a test suite which changes the
encryption method in the middle of the video decoding. This triggers
the flush behavior and the Chromium sends the stop/start cmd to the
V4L2 kernel component, and the test expects the video to continue the
playback normally. Unfortunately, it was causing a stall of the video
at the same time.
[1] https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/v4l2/
>
> > Thank you,
> > Michał
>
> Thanks,
> Vikash
Powered by blists - more mailing lists