Linux-Media Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
@ 2019-04-12 15:59 Stanimir Varbanov
  2019-05-02 12:55 ` Mauro Carvalho Chehab
  2019-05-14  8:54 ` Hans Verkuil
  0 siblings, 2 replies; 12+ messages in thread
From: Stanimir Varbanov @ 2019-04-12 15:59 UTC (permalink / raw)
  To: linux-media
  Cc: Mauro Carvalho Chehab, Hans Verkuil, linux-arm-msm, linux-kernel,
	Stanimir Varbanov

This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
field description to allow v4l clients to set bigger image size
in case of variable length compressed data.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
 Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
 Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
index 5688c816e334..005428a8121e 100644
--- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
@@ -31,7 +31,18 @@ describing all planes of that format.
 
     * - __u32
       - ``sizeimage``
-      - Maximum size in bytes required for image data in this plane.
+      - Maximum size in bytes required for image data in this plane,
+	set by the driver. When the image consists of variable length
+	compressed data this is the number of bytes required by the
+	codec to support the worst-case compression scenario.
+
+	For uncompressed images the driver will set the value. For
+	variable length compressed data clients are allowed to set
+	the sizeimage field, but the driver may ignore it and set the
+	value itself, or it may modify the provided value based on
+	alignment requirements or minimum/maximum size requirements.
+	If the client wants to leave this to the driver, then it should
+	set sizeimage to 0.
     * - __u32
       - ``bytesperline``
       - Distance in bytes between the leftmost pixels in two adjacent
diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
index 71eebfc6d853..0f7771151db9 100644
--- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
@@ -89,7 +89,16 @@ Single-planar format structure
       - Size in bytes of the buffer to hold a complete image, set by the
 	driver. Usually this is ``bytesperline`` times ``height``. When
 	the image consists of variable length compressed data this is the
-	maximum number of bytes required to hold an image.
+	number of bytes required by the codec to support the worst-case
+	compression scenario.
+
+	For uncompressed images the driver will set the value. For
+	variable length compressed data clients are allowed to set
+	the sizeimage field, but the driver may ignore it and set the
+	value itself, or it may modify the provided value based on
+	alignment requirements or minimum/maximum size requirements.
+	If the client wants to leave this to the driver, then it should
+	set sizeimage to 0.
     * - __u32
       - ``colorspace``
       - Image colorspace, from enum :c:type:`v4l2_colorspace`.
