[01:51] *** jernej has quit IRC (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
[13:28] <ndufresne> paulk-leonov:  mripard: I'm trying to debug some remaining glitches with gst native code, and trying to see if I'm on the wrong path
[13:29] <ndufresne> Basically, I see that GStreamer does not produce implicit weight prediction (weighted_bipred_idc == 2), but at the same time, if I read cedrus code well, it does not seem to program the weight tables unless idc == 1
[13:29] <ndufresne> So I'm starting to think while this is a gst/ffmpeg delta, it's unlikely the release for the glitch I get ?
[14:44] *** Whoopie has quit IRC (Ping timeout: 272 seconds)
[14:54] <dafna2> pinchartl: ping
[14:57] <pinchartl> dafna2: pong
[15:03] <dafna2> regarding this patch https://patchwork.kernel.org/patch/11458655/
[15:04] <pinchartl> yes ?
[15:04] <dafna2> this patch or another solution is needed for the rkisp1 to move from staging
[15:05] <pinchartl> b-rad reported an issue yesterday that would benefit from describing with a bit more detail what a pad can carry
[15:05] <dafna2> So it seems that you suggested this solution so it can later be expanded to other flags
[15:05] <pinchartl> it was about analog video in his case
[15:06] <pinchartl> my point during review was that we need to consider the wider problem scope
[15:07] <b-rad> this is about both analog and digital
[15:07] <dafna2> to me it seem simpler to introduce a new media bus format MEDIA_BUS_FMT_FIXED_METADATA
[15:08] <b-rad> the em28xx devices have no analog functionality and still trigger the warning
[15:08] <b-rad> the cx231xx devices do have analog
[15:09] <dafna2> but, if you think the solution with the flag is a good idea, maybe you can add reviewed-by?
[15:10] <pinchartl> dafna2: what is the issue you're trying to solve, why does the rkisp1 driver need this ?
[15:10] <dafna2> currently the compliance testes fail if the width/height are 0
[15:11] <dafna2> so there the driver set them to some non 0 value just to pass the test, but it should actually be 0
[15:12] <pinchartl> width and height in which structures ?
[15:12] <dafna2> the stats and params
[15:13] <dafna2> oh, no, the pads in the isp block that connects to the stats and params
[15:13] <dafna2> this is the rksip1 fix https://patchwork.kernel.org/patch/11458657/
[15:13] <dafna2> using the flag MEDIA_PAD_FL_METADATA
[15:15] <pinchartl> sorry, which ioctl checks fail from v4l2-compliance ?
[15:15] <pinchartl> it's been a long time, I've lost all context
[15:16] <dafna2> the g_fmt for subdevice
[15:16] <dafna2> this is the compliance patch https://patchwork.kernel.org/patch/11458711/
[15:19] <pinchartl> in your specific case a pad flag would work, but as Sakari pointed out, we could have pads that can carry different types of data
[15:19] <pinchartl> on the other hand
[15:19] <pinchartl> in those cases
[15:20] <pinchartl> I expect the width and height to be non-zero for metadata
[15:20] <pinchartl> as metadata will be carried the same way as image data
[15:20] <pinchartl> sailus: ping
[15:24] <dafna2> so this argument supports  the solution of adding MEDIA_BUS_FMT_FIXED_METADATA, adding flags on the pad for the data format can be added anyway
[15:26] <pinchartl> I'd name it MEDIA_BUS_FMT_METADATA_FIXED and add a separate category for metadata formats
[15:26] <pinchartl> thinking about CSI-2, we may need MEDIA_BUS_FMT_METADATA_RAW8, MEDIA_BUS_FMT_METADATA_RAW10, ...
[15:26] <pinchartl> but I'd like to know Sakari's opinion on this
[15:47] <dafna2> the format MEDIA_BUS_FMT_FIXED is used for a formats that are specific for the driver?
[15:56] <pinchartl> dafna2: it's a catch-all that says the format doesn't matter for userspace
[16:00] <dafna2> oh, ok
[16:03] <dafna2> this is why the documentation does not say much "MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where the data format is fixed"
[16:05] <pinchartl> when the format is very device-specific, is fixed, and doesn't matter for userspace, we considered it to be overkill to define device-specific media bus codes
[16:06] <pinchartl> in your case knowing that metadata is transferred doesn't really matter for userspace, except for the compliance tool
[16:06] <pinchartl> I'm tempted to say it's an issue of v4l2-compliance
[16:06] <pinchartl> adding APIs for the only reason that we need to verify them, without any other user, is borderline
[16:11] <sailus> pinchartl: Sorry, I need to go now but I'll be back later on.
[16:12] <pinchartl> sailus: no worries
[16:15] <dafna2> I can add a patch to the tests that don't check the dimensions for MEDIA_BUS_FMT_FIXED but then it means it is official ok to have 0 dimension for this format
[18:29] <b-rad> got it
[18:30] <b-rad> bug is in dvbdev.c, overlooked until everything else possible looked at
[18:30] <b-rad> it tries to connect tuner sink to demod sink, plain as that
[18:31] <b-rad> i'll mail in patch, i think it's correct, the mc topology looks all good now
[18:59] <pinchartl> b-rad: nice
[20:27] <sailus> pinchartl, dafna2: Hello!
[20:28] <sailus> Sub-device formats are different from V4L2 formats as they do not have a size.
[20:29] <sailus> Therefore width and height are the only fields telling size information.
[20:29] <sailus> So they are required.
[20:32] <pinchartl> sailus: even for metadata ?
[20:32] <sailus> Yes.
[20:32] <pinchartl> think about the IMGU input parameters for instance
[20:32] <pinchartl> what size would you use there ?
[20:32] <sailus> That's a bit special.
[20:32] <sailus> The same driver is handling both sides of the link.
[20:33] <pinchartl> that's the problem Dafna is hitting with rkisp1
[20:33] <pinchartl> input parameters, and output stats
[20:33] <sailus> A moment.
[20:33] <pinchartl> the media bus code is currently MEDIA_BUS_FMT_FIXED
[20:37] <sailus> Back.
[20:37] <sailus> What would be the benefit of having another one for metadata?
[20:37] <sailus> The FIXED code is there to tell, well, that the format is unchangeable and does not really matter...
[20:38] <pinchartl> v4l2-compliance enforces width != 0 && height != 0 even for MEDIA_BUS_FMT_FIXED
[20:38] <sailus> Ah.
[20:38] <pinchartl> this could be fixed in v4l2-compliance
[20:39] <pinchartl> but could there be cases where width and height matter with MEDIA_BUS_FMT_FIXED ?
[20:39] <sailus> I guess the width and height is indeed zero in cases where the result is pre-defined.
[20:39] <sailus> I think it's unlikely.
[20:39] <pinchartl> could the media bus code be MEDIA_BUS_FMT_FIXED for image data where the width and height could still be configurable ?
[20:39] <sailus> Oh, hmm.
[20:39] <sailus> This can be image data.
[20:39] <sailus> So it does matter.
[20:40] <pinchartl> if it's image data with a fixed width and height, and where the width and height is irrelevant for userspace, width and height could be reported as 0
[20:40] <pinchartl> but I'm not sure we can guarantee that
[20:40] <sailus> It could be used between two sub-devices that are implemented by the same driver.
[20:40] <pinchartl> I haven't reviewed existing usage, but I wouldn't be surprised if we used MEDIA_BUS_FMT_FIXED on links where the width and height are configurable, or at least need to be propagated between subdevs by userspace
[20:40] <sailus> And width and height may well still matter.
[20:41] <pinchartl> (or is used by userspace to perform other computations)
[20:41] <sailus> Mostly when it's image data then the actual format is used.
[20:41] <sailus> And not the "fixed" mbus code.
[20:41] <pinchartl> hence the proposal to create a MEDIA_BUS_FMT_METADATA_FIXED for this case, with width and height explicitly hardcoded to 0
[20:41] <sailus> I think it'd be fair to allow width and height to be zero when the code is FIXED.
[20:42] <pinchartl> allowing width and height to be zero or non-zero with MEDIA_BUS_FMT_FIXED means that we won't be able to implement a compliance test that verifies that drivers report a non-zero value when the value matters
[20:42] <pinchartl> maybe that's fine, I can't tell
[20:45] <sailus> There never was a requirement for them to be non-zero.
[20:45] <sailus> Adding that now is bound to be problematic.
[20:50] <pinchartl> sailus: it's a check that exists today in v4l2-compliance
[20:50] <pinchartl> dafna2: what do you think ?
[20:50] <pinchartl> hverkuil: same question
[20:51] <sailus> I think width and height should be allowed to be zero if the format is FIXED.
[20:53] <pinchartl> I'm ok with that
[21:13] <ndufresne> mripard: paulk-leonov: Finally got it working, I had a stupid bug, but it made me find some other bugs (mostly minor)
[21:39] <pinchartl> mchehab: the jenkins build of libcamera is failing. I've replied with information regarding how to fix it. have you received my e-mail ?
[21:41] <pinchartl> (why does git want to download 3GB of data when I pull from the linuxtv media_tree ? :-o)
[23:35] *** harrow has quit IRC (Quit: Leaving)