Is there anyone here who had success with atomisp? It looks like Mauro is too busy.
Sorry for bumping this topic.
hi all... is there a general abstraction of image signal processors (such as rkisp1, ipu3, ...) or do they expose different apis to user space?
mriesch, They use the api's avaialble in v4l, but they are different between them. For instance they have their own specific controls and buffers which control the parameters.
mriesch, The aim of libcamera will be to abstract these so that applications don't have to know or worry about which platform is being used directly.
kbingham: so a driver for a new isp could define its own controls and a new pipeline handler in libcamera would abstract it?
mriesch, Yes
mriesch, Which platform are you working towards supporting ?
kbingham: i am currently evaluating the rkisp2.1 in the rk3568
so i thought i may take the v4l2 controls as starting point when digging through the sdk code
mriesch, I guess that all depends on how they've handled the BSP/SDK ... is that something that's been made publicly available already?
kbingham: i am afraid this is not and in near future will not be public
there seems to be different versions of the rkisp1 support and extensions for 2.x... it's quite a mess :-/
hverkuil: Hi, well I had a go backporting your ctrl code but something doesn't like me. I end up with a kernel panic on boot in ext4_htree_store_dirent so I'm guessing that something has stomped on memory
I think I have to leave it there for now - I don't really have time to try harder just at the moment
I'm a bit surprised as the backport wasn't too horrid - mostly just picking up your new code and fixing the few conflicts where we had local changes
mriesch: hey there -- we are working on rk3566 over here. It seems the ISP is completely new, so it seems a new driver is needed, not based on rkisp1.
mriesch: might be good to note that rkisp isn't RK
* rkisp1
jc44: I've started testing the dynamic array control code and found a few bugs already (not surprisingly). So wait a bit with testing.
hi ezequielg the two chips (rk3566 and rk3568) have the same isp, right?
and you reckon there will be a rkisp2 ?
mriesch: i have no idea what will be the driver name,
it is not currently in our roadmap to write an ISP driver for that.
hi ndufresne: you mean the rkisp1 differs from the version provided by rockchip?
ezequielg well the name is not too relevant, but it would have to be a separate one? or is there a chance to reuse bits of the rkisp1 driver?
from what I have seen, no.
it is a new driver, new hw.
ok
ezequielg but if a mainline driver is not in your roadmap, will it be in any roadmap? :-)
mriesch: someone found recently that rkisp1 is not a rockchip design, the design was found on another SoC (at bit like stmmac, which is designware)
rkisp2 might actually be a rockchip design
we notice this transition with CODEC too, they use to have Hantro codec, and then moved one with their own
hverkuil: great news about ctrl arrays. A first user could be h264 cedrus, right? Cc jernej
ezequielg: rkvdec is also an option
for cedrus that would be an optimization
Rkvdec hevc you mean?
so perhaps not urgent considering most streams have 1 slice
ezequielg: correct
ndufresne that's interesting. i was aware of the fact that they switched to own encoders, but didn't know that the isp is that different
speaking of which, do you know whether the new codecs in the rk356x are stateful or stateless?
(the h.264/hevc codecs)
ezequielg: jc44: fixed my dyn array branch https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=ctrl-refactor
Dynamic array support is now validated for use outside of requests. Tomorrow I'll add compliance tests for when it is used in requests.
Hope to be able to post a series perhaps as soon as tomorrow.
ezequielg: I would rather use it on HEVC entry points array control for Cedrus first
mriesch: afaik, they are stateless.
jernej: great :-)
jernej: sounds like hevc uapi will be going stable.
speaking of which, I think Benjamin has some scaling list support patches.
regarding that, what's the plan?
I plan to send one small UAPI fixup once Benjamin's series is applied
I don't think we have a plan, but we can agree on one.
jernej: why wait? send it now?
ezequilg: i was told that stateless codecs are not supported by gstreamer. is this correct?
mriesch: unsure who told yo that :)
ezequielg: on second thought, i think it was more a question than a statement back then
Gstreamer supports stateless: h264, mpeg-2, vp8 and soon vp9 and hevc.
ezequelg: given that it's just one additional flag, I might just as well do that
we are all working hard to get proper codec uapis, so userspace can rely on that.
but what about scaling matrix control? Does Benjamin plan to do that?
jernej: you can submit the patch now, and ask hverkuil to merge it before Benjamin's.. or you can also submit now, and mention it depends on Benjamin's, so has to be merged after that.
ezequielg:  i have heard of the recent vp9 stateless support discussion. i might have drawn some wrong conclusions by myself as well ;-)
jernej: yes, scaling list control is planned. We dropped it because I didn't want the series to be too big, and miss the window. Turns out it was too big anyway, and we missed it.
A healthy mindset is aiming at getting things in, and avoid scope creeping.
ezequielg: but nice to here that there is support
hear
jernej: I recall you were annoyed but that, but I can assure you, stable uapis is my #1 priority.
because users.
you may have seen the VP9 RFC was straight to proper API, skipping staging.
yeah, I noticed that
and I wonder - are you sure enough about controls to do that?
yes.
jernej: you do realize no other subsytem has unstable uAPIs.
(or almost no other)
we are not special :)
well, hopefully HEVC will be close to public next cycle
The first hantro/rk3288 h264 driver is from around 2014. I honestly think we should aim at shorter development times, if we want to be taken seriously by users (ffmpeg, gstreamer) and vendors (Google, Verisilicon, Rockchip, etc). 7 years is too much, isn't it?
I concur, but I have no power to speed up things - I work on these things in spare time as a hobby