[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [RFC PATCH v6] virtio-video: Add virtio video device specification
On 28.04.23 05:22, Alexandre Courbot wrote:
On Thu, Apr 27, 2023 at 11:20âPM Alexander Gordeev <alexander.gordeev@opensynergy.com> wrote:On 26.04.23 07:52, Alexandre Courbot wrote:On Mon, Apr 24, 2023 at 4:52âPM Alexander Gordeev <alexander.gordeev@opensynergy.com> wrote:On 21.04.23 18:01, Alexander Gordeev wrote:Let's compare VIRTIO_VIDEO_CMD_RESOURCE_QUEUE with VIDIOC_QBUF+VIDIOC_DQBUF. Including the parameters, of course. First, let's compare the word count to get a very rough estimate of complexity. I counted 585 words for VIRTIO_VIDEO_CMD_RESOURCE_QUEUE, including the parameters. VIDIOC_QBUF+VIDIOC_DQBUF are defined together and take 1206 words, they both use struct v4l2_buffer as a parameter. The struct takes 2716 words to be described. So the whole thing takes 3922 words. This is 6.7 times more, than VIRTIO_VIDEO_CMD_RESOURCE_QUEUE. If we check the definitions of the structs, it is also very obvious, that V4L2 UAPI is almost like an order of magnitude more complex.I think, it is best to add all the steps necessary to reproduce my calculations just in case. VIRTIO_VIDEO_CMD_RESOURCE_QUEUE is doing essentially the same thing as VIDIOC_QBUF+VIDIOC_DQBUF, so we're comparing apples to apples (if we don't forget to compare their parameters too). To get the word count for the VIRTIO_VIDEO_CMD_RESOURCE_QUEUE I opened the rendered PDF of video section only from the first email in this thread. Here is the link: https://drive.google.com/file/d/1Sm6LSqvKqQiwYmDE9BXZ0po3XTKnKYlD/view?usp=sharing . Then I scrolled to page 11 and copied everything related a text file. This is around two pages in the PDF. Then I removed page numbers from the copied text and used 'wc -w' to count words. To get the word count for VIDIOC_QBUF+VIDIOC_DQBUF I opened this link: https://docs.kernel.org/userspace-api/media/v4l/vidioc-qbuf.html . Then I selected all the text except table of contents and did followed the same procedure. To get the word count for struct v4l2_buffer and other types, that are referenced from it, I opened this link: https://docs.kernel.org/userspace-api/media/v4l/buffer.html#struct-v4l2-buffer . Then I selected all the text except the table of contents and the text above struct v4l2_buffer definition. The rest is the same. Also it's quite obvious if you look at them how much bigger struct v4l2_buffer (including the referenced types) is compared to struct virtio_video_resource_queue.You are comparing not the complexity of the structures but the verbosity of their documentation, which are written in a different style, format, and by different people.I agree to some extent. At least this benchmark is simple and it provokes to actually go and look at the definitions, which IMO should be enough to already see the difference. What could be a better benchmark? Maybe counting the number of various fields and flags and enum cases, that one has to read through?I give you another point of comparison literally 5 lines down my email.And the V4L2 page also contains the description of memory types, which is part of another section in the virtio-video spec.You mean only enum v4l2_memory? Or anything else too?There is no way to draw a meaningful conclusion from this. If you want to compare, do it with how the structures are actually used. Here is how you would queue an input buffer with virtio-video: struct virtio_video_resource_queue queue_buf = { .cmd_type = VIRTIO_VIDEO_CMD_RESOURCE_QUEUE, .stream_id = 42, .queue_type = VIRTIO_VIDEO_QUEUE_TYPE_INPUT, .resource_id = 1, .timestamp = 0x10, .data_sizes = { [0] = 0x1000, }, }; Now the same with virtio-v4l2: struct virtio_v4l2_queue_buf queue_buf = { .cmd = VIRTIO_V4L2_CMD_IOCTL, .code = VIDIOC_QBUF, .session_id = 42, .buffer.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, .buffer.index = 1, .buffer.timestamp.tv_usec = 0x10, .buffer.memory = V4L2_MEMORY_MMAP, .planes = { [0] = { .bytesused = 0x1000 }, } }; In both cases, you pass a structure with some members set, and the rest to 0. The host receives basically the same thing - it's the same data! The only difference is how it is laid out.How do I know this from the text? How do I verify, that this is correct? Can I be sure this code is going to work or not between any device and any driver? With virtio-video you can just go to the spec/header file, take the struct definition and simply set all the fields. With V4L2 UAPI I don't see any other way except going through the whole buffer.html file, filtering potentially irrelevant stuff, then doing some trials, and maybe looking into the device or driver code. Maybe also asking you for an advice?The relevant fields for each decoding operation are clearly detailed in https://www.kernel.org/doc/html/v5.18/userspace-api/media/v4l/dev-decoder.html, which I already linked to multiple times.
That's true for most of them. I'd prefer a single document without all the irrelevant stuff at all. So this one is not quite readable and it never asks to zero the not required fields. Still this is bearable. But this is not true for struct v4l2_buffer. I couldn't find anything in the document, that you're linking. I went there and rechecked it again, still no. Where is it exactly? -- Alexander Gordeev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin Phone: +49 30 60 98 54 0 - 88 Fax: +49 (30) 60 98 54 0 - 99 EMail: alexander.gordeev@opensynergy.com www.opensynergy.com Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B GeschÃftsfÃhrer/Managing Director: RÃgis Adjamah Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]