[08:46] *** neg has quit IRC (Read error: Connection reset by peer)
[09:07] <syoung> mchehab: hverkuil: do you have the si2168 datasheet? Thanks
[09:09] <hverkuil> syoung: no, sorry.
[10:29] *** prabhakarlad has left 
[10:39] *** jherland has quit IRC (Ping timeout: 276 seconds)
[11:58] *** jusual has left 
[15:02] *** cybrNaut has quit IRC (Ping timeout: 250 seconds)
[15:10] *** benjiG has left 
[15:27] <ndufresne> hverkuil, we are trying to understand what was the rational for some code, which was done after some discussion with you apparently, https://git.linuxtv.org/media_tree.git/tree/drivers/staging/media/rockchip/vpu/rockchip_vpu_v4l2.c#n226
[15:28] <ndufresne> Basically, "ignoring" capture queue would prevent userspace from allocation larger capture buffers
[15:29] <ndufresne> Why should the kernel prevent from doing that ? Userspace knows better which size the buffers should be, maybe we have an anaptive stream, between 480p and 1080p, and want to allocate to 1080p ?
[16:00] <hverkuil> ndufresne: the OUTPUT format is effectively the source of the CAPTURE format. It's like capturing from a sensor: unless the hardware can scale or compose, you are stuck to the sensor resolution. If you want larger buffers, then use VIDIOC_CREATEBUFS.
[16:01] <ndufresne> hverkuil, that only means you need a minimum buffer size
[16:01] <hverkuil> Changes to this would require a larger overhaul of how formats are used. That's something for the future (some preliminary work has already been done).
[16:02] <ndufresne> why, it's just a random limitation added in software ?
[16:02] <ndufresne> if you patch all drivers to enforce something, it will be much hard later to fix it, so why do we do that in the first place ?
[16:03] <ndufresne> also, why do we need to set the width/output on the output side of a stateless decoder ?
[16:04] <ndufresne> isn't the information in the PPS instead ?
[16:04] <ndufresne> (expressed in a codec specific way)
[16:05] <ndufresne> anyway, all this seems like arbitrary restrictions to me, I just can't make any sense of it atm
[16:05] <ndufresne> it's like if we like to enforce how the driver will be used, instead of actually exposing the HW capabilities leaving userspace code to some creativity ...
[16:06] <hverkuil> The spec defines that sizeimage is set by the driver. We now allow it to be set by userspace as well for compressed formats, but changing the behavior for raw formats might very well have unforeseen side effects since applications might have random values filled in for sizeimage. So that's not going to change with the existing API.
[16:07] <ndufresne> this has nothing to do about it
[16:07] <ndufresne> the size image on capture is calculated from the width high of the same queue
[16:07] <ndufresne> the spec has no notion of internal queue relationship
[16:08] <hverkuil> which spec? The stateless decoder spec?
[16:08] <ndufresne> I thought you refer to the main spec
[16:09] <ndufresne> all this makes me feels we are running toward a wall
[16:09] <hverkuil> The interaction between output and capture formats is part of the decoder spec (or really all mem2mem devices), since for those the two queues do have a relationship.
[16:10] <ndufresne> I think that's where we are wrong, we cannot define this relationship
[16:10] <hverkuil> What that relationship is can be changed: the stateless decoder spec is still RFC.
[16:10] <ndufresne> it's not generic at all
[16:11] <ndufresne> Just an example, you said "unless the hardware can scale or compose"
[16:11] <hverkuil> Saying that there is no relationship is also an option. I vaguely remember a past discussion of keeping the capture and output formats completely separate.
[16:11] <ndufresne> well, turns out that yes, all Hantro base decoder comes with an IPP that has limited scaling and colorspace conversion support
[16:12] <ndufresne> we don't enable it, because we need to get something working first, but I believe pH5 will be interested
[16:13] <ndufresne> hverkuil, I'm wondering if we didn't make a mistake with reusing the format state to transmit the new format on format changes ...
[16:14] <ndufresne> basically, you want to know what the new solution will be, but could avoid re-allocation if you have enough buffers already, and that these buffers are large enough
[16:14] <ndufresne> or maybe it's just this issue that allocation / queue / format is too coupled together ...
[16:15] <hverkuil> The missing piece in all this is that there is no clean way of asking the driver what the size of the buffer should be for a certain resolution.
[16:16] <hverkuil> That's an API problem that's been known for a long time.
[16:17] <hverkuil> Everything else is fine (although the stateless decoder spec probably needs a bit more work).
[16:20] <hverkuil> Sorry, dinner time. It's easier for me (given the timezone differences) if you post your concerns to the mailinglist.
[16:58] <mchehab> svarbanov: there are several patches for venus at patchwork. Please don't let to send them to me late at -rc cycle
[18:10] <tonyk> hverkuil: is there any particular reason to vivid/Makefile uses vivid-objs instead of vivid-y? I saw that others media driver does this as well. When reading Docs/kbuild/makefiles.txt, it's looks like the most intuitive approach to use vivid-y
[19:34] <hverkuil> tonyk: it's all copy-and-paste :-)