linux-kernel - Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <465BBAFB.30906@free.fr>
Date:	Tue, 29 May 2007 07:32:43 +0200
From:	Thierry Merle <thierry.merle@...e.fr>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
CC:	linux-kernel@...r.kernel.org, video4linux-list@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver



Thierry Merle a écrit :
> Mauro Carvalho Chehab a écrit :
>>>> As Luca pointed, if we add conversion for one driver, we should add 
>>>> for
>>>> the rest.
>>>>
>>>> Instead, it would be better if Jiri sends the decoding and the 
>>>> rescaling
>>>> stuff as a patch to v4l2-apps/lib, starting the API decoding library.
>>>> Once we have a library, we can ask the userspace developers to use it
>>>> for the formats not recognized by their userspace apps.
>>>>
>>>>       
>>> I think it would be better to evaluate existing solutions (eg. libpw).
>>>     
>>
>> Agreed. Volunteers?
>>
>>   
> Hi Mauro and Markus,
> Just to summ up what I understood we need:
>
> What do we need in userspace, only for v4l (dvb is not concerned):
> - colorspace translations
> - filters that be done in hardware if the selected hardware can, 
> otherwise software plugin
> - decompression algorithm like stk11xx or usbvision (the decompression 
> algorithm is in kernelspace since it is of linear complexity but shall 
> be moved to userspace)
>
> Using pwlib will not mean that application developers will use pwlib 
> to decode v4l driver outputs.
> C bindings are much more popular than C++ bindings and do not prevent 
> object oriented design.
> Application developers implement their own codecs.
> As an example, every application do deinterlacing internally or not...
> Application developers will probably not use pwlib v4l extensions 
> because they will prefer to write adapted codecs for their framework.
>
> Much more important for me is to see the actual specification of the 
> needed v4l extensions points, with advice/participation of 
> application/codec developers.
As an example, we could empacket frames with a header containing 
audio/video format as it is done for MPEG streams.
Is it possible without breaking the current ABI?
Do application developers would cope with that?
>
> Thierry
>

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