VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Andre Draszik]

Hi,

As per the spec, the above ioctl codes are defined for inputs only -
it would be useful if there were similar codes for outputs.

I therefore propose to add the following:

VIDIOC_G_OUTPUT_STD
VIDIOC_S_OUTPUT_STD
VIDIOC_ENUM_OUTPUT_STD

which would behave similar to the above, but for output devices.

Thoughts?


Cheers,
Andre'

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Andy Walls]

On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
> Hi,
> 
> As per the spec, the above ioctl codes are defined for inputs only -
> it would be useful if there were similar codes for outputs.
> 
> I therefore propose to add the following:
> 
> VIDIOC_G_OUTPUT_STD
> VIDIOC_S_OUTPUT_STD
> VIDIOC_ENUM_OUTPUT_STD
> 
> which would behave similar to the above, but for output devices.
> 
> Thoughts?

Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD.

>From what I see:

ivtv/ioctl.c
zoran/zoran_driver.c
davinci/vpif_display.c

all use VIDIOC_S_STD for setting the output standard.

Note that the v4l2_subdev video_ops have a "s_std_output" method which
is what you can grep for in the code to verify for yourself.


Some thoughts:

1. to me it appears that the ivtv driver looks like it ties the output
standard to the input standard currently (probably due to some firmware
limitation).  This need not be the case in general.

2. currently the ivtv driver uses sepearte device nodes for input device
and an output device.  If bridge drivers maintain that paradigm, then
separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.

3. ENUMSTD is currently handled by the v4l2 core in v4l2-ioctl.c with no
hook for bridge drivers.  The bridge drivers were all getting it wrong
in some way or another for enumerating stanadrds on the input.

4. What's the harm in letting S_STD fail for an unsupported standard on
an output?  An application usually doesn't have much choice but to fail,
if the hardware doesn't support the user's desired standard.
ENUMSTD_OUTPUT for outputs seems superfulous.  If you had an
ENUM_STD_OUTPUT ioctl() to call, an application will either find the
desired standard in the list and know S_STD should succeed, or it won't
an will assume S_STD will fail.  From an application writing
perspective, it seems like less work for the application to just detect
when S_STD fails.


Regards,
Andy

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Ian Armstrong]

On Saturday 22 May 2010, Andy Walls wrote:
> On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
> > Hi,
> > 
> > As per the spec, the above ioctl codes are defined for inputs only -
> > it would be useful if there were similar codes for outputs.
> > 
> > I therefore propose to add the following:
> > 
> > VIDIOC_G_OUTPUT_STD
> > VIDIOC_S_OUTPUT_STD
> > VIDIOC_ENUM_OUTPUT_STD
> > 
> > which would behave similar to the above, but for output devices.
> > 
> > Thoughts?
> 
> Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD.
> 
> >From what I see:
> ivtv/ioctl.c
> zoran/zoran_driver.c
> davinci/vpif_display.c
> 
> all use VIDIOC_S_STD for setting the output standard.
> 
> Note that the v4l2_subdev video_ops have a "s_std_output" method which
> is what you can grep for in the code to verify for yourself.
> 
> 
> Some thoughts:
> 
> 1. to me it appears that the ivtv driver looks like it ties the output
> standard to the input standard currently (probably due to some firmware
> limitation).  This need not be the case in general.

The ivtv limitation is the driver and not the firmware. The firmware itself 
seems quite happy with mixed standards & in some cases will automatically 
switch the output standard itself (resulting in a standards mismatch between 
the cx23415 & saa7127, breaking output). For the previous 2 months I've been 
running a patched version of the ivtv driver that separates the input & output 
format with no noticeable issues.

> 2. currently the ivtv driver uses sepearte device nodes for input device
> and an output device.  If bridge drivers maintain that paradigm, then
> separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.

This is how my patched version works, talk to an input device for the input & 
an output device for the output. However, from my reading of the specs I do 
get the impression this is not the 'correct' way to do this and it should 
really be a separate ioctl. I don't know what other cards, if any, support 
mixed input & output standards or how they handle it.

-- 
Ian

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Hans Verkuil]

