Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
Regards,
Hans
Hi,
On 08/17/2012 12:35 PM, Hans Verkuil wrote:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
A note on the Pixel Aspect Ratio from me, since I won't be attending:
I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen
Regards,
Hans
On Fri August 17 2012 14:48:23 Hans de Goede wrote:
Hi,
On 08/17/2012 12:35 PM, Hans Verkuil wrote:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
A note on the Pixel Aspect Ratio from me, since I won't be attending:
I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen
Pixel aspect doesn't belong in the FMT ioctls: the pixel aspect ratio is a property of the video input/output format, but the FMT ioctls deal with scaling as well, so the aspect ratio would then be scaled as well, making it very complex indeed.
Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable.
Regards,
Hans
On Friday 17 August 2012 14:55:13 Hans Verkuil wrote:
On Fri August 17 2012 14:48:23 Hans de Goede wrote:
On 08/17/2012 12:35 PM, Hans Verkuil wrote:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
A note on the Pixel Aspect Ratio from me, since I won't be attending:
I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen
Pixel aspect doesn't belong in the FMT ioctls: the pixel aspect ratio is a property of the video input/output format, but the FMT ioctls deal with scaling as well, so the aspect ratio would then be scaled as well, making it very complex indeed.
Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable.
Do we have sensors with non-square pixels ?
Hi,
On 08/17/2012 02:57 PM, Laurent Pinchart wrote:
<Snip>
Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable.
Do we have sensors with non-square pixels ?
Short answer: not that I know of.
Long answer: that depends on the optics (so the sensor pixels may be square, but the optics could make them non-square from a proper mapping to a real world picture pov).
As I've done too much with weird old webcams I actually now webcams which do this, the vicam cameras to be precise. The 3 com HomeConnect (04c1:009) has a sensor with a native resolution of 512x244, yeah widescreen baby!
But it stems from an area where widescreen was unheard of in computer graphics, so it actually has optics which force that cool widescreen resolution back into a 4x3 field of view. So for a proper square pixels image form that camera its image needs to be scaled from 512x244 to 512x384 (*). But with that one exception proving the rule (Dutch expression), I think all sensors have square pixels.
Regards,
Hans
*) Really? Yes really!
Em 17-08-2012 07:35, Hans Verkuil escreveu:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
With regards to "tuner ownership" topic, I think it should be handled on a more generic way. There are several parts of the media devices that could be owned by more than one device type: - tuners; - i2c buses; - DMA engines; - device-internal buses; ...
So, devices that share the same resource for more than one different type of access (radio, analog TV, digital TV, subdev API), should be locking the used resources.
A good news is that the i2c concurrency can now be handled using i2c_lock_adapter() and i2c_unlock_adapter(), but currently, just one driver currently uses it.
In practice, concurrency between radio and analog TV is not the worse problem, as, typically, there are different applications for each.
The concurrency between analog and digital TV is a way more severe, as there are well-used applications (mythtv) that loves to play with both API's and are known to cause several race effects.
Most hybrid devices don't allow neither tune or stream at the same time. Yet, it could be useful to allow tuning into one frequency and check using both DVB and V4L API's, if a frequency is locked and if the signal is either digital or analog, e. g., just like we did with streaming ownership, at V4L2, one file descriptor may have write access and the other ones read access only.
Regards, Mauro
Hi,
On 08/17/2012 04:44 PM, Mauro Carvalho Chehab wrote:
Em 17-08-2012 07:35, Hans Verkuil escreveu:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
With regards to "tuner ownership" topic, I think it should be handled on a more generic way. There are several parts of the media devices that could be owned by more than one device type:
- tuners;
- i2c buses;
- DMA engines;
- device-internal buses;
...
So, devices that share the same resource for more than one different type of access (radio, analog TV, digital TV, subdev API), should be locking the used resources.
Right, the problem the tuner discussion talks about is not as much, how to do the locking, as about *when* to do the locking, which is very much tuner specific. The problem is most apps don't use the priority API, so we need some way to figure out when an app should become the tuner "owner" and lock the tuner on its behalf, so that other apps cannot mess with it breaking the functionality of the first app to become the owner.
Regards,
Hans
Em 17-08-2012 12:29, Hans de Goede escreveu:
Hi,
On 08/17/2012 04:44 PM, Mauro Carvalho Chehab wrote:
Em 17-08-2012 07:35, Hans Verkuil escreveu:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
With regards to "tuner ownership" topic, I think it should be handled on a more generic way. There are several parts of the media devices that could be owned by more than one device type: - tuners; - i2c buses; - DMA engines; - device-internal buses; ...
So, devices that share the same resource for more than one different type of access (radio, analog TV, digital TV, subdev API), should be locking the used resources.
Right, the problem the tuner discussion talks about is not as much, how to do the locking, as about *when* to do the locking, which is very much tuner specific. The problem is most apps don't use the priority API, so we need some way to figure out when an app should become the tuner "owner" and lock the tuner on its behalf, so that other apps cannot mess with it breaking the functionality of the first app to become the owner.
The priority API doesn't lock hybrid access (e. g. an access via DVB API, another via V4L2 API). Not sure if it even lock access between subdev API and V4L2 API.
Regards,
Hans
On Fri August 17 2012 12:35:58 Hans Verkuil wrote:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
One additional topic:
The V4L2 API has a number of experimental API elements, see:
http://hverkuil.home.xs4all.nl/spec/media.html#experimental
The following have been in use for a considerable amount of time I and propose to drop the experimental tag:
Video Output Overlay (OSD) Interface, the section called “Video Output Overlay Interface”.
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY, enum v4l2_buf_type, Table 3.3, “enum v4l2_buf_type”.
V4L2_CAP_VIDEO_OUTPUT_OVERLAY, VIDIOC_QUERYCAP ioctl, Table A.92, “Device Capabilities Flags”.
VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
VIDIOC_G_ENC_INDEX ioctl.
VIDIOC_ENCODER_CMD and VIDIOC_TRY_ENCODER_CMD ioctls.
VIDIOC_DECODER_CMD and VIDIOC_TRY_DECODER_CMD ioctls.
While the (TRY_)DECODER_CMD ioctls are strictly speaking new to V4L2 (appearing in 3.4) they started life as identical ioctls (although with a different name) in dvb/video.h.
Other than being renamed and folded into the V4L2 specification they are quite old as well.
Regards,
Hans
Em 22-08-2012 08:09, Hans Verkuil escreveu:
On Fri August 17 2012 12:35:58 Hans Verkuil wrote:
Hi all,
I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received.
It is available here:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf
Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics.
One additional topic:
The V4L2 API has a number of experimental API elements, see:
http://hverkuil.home.xs4all.nl/spec/media.html#experimental
The following have been in use for a considerable amount of time I and propose to drop the experimental tag:
Video Output Overlay (OSD) Interface, the section called “Video Output Overlay Interface”.
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY, enum v4l2_buf_type, Table 3.3, “enum v4l2_buf_type”.
V4L2_CAP_VIDEO_OUTPUT_OVERLAY, VIDIOC_QUERYCAP ioctl, Table A.92, “Device Capabilities Flags”.
VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
VIDIOC_G_ENC_INDEX ioctl.
VIDIOC_ENCODER_CMD and VIDIOC_TRY_ENCODER_CMD ioctls.
VIDIOC_DECODER_CMD and VIDIOC_TRY_DECODER_CMD ioctls.
While the (TRY_)DECODER_CMD ioctls are strictly speaking new to V4L2 (appearing in 3.4) they started life as identical ioctls (although with a different name) in dvb/video.h.
Other than being renamed and folded into the V4L2 specification they are quite old as well.
I don't think this deserves our time there... we can just ack this at the ML.
From my side:
ACK
Regards, Mauro
-
Hans de Goede -
Hans Verkuil -
Laurent Pinchart -
Mauro Carvalho Chehab