Re: [RESEND][PATCH 1/2] v4l2: modify the webcam video standard handling

[Hans Verkuil]

> Hi Mauro,
>
> On Monday 31 August 2009 04:41:14 Mauro Carvalho Chehab wrote:
>> Hi Németh,
>>
>> Em Sun, 23 Aug 2009 11:30:42 +0200
>>
>> Németh Márton <nm127@xxxxxxxxxxx> escreveu:
>> > From: Márton Németh <nm127@xxxxxxxxxxx>
>> >
>> > Change the handling of the case when vdev->tvnorms == 0.
>>
>> This patch (together with a few others related to tvnorms and camera
>> drivers) reopens an old discussion: should webcams report a tvnorm?
>>
>> There's no easy answer for it since:
>>
>> 1) removing support for VIDIOC_G_STD/VIDIOC_S_STD causes regressions,
>> since
>> some userspace apps stops working;
>
> Then those applications don't work with the uvcvideo driver in the first
> place. This is getting less and less common :-)
>
>> 2) It is a common scenario to use cameras connected to some capture only
>> devices like several bttv boards used on surveillance systems. Those
>> drivers report STD, since they are used also on TV;
>>
>> 3) There are even some devices that allows cameras to be connected to
>> one
>> input and TV on another input. This is another case were the driver will
>> report a TV std;
>
> TV standards are ill-named, they are actually analog standards.
> VIDIOC_[GS]_STD are perfectly valid for capture devices with analog
> inputs,
> even if they don't use a TV tuner.
>
>> 4) Most webcam formats are based on ITU-T formats designed to be
>> compatible
>> with TV (formats like CIF and like 640x480 - and their
>> multiple/sub-multiples);
>
> Even HD formats still have roots in the analog TV world. It's a real mess.
> Nonetheless, even if the actual frame size is compatible with TV, there is
> simply no concept of PAL/NTSC for webcams.
>
>> 5) There are formats that weren't originated from TV on some digital
>> webcams, so, for those formats, it makes no sense to report an existing
>> std.
>>
>> Once people proposed to create an special format for those cases
>> (V4L2_STD_DIGITAL or something like that), but, after lots of
>> discussions,
>> no changes were done at API nor at the drivers.
>
> TV standards only apply to analog video. Let's simply not use it for
> digital
> video. We don't expect drivers to implement VIDIOC_[GS]_JPEGCOMP with fake
> values when they don't support JPEG compression, so we should not expect
> them
> to implement VIDIOC_[GS]_STD when they don't support analog TV.

Exactly. Work is underway to add an API for HDTV and similar digital video
formats. But we should just freeze the v4l2_std_id API and only use it for
the analog PAL/NTSC/SECAM type formats. This nicely corresponds with the
underlying standards as those have been frozen as well.

Regards,

        Hans

>
>> While we don't have an agreement on this, I don't think we should apply
>> a
>> patch like this.
>
> --
> Regards,
>
> Laurent Pinchart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/