-- 
2.17.1


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-04-12 15:59 [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients Stanimir Varbanov
@ 2019-05-02 12:55 ` Mauro Carvalho Chehab
  2019-05-02 13:16   ` Hans Verkuil
  2019-05-14  8:54 ` Hans Verkuil
  1 sibling, 1 reply; 12+ messages in thread
From: Mauro Carvalho Chehab @ 2019-05-02 12:55 UTC (permalink / raw)
  To: Stanimir Varbanov; +Cc: linux-media, Hans Verkuil, linux-arm-msm, linux-kernel

Em Fri, 12 Apr 2019 18:59:15 +0300
Stanimir Varbanov <stanimir.varbanov@linaro.org> escreveu:

> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
> field description to allow v4l clients to set bigger image size
> in case of variable length compressed data.
> 
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> index 5688c816e334..005428a8121e 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> @@ -31,7 +31,18 @@ describing all planes of that format.
>  
>      * - __u32
>        - ``sizeimage``
> -      - Maximum size in bytes required for image data in this plane.
> +      - Maximum size in bytes required for image data in this plane,
> +	set by the driver. When the image consists of variable length
> +	compressed data this is the number of bytes required by the
> +	codec to support the worst-case compression scenario.
> +
> +	For uncompressed images the driver will set the value. For
> +	variable length compressed data clients are allowed to set
> +	the sizeimage field, but the driver may ignore it and set the
> +	value itself, or it may modify the provided value based on
> +	alignment requirements or minimum/maximum size requirements.
> +	If the client wants to leave this to the driver, then it should
> +	set sizeimage to 0.
>      * - __u32
>        - ``bytesperline``
>        - Distance in bytes between the leftmost pixels in two adjacent
> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> index 71eebfc6d853..0f7771151db9 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> @@ -89,7 +89,16 @@ Single-planar format structure
>        - Size in bytes of the buffer to hold a complete image, set by the
>  	driver. Usually this is ``bytesperline`` times ``height``. When
>  	the image consists of variable length compressed data this is the
> -	maximum number of bytes required to hold an image.
> +	number of bytes required by the codec to support the worst-case
> +	compression scenario.
> +
> +	For uncompressed images the driver will set the value. For
> +	variable length compressed data clients are allowed to set
> +	the sizeimage field, but the driver may ignore it and set the
> +	value itself, or it may modify the provided value based on
> +	alignment requirements or minimum/maximum size requirements.
> +	If the client wants to leave this to the driver, then it should
> +	set sizeimage to 0.

It is very confusing to understand what you meant by the above paragraph,
as you inverted the sentence order and forgot a comma.

I would, instead, write the phrases using the direct order, and break
into two paragraphs, e. g., changing the above to:

	"The driver will set the value for uncompressed images.

	Clients are allowed to set the sizeimage field for variable length
	compressed data, but the driver may ignore it and set the
	value itself, or it may modify the provided value based on
	alignment requirements or minimum/maximum size requirements.
	If the client wants to leave this to the driver, then it should
	set sizeimage to 0."

That makes it a lot easier to read, hopefully preventing mistakes from
app and driver developers when reading about sizeimage.

Yet, I'm not too comfortable on letting this too generic. I mean,
how an app writer would know what formats are "variable length
compressed data", specially since libv4l may actually change that.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-02 12:55 ` Mauro Carvalho Chehab
@ 2019-05-02 13:16   ` Hans Verkuil
  2019-05-02 13:29     ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 12+ messages in thread
From: Hans Verkuil @ 2019-05-02 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Stanimir Varbanov
  Cc: linux-media, linux-arm-msm, linux-kernel

On 5/2/19 2:55 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 12 Apr 2019 18:59:15 +0300
> Stanimir Varbanov <stanimir.varbanov@linaro.org> escreveu:
> 
>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>> field description to allow v4l clients to set bigger image size
>> in case of variable length compressed data.
>>
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>> ---
>>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
>>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
>>  2 files changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>> index 5688c816e334..005428a8121e 100644
>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>> @@ -31,7 +31,18 @@ describing all planes of that format.
>>  
>>      * - __u32
>>        - ``sizeimage``
>> -      - Maximum size in bytes required for image data in this plane.
>> +      - Maximum size in bytes required for image data in this plane,
>> +	set by the driver. When the image consists of variable length
>> +	compressed data this is the number of bytes required by the
>> +	codec to support the worst-case compression scenario.
>> +
>> +	For uncompressed images the driver will set the value. For
>> +	variable length compressed data clients are allowed to set
>> +	the sizeimage field, but the driver may ignore it and set the
>> +	value itself, or it may modify the provided value based on
>> +	alignment requirements or minimum/maximum size requirements.
>> +	If the client wants to leave this to the driver, then it should
>> +	set sizeimage to 0.
>>      * - __u32
>>        - ``bytesperline``
>>        - Distance in bytes between the leftmost pixels in two adjacent
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>> index 71eebfc6d853..0f7771151db9 100644
>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>> @@ -89,7 +89,16 @@ Single-planar format structure
>>        - Size in bytes of the buffer to hold a complete image, set by the
>>  	driver. Usually this is ``bytesperline`` times ``height``. When
>>  	the image consists of variable length compressed data this is the
>> -	maximum number of bytes required to hold an image.
>> +	number of bytes required by the codec to support the worst-case
>> +	compression scenario.
>> +
>> +	For uncompressed images the driver will set the value. For
>> +	variable length compressed data clients are allowed to set
>> +	the sizeimage field, but the driver may ignore it and set the
>> +	value itself, or it may modify the provided value based on
>> +	alignment requirements or minimum/maximum size requirements.
>> +	If the client wants to leave this to the driver, then it should
>> +	set sizeimage to 0.
> 
> It is very confusing to understand what you meant by the above paragraph,
> as you inverted the sentence order and forgot a comma.
> 
> I would, instead, write the phrases using the direct order, and break
> into two paragraphs, e. g., changing the above to:
> 
> 	"The driver will set the value for uncompressed images.
> 
> 	Clients are allowed to set the sizeimage field for variable length
> 	compressed data, but the driver may ignore it and set the
> 	value itself, or it may modify the provided value based on
> 	alignment requirements or minimum/maximum size requirements.
> 	If the client wants to leave this to the driver, then it should
> 	set sizeimage to 0."
> 
> That makes it a lot easier to read, hopefully preventing mistakes from
> app and driver developers when reading about sizeimage.
> 
> Yet, I'm not too comfortable on letting this too generic. I mean,
> how an app writer would know what formats are "variable length
> compressed data", specially since libv4l may actually change that.

It's actually quite clearly defined: compressed formats set the
V4L2_FMT_FLAG_COMPRESSED flag in VIDIOC_ENUMFMT.

Also bytesperline will be 0 for compressed formats.

Regards,

	Hans

> 
> Thanks,
> Mauro
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-02 13:16   ` Hans Verkuil
@ 2019-05-02 13:29     ` Mauro Carvalho Chehab
  2019-05-07 16:54       ` Stanimir Varbanov
  0 siblings, 1 reply; 12+ messages in thread
From: Mauro Carvalho Chehab @ 2019-05-02 13:29 UTC (permalink / raw)
  To: Hans Verkuil; +Cc: Stanimir Varbanov, linux-media, linux-arm-msm, linux-kernel

Em Thu, 2 May 2019 15:16:54 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 5/2/19 2:55 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 12 Apr 2019 18:59:15 +0300
> > Stanimir Varbanov <stanimir.varbanov@linaro.org> escreveu:
> >   
> >> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
> >> field description to allow v4l clients to set bigger image size
> >> in case of variable length compressed data.
> >>
> >> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> >> ---
> >>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
> >>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
> >>  2 files changed, 22 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> >> index 5688c816e334..005428a8121e 100644
> >> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> >> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> >> @@ -31,7 +31,18 @@ describing all planes of that format.
> >>  
> >>      * - __u32
> >>        - ``sizeimage``
> >> -      - Maximum size in bytes required for image data in this plane.
> >> +      - Maximum size in bytes required for image data in this plane,
> >> +	set by the driver. When the image consists of variable length
> >> +	compressed data this is the number of bytes required by the
> >> +	codec to support the worst-case compression scenario.
> >> +
> >> +	For uncompressed images the driver will set the value. For
> >> +	variable length compressed data clients are allowed to set
> >> +	the sizeimage field, but the driver may ignore it and set the
> >> +	value itself, or it may modify the provided value based on
> >> +	alignment requirements or minimum/maximum size requirements.
> >> +	If the client wants to leave this to the driver, then it should
> >> +	set sizeimage to 0.
> >>      * - __u32
> >>        - ``bytesperline``
> >>        - Distance in bytes between the leftmost pixels in two adjacent
> >> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> >> index 71eebfc6d853..0f7771151db9 100644
> >> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> >> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> >> @@ -89,7 +89,16 @@ Single-planar format structure
> >>        - Size in bytes of the buffer to hold a complete image, set by the
> >>  	driver. Usually this is ``bytesperline`` times ``height``. When
> >>  	the image consists of variable length compressed data this is the
> >> -	maximum number of bytes required to hold an image.
> >> +	number of bytes required by the codec to support the worst-case
> >> +	compression scenario.
> >> +
> >> +	For uncompressed images the driver will set the value. For
> >> +	variable length compressed data clients are allowed to set
> >> +	the sizeimage field, but the driver may ignore it and set the
> >> +	value itself, or it may modify the provided value based on
> >> +	alignment requirements or minimum/maximum size requirements.
> >> +	If the client wants to leave this to the driver, then it should
> >> +	set sizeimage to 0.  
> > 
> > It is very confusing to understand what you meant by the above paragraph,
> > as you inverted the sentence order and forgot a comma.
> > 
> > I would, instead, write the phrases using the direct order, and break
> > into two paragraphs, e. g., changing the above to:
> > 
> > 	"The driver will set the value for uncompressed images.
> > 
> > 	Clients are allowed to set the sizeimage field for variable length
> > 	compressed data, but the driver may ignore it and set the
> > 	value itself, or it may modify the provided value based on
> > 	alignment requirements or minimum/maximum size requirements.
> > 	If the client wants to leave this to the driver, then it should
> > 	set sizeimage to 0."
> > 
> > That makes it a lot easier to read, hopefully preventing mistakes from
> > app and driver developers when reading about sizeimage.
> > 
> > Yet, I'm not too comfortable on letting this too generic. I mean,
> > how an app writer would know what formats are "variable length
> > compressed data", specially since libv4l may actually change that.  
> 
> It's actually quite clearly defined: compressed formats set the
> V4L2_FMT_FLAG_COMPRESSED flag in VIDIOC_ENUMFMT.

Ok, so let's be explicit here, e. g. something like:

 	"Clients are allowed to set the sizeimage field for variable length
 	compressed data flagged with V4L2_FMT_FLAG_COMPRESSED at
	VIDIOC_ENUMFMT, but the driver may ignore it and set the
 	value itself, or it may modify the provided value based on
 	alignment requirements or minimum/maximum size requirements.
 	If the client wants to leave this to the driver, then it should
 	set sizeimage to 0."

That makes clear for app developers when they can use this new
feature.

That still leads us to what happens at libv4l with sizeimage
for a compressed format that got uncompressed by the library, in
order to ensure that a change like this won't cause breakages at
existing userspace apps.

> 
> Also bytesperline will be 0 for compressed formats.
> 
> Regards,
> 
> 	Hans
> 
> > 
> > Thanks,
> > Mauro
> >   
> 



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-02 13:29     ` Mauro Carvalho Chehab
@ 2019-05-07 16:54       ` Stanimir Varbanov
  0 siblings, 0 replies; 12+ messages in thread
From: Stanimir Varbanov @ 2019-05-07 16:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Hans Verkuil
  Cc: Stanimir Varbanov, linux-media, linux-arm-msm, linux-kernel

Hi Mauro,

Thanks for comments!

On 5/2/19 4:29 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 2 May 2019 15:16:54 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>> On 5/2/19 2:55 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 12 Apr 2019 18:59:15 +0300
>>> Stanimir Varbanov <stanimir.varbanov@linaro.org> escreveu:
>>>   
>>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>>> field description to allow v4l clients to set bigger image size
>>>> in case of variable length compressed data.
>>>>
>>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>>> ---
>>>>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
>>>>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
>>>>  2 files changed, 22 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> index 5688c816e334..005428a8121e 100644
>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> @@ -31,7 +31,18 @@ describing all planes of that format.
>>>>  
>>>>      * - __u32
>>>>        - ``sizeimage``
>>>> -      - Maximum size in bytes required for image data in this plane.
>>>> +      - Maximum size in bytes required for image data in this plane,
>>>> +	set by the driver. When the image consists of variable length
>>>> +	compressed data this is the number of bytes required by the
>>>> +	codec to support the worst-case compression scenario.
>>>> +
>>>> +	For uncompressed images the driver will set the value. For
>>>> +	variable length compressed data clients are allowed to set
>>>> +	the sizeimage field, but the driver may ignore it and set the
>>>> +	value itself, or it may modify the provided value based on
>>>> +	alignment requirements or minimum/maximum size requirements.
>>>> +	If the client wants to leave this to the driver, then it should
>>>> +	set sizeimage to 0.
>>>>      * - __u32
>>>>        - ``bytesperline``
>>>>        - Distance in bytes between the leftmost pixels in two adjacent
>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> index 71eebfc6d853..0f7771151db9 100644
>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> @@ -89,7 +89,16 @@ Single-planar format structure
>>>>        - Size in bytes of the buffer to hold a complete image, set by the
>>>>  	driver. Usually this is ``bytesperline`` times ``height``. When
>>>>  	the image consists of variable length compressed data this is the
>>>> -	maximum number of bytes required to hold an image.
>>>> +	number of bytes required by the codec to support the worst-case
>>>> +	compression scenario.
>>>> +
>>>> +	For uncompressed images the driver will set the value. For
>>>> +	variable length compressed data clients are allowed to set
>>>> +	the sizeimage field, but the driver may ignore it and set the
>>>> +	value itself, or it may modify the provided value based on
>>>> +	alignment requirements or minimum/maximum size requirements.
>>>> +	If the client wants to leave this to the driver, then it should
>>>> +	set sizeimage to 0.  
>>>
>>> It is very confusing to understand what you meant by the above paragraph,
>>> as you inverted the sentence order and forgot a comma.
>>>
>>> I would, instead, write the phrases using the direct order, and break
>>> into two paragraphs, e. g., changing the above to:
>>>
>>> 	"The driver will set the value for uncompressed images.
>>>
>>> 	Clients are allowed to set the sizeimage field for variable length
>>> 	compressed data, but the driver may ignore it and set the
>>> 	value itself, or it may modify the provided value based on
>>> 	alignment requirements or minimum/maximum size requirements.
>>> 	If the client wants to leave this to the driver, then it should
>>> 	set sizeimage to 0."
>>>
>>> That makes it a lot easier to read, hopefully preventing mistakes from
>>> app and driver developers when reading about sizeimage.
>>>
>>> Yet, I'm not too comfortable on letting this too generic. I mean,
>>> how an app writer would know what formats are "variable length
>>> compressed data", specially since libv4l may actually change that.  
>>
>> It's actually quite clearly defined: compressed formats set the
>> V4L2_FMT_FLAG_COMPRESSED flag in VIDIOC_ENUMFMT.
> 
> Ok, so let's be explicit here, e. g. something like:
> 
>  	"Clients are allowed to set the sizeimage field for variable length
>  	compressed data flagged with V4L2_FMT_FLAG_COMPRESSED at
> 	VIDIOC_ENUMFMT, but the driver may ignore it and set the
>  	value itself, or it may modify the provided value based on
>  	alignment requirements or minimum/maximum size requirements.
>  	If the client wants to leave this to the driver, then it should
>  	set sizeimage to 0."
> 
> That makes clear for app developers when they can use this new
> feature.

OK, I will resend with that description.

> 
> That still leads us to what happens at libv4l with sizeimage
> for a compressed format that got uncompressed by the library, in
> order to ensure that a change like this won't cause breakages at
> existing userspace apps.

libv4l can decompress formats like MJPEG, right? I mean it isn't to
decompress MPEG/H264 for example.

-- 
-- 
regards,
Stan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-04-12 15:59 [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients Stanimir Varbanov
  2019-05-02 12:55 ` Mauro Carvalho Chehab
@ 2019-05-14  8:54 ` Hans Verkuil
  2019-05-14 12:19   ` Nicolas Dufresne
  2019-05-16  8:09   ` Stanimir Varbanov
  1 sibling, 2 replies; 12+ messages in thread
From: Hans Verkuil @ 2019-05-14  8:54 UTC (permalink / raw)
  To: Stanimir Varbanov, linux-media
  Cc: Mauro Carvalho Chehab, linux-arm-msm, linux-kernel

Hi Stanimir,

On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
> field description to allow v4l clients to set bigger image size
> in case of variable length compressed data.

I've been reconsidering this change. The sizeimage value in the format
is the minimum size a buffer should have in order to store the data of
an image of the width and height as described in the format.

But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
instead of VIDIOC_REQBUFS to allocate larger buffers.

So do we really need this change?

The more I think about this, the more uncomfortable I become with this change.

Regards,

	Hans

> 
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> index 5688c816e334..005428a8121e 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> @@ -31,7 +31,18 @@ describing all planes of that format.
>  
>      * - __u32
>        - ``sizeimage``
> -      - Maximum size in bytes required for image data in this plane.
> +      - Maximum size in bytes required for image data in this plane,
> +	set by the driver. When the image consists of variable length
> +	compressed data this is the number of bytes required by the
> +	codec to support the worst-case compression scenario.
> +
> +	For uncompressed images the driver will set the value. For
> +	variable length compressed data clients are allowed to set
> +	the sizeimage field, but the driver may ignore it and set the
> +	value itself, or it may modify the provided value based on
> +	alignment requirements or minimum/maximum size requirements.
> +	If the client wants to leave this to the driver, then it should
> +	set sizeimage to 0.
>      * - __u32
>        - ``bytesperline``
>        - Distance in bytes between the leftmost pixels in two adjacent
> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> index 71eebfc6d853..0f7771151db9 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> @@ -89,7 +89,16 @@ Single-planar format structure
>        - Size in bytes of the buffer to hold a complete image, set by the
>  	driver. Usually this is ``bytesperline`` times ``height``. When
>  	the image consists of variable length compressed data this is the
> -	maximum number of bytes required to hold an image.
> +	number of bytes required by the codec to support the worst-case
> +	compression scenario.
> +
> +	For uncompressed images the driver will set the value. For
> +	variable length compressed data clients are allowed to set
> +	the sizeimage field, but the driver may ignore it and set the
> +	value itself, or it may modify the provided value based on
> +	alignment requirements or minimum/maximum size requirements.
> +	If the client wants to leave this to the driver, then it should
> +	set sizeimage to 0.
>      * - __u32
>        - ``colorspace``
>        - Image colorspace, from enum :c:type:`v4l2_colorspace`.
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-14  8:54 ` Hans Verkuil
@ 2019-05-14 12:19   ` Nicolas Dufresne
  2019-05-14 12:23     ` Hans Verkuil
  2019-05-16  8:09   ` Stanimir Varbanov
  1 sibling, 1 reply; 12+ messages in thread
From: Nicolas Dufresne @ 2019-05-14 12:19 UTC (permalink / raw)
  To: Hans Verkuil, Stanimir Varbanov, linux-media
  Cc: Mauro Carvalho Chehab, linux-arm-msm, linux-kernel

Le mardi 14 mai 2019 à 10:54 +0200, Hans Verkuil a écrit :
> Hi Stanimir,
> 
> On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
> > This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
> > field description to allow v4l clients to set bigger image size
> > in case of variable length compressed data.
> 
> I've been reconsidering this change. The sizeimage value in the format
> is the minimum size a buffer should have in order to store the data of
> an image of the width and height as described in the format.

Should this read as the minimum size for the specific (returned by
driver) width/height/bytesperline ?

> 
> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
> instead of VIDIOC_REQBUFS to allocate larger buffers.
> 
> So do we really need this change?
> 
> The more I think about this, the more uncomfortable I become with this change.
> 
> Regards,
> 
> 	Hans
> 
> > Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> > ---
> >  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
> >  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
> >  2 files changed, 22 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> > index 5688c816e334..005428a8121e 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
> > @@ -31,7 +31,18 @@ describing all planes of that format.
> >  
> >      * - __u32
> >        - ``sizeimage``
> > -      - Maximum size in bytes required for image data in this plane.
> > +      - Maximum size in bytes required for image data in this plane,
> > +	set by the driver. When the image consists of variable length
> > +	compressed data this is the number of bytes required by the
> > +	codec to support the worst-case compression scenario.
> > +
> > +	For uncompressed images the driver will set the value. For
> > +	variable length compressed data clients are allowed to set
> > +	the sizeimage field, but the driver may ignore it and set the
> > +	value itself, or it may modify the provided value based on
> > +	alignment requirements or minimum/maximum size requirements.
> > +	If the client wants to leave this to the driver, then it should
> > +	set sizeimage to 0.
> >      * - __u32
> >        - ``bytesperline``
> >        - Distance in bytes between the leftmost pixels in two adjacent
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> > index 71eebfc6d853..0f7771151db9 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
> > @@ -89,7 +89,16 @@ Single-planar format structure
> >        - Size in bytes of the buffer to hold a complete image, set by the
> >  	driver. Usually this is ``bytesperline`` times ``height``. When
> >  	the image consists of variable length compressed data this is the
> > -	maximum number of bytes required to hold an image.
> > +	number of bytes required by the codec to support the worst-case
> > +	compression scenario.
> > +
> > +	For uncompressed images the driver will set the value. For
> > +	variable length compressed data clients are allowed to set
> > +	the sizeimage field, but the driver may ignore it and set the
> > +	value itself, or it may modify the provided value based on
> > +	alignment requirements or minimum/maximum size requirements.
> > +	If the client wants to leave this to the driver, then it should
> > +	set sizeimage to 0.
> >      * - __u32
> >        - ``colorspace``
> >        - Image colorspace, from enum :c:type:`v4l2_colorspace`.
> > 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-14 12:19   ` Nicolas Dufresne
@ 2019-05-14 12:23     ` Hans Verkuil
  0 siblings, 0 replies; 12+ messages in thread
From: Hans Verkuil @ 2019-05-14 12:23 UTC (permalink / raw)
  To: Nicolas Dufresne, Stanimir Varbanov, linux-media
  Cc: Mauro Carvalho Chehab, linux-arm-msm, linux-kernel

On 5/14/19 2:19 PM, Nicolas Dufresne wrote:
> Le mardi 14 mai 2019 à 10:54 +0200, Hans Verkuil a écrit :
>> Hi Stanimir,
>>
>> On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>> field description to allow v4l clients to set bigger image size
>>> in case of variable length compressed data.
>>
>> I've been reconsidering this change. The sizeimage value in the format
>> is the minimum size a buffer should have in order to store the data of
>> an image of the width and height as described in the format.
> 
> Should this read as the minimum size for the specific (returned by
> driver) width/height/bytesperline ?

Yes. Although for compressed formats the bytesperline value plays no role
of course.

Regards,

	Hans

> 
>>
>> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
>> instead of VIDIOC_REQBUFS to allocate larger buffers.
>>
>> So do we really need this change?
>>
>> The more I think about this, the more uncomfortable I become with this change.
>>
>> Regards,
>>
>> 	Hans
>>
>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>> ---
>>>  Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 ++++++++++++-
>>>  Documentation/media/uapi/v4l/pixfmt-v4l2.rst        | 11 ++++++++++-
>>>  2 files changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>> index 5688c816e334..005428a8121e 100644
>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>> @@ -31,7 +31,18 @@ describing all planes of that format.
>>>  
>>>      * - __u32
>>>        - ``sizeimage``
>>> -      - Maximum size in bytes required for image data in this plane.
>>> +      - Maximum size in bytes required for image data in this plane,
>>> +	set by the driver. When the image consists of variable length
>>> +	compressed data this is the number of bytes required by the
>>> +	codec to support the worst-case compression scenario.
>>> +
>>> +	For uncompressed images the driver will set the value. For
>>> +	variable length compressed data clients are allowed to set
>>> +	the sizeimage field, but the driver may ignore it and set the
>>> +	value itself, or it may modify the provided value based on
>>> +	alignment requirements or minimum/maximum size requirements.
>>> +	If the client wants to leave this to the driver, then it should
>>> +	set sizeimage to 0.
>>>      * - __u32
>>>        - ``bytesperline``
>>>        - Distance in bytes between the leftmost pixels in two adjacent
>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>> index 71eebfc6d853..0f7771151db9 100644
>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>> @@ -89,7 +89,16 @@ Single-planar format structure
>>>        - Size in bytes of the buffer to hold a complete image, set by the
>>>  	driver. Usually this is ``bytesperline`` times ``height``. When
>>>  	the image consists of variable length compressed data this is the
>>> -	maximum number of bytes required to hold an image.
>>> +	number of bytes required by the codec to support the worst-case
>>> +	compression scenario.
>>> +
>>> +	For uncompressed images the driver will set the value. For
>>> +	variable length compressed data clients are allowed to set
>>> +	the sizeimage field, but the driver may ignore it and set the
>>> +	value itself, or it may modify the provided value based on
>>> +	alignment requirements or minimum/maximum size requirements.
>>> +	If the client wants to leave this to the driver, then it should
>>> +	set sizeimage to 0.
>>>      * - __u32
>>>        - ``colorspace``
>>>        - Image colorspace, from enum :c:type:`v4l2_colorspace`.
>>>
> 


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-14  8:54 ` Hans Verkuil
  2019-05-14 12:19   ` Nicolas Dufresne
@ 2019-05-16  8:09   ` Stanimir Varbanov
  2019-05-16  9:56     ` Tomasz Figa
  1 sibling, 1 reply; 12+ messages in thread
From: Stanimir Varbanov @ 2019-05-16  8:09 UTC (permalink / raw)
  To: Hans Verkuil, Stanimir Varbanov, linux-media
  Cc: Mauro Carvalho Chehab, linux-arm-msm, linux-kernel, Tomasz Figa

Hi Hans,

On 5/14/19 11:54 AM, Hans Verkuil wrote:
> Hi Stanimir,
> 
> On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>> field description to allow v4l clients to set bigger image size
>> in case of variable length compressed data.
> 
> I've been reconsidering this change. The sizeimage value in the format
> is the minimum size a buffer should have in order to store the data of
> an image of the width and height as described in the format.
> 
> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
> instead of VIDIOC_REQBUFS to allocate larger buffers.

Sometimes CREATEBUFS cannot be implemented for a particular fw/hw.

CC: Tomasz for his opinion.

> 
> So do we really need this change?
> 
> The more I think about this, the more uncomfortable I become with this change.
> 
> Regards,
> 
> 	Hans
> 

<cut>

-- 
regards,
Stan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-16  8:09   ` Stanimir Varbanov
@ 2019-05-16  9:56     ` Tomasz Figa
  2019-05-16 10:40       ` Hans Verkuil
  0 siblings, 1 reply; 12+ messages in thread
From: Tomasz Figa @ 2019-05-16  9:56 UTC (permalink / raw)
  To: Stanimir Varbanov
  Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
	linux-arm-msm, Linux Kernel Mailing List

On Thu, May 16, 2019 at 5:09 PM Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
>
> Hi Hans,
>
> On 5/14/19 11:54 AM, Hans Verkuil wrote:
> > Hi Stanimir,
> >
> > On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
> >> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
> >> field description to allow v4l clients to set bigger image size
> >> in case of variable length compressed data.
> >
> > I've been reconsidering this change. The sizeimage value in the format
> > is the minimum size a buffer should have in order to store the data of
> > an image of the width and height as described in the format.
> >
> > But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
> > instead of VIDIOC_REQBUFS to allocate larger buffers.
>
> Sometimes CREATEBUFS cannot be implemented for a particular fw/hw.
>
> CC: Tomasz for his opinion.
>

Thanks Stanimir.

Actually, if called at the same point in time as REQBUFS, CREATE_BUFS
doesn't really differ to much, except that it gives more flexibility
for allocating the buffers and that shouldn't depend on any specific
features of hardware or firmware.

Actually, one could even allocate any buffers any time regardless of
hardware/firmware support, but the ability to use such buffers would
actually depend on such.

Perhaps we should just let the drivers return -EBUSY from CREATE_BUFS
if called at the wrong time?

> >
> > So do we really need this change?
> >

Yes, because this has worked like this all the time, but it was just
not documented. Disallowing this would break quite a bit of existing
userspace.

Best regards,
Tomasz

> > The more I think about this, the more uncomfortable I become with this change.
> >
> > Regards,
> >
> >       Hans
> >
>
> <cut>
>
> --
> regards,
> Stan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-16  9:56     ` Tomasz Figa
@ 2019-05-16 10:40       ` Hans Verkuil
  2019-05-16 15:09         ` Stanimir Varbanov
  0 siblings, 1 reply; 12+ messages in thread
From: Hans Verkuil @ 2019-05-16 10:40 UTC (permalink / raw)
  To: Tomasz Figa, Stanimir Varbanov
  Cc: Linux Media Mailing List, Mauro Carvalho Chehab, linux-arm-msm,
	Linux Kernel Mailing List

On 5/16/19 11:56 AM, Tomasz Figa wrote:
> On Thu, May 16, 2019 at 5:09 PM Stanimir Varbanov
> <stanimir.varbanov@linaro.org> wrote:
>>
>> Hi Hans,
>>
>> On 5/14/19 11:54 AM, Hans Verkuil wrote:
>>> Hi Stanimir,
>>>
>>> On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
>>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>>> field description to allow v4l clients to set bigger image size
>>>> in case of variable length compressed data.
>>>
>>> I've been reconsidering this change. The sizeimage value in the format
>>> is the minimum size a buffer should have in order to store the data of
>>> an image of the width and height as described in the format.
>>>
>>> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
>>> instead of VIDIOC_REQBUFS to allocate larger buffers.
>>
>> Sometimes CREATEBUFS cannot be implemented for a particular fw/hw.
>>
>> CC: Tomasz for his opinion.
>>
> 
> Thanks Stanimir.
> 
> Actually, if called at the same point in time as REQBUFS, CREATE_BUFS
> doesn't really differ to much, except that it gives more flexibility
> for allocating the buffers and that shouldn't depend on any specific
> features of hardware or firmware.
> 
> Actually, one could even allocate any buffers any time regardless of
> hardware/firmware support, but the ability to use such buffers would
> actually depend on such.
> 
> Perhaps we should just let the drivers return -EBUSY from CREATE_BUFS
> if called at the wrong time?
> 
>>>
>>> So do we really need this change?
>>>
> 
> Yes, because this has worked like this all the time, but it was just
> not documented. Disallowing this would break quite a bit of existing
> userspace.

Which drivers allow this today? I think that would be useful information
for the commit log of a v4 of this patch.

Regards,

	Hans

> 
> Best regards,
> Tomasz
> 
>>> The more I think about this, the more uncomfortable I become with this change.
>>>
>>> Regards,
>>>
>>>       Hans
>>>
>>
>> <cut>
>>
>> --
>> regards,
>> Stan


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
  2019-05-16 10:40       ` Hans Verkuil
@ 2019-05-16 15:09         ` Stanimir Varbanov
  0 siblings, 0 replies; 12+ messages in thread
From: Stanimir Varbanov @ 2019-05-16 15:09 UTC (permalink / raw)
  To: Hans Verkuil, Tomasz Figa, Stanimir Varbanov
  Cc: Linux Media Mailing List, Mauro Carvalho Chehab, linux-arm-msm,
	Linux Kernel Mailing List

Hi Hans,

On 5/16/19 1:40 PM, Hans Verkuil wrote:
> On 5/16/19 11:56 AM, Tomasz Figa wrote:
>> On Thu, May 16, 2019 at 5:09 PM Stanimir Varbanov
>> <stanimir.varbanov@linaro.org> wrote:
>>>
>>> Hi Hans,
>>>
>>> On 5/14/19 11:54 AM, Hans Verkuil wrote:
>>>> Hi Stanimir,
>>>>
>>>> On 4/12/19 5:59 PM, Stanimir Varbanov wrote:
>>>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>>>> field description to allow v4l clients to set bigger image size
>>>>> in case of variable length compressed data.
>>>>
>>>> I've been reconsidering this change. The sizeimage value in the format
>>>> is the minimum size a buffer should have in order to store the data of
>>>> an image of the width and height as described in the format.
>>>>
>>>> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS
>>>> instead of VIDIOC_REQBUFS to allocate larger buffers.
>>>
>>> Sometimes CREATEBUFS cannot be implemented for a particular fw/hw.
>>>
>>> CC: Tomasz for his opinion.
>>>
>>
>> Thanks Stanimir.
>>
>> Actually, if called at the same point in time as REQBUFS, CREATE_BUFS
>> doesn't really differ to much, except that it gives more flexibility
>> for allocating the buffers and that shouldn't depend on any specific
>> features of hardware or firmware.
>>
>> Actually, one could even allocate any buffers any time regardless of
>> hardware/firmware support, but the ability to use such buffers would
>> actually depend on such.
>>
>> Perhaps we should just let the drivers return -EBUSY from CREATE_BUFS
>> if called at the wrong time?
>>
>>>>
>>>> So do we really need this change?
>>>>
>>
>> Yes, because this has worked like this all the time, but it was just
>> not documented. Disallowing this would break quite a bit of existing
>> userspace.
> 
> Which drivers allow this today? I think that would be useful information
> for the commit log of a v4 of this patch.
> 

I'd say s5p-mfc and mtk-vcodec at least.

-- 
regards,
Stan

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-12 15:59 [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients Stanimir Varbanov
2019-05-02 12:55 ` Mauro Carvalho Chehab
2019-05-02 13:16   ` Hans Verkuil
2019-05-02 13:29     ` Mauro Carvalho Chehab
2019-05-07 16:54       ` Stanimir Varbanov
2019-05-14  8:54 ` Hans Verkuil
2019-05-14 12:19   ` Nicolas Dufresne
2019-05-14 12:23     ` Hans Verkuil
2019-05-16  8:09   ` Stanimir Varbanov
2019-05-16  9:56     ` Tomasz Figa
2019-05-16 10:40       ` Hans Verkuil
2019-05-16 15:09         ` Stanimir Varbanov

Linux-Media Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \
		linux-media@vger.kernel.org linux-media@archiver.kernel.org
	public-inbox-index linux-media


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media


AGPL code for this site: git clone https://public-inbox.org/ public-inbox