08:18 <warpme_> hi *

08:20 <warpme_> I’m courious why meson/vdec in 5.3 staging has only mpeg1/mpeg2 decode support? Is there any issue with other formats support (h265/hvec/vp9)?

08:29 <wens> slowly added one by one?

08:35 <warpme_> hmm: rationale is probably here: https://lkml.org/lkml/2019/5/27/212

09:28 <chewitt> warpme_ because if one codec is submitted (in addition to the all the other core plumbing) the amount of code to review is 1/10th the size and more likely to be done quicker

09:30 <chewitt> and the more code you submit, the more feedback you get, which also doesn't help things being merged sometimes :)

09:30 <chewitt> so .. submit the basics, get the core merged

09:30 <chewitt> then once that's done, stack the rest

09:51 <warpme_> chewitt: thx! This indeed explains :-). Probably it is worth to add that v4l2 statefull decoders spec is still under finalization - so it it make sense for me to 1\finalize specs; 2\make sure code is conformant; 3\pull code to mainline; 4\let api consumers (ffmpeg, etc) follow standarized api. It takes time - but imho goal seems to be attracive: standarized way to access sooooo fragmented arm hw decode world

09:53 <chewitt> stateful should mature once the Raspberry Pi foundation stop fiddling with their current GBM/MMAL arrangement and refocus on GBM/V4L2

09:55 <chewitt> currently the carrot is being dangled, but more stick needs to be wielded

09:56 <warpme_> chewitt: ough. that would be fantastic!. So far their answer for: when v4l2 m2m in mainline? is: „When we have resource to attempt to upstream it.

09:56 <warpme_> Sorry, upstreaming stuff is not a priority.”

09:57 <warpme_> chewitt: this for sure excludes rpi from my shopping list!

09:58 <chewitt> we already have it half-running

09:58 <chewitt> the ffmpeg side is under-developed

09:59 <chewitt> modern v4l2 support was originally first-done on amlogic, to a basic (useable but not polished) state

10:00 <chewitt> then all the stateless stuff was worked upon .. allwinner/rockchip are now in quite good shape

10:00 <wens> chewitt: funny you should say that

10:00 <warpme_> chewitt: „we already have it half-running” - do you mean v4l2 m2m in mainline in a state where mainline ffmpeg can exploit this?

10:00 <chewitt> and now it's time to apply some of the lessons learned back to the stateful side

10:00 <wens> chewitt: see https://github.com/raspberrypi/linux/pull/3097

10:01 <chewitt> 6by9 (aka Dave) is the main dev for V4L2 on the RPiF side

10:01 <chewitt> long-story short.. Kodi sells lots of pi boards and Kodi will not support GBM/MMAL in the next major release

10:02 <chewitt> the PR to remove MMAL is submitted

10:02 <chewitt> so at some point soon, they need to switch focus

10:02 <wens> what backend does Kodi use? ffmpeg? gstreamer? or their own?

10:02 <chewitt> ffmpeg

10:03 <wens> ok. IIRC that had a few issues with v4l2 as mentioned in the last reply in the PR given above

10:06 <warpme_> wens: Your tests were with https://github.com/raspberrypi/linux/pull/3097#issuecomment-517378616 ? If so - on what kernel?

10:08 <wens> warpme_: kernel built from that pull request

10:09 <wens> rpi doesn't have v4l2 codec upstreamed yet

10:09 <wens> as for meson, I haven't gotten around to it yet. been fighting mali / armsoc last week (again)

10:13 <warpme_> wens: „rpi doesn't have v4l2 codec upstreamed yet” - and probably will not have soon :-(

10:15 <wens> we'll see. It's a valid platform for user applications using v4l2 stateful codecs nonetheless

10:16 <warpme_> wens: exactly! By this I’m so surpriced by their answer: „Sorry, upstreaming stuff is not a priority.”

10:18 <wens> warpme_: their first priority is producing a usable software stack

10:21 <wens> you could say they painted themselves into a corner by diverging from upstream from the beginning

10:21 <wens> but AFAIK most embedded platforms start off that way, and then play catch up

10:37 <warpme_> wens: „painted themselves into a corner” - fully agree. Whats surprises me is initial decission about diverging from upstream. iirc decision to have different windowing internal structures in their gles (when compared with mesa) forced qt guys to develop dedicted rpi platform driver. For me it was a bit strange: arbitral decission at design stage (data struct. def) resulting in signifficant sw. downstream consequences…

10:39 <wens> warpme_: are you referring to the old GL driver?

10:40 <warpme_> wens: i think yes. I was meaning rpi gles blobs required to get qt subsystem working.

10:40 <warpme_> qt-> qt gl subsystem

10:41 <wens> weren't those provided by Broadcom. I doubt they (rpi) had a say in it.

10:41 <wens> though it does suprise me. isn't GL/GLES/EGL supposed to be standardized? or are these "extensions"?

10:42 <wens> I don't have enought background knowledge on OpenGL to understand it

10:43 <warpme_> indeed. it was by broadcom - so indeed maybe it was part of solutiuon provided by broadcom to rpi (i mean vc4 hw + software backend like gles blobs)

10:49 <warpme_> what was really my surprice that rpi vc4 blobs are called GLES (so should be standarized to khronos api defs) - but in reality it turns that it was gles api with some different internal structures. different in a way that api consumer (qt) was foreced to write dedicated interface to exploit them. For me it smells like support of bussines model where planned incompability is way for lock-in

10:49 <wens> :/

11:24 <chewitt> I was on a long conference call :)

11:24 <chewitt> RPiF are very aware that their approach c.2012 with the original pi wasn't perfect and they've ended up hoarding way too much code in their downstream repo

11:26 <chewitt> RPi4 bring-up has involved many more people than earlier generations, and deliberately people with an eye on upstreaming

11:26 <chewitt> fortunately their ecosystem of friendly developers is somewhat larger and more experienced than it was before :)

11:27 <chewitt> the need to ship a 'working' product will still/always trump being perfect

11:28 <chewitt> but the intent is there is upstream more, earlier in the cycle, and more frequently than before

11:28 <chewitt> the link between doing it and long term technical debt is very well understood

19:12 <xdarklight> narmstrong: I didn't get to reviewing https://patchwork.kernel.org/patch/11067319/ last weekend. it's a pretty big change and I didn't have enough consecutive time to review it yet. if you're happy to provide fixes on top of that patch if I (or someone else) find an issue then feel free to apply it now