| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | TrishoolinKing has left | [09:36] |
| ........ (idle for 36mn) | ||
| hverkuil1 | neg: can you look at this and Ack if you are OK? https://patchwork.linuxtv.org/patch/51432/
neg: and this one https://patchwork.linuxtv.org/patch/51434/ still needs an Ack from Rob. BTW, it's easier to track this is the bindings changes are in a separate patch instead of combined with code changes. | [10:12] |
| neg | hverkuil1: I have checked it and it looks OK, but everytime we extened support for rcar-vin and/or rcar-csi2 there have been a small issue needing to be handled. As Sergei have not tested the patches I'm reluctant to ack them before someone have tested them and I do not have access to the board in question to test myself | [10:17] |
| hverkuil1 | OK. Can you follow-up with Sergei? And please ask him to split up the patches if he posts new version. | [10:20] |
| neg | Will do, thanks for bringing it up | [10:21] |
| ................. (idle for 1h24mn) | ||
| ezequielg | hverkuil1: do you have some time to discuss the JPEG quantization controls? | [11:45] |
| hverkuil1 | ezequielg: in 25 minutes? (still need to read the email thread) | [11:48] |
| ezequielg | i'm here :-) | [11:50] |
| R5UIOP[P9SD1~4\
ZGCKNBL M,, weq@!21qsuuuuuuuuuuuuuuuuuuuuuuuuw :w :w$bbbCHERNAN.w (ouch) : :Q :Q:Q! :q! :q! E G:w sorry about that :Quuuuu:q | [12:01] | |
| hverkuil1 | ezequielg: ping | [12:10] |
| ezequielg | hverkuil1: here | [12:11] |
| hverkuil1 | So I've been reading the JPEG thread. If I understand it correctly, then there are three 'profiles':
- baseline - baseline, but with optional 16 bit quantization support - extended It depends on the HW whether either of the last two are supported. | [12:12] |
| ezequielg | there are just two profiles baselines and extended, but some encoders have produced baselines JPEGs with 16-bit quantization tables. | [12:13] |
| hverkuil1 | the second isn't a real profile, just a 'semi-official optional' extension (as I understand it) | [12:14] |
| ezequielg | apparently it's non standard
encoders apparently abused the spec there | [12:14] |
| hverkuil1 | What can your HW support? | [12:15] |
| ezequielg | baselines, 8-bit coefficients for everything. | [12:15] |
| hverkuil1 | OK.
Then let's keep it simple: just use u8 in the quant controls. If 16 bit support is ever needed, then new u16 variants should be added. I'm unsure if we need a profile control at this stage. Existing jpeg drivers only support baseline, and so I think a profile control is only needed if we get HW that supports the extended profile. I think we should just skip that for now. What do you think? | [12:15] |
| ezequielg | yeah, I agree with having separate controls for 8-bit and 16-bit coefficients.
I don't think we will see hardware that will support the 8-bit data, 16-bit quantization case. i guess in that case, the application will have to upgrade the data to 16-bit. | [12:20] |
| hverkuil1: do you think we need to explicitly advertise the JPEG baseline profile?
even if it's the only one supported | [12:26] | |
| hverkuil1 | None of the other jpeg encoders/decoders do so, they all only support baseline.
I think such a control should only be added if we add a driver that supports both baseline and extended profile. I'm not even sure we should bother retrofitting existing jpeg drivers in that case to support such a control. We can always document that in the absence of that control only the baseline profile is supported. | [12:26] |
| ezequielg | btw, the coda jpeg codec seems to be more stateless than stateful.
there is some parsing being than there. if we can agree on this, I can submit a new patchset for you to review. The only change needed seems to be this. | [12:29] |
| hverkuil1 | Yes, drop precision and go back to u8.
It was a bit of a detour, but we all learned something :-) It looks like the coda driver could use these new controls as well. | [12:35] |
| ezequielg | I wonder how possible it is for a driver that was written as stateful, to support stateless.
well, if it enums the compressed format to JPEG_RAW then it knows it'll work as stateless. | [12:38] |
| hverkuil1 | All that V4L2_CID_JPEG_QUANTIZATION does is to set the quantization matrices for the encoder. That will work just as well for stateful encoders.
For decoding JPEG it looks like the coda driver is stateful since I don't see any code that parses the jpeg header (unless I'm missing something). | [12:41] |
| ezequielg | right | [12:47] |
| sailus | hverkuil1: What would you call an input or an output on an ISP device?
Apparently VIDIOC_ENUMINPUT and VIDIOC_ENUMOUTPUT need to be supported on these devices. | [12:48] |
| hverkuil1 | We're talking about MC centric devices, right? | [12:50] |
| sailus | I presume this includes video nodes dealing with META buffers.
Correct. | [12:50] |
| hverkuil1 | This has never been fully resolved. There was a discussion about this with koike a fairly long time ago. Let me see if I can find it. | [12:51] |
| sailus | As for stand-alone ISPs without a direct connection to camera in the same device, calling it "camera" would seem to stretch the concept more than just a little.
Albeit it's intended for processing images from a camera. | [12:52] |
| hverkuil1 | https://www.mail-archive.com/linux-media@vger.kernel.org/msg110746.html | [12:52] |
| sailus | How about just "Image Signal Processor"? | [12:52] |
| ndufresne | except for the term Signal, it seems fair | [12:53] |
| pinchartl | sailus: why do we need to support VIDIOC_ENUMINPUT and VIDIOC_ENUMOUTPUT ? | [12:53] |
| ndufresne | I'm saying that because some ISP are m2m (frame based) | [12:53] |
| pinchartl | those ioctls don't make much sense for MC-centric devices | [12:53] |
| hverkuil1 | See the discussion of that link. It fizzled out without a clear resolution. | [12:53] |
| pinchartl | time to reach a conclusion then :-) | [12:54] |
| sailus | v4l2-compliance...?
If you ask me, this is just noise. | [12:54] |
| hverkuil1 | In the absence of any clear guidelines v4l2-compliance tests for this, yes. | [12:54] |
| pinchartl | sailus: that's putting the cart before the horse. we need to decide on the API first, and then either update drivers, or update the compliance tool | [12:55] |
| sailus | But if it's required, then I'd prefer to keep the driver changes needed to support this as small as reasonably possible. | [12:55] |
| hverkuil1 | It is currently a requirement of the spec. | [12:55] |
| pinchartl | hverkuil1: and I still think it should be fixed
because those ioctls would basically have no use | [12:56] |
| hverkuil1 | pinchartl: I don't mind, but someone needs to driver this.
drive | [12:56] |
| pinchartl | that we agree on
let me finish with my review backlog (request and properties API) this week first (and if it's just about updating the documentation to make those ioctls optional for MC-centric devices, I won't mind if someone beats me to it) | [12:56] |
| sailus | pinchartl: I think that'd sound reasonable. | [13:00] |
| hverkuil1 | Currently the input and output ioctls are compulsory for the following buffer types:
The input ioctls are compulsory for: V4L2_CAP_VIDEO_CAPTURE, V4L2_CAP_VBI_CAPTURE, V4L2_CAP_VIDEO_CAPTURE_MPLANE, V4L2_CAP_SLICED_VBI_CAPTURE The output ioctls are compulsory for: V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VBI_OUTPUT, V4L2_CAP_VIDEO_OUTPUT_MPLANE, V4L2_CAP_SLICED_VBI_OUTPUT So not required for META types. | [13:03] |
| sailus | hverkuil1: Where is that defined? | [13:04] |
| hverkuil1 | In the spec somewhere :-)
My problem is that we still don't have a clear method to signal to userspace that a specific video node is MC centric. The thread I refer to above suggests adding V4L2_CAP_MC for this. v4l2-compliance needs to know in order to perform the correct test. In any case, if someone wants to tackle this again, please read the thread first. | [13:04] |
| ............... (idle for 1h13mn) | ||
| *** | TrishoolinKing has left | [14:21] |
| ........................ (idle for 1h56mn) | ||
| benjiG has left | [16:17] | |
| .................... (idle for 1h38mn) | ||
| hverkuil1 | ezequielg: it will probably be Friday before I can look at your v6. Just so you know. | [17:55] |
| ............ (idle for 58mn) | ||
| ezequielg | hverkuil1: np. | [18:53] |
| *** | TrishoolinKing has left | [19:07] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |