[04:31] *** larsc has quit IRC (Quit: Lost terminal)
[04:33] *** r0kc4t_ has quit IRC (Remote host closed the connection)
[07:36] <tfiga> mjourdan: do you have an IOMMU there?
[07:37] <tfiga> or a register that tells the hardware about the buffer size?
[07:38] <tfiga> it feels a bit scary to give the userspace the ability to ask the kernel to overwrite some random part of system memory (by setting to small CAPTURE buffer size)
[08:42] <mjourdan> tfiga: I was wrong about this part.. I setup a buffer list in registers that holds the phy addrs as well as the width/height etc., and the decoder will only write what can fit the resolution provided, discarding the rest. Still finding out things about this IP.. So I don't even need the hack which would have been to force max-size capture buffers driver-side.
[08:42] <mjourdan> tfiga: I'm curious about your answer regarding resolution change and full reset. Isn't the procedure to reset only the capture queue and then keep going ?
[08:42] <tfiga> mjourdan: that sounds much more reasonable then
[08:42] <tfiga> mjourdan: I'm talking about operations on hardware level
[08:43] <tfiga> the userspace will reset the CAPTURE queue, but your driver can reset the decode state in the hardware and requeue any OUTPUT buffers starting from the one that triggered the change
[08:44] <tfiga> I mean, requeue to hardware
[08:50] <mjourdan> tfiga: Oh, I see what you mean now. Yeah, I think this is feasible.
[09:16] <mjourdan> tfiga: I'm just not a big fan of holding on to the OUTPUT buffers, doesn't it mean userspace needs to allocate as many as the CAPTURE buffers (maybe even more ?) to avoid any stall ?
[09:29] <tfiga> mjourdan: what kind of stalls would happen in that case?
[09:30] <tfiga> you need to hold OUTPUT buffers until they are decoded anyway
[09:30] <mjourdan> For instance: OUTPUT queue is full but a staging frame is still referenced, so the firmware doesn't interrupt me until it gets more data. Or a bframe needs more data, etc.
[09:30] <tfiga> if you get a "decode done" for OUTPUT buffer X and the resolution is still the same, you return it
[09:31] <mjourdan> Thing is, I can't get per-output-buffer events. I only get interrupts when frames are decoded and "free to release" basically.
[09:32] <tfiga> in this case you indeed need enough buffers
[09:33] <tfiga> but we don't know how many are needed until we parse the stream...
[09:33] <tfiga> I guess you might need to have a similar design to coda
[09:34] <tfiga> where you maintain an internal ring buffer with the bitstream
[09:34] <tfiga> and only append to it from OUTPUT buffers
[09:35] <tfiga> and then you could just release OUTPUT buffers instantly after copying
[09:36] <mjourdan> That's pretty much already what I have, except it's a fully automated ring buffer.. There's an IP with a DMA that copies over the output buffers, and then does what is needed to interrupt the firmware to tell it "hey, new bitstream packet at offset X in ring buffer"
[09:36] <mjourdan> I wonder if this is something I can drive manually, but that'd be quite the overhaul
[09:46] <tfiga> mjourdan: hmm, wouldn't you then get an interrupt from that DMA that it copied the output buffer?
[09:47] <mjourdan> tfiga: Oh sure, I get that, and this is where I DONE the OUTPUT buffers (currently).
[09:47] <mjourdan> tfiga: But I don't really have the ability to "rewind" or manipulate that ring buffer
[09:47] <tfiga> hmm
[09:48] <tfiga> is there a mode in which you could skip the copy of output buffer and just use it in place? then you would handle the copy yourself
[09:49] <tfiga> if not, in the worst case you would have a double copy, which is ugly, but wouldn't be so terribly bad yet
[09:50] <tfiga> hmm, maybe there is another way around
[09:51] <tfiga> if you could assume that 1 OUTPUT buffer contains the whole frame, then if the frame changes the resolution, AFAIK it would be a keyframe, so the hardware would have to decode it
[09:53] <tfiga> never mind, you would still have to hold onto the OUTPUT buffers
[09:53] <tfiga> I need to think a bit more :)
[09:57] <mjourdan> tfiga: eh, don't worry about it, thanks for the help. The thing is, the firmwares for H264/HEVC/VP9 are kind enough to pause and not decode on resolution change, so I can fully support CH_RESOLUTION for those without too much hassle.
[09:57] <mjourdan> which is why I wanted a flag to just drop support for that event for older codecs
[09:59] <mjourdan> every codec has a distinct firmware with different behaviour than the others, so trying to support everything in a generic way is a nightmare
[10:07] <svarbanov> mjourdan: I'm almost on the same situation with Venus driver, different versions -> different firmware's -> different behaviors. it's always a nightmare when you have firmware :)
[10:18] <mjourdan> svarbanov: Hehe, yep. Now that the request API is there, having a stateless decoder is almost preferable :D .
[10:43] <tfiga> mjourdan: actually, I wonder if dynamic resolution changes in such old formats actually exist in practice
[10:44] <tfiga> I guess a flag doesn't hurt either
[10:52] <sailus> mchehab: Have you had time to check the fwnode patches?
[10:52] <sailus> I'd have sensor drivers coming up that require changes (trivial but still) because of the fwnode changes.
[10:58] <mchehab> will try to look them today
[10:58] <mchehab> sorry for taking so long
[11:02] <sailus> Great!
[11:07] <svarbanov> tfiga: what mean by "such old formats"?
[12:24] <mjourdan> tfiga: yes, I'll go with the flag
[13:29] *** benjiG has left 
[13:40] <ezequielg> hverkuil: ok, i'm here..
[13:45] <hverkuil> ezequielg: let me read your last email on this topic
[13:53] <hverkuil> ezequielg: OK, you have good arguments (esp. w.r.t. the decoder)
[13:54] <hverkuil> Since this is a staging driver I will accept this (when I get a v7 with the checkpatch issues fixed).
[13:54] <hverkuil> But:
[13:56] <hverkuil> before this can move out of staging we will need a userspace component that can do the jpeg handling for the encoder (and later the decoder) so applications do not need to know whether the underlying driver uses JPEG or JPEG_RAW.
[13:57] <hverkuil> I think I would like to set aside some time before the media summit to talk about this.
[13:58] <ezequielg> hverkuil: you want a shim that hides the JPEG_RAW ?
[13:59] <hverkuil> Yes. It's part of a larger solution that we need to handle stateful and stateless codecs. You don't want to have everyone re-invent the parsers for each stateless codec.
[14:00] <hverkuil> We need a library or something in v4l-utils where this is done.
[14:00] <ezequielg> w.r.t to jpeg, we only need to figure out where to put it. the code is trivial.
[14:01] <hverkuil> yes, for jpeg it's easy, but for h264 etc. it is a lot harder, but at the core it is the same problem.
[14:03] <hverkuil> ndufresne: ezequielg: mripard: shall we organize a (informal) meeting for this during the ELCE?
[14:03] <hverkuil> paulk-leonov: are you at the ELCE?
[14:05] <ezequielg> i'd love to. ideally before gstreamer conf, so nicolas can be there.
[14:05] <hverkuil> when is the gstreamer conf?
[14:05] <mripard> hverkuil: we can, I'll be there
[14:05] <mripard> to both the ELC and the media-summit
[14:06] <ezequielg> 25 and 26
[14:06] <hverkuil> OK. The media summit is the 25th, so I wanted to do this before that summit anyway.
[14:07] <hverkuil> Esp. ndufresne's experience is very useful for this.
[14:13] <ezequielg> hverkuil: meanwhile, nothing prevents to push a sample for the JPEG_RAW encoder somewhere, right?
[14:13] <ezequielg> I don't have the JPEG_RAW decoder done, yet, unfortunately.
[14:14] <hverkuil> ezequielg: sorry, I don't understand what you mean
[14:14] <hverkuil> you mean sample output of the encoder?
[14:14] <ezequielg> a small app/lib so users with rockchip boards can test the encoder
[14:15] <hverkuil> Ah. Of course, no problem. But to get it out of staging we need some support in v4l-utils.
[14:22] <ezequielg> i'll add that to the TODO, so it's clear why it's there.
[14:22] <ezequielg> hverkuil: thanks!
[15:08] <paulk-leonov> hverkuil, I didn't make it in the end, sorry
[15:10] <mchehab> just remember that we're already full for the media summit... if a developer is interested on joining it, please ping me, after registering for ELCE
[15:10] <mchehab> via e-mail
[15:11] <mchehab> ndufresne, paulk-leonov ^
[15:11] <mchehab> as otherwise you'll be on a waiting list
[17:51] <neg> hverkuil: ping
[18:52] <hverkuil> neg: pong
[18:56] <neg> hverkuil: commit d26e4941419b05fc ("v4l2-compliance: allow both regular and mplane variants for crop API") in v4l-utils confuses me
[18:58] <neg> hverkuil: are you sure the last line of addtion in that commit 'fail_on_test(doioctl(node, VIDIOC_CROPCAP, &cap));' is correct? It inverts the behavior from before the commit
[19:03] <hverkuil> Yes, it is correct. Both CAPTURE/OUTPUT and CAPTURE/OUTPUT_MPLANE are allowed for cropcap (or any cropping/selection API).
[19:03] <hverkuil> It used to be messy: some drivers accepted one variant and not the other, some accepted both. The API has been relaxed to explicitly accept both.
[19:04] <hverkuil> Which makes sense anyway since single or multiplanar is irrelevant for cropping/composing.
[19:05] <hverkuil> So this test checks that if cropcap(CAPTURE) works, then cropcap(CAPTURE_MPLANE) must also work (and vice versa)
[19:06] <neg> hverkuil: ahh I see but what if my driver don't support MPLANES, in that case is CAPTURE == CAPTURE_MPLANE ?
[19:07] <hverkuil> for cropcap, yes.
[19:07] <neg> hverkuil: with this change rcar-vin now fails the compliance test and I'm not sure how to solve it
[19:08] <hverkuil> rvin_cropcap should accept both V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
[19:09] <neg> hverkuil: OK so for rcar-vin all that really is need is to extend the if () at https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/rcar-vin/rcar-v4l2.c#n413 to also allow V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE ?
[19:09] <hverkuil> yes
[19:10] <hverkuil> What would actually be better is to handle this in v4l2-ioctl.c (mapping MPLANE to the regular type).
[19:10] <hverkuil> I've done that for g/s/try_selection already.
[19:13] <hverkuil> We really need to get rid of the last few vidioc_g/s_crop users.
[19:16] <neg> hverkuil: I see, if you prefere I can try and solve it in v4l2-ioctl.c instead of in the rcar-vin driver. Or do you prefere to work on it?
[19:25] <hverkuil> neg: can you make a patch for the cropcap call in v4l2-ioctl.c? Along the same lines as is done in v4l_g_selection.
[19:25] <hverkuil> I've started looking at removing the last few crop ioctls in the media drivers.
[19:26] <neg> hverkuil: sure, I will finish up my current work and do so later tonight or tomorrow. Thanks for your time
[19:27] <hverkuil> np