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