On Saturday 22 May 2010 19:21:32 Ian Armstrong wrote:
> On Saturday 22 May 2010, Andy Walls wrote:
> > On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
> > > Hi,
> > > 
> > > As per the spec, the above ioctl codes are defined for inputs only -
> > > it would be useful if there were similar codes for outputs.
> > > 
> > > I therefore propose to add the following:
> > > 
> > > VIDIOC_G_OUTPUT_STD
> > > VIDIOC_S_OUTPUT_STD
> > > VIDIOC_ENUM_OUTPUT_STD
> > > 
> > > which would behave similar to the above, but for output devices.
> > > 
> > > Thoughts?
> > 
> > Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD.
> > 
> > >From what I see:
> > ivtv/ioctl.c
> > zoran/zoran_driver.c
> > davinci/vpif_display.c
> > 
> > all use VIDIOC_S_STD for setting the output standard.
> > 
> > Note that the v4l2_subdev video_ops have a "s_std_output" method which
> > is what you can grep for in the code to verify for yourself.
> > 
> > 
> > Some thoughts:
> > 
> > 1. to me it appears that the ivtv driver looks like it ties the output
> > standard to the input standard currently (probably due to some firmware
> > limitation).  This need not be the case in general.
> 
> The ivtv limitation is the driver and not the firmware.

Correct.

> The firmware itself 
> seems quite happy with mixed standards & in some cases will automatically 
> switch the output standard itself (resulting in a standards mismatch between 
> the cx23415 & saa7127, breaking output). For the previous 2 months I've been 
> running a patched version of the ivtv driver that separates the input & output 
> format with no noticeable issues.
> 
> > 2. currently the ivtv driver uses sepearte device nodes for input device
> > and an output device.  If bridge drivers maintain that paradigm, then
> > separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.
> 
> This is how my patched version works, talk to an input device for the input & 
> an output device for the output. However, from my reading of the specs I do 
> get the impression this is not the 'correct' way to do this and it should 
> really be a separate ioctl. I don't know what other cards, if any, support 
> mixed input & output standards or how they handle it.

I have considered implementing these output ioctls as well and as mentioned
s_std_output is actually implemented on the subdev level (it was really needed
there).

The reason it was never done for bridge drivers is twofold:

1) No one ever needed it. Why would you want to select one format for input
and another for output? Other than debugging this never happens for the sort
of drivers we have now. So selecting e.g. PAL and have it change both input
and output is actually what most people expect.

2) Do we really need to make new ioctls? Here it becomes hairy. According to
the V4L2 spec changing the std for one video device should change it for all
others as well. So if we follow that spec, then we should indeed introduce
new ioctls. But in practice all driver have separate device nodes for capture
and output. So perhaps we should change the spec and specify that it will
only change the std for those device nodes that are linked to the same input
or output.

This bring me to another related issue with the spec: strictly speaking the
spec allows you to capture VBI data from /dev/videoX or video data from
/dev/vbiX. But very few if any drivers actually support this. I personally
think this requirement makes no sense and should be dropped.

Anyway, the bottom line is that I would prefer to bring the spec in line
with what happens in practice. Then there is no need to add new ioctls.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Andre Draszik]

Hi,

On Sun, May 23, 2010 at 12:20 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Saturday 22 May 2010 19:21:32 Ian Armstrong wrote:
>> On Saturday 22 May 2010, Andy Walls wrote:
>> > On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
>> > Some thoughts:
>> >
>> > 1. to me it appears that the ivtv driver looks like it ties the output
>> > standard to the input standard currently (probably due to some firmware
>> > limitation).  This need not be the case in general.

That's what I think, why should the API enforce input and output
standard to be the same? An application or user might decide to do so,
if they want to, but it seems like a strange limitation.

>> The ivtv limitation is the driver and not the firmware.
>
> Correct.

So, why limit the API because of one driver's limitations?

>> > 2. currently the ivtv driver uses sepearte device nodes for input device
>> > and an output device.  If bridge drivers maintain that paradigm, then
>> > separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.

Here http://www.stlinux.com/download/updates.php?r=2.3;u=stlinux23-host-stmfb-source-3.1_stm23_0031-1.src.rpm
we don't use separate nodes for input and output.

>> This is how my patched version works, talk to an input device for the input &
>> an output device for the output. However, from my reading of the specs I do
>> get the impression this is not the 'correct' way to do this and it should
>> really be a separate ioctl. I don't know what other cards, if any, support
>> mixed input & output standards or how they handle it.

That's what I'm saying :-) And it works perfectly (the API is great!
:-) except for this minor issue.

> The reason it was never done for bridge drivers is twofold:
>
> 1) No one ever needed it. Why would you want to select one format for input
> and another for output?

Why not? Capturing in one mode and outputting in a different is not
uncommon, at least in embedded (STB) environments. Think e.g. of an
AV-Receiver and such things.

