03:26 <Allak> To be a ghost with a pulse, get in a situation where the mind gives the perceived death signal, by watching a scary movie alone in the dark, and when it does just ignore it or pay no attention to it.- Daniel Alan Gabriel- ghostpeople@gmx.com

08:06 <janneg> tobhe_: which AsahiLinux/u-boot branch/tags does UbuntuAsahi use? I suspect it might be 'asahi' instead of the working 'asahi-releng' see https://github.com/AsahiLinux/linux/issues/115

08:07 <janneg> marcan: can I get permissions to close issues across the github repos?

08:30 <kettenis_> ah, I still need to pick up marcan's oslog diff

08:59 <eiln> janneg: decode stream skeleton https://pastebin.com/ZxRyPRPm. this generates a decode stream for a trivial 30sec test video, though output is bit-identical to macos

08:59 <eiln> we basically hand it off at the macroblocks. it's not just parsing headers, we have actively manage state, including reference lists which it is particularly picky about

08:59 <eiln> how should we go about this in v4l2

08:59 <eiln> currently writing python bindings around ffmpeg/h264bitstream because my current attempted backend is showing its limits

09:45 <janneg> eiln: we do not have to parse the bitstream and manage state. the user application is responsible for that for the stateless v4l2 m2m decoder interface. see https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/ext-ctrls-codec-stateless.html for what the video decoder can expect to receive

10:08 <eiln> janneg: it sends a lot more than I thought. but we still need a couple more e.g. ref_pic_list_modification_flag_l0 and some not in spec e.g. counter from last I slice. I don't know if I trust myself to do all this in the kernel though, iova allocations and all

11:37 <janneg> it would be unfortunate if avd requires doing the reference pic management itself and requires explicitly parsed values for it. I don't see a reason why anyone would want to do that in the HW decoder itself (unless it's black box which excepts bitstream data and outputs decoded frames)

13:29 <tobhe_> janneg: hm I usually use release tags

13:30 <tobhe_> why do you ask? did someone report a bug somewhere?

13:31 <j`ey> tobhe_: https://github.com/AsahiLinux/linux/issues/115

13:34 <tobhe_> thx for redirecting them to our bug tracker. I think this might have been fixed by recent kernel and m1n1 updates

13:34 <tobhe_> if not they will hopefully open a new bug

13:53 <janneg> tobhe_: asahi release tags are fine too

13:55 <janneg> eiln: I've previously missed this in your avd notes: has avd in M1 already (partial) support for AV1?

15:40 <janneg> eiln: has the M1 avd firmware (hardware) av1 support?

15:43 <eiln> janneg: I worded that terribly, pushed a fix. 2/6 revisions support AV1, mine is not one of them. 12.5 has them, so those two have been there for a while.

15:44 <eiln> mmco L0 ST unref signal is [0x2de04201, 0x2df0ffff]. it's not managing the lists itself, it's to signal that *we* did

15:44 <eiln> ref_pic_list_modification_flag_l0 I would guess it's to adjust pic_num. weirdly when a frame is unrefed the pic_nums in the reflist get shifted to 0, hence the i = list(fmt.ref_map.keys()).index(lst.fn)

15:44 <eiln> either way things do not work without it

15:44 <eiln> I don't even know which codenames are which outside of mine (j293ap "viola")

15:44 <eiln> the firmware doesn't do much codec specifc. it kinda just pipes the kext-given decode stream, albeit really overcomplicatedly

15:49 <eiln> it's a hassle to switch to the vp9 branch rn but the firmware ran the identical interrupt handler. I poked it myself and got it working with the same register layout too. it seems to be their "unified codec" model hence the kernel handles all the syntax parsing / mgmt stuff

15:52 <eiln> actually I think all this is glue in effort to unify the entry point

16:20 <marcan> eiln: going by devicetrees, M1 has AVD "V3", everything after that (including t600x) has "V4"

16:32 <eiln> it doesn't seem like there's a public videotoolbox api, but I don't know why there would be two hal revisions (sitting in the kernel for a year+) for something unreleased

19:39 <janneg> a17 pro is still avd-version = 4 and compatible = "avd,t8103"