11:12 <warpme> detlevc : just fyi: i updated rkvdec to current one and now rkvdec3 h264 issue is more "consistent": on some content playback is consistently fine while on other is consistently with artefacts. For example this sample plays always ok: https://minimyth2.mooo.com/h264-TVN_2_1080_25fps.ts This sample always has artefacts: http://minimyth2.mooo.com/h264-Sat_1080i_25fps.mkv So maybe there is specific h264 content type when rkvdec3 fails? All this is

11:12 <warpme> only on rkvdec3. rkvdec2 is all fine.

13:45 <CounterPillow> mmind00: looks like RK3588 surprisingly enough does not need the same svbus treatment. I have no idea why. the vbus valid pin of the board I'm using is pulled up, not even by an fusb302 but by a resistor. May need to cobble together some solution to power one of my other RK3588 boards through not-usb-c so I can look into what's happening there.

14:01 <CounterPillow> the rock5b I have also just ties it high, and the ODROID M2 I have also just ties it high. Now I'm gonna look into the sige5 again, which also seems to just tie it high, to make sure what I'm doing is actually needed

14:04 <CounterPillow> oh, I should probably test with a USB-C device that does not have a battery in it

14:11 <CounterPillow> now it just works on sige5 as well without the patch :/ what the hell changed between me getting stuck in detection loops and now

14:23 <CounterPillow> this is the downstream commit btw https://github.com/rockchip-linux/kernel/commit/7d2237b0adc2e0a0105d63b645528993b44c8c36

14:31 <CounterPillow> even with the udphy part that also sets those grf regs commented out and a cold reboot, it's no longer needed. Oh well, mysteries

14:47 <detlevc> warpme: Still all fine here. I'll need the exact distro you are using (kernel + userspace), because I have no idea what is happening on your side

14:49 <detlevc> warpme: Have you seen the issue with mpv + patched ffmpeg ?

14:54 <warpme> detlevc : let me rebuild latest mpv. i'm not playing with mpv frequently - do i need patching it to add v4l2_request support?

14:55 <detlevc> warpme: No, it just uses ffmpeg for that

14:56 <warpme> ah ok - let me try then. give me sec

14:56 <detlevc> then just mpv --no-audio -fs --hwdec=v4l2request --msg-level=vd=v ~/h264-Sat_1080i_25fps.mkv

14:56 <warpme> oh thx for this. indeed helpful!

14:57 <detlevc> also, do you run your tests standalone or on to of a wayland compositor like weston ?

15:21 <warpme> my tests are: mythtv: eglfs (qt full screen via egl); kodi: kodi-gbm. I tested 2 drawing methods: egl dmabuf and direct-to-plane. both players with both drawing methods have the same artefacts. Now i tested also mpv and with mpv there is on artefacts....but this is because - by some reason - mpv is not using hw accell : https://gist.github.com/warpme/5b7a24904430a4ec017b7bfb5ea12108 Should i run mpv under Xserver maybe?

15:24 <warpme> when you are playing sample under your mpv: what cpu load you have?

15:30 <detlevc> Is it using the patched ffmpeg version ?

15:32 <detlevc> The mpv log gives me `Using hardware decoding (v4l2request).` and I checked with strace that v4l2 ioctl are used

15:32 <warpme> i think yes. i have single build wide ffmpeg7.1 used by kodi and mpv. are you building yours mpv from sources?

15:35 <detlevc> Oh yes, right, I forgot it actually also needs patches, I built a debian package from this: https://salsa.debian.org/diederik/mpv

15:36 <detlevc> warpme this branch: https://salsa.debian.org/diederik/mpv/-/tree/v4l2request-support

15:37 <detlevc> but I guess you can just apply the patches in debian/patches/v4l2request/ if you don't want to build a debian package (which would be understandable)

15:37 <warpme> ah this is important. let me try build from this branch...

15:50 <warpme> hmm with this branch still sw.decoding: https://gist.github.com/warpme/4f0444c62f0dcbcee85876cff1af7ad8 What ffmpeg ver are you using?

15:52 <warpme> by some reason i'm getting: [vd] Could not create device.

15:52 <detlevc> Mmmh, that's a debian package tree, did you apply the patches manually ?

15:52 <detlevc> I use ffmpeg at tag n7.1, with the patches you pointed to me

15:52 <warpme> do you mean patches on : ffmpeg ot mpv?

15:52 <detlevc> mpv

15:53 <detlevc> well, both actually

15:54 <warpme> mpv: nope. i'm building just from diederik repo; ffmpeg: yes. it is patched with v4l2_req code

15:55 <detlevc> ok, so diederik repo doesn't have the patches applied, you have to apply them manually from the debian/patches/v4l2request folder

16:00 <warpme> ok now hw accell works and i .... have artefacts :-)

16:02 <warpme> what exact ffmpeg v4l2_req patches are you using?

16:02 <detlevc> that's a way to confirm hw accel :')

16:02 <warpme> :-)

16:02 <detlevc> ffmpeg patches: https://github.com/warpme/minimyth2/tree/master/script/lib/ffmpeg7.1/

16:03 <detlevc> applied on tag n7.1 from FFmpeg upstream

16:04 <warpme> ok let me try rebuild with dedicated ffmpeg7.1 libs (now i'm using system wide shared between myth, kodi and mpv)

16:04 <detlevc> ok

16:04 <detlevc> do you still use a kernel based on 6.15 ? or is it my driver branch as is ?

16:08 <warpme> i'm on 6.16 + all commits from https://gitlab.collabora.com/detlev/linux/-/commits/add-vdpu381-and-383-to-rkvdec

16:23 <diederik> warpme: You first need to built the patched ffmpeg and then you need to install the -dev packages it generates and then you build mpv with its own (2) patches

16:25 <warpme> yes. i done exactly such order (deleted any ffmpeg libs; build ffmpeg7.1 with v4l2 patches; rebuild mpv with 2 patches) and...still artefacts

16:25 <diederik> When building a debian package, the patches under debian/patches (which are listed in debian/patches/series) get applied (and then the compile itself starts).

16:26 <diederik> ok :-)

16:27 <warpme> i'm not at debian. i'm on my distro build system... I'll try to go with exact detlev kernel repo (no any other patches)

16:28 <diederik> I haven't yet tried detlevc' patch-set, but I did get mixed results previously. But that was with rkvdec1 and it's been a while since I last tried it

16:28 <warpme> now i must run. will return to you soon!

16:32 <diederik> I kinda had that feeling; my description was to explain the separation *in* Debian packages between the normal/upstream source and (potential) Debian patches applied on top. Outside Debian packages you can just ``git am`` the patches under debian/patches (in the sequence mentioned in the series file)