> Other than debugging this never happens for the sort
> of drivers we have now.

Yes, you have a point here that above mentioned driver is not part of
the linux tree, but still it seems like an issue that could easily be
solved. And others might profit, too - surely more hardware exists
that can handle input != output.

> So selecting e.g. PAL and have it change both input
> and output is actually what most people expect.

What if your source can not output PAL and your sink only accepts PAL?
Most people would expect that to work anyway.

> 2) Do we really need to make new ioctls? Here it becomes hairy. According to

At the moment there is no requirement in the spec to say that input
and output devices must have a separate node, and all remaining
(existing) ioctls are perfectly suited for having a single device
node.
Not having separate output controls would implicitly create such a
requirement, though.


Cheers,
Andre'

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Ian Armstrong]

On Sunday 23 May 2010, Hans Verkuil wrote:
> On Saturday 22 May 2010 19:21:32 Ian Armstrong wrote:
> > On Saturday 22 May 2010, Andy Walls wrote:

> > > Some thoughts:
> > > 
> > > 1. to me it appears that the ivtv driver looks like it ties the output
> > > standard to the input standard currently (probably due to some firmware
> > > limitation).  This need not be the case in general.
> > 
> > The ivtv limitation is the driver and not the firmware.
> 
> Correct.
> 
> > The firmware itself
> > seems quite happy with mixed standards & in some cases will automatically
> > switch the output standard itself (resulting in a standards mismatch
> > between the cx23415 & saa7127, breaking output). For the previous 2
> > months I've been running a patched version of the ivtv driver that
> > separates the input & output format with no noticeable issues.
> > 
> > > 2. currently the ivtv driver uses sepearte device nodes for input
> > > device and an output device.  If bridge drivers maintain that
> > > paradigm, then separate ioctl()s for S_STD, G_STD, and ENUMSTD are
> > > likely not needed.
> > 
> > This is how my patched version works, talk to an input device for the
> > input & an output device for the output. However, from my reading of the
> > specs I do get the impression this is not the 'correct' way to do this
> > and it should really be a separate ioctl. I don't know what other cards,
> > if any, support mixed input & output standards or how they handle it.
> 
> I have considered implementing these output ioctls as well and as mentioned
> s_std_output is actually implemented on the subdev level (it was really
> needed there).
> 
> The reason it was never done for bridge drivers is twofold:
> 
> 1) No one ever needed it. Why would you want to select one format for input
> and another for output? Other than debugging this never happens for the
> sort of drivers we have now. So selecting e.g. PAL and have it change both
> input and output is actually what most people expect.

There's no denying that mixed standards is unusual, but is it a case of nobody 
ever wanted it, or did they just assume the hardware wasn't capable of it. The 
only reason I ever created a patch to support mixed standards in the ivtv 
driver is because it was a feature which I wanted to use.

In my case all captures are PAL, but I view a lot of NTSC material. I find 
that interlaced video looks best when displayed in its native format so I use 
a script to identify & change the output to match. Mixed standards allow 
MythTV to record a show in PAL while I'm watching an NTSC video on an NTSC  
output.

Another instance when mixed formats would be useful is when capturing a video 
which doesn't match your regions standard. If I'm trying to capture an NTSC 
video, it doesn't mean I want the output mode changed from my native PAL. Just 
because the card can output NTSC doesn't mean the display can handle it.

> 2) Do we really need to make new ioctls? Here it becomes hairy. According
> to the V4L2 spec changing the std for one video device should change it
> for all others as well. So if we follow that spec, then we should indeed
> introduce new ioctls. But in practice all driver have separate device
> nodes for capture and output. So perhaps we should change the spec and
> specify that it will only change the std for those device nodes that are
> linked to the same input or output.

I doubt it's really used outside of v4l2-ctl, but the ivtv driver allows 
output configuration to be changed via the capture device. In this instance a 
new ioctl would avoid a situation where the output can only be partially 
configured through the capture device. In reality I doubt any application 
actually configures the output via the capture device, but to reuse the ioctl 
& link it to a specific device node would create an inconsistency.

-- 
Ian

VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Andre Draszik]

Hi,

As per the spec, the above ioctl codes are defined for inputs only -
it would be useful if there were similar codes for outputs.

I therefore propose to add the following:

VIDIOC_G_OUTPUT_STD
VIDIOC_S_OUTPUT_STD
VIDIOC_ENUM_OUTPUT_STD

which would behave similar to the above, but for output devices.

Thoughts?


Cheers,
Andre'

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list