From: Vikash Garodia <quic_vgarodia@quicinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Marc Gonzalez <mgonzalez@freebox.fr>,
Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: linux-media <linux-media@vger.kernel.org>,
MSM <linux-arm-msm@vger.kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Jeffrey Hugo <quic_jhugo@quicinc.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Pierre-Hugues Husson <phh@phh.me>,
Marijn Suijten <marijn.suijten@somainline.org>
Subject: Re: [RFC WIP PATCH] venus: add qcom,no-low-power property
Date: Wed, 10 Apr 2024 16:04:57 +0530 [thread overview]
Message-ID: <855d6c78-c06f-db9c-13b9-b8417ea62121@quicinc.com> (raw)
In-Reply-To: <8b9cc46d-4267-43fb-b2be-f5996566a349@linaro.org>
On 4/10/2024 1:47 PM, Bryan O'Donoghue wrote:
> On 09/04/2024 17:53, Marc Gonzalez wrote:
>> On 09/04/2024 13:27, Bryan O'Donoghue wrote:
>>
>>> Can you give it a try ?
>>
>> Random notes
>>
>> For easy reference, I've used this command to test:
>>
>> $ mpv --hwdec=v4l2m2m-copy --vo=tct --quiet --no-audio demo-480.webm
>>
>> And it displays the video directly in the terminal :)
>> (Rendering speed depends on terminal size)
>>
>> I'd never played the video to the end.
>> I notice I get:
>>
>> [ 397.410006] qcom-venus cc00000.video-codec: session error: event id:1001
>> (deadb000), session id:79d7c000
>> [ 397.410114] qcom-venus-decoder cc00000.video-codec:video-decoder: dec:
>> event session error 1001
>>
>> How bad is that?
>>
>>
>> Sometimes, decoding simply fails immediately.
>> Must quit & restart.
>> Will have to script a 100 starts and check frequency of failures.
>>
>>
>> Will test with higher-resolution video.
We were writing sample test application [1] to test video usecase and more
specifically with user driven inputs. Incase this help in your trial. I haven't
yet tried this on venus driver and used it mainly for the some other v4l video
driver, but i can expect it to work given it is v4l interface based. It has few
sample config which can dump the decoded output to validate. Ignore if this adds
to your effort to validate from this app, will publish once we try on venus driver.
Regards,
Vikash
[1] https://github.com/quic/v4l-video-test-app
>>
>> # time mpv --hwdec=v4l2m2m-copy --vo=null --quiet --no-audio --untimed
>> demo-480.webm
>> (+) Video --vid=1 (*) (vp9 854x480 29.970fps)
>> Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> Using hardware decoding (v4l2m2m-copy).
>> VO: [null] 854x480 nv12
>> [ffmpeg/video] vp9_v4l2m2m: capture POLLERR
>> Exiting... (Quit)
>> /*** HANGS UNTIL CTRL-C ***/
>
> I think there are a number of different resolutions across SoCs that will
> exhibit this behavior, I've seen it with lower resolutions on 8250.
>
> Its a bug that we need to drill into in Venus but I don't think is a bug that is
> specific to your setup.
>
>>
>> real 0m21.467s
>> user 0m3.795s
>> sys 0m1.914s
>>
>>
>> # time mpv --hwdec=v4l2m2m-copy --vo=null --quiet --no-audio --untimed
>> --length=30 demo-1440.webm
>> (+) Video --vid=1 (*) (vp9 2560x1440 59.940fps)
>> Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
>> [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
>> Using hardware decoding (v4l2m2m-copy).
>> VO: [null] 2560x1440 nv12
>> Exiting... (End of file)
>>
>> real 0m16.433s
>> user 0m1.764s
>> sys 0m1.118s
>
> If this higher resolution is stable for you, I'd say this is about baseline.
>
> 1. The GDSC change should make no impact on playback or available resolution
>
> 2. Higher more "normal" use cases like 1080p should be fine.
>
> If so, then file "low resolution is broken" under a "known unknown" and scrub
> your patches for submission.
>
> If not, we need to do more 8998 specific debug.
>
> ---
> bod
next prev parent reply other threads:[~2024-04-10 10:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 17:18 [RFC WIP PATCH] venus: add qcom,no-low-power property Marc Gonzalez
2024-02-19 17:28 ` Konrad Dybcio
2024-02-19 17:44 ` Dmitry Baryshkov
2024-02-19 19:24 ` Bryan O'Donoghue
2024-02-20 10:56 ` Marc Gonzalez
2024-02-20 11:21 ` Bryan O'Donoghue
2024-02-20 11:37 ` Krzysztof Kozlowski
2024-02-20 12:34 ` Marc Gonzalez
2024-02-20 13:27 ` Krzysztof Kozlowski
2024-02-20 13:53 ` Vikash Garodia
2024-02-20 14:45 ` Marc Gonzalez
2024-02-23 13:48 ` Vikash Garodia
2024-02-26 13:09 ` Marc Gonzalez
2024-02-26 14:30 ` Vikash Garodia
2024-02-26 15:55 ` Marc Gonzalez
2024-02-27 6:55 ` Vikash Garodia
2024-02-27 16:11 ` Marc Gonzalez
2024-02-29 15:32 ` Vikash Garodia
2024-02-29 16:24 ` Marc Gonzalez
2024-02-29 16:47 ` Jeffrey Hugo
2024-03-12 18:39 ` Konrad Dybcio
2024-04-10 10:24 ` Vikash Garodia
2024-04-08 15:39 ` Marc Gonzalez
2024-04-09 11:27 ` Bryan O'Donoghue
2024-04-09 14:09 ` Marc Gonzalez
2024-04-09 16:53 ` Marc Gonzalez
2024-04-10 8:17 ` Bryan O'Donoghue
2024-04-10 10:34 ` Vikash Garodia [this message]
2024-04-10 12:23 ` Marc Gonzalez
2024-04-10 13:14 ` Bryan O'Donoghue
2024-04-10 13:18 ` Marc Gonzalez
2024-04-10 13:29 ` Bryan O'Donoghue
2024-04-10 13:31 ` Bryan O'Donoghue
2024-04-11 9:02 ` Bryan O'Donoghue
2024-04-25 16:43 ` Marc Gonzalez
2024-04-30 16:13 ` venus decoder hangs at EOF Marc Gonzalez
2024-02-19 18:33 ` [RFC WIP PATCH] venus: add qcom,no-low-power property Rob Herring
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=855d6c78-c06f-db9c-13b9-b8417ea62121@quicinc.com \
--to=quic_vgarodia@quicinc.com \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mchehab@kernel.org \
--cc=mgonzalez@freebox.fr \
--cc=phh@phh.me \
--cc=quic_jhugo@quicinc.com \
--cc=stanimir.k.varbanov@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).