<!-- 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>
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
<br> 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
<br> So I'm starting to think while this is a gst/ffmpeg delta, it's unlikely the release for the glitch I get ?
***: Whoopie has quit IRC (Ping timeout: 272 seconds)
dafna2: <u>pinchartl</u>: ping
pinchartl: <u>dafna2</u>: pong
dafna2: regarding this patch https://patchwork.kernel.org/patch/11458655/
pinchartl: yes ?
dafna2: this patch or another solution is needed for the rkisp1 to move from staging
pinchartl: b-rad reported an issue yesterday that would benefit from describing with a bit more detail what a pad can carry
dafna2: So it seems that you suggested this solution so it can later be expanded to other flags
pinchartl: it was about analog video in his case
<br> my point during review was that we need to consider the wider problem scope
b-rad: this is about both analog and digital
dafna2: to me it seem simpler to introduce a new media bus format MEDIA_BUS_FMT_FIXED_METADATA
b-rad: the em28xx devices have no analog functionality and still trigger the warning
<br> the cx231xx devices do have analog
dafna2: but, if you think the solution with the flag is a good idea, maybe you can add reviewed-by?
pinchartl: <u>dafna2</u>: what is the issue you're trying to solve, why does the rkisp1 driver need this ?
dafna2: currently the compliance testes fail if the width/height are 0
<br> so there the driver set them to some non 0 value just to pass the test, but it should actually be 0
pinchartl: width and height in which structures ?
dafna2: the stats and params
<br> oh, no, the pads in the isp block that connects to the stats and params
<br> this is the rksip1 fix https://patchwork.kernel.org/patch/11458657/
<br> using the flag MEDIA_PAD_FL_METADATA
pinchartl: sorry, which ioctl checks fail from v4l2-compliance ?
<br> it's been a long time, I've lost all context
dafna2: the g_fmt for subdevice
<br> this is the compliance patch https://patchwork.kernel.org/patch/11458711/
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
<br> on the other hand
<br> in those cases
<br> I expect the width and height to be non-zero for metadata
<br> as metadata will be carried the same way as image data
<br> <u>sailus</u>: ping
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
pinchartl: I'd name it MEDIA_BUS_FMT_METADATA_FIXED and add a separate category for metadata formats
<br> thinking about CSI-2, we may need MEDIA_BUS_FMT_METADATA_RAW8, MEDIA_BUS_FMT_METADATA_RAW10, ...
<br> but I'd like to know Sakari's opinion on this
dafna2: the format MEDIA_BUS_FMT_FIXED is used for a formats that are specific for the driver?
pinchartl: <u>dafna2</u>: it's a catch-all that says the format doesn't matter for userspace
dafna2: oh, ok
<br> 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"
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
<br> in your case knowing that metadata is transferred doesn't really matter for userspace, except for the compliance tool
<br> I'm tempted to say it's an issue of v4l2-compliance
<br> adding APIs for the only reason that we need to verify them, without any other user, is borderline
sailus: <u>pinchartl</u>: Sorry, I need to go now but I'll be back later on.
pinchartl: <u>sailus</u>: no worries
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
b-rad: got it
<br> bug is in dvbdev.c, overlooked until everything else possible looked at
<br> it tries to connect tuner sink to demod sink, plain as that
<br> i'll mail in patch, i think it's correct, the mc topology looks all good now
pinchartl: b-rad: nice
sailus: pinchartl, dafna2: Hello!
<br> Sub-device formats are different from V4L2 formats as they do not have a size.
<br> Therefore width and height are the only fields telling size information.
<br> So they are required.
pinchartl: <u>sailus</u>: even for metadata ?
sailus: Yes.
pinchartl: think about the IMGU input parameters for instance
<br> what size would you use there ?
sailus: That's a bit special.
<br> The same driver is handling both sides of the link.
pinchartl: that's the problem Dafna is hitting with rkisp1
<br> input parameters, and output stats
sailus: A moment.
pinchartl: the media bus code is currently MEDIA_BUS_FMT_FIXED
sailus: Back.
<br> What would be the benefit of having another one for metadata?
<br> The FIXED code is there to tell, well, that the format is unchangeable and does not really matter...
pinchartl: v4l2-compliance enforces width != 0 && height != 0 even for MEDIA_BUS_FMT_FIXED
sailus: Ah.
pinchartl: this could be fixed in v4l2-compliance
<br> but could there be cases where width and height matter with MEDIA_BUS_FMT_FIXED ?
sailus: I guess the width and height is indeed zero in cases where the result is pre-defined.
<br> I think it's unlikely.
pinchartl: could the media bus code be MEDIA_BUS_FMT_FIXED for image data where the width and height could still be configurable ?
sailus: Oh, hmm.
<br> This can be image data.
<br> So it does matter.
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
<br> but I'm not sure we can guarantee that
sailus: It could be used between two sub-devices that are implemented by the same driver.
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
sailus: And width and height may well still matter.
pinchartl: (or is used by userspace to perform other computations)
sailus: Mostly when it's image data then the actual format is used.
<br> And not the "fixed" mbus code.
pinchartl: hence the proposal to create a MEDIA_BUS_FMT_METADATA_FIXED for this case, with width and height explicitly hardcoded to 0
sailus: I think it'd be fair to allow width and height to be zero when the code is FIXED.
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
<br> maybe that's fine, I can't tell
sailus: There never was a requirement for them to be non-zero.
<br> Adding that now is bound to be problematic.
pinchartl: <u>sailus</u>: it's a check that exists today in v4l2-compliance
<br> <u>dafna2</u>: what do you think ?
<br> <u>hverkuil</u>: same question
sailus: I think width and height should be allowed to be zero if the format is FIXED.
pinchartl: I'm ok with that
ndufresne: <u>mripard</u>: paulk-leonov: Finally got it working, I had a stupid bug, but it made me find some other bugs (mostly minor)
pinchartl: <u>mchehab</u>: the jenkins build of libcamera is failing. I've replied with information regarding how to fix it. have you received my e-mail ?
<br> (why does git want to download 3GB of data when I pull from the linuxtv media_tree ? :-o)
***: harrow has quit IRC (Quit: Leaving)