From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 14F7F9865B7 for ; Thu, 12 Jan 2023 15:24:06 +0000 (UTC) From: Cornelia Huck In-Reply-To: References: <20221208072325.2259940-1-acourbot@chromium.org> <87bkoehrds.fsf@redhat.com> <871qo1xxvu.fsf@redhat.com> Date: Thu, 12 Jan 2023 16:23:57 +0100 Message-ID: <87o7r3dbea.fsf@redhat.com> MIME-Version: 1.0 Subject: Re: [virtio-dev] [RFC PATCH v6] virtio-video: Add virtio video device specification Content-Type: text/plain To: Alexandre Courbot Cc: virtio-dev@lists.oasis-open.org, Keiichi Watanabe , Alex =?utf-8?Q?Benn=C3=A9e?= , Marcin Wojtas , Matti =?utf-8?Q?M=C3=B6ll?= , Andrew Gazizov , Enrico Granata , Gustavo Padovan , Peter Griffin , =?utf-8?Q?Bart=C5=82omiej?= Grzesik , Tomasz Figa , Daniel Almeida List-ID: On Thu, Jan 12 2023, Alexandre Courbot wrote: > Hi Cornelia, > > On Wed, Jan 11, 2023 at 5:45 PM Cornelia Huck wrote: >> >> > + >> >> > +The device MUST set the \field{caps_length} field to a value equal to >> >> > +the response size of VIRTIO\_VIDEO\_CMD\_DEVICE\_QUERY\_CAPS. >> >> >> >> Could the device also support a minimum response size that only supports >> >> a subset of the caps to be returned? Otherwise, I think caps_length is >> >> the maximum (or fixed?) length of the query caps response? >> > >> > I think this can be replaced by a fixed-size call for getting only one >> > format at a time. The guest would have to make several of these in >> > order to obtain the whole set of supported formats, but it would be >> > easier to parse compared to the large result returned by QUERY_CAP and >> > simpler overall. >> >> How would you implement this? Would the driver do the call repeatedly >> until no more formats remain (requires the device to track state, and >> needs a specification on what happens if the driver continues doing the >> call?) Or would the driver pass in an index, and the device only needs >> to check for out-of-range? > > One peculiarity of codecs is that the pixel formats available may > depend on the coded format (and sometimes even its resolution). For > instance, NV12 may be available if you do VP8 at 1080p but not 4K > H.264. > > This means that a single call returning all the coded and pixel > formats won't be able to convey all the possible subtleties. In > previous versions of this spec we used bitmasks to associate pixel > formats to their supported coded formats, but it's a bit of a pain to > manage while still not bringing the necessary precision. > > So here again the safe way is to follow the V4L2 lead: get a list of > supported bitstream formats (one at a time, using an index with a > range defined by the configuration space), apply the one we are > interested in, and query the supported pixel formats for that specific > bitstream format using the same mechanism. That's more back-and-forth > between the guest and the host, but it happens before streaming starts > and better reflects the actual decoding workflow where the client is > typically only interested in the supported formats for the codec they > want to decode. Thanks for the explanation; I agree that this is probably a good way to handle a complex situation. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org