Message ID | 20240510134317.3201746-1-aesteve@redhat.com (mailing list archive) |
---|---|
Headers |
Received: from sy.mirrors.kernel.org ([147.75.48.161]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-11322-patchwork=linuxtv.org@vger.kernel.org>) id 1s5QXO-0006jI-1L for patchwork@linuxtv.org; Fri, 10 May 2024 13:43:51 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 1B454B211D3 for <patchwork@linuxtv.org>; Fri, 10 May 2024 13:43:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C426612C498; Fri, 10 May 2024 13:43:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KD61kaEB" X-Original-To: linux-media@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D526A7E58F for <linux-media@vger.kernel.org>; Fri, 10 May 2024 13:43:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715348618; cv=none; b=MbWspuOBkFqAhfumqMcLLoAezuZ32B+muVVycvvsZdFEZh1gYMyGk3e3bVAehC7njITEDChUqwRczuY35BohHqsdEP6jTa0Br4Zaw1nBZ966lX1UTWinplVCfoZKPzQku/cc6yP0kYrkgulL7snYDtzPJhxcoxpRklVRoUfcftw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715348618; c=relaxed/simple; bh=BoLQvBVJOoCjk+iZrCEftQdwEpUcH5Vtc6iOYEj5zqs=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=YcCy6w3XQuAiyc/C5pxnY/MqGGR0fiA2XTlqmxW3ySfdNJ00Z0gypDyDgT395+R6kUfdGGcUhcwtmu3AWwSs9aYsKK+M+Z4ysScwL05OHkW4q/G5Ev24d2Jfl/blkGZSCr/NT9YwQ0U6mC/LFprfh7lLwezXAkwKOXUhqgE63mw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KD61kaEB; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715348615; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=EGPFRAm20EF2gNKmn5OIm+wKsmkKPz5p/hST/VOsK7U=; b=KD61kaEBMUKk0D0NY3QIztfrlLY6w4nEBiA/oOaEqWlqev6tmJW3TCnZV0jpGAVKXr4uXq 0oy8FCSHmlKvbuhdZgT6FYtFDIQckNbM+FTKYyAy9AmEjxuYzNdPaB7XyladD0mE8vU6+s l7Iz4G1fdMmffTyw4p5NiQeyQrYiLuI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-630-RkAVSjXyMYCP04LLMGCxHw-1; Fri, 10 May 2024 09:43:22 -0400 X-MC-Unique: RkAVSjXyMYCP04LLMGCxHw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E746E800656; Fri, 10 May 2024 13:43:21 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.45.224.245]) by smtp.corp.redhat.com (Postfix) with ESMTP id CDB475751BE; Fri, 10 May 2024 13:43:18 +0000 (UTC) From: Albert Esteve <aesteve@redhat.com> To: virtio-dev@lists.oasis-open.org Cc: cohuck@redhat.com, alex.bennee@linaro.org, changyeon@google.com, daniel.almeida@collabora.com, mst@redhat.com, virtio-comment@lists.oasis-open.org, linux-media@vger.kernel.org, eballetb@redhat.com, gurchetansingh@google.com, nicolas.dufresne@collabora.com, acourbot@chromium.org, Alexander.Gordeev@opensynergy.com, Albert Esteve <aesteve@redhat.com> Subject: [PATCH 0/1] virtio-media: Add device specification Date: Fri, 10 May 2024 15:43:16 +0200 Message-ID: <20240510134317.3201746-1-aesteve@redhat.com> Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-LSpam-Score: -3.6 (---) X-LSpam-Report: No, score=-3.6 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIMWL_WL_HIGH=-1,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no |
Series |
virtio-media: Add device specification
|
|
Message
Albert Esteve
May 10, 2024, 1:43 p.m. UTC
Hi, This a formal attempt of including virtio-media device specification. Virtio-media came from a discussion on virtio-dev mailing list, which lead to presenting virtio-v4l2[1] specification as an alternative to virtio-video. Later, virtio-v4l2 was renamed to virtio-media[2] and published through: https://github.com/chromeos/virtio-media The repository above includes a guest V4L2 driver able to pass v4l2-compliance when proxying the vivid/vicodec virtual devices or an actual UVC camera using the crosvm V4L2 proxy device. Steps to reproduce are also detailed[3]. There is some overlap with virtio-video in regards to which devices it can handle. However, as virtio-media will likely be the virtualization solution for ChromeOS (already landed into the chromeos organization) and possibly other Google projects for media devices, it would be desirable to include the specification in the next virtio release despite the aforementioned overlap. The device ID in this document differs from the ID in the virtio-media project repository. And it will probably need some discussion on which would be the correct definitive ID. Full PDF: https://drive.google.com/file/d/1PG1YxzbSvQHPphFhbUKyKKdvuwO6shyi/view?usp=sharing PDF with the media section only: https://drive.google.com/file/d/1Y7kAGzlUfl30VIUx9wQtz5sFTkWnBiyA/view?usp=sharing [1] https://mail.google.com/mail/u/0?ui=2&ik=73ebd65ebd&attid=0.1&permmsgid=msg-f:1767388565327924962&th=1887068940754ee2&view=att&disp=inline&realattid=f_libalimc0 [2] https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg12665.html [3] https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md Albert Esteve (1): virtio-media: Add virtio media device specification conformance.tex | 13 +- content.tex | 1 + device-types/media/description.tex | 574 ++++++++++++++++++++++ device-types/media/device-conformance.tex | 11 + device-types/media/driver-conformance.tex | 9 + 5 files changed, 604 insertions(+), 4 deletions(-) create mode 100644 device-types/media/description.tex create mode 100644 device-types/media/device-conformance.tex create mode 100644 device-types/media/driver-conformance.tex
Comments
+CC Matti Hi Albert, On 10.05.24 15:43, Albert Esteve wrote: > Hi, > > This a formal attempt of including virtio-media > device specification. > > Virtio-media came from a discussion on virtio-dev > mailing list, which lead to presenting virtio-v4l2[1] > specification as an alternative to virtio-video. > > Later, virtio-v4l2 was renamed to virtio-media[2] > and published through: > > https://github.com/chromeos/virtio-media > > The repository above includes a guest V4L2 driver able > to pass v4l2-compliance when proxying the vivid/vicodec > virtual devices or an actual UVC camera using the > crosvm V4L2 proxy device. Steps to reproduce are > also detailed[3]. > > There is some overlap with virtio-video in regards > to which devices it can handle. However, > as virtio-media will likely be the virtualization > solution for ChromeOS (already landed into the chromeos > organization) and possibly other Google projects for > media devices, it would be desirable to include the > specification in the next virtio release despite > the aforementioned overlap. Well, last year Cornelia made it clear, that this kind of overlap is not desirable in the specification. After long email discussion we had a video call with some selected experts on June 1st discussing the proposed approaches. The conclusion was that virtio-video development should be continued, that the virtio-v4l2 use-case is valid, but the proposed approach is not desirable in the specification, it should be instead implemented with multiple device types. It was also concluded, that a new device ID should not be reserved. It is a pity, that there were no public announcement after that, so now it looks like we're going to have the same debate again. But I'll be happy to discuss all of this with Albert and the new joiners in the discussion. I believe my arguments are still valid. I suggest, that at least both of us (and hopefully others) start with familiarizing ourselves with both virtio-video and virtio-media. I'd be happy to present the current state of the virtio-video spec in details and answer questions in a video call. I think, I'll need two weeks to prepare. Maybe we can even resolve the issue ourselves. I think that would be a good start. WDYT? > The device ID in this document differs from > the ID in the virtio-media project repository. > And it will probably need some discussion on which > would be the correct definitive ID. > > Full PDF: https://drive.google.com/file/d/1PG1YxzbSvQHPphFhbUKyKKdvuwO6shyi/view?usp=sharing > PDF with the media section only: https://drive.google.com/file/d/1Y7kAGzlUfl30VIUx9wQtz5sFTkWnBiyA/view?usp=sharing > > [1] https://mail.google.com/mail/u/0?ui=2&ik=73ebd65ebd&attid=0.1&permmsgid=msg-f:1767388565327924962&th=1887068940754ee2&view=att&disp=inline&realattid=f_libalimc0 > [2] https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg12665.html > [3] https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md > > Albert Esteve (1): > virtio-media: Add virtio media device specification > > conformance.tex | 13 +- > content.tex | 1 + > device-types/media/description.tex | 574 ++++++++++++++++++++++ > device-types/media/device-conformance.tex | 11 + > device-types/media/driver-conformance.tex | 9 + > 5 files changed, 604 insertions(+), 4 deletions(-) > create mode 100644 device-types/media/description.tex > create mode 100644 device-types/media/device-conformance.tex > create mode 100644 device-types/media/driver-conformance.tex > Kind regards
On 13.05.24 13:18, Albert Esteve wrote: > > > On Mon, May 13, 2024 at 11:56 AM Alexander Gordeev > <alexander.gordeev@opensynergy.com > <mailto:alexander.gordeev@opensynergy.com>> wrote: > > +CC Matti > > Hi Albert, > > On 10.05.24 15:43, Albert Esteve wrote: > > Hi, > > > > This a formal attempt of including virtio-media > > device specification. > > > > Virtio-media came from a discussion on virtio-dev > > mailing list, which lead to presenting virtio-v4l2[1] > > specification as an alternative to virtio-video. > > > > Later, virtio-v4l2 was renamed to virtio-media[2] > > and published through: > > > > https://github.com/chromeos/virtio-media > <https://github.com/chromeos/virtio-media> > > > > The repository above includes a guest V4L2 driver able > > to pass v4l2-compliance when proxying the vivid/vicodec > > virtual devices or an actual UVC camera using the > > crosvm V4L2 proxy device. Steps to reproduce are > > also detailed[3]. > > > > There is some overlap with virtio-video in regards > > to which devices it can handle. However, > > as virtio-media will likely be the virtualization > > solution for ChromeOS (already landed into the chromeos > > organization) and possibly other Google projects for > > media devices, it would be desirable to include the > > specification in the next virtio release despite > > the aforementioned overlap. > > Well, last year Cornelia made it clear, that this kind of overlap is > not > desirable in the specification. After long email discussion we had a > video call with some selected experts on June 1st discussing the > proposed approaches. The conclusion was that virtio-video development > should be continued, that the virtio-v4l2 use-case is valid, but the > proposed approach is not desirable in the specification, it should be > instead implemented with multiple device types. It was also concluded, > that a new device ID should not be reserved. It is a pity, that there > were no public announcement after that, so now it looks like we're > going > to have the same debate again. But I'll be happy to discuss all of this > with Albert and the new joiners in the discussion. I believe my > arguments are still valid. > > > Hi Alexander, > > My intention is not to re-open the debate. The debate already happened > and the points given were clear enough. I will certainly noy be able to > enrich the debate with my own points. Sadly, we did not get a clear > conclusion, nor an agreement, on the way to move forward. > Instead, we ended up with two different specifications, one > that is still working towards standarization, one that did not. > > I completely agree with Cornelia, the overlap is not desirable. I > really wish there had been an agreement and moved together > towards a common goal. But alas, that did not happen. And I > think that having a non-standard virtual device used in some > systems is the worst case, and hence decided to attempt > standardization. Thanks for the clarification! Yeah, I also wish we could move together to a common goal. But it looks like we have different sets of requirements and therefore quite different short term goals. I hope virtio-video can become suitable for all of us in the long term, if there is also the virtio-camera, so that the compatibility is much less a problem. > I suggest, that at least both of us (and hopefully others) start with > familiarizing ourselves with both virtio-video and virtio-media. I'd be > happy to present the current state of the virtio-video spec in details > and answer questions in a video call. I think, I'll need two weeks to > prepare. Maybe we can even resolve the issue ourselves. I think that > would be a good start. WDYT? > > > I am more or less familiar with virtio-video (not so much in the latest > drops, but I still checked them). But I do not own virtio-media, or have > any intellectual involvement in its design. I merely followed its > progress, and decided to collect the specification written at > https://github.com/chromeos/virtio-media > <https://github.com/chromeos/virtio-media>. > > So I am in no position to solve the issue. But I decided to try > and alleviate its impact by having both in the standard. > > That said, I will read your next virtio-video drop and try to > provide feedback :) Thanks, looking forward to your feedback. :) > BR, > Albert > > > > The device ID in this document differs from > > the ID in the virtio-media project repository. > > And it will probably need some discussion on which > > would be the correct definitive ID. > > > > Full PDF: > https://drive.google.com/file/d/1PG1YxzbSvQHPphFhbUKyKKdvuwO6shyi/view?usp=sharing <https://drive.google.com/file/d/1PG1YxzbSvQHPphFhbUKyKKdvuwO6shyi/view?usp=sharing> > > PDF with the media section only: > https://drive.google.com/file/d/1Y7kAGzlUfl30VIUx9wQtz5sFTkWnBiyA/view?usp=sharing <https://drive.google.com/file/d/1Y7kAGzlUfl30VIUx9wQtz5sFTkWnBiyA/view?usp=sharing> > > > > [1] > https://mail.google.com/mail/u/0?ui=2&ik=73ebd65ebd&attid=0.1&permmsgid=msg-f:1767388565327924962&th=1887068940754ee2&view=att&disp=inline&realattid=f_libalimc0 <https://mail.google.com/mail/u/0?ui=2&ik=73ebd65ebd&attid=0.1&permmsgid=msg-f:1767388565327924962&th=1887068940754ee2&view=att&disp=inline&realattid=f_libalimc0> > > [2] > https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg12665.html <https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg12665.html> > > [3] > https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md > <https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md> > > > > Albert Esteve (1): > > virtio-media: Add virtio media device specification > > > > conformance.tex | 13 +- > > content.tex | 1 + > > device-types/media/description.tex | 574 > ++++++++++++++++++++++ > > device-types/media/device-conformance.tex | 11 + > > device-types/media/driver-conformance.tex | 9 + > > 5 files changed, 604 insertions(+), 4 deletions(-) > > create mode 100644 device-types/media/description.tex > > create mode 100644 device-types/media/device-conformance.tex > > create mode 100644 device-types/media/driver-conformance.tex > > > > Kind regards > > -- > Alexander Gordeev > Senior Software Engineer > > OpenSynergy GmbH > Rotherstr. 20, 10245 Berlin > www.opensynergy.com <http://www.opensynergy.com> >