<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
grohne: <u>sailus</u>: thinking more about V4L2_CID_STREAMING_TRIGGER_EXTERNAL, how bad would it be to allow a s_frame_interval with a zero denominator?
pinchartl: <u>grohne</u>: the issue with s_frame_interval is that it's an ill-defined API
<br> most sensors don't have a concept of frame interval
<br> they have a pixel array sampling clock rate, and vertical and horizontal blanking
<br> which all together result in a given frame rate
<br> so there are multiple ways to achieve a given frame rate
<br> the use of that API is thus discouraged, in favour of exposing the individual parameters explicitly, except when the sensor exposes a frame rate natively
grohne: ok
pinchartl: (which is the case of some sensors containing an ISP, they expose the frame rate through a register and offer no way to control the clock rate and blankings individually)
<br> and I expect external triggers to be mostly used with raw sensors
grohne: can you tell me what I was looking for instead? is that some CID?
<br> V4L2_CID_VBLANK maybe?
pinchartl: V4L2_CID_HBLANK and V4L2_CID_VBLANK
<br> and possibly V4L2_CID_LINK_FREQ if the driver supports changing the frequency
grohne: looking into them. thanks
<br> so when targetting a particular frame rate, a user is supposed to retrieve the V4L2_CID_PIXEL_RATE, lookup the requested image dimensions w * h and determine values vblank, hblank within their respetive bounds such that (w + hblank) * (h + vblank) / pixel_rate becomes the desired frame interval?
<br> is there any easier way to do this on the user side?
pinchartl: that's correct
<br> someone has to perform that calculation, and having it on the driver side would effectively remove flexibility from applications that need fine-grained control of the sensor
<br> that's why it's not considered to be the driver's responsibility
grohne: it kinda feels obvious in retrospect, but it wasn't. thank you.
<br> is there some way to initiate a s_stream call from userspace on a subdev?
pinchartl: no, that's always done through a video node
grohne: hmm. can I do one without a whole vb2?
pinchartl: do you mean without actually capturing to memory ?
grohne: yes
<br> err without capturing memory
pinchartl: in theory yes. what kind of hardware do you have, where do the frames produced by the camera sensor go to ?
grohne: it's a custom board. the camer sensor feeds into another hardware before the data gets into the cpu
pinchartl: shouldn't you model the whole pipeline with V4L2 subdevs, until the DMA engine that captures frames to memory, which should then be modelled as a video node, using vb2 ?
grohne: in theory, yes. that's a huge task however. so the idea was to work on the camera sensor and bolt the rest together
<br> I actually guess that the dma engine has a mainline driver, but switching over to it is not exactly trivial
<br> I've been working on getting this driver published for five years now.
pinchartl: it should be possible to hack something in the meantime, with a video node that doesn't actually perform capture
grohne: if you want the driver before the hardware is obsolete, I better hurry up :)
<br> I actually do have a hacked up bolt-things-together-driver. it does the v4l2_async_notifier stuff to get the subdevs into /dev
<br> does that mean I need a struct video_device?
pinchartl: yes
<br> but you can implement the bare minimum of the ioctls
<br> probably even just VIDIOC_S_STREAM
grohne: good that's up next then. thank you again
<br> so I'll actually be able to test s_stream
ezequielg: <u>pinchartl</u>: sailus: we never maanaged to merge the pixfmt to string helper?
<br> I can't find it.
<br> I thought it was here already.
pinchartl: <u>ezequielg</u>: not sure, I haven't followed up
ezequielg: :'(
<br> here it is https://lore.kernel.org/linux-media/20190916115207.GO843@valkosipuli.retiisi.org.uk/t/#m1dda89afb049bad0065e7be9dd3242af6e2165af
<br> still stalled?
<br> <u>sailus</u>: need help with those, i might be able to squeeze them if it's not a lot of work.
sailus: <u>ezequielg</u>: Uh-oh.
ezequielg: did I open pandora's box?
sailus: There were patches, but I don't quite remember where it ended up to.
<br> Let me find them.
<br> It seems to have stalled in my inbox, yes.
<br> Sorry about that.
<br> Here:
<br> https://lore.kernel.org/linux-media/20200427145303.29943-1-sakari.ailus@linux.intel.com/
<br> I think it actually should be close to merging.
<br> Lots of small things to fix still. No wonder that something else took over this in priority. :-P
formruga: Hi. I would like to ask how to check if v4l2 m2m kernel driver is compilant with specification. I'm focused on "dynamic resolution change" as stated in https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html#dynamic-resolution-change.
<br> I would like to check if decoder is capable to play crowd_run_1080X512_fr30_bd8_frm_resize_l3.webm stream playback from VP9 test suite. This stream uses frame resize feature, which changes resolution of decoded frames twice a second (https://www.webmproject.org/vp9/levels/). I try to check the stream on Odroid N2 with Armbian Buster with 5.8.16 mainline kernel.
<br> I am trying to play with V4L2 GStreamer element and some abandoned patches. I see that the code is able to subscribe proper event and detect source resolution change. I also see expected "last buffer"/EPIPE behaviour, but I have a problem with streaming resuming. I think that maybe I should look into v4l2-compliance, but it seems that I can't use it.
<br> or maybe I don't know how to use it
<br> BTW. I tried to search logs of this channels on https://linuxtv.org/irc/irclogger_log_search/v4l?search=VP9&action=search&error=0, but I got the error "*** ERROR: agrep not found!***"
ezequielg: <u>sailus</u>: ah, right. Last time I looked I wasn't a fan of that solution, but I'm probably wrong since it's the one that gained more traction.
sailus: <u>ezequielg</u>: Not my first choice either, no, but it seems people like it.
<br> And having a way to do that is really nice.
<br> Although I have to admit that this way the end result can be move verbose and flexible than the one based on format specifier macros.
***: kaairagupta has quit IRC (*.net *.split)
<br> kbingham[m] has quit IRC (*.net *.split)
<br> epaul1 has quit IRC (*.net *.split)
<br> ric96 has quit IRC (*.net *.split)
<br> koike1 is now known as koike
ezequielg: <u>sailus</u>: yes, I guess something is better than nothing and each driver does its own thing. the v3 is from April, do you plan to revive it ? :-)
sailus: <u>ezequielg</u>: I'm a little busy right now but I factored in the comments I got, need to test the end result still.
<br> I pushed it to fourcc branc in my linuxtv.org tree if you want to play with it.
<br> There are no guarantees.
***: fling has quit IRC (Ping timeout: 272 seconds)