Hi Jiri,
I CC-ed the answer on the ML since there are some information for
comment and action.
Jiri Slaby a écrit :
> Hi.
>
> Wow. I was out for only two days, and so many things had changed. We have ML,
> pages on linuxtv... Good work!
>
>
Yes, Mauro had the good idea to create a separate list in order to
discuss between interested people as it concerns only a specific problem.
> I have been thinking about your idea of preserving the old base driver
> /dev/videoX and yes, it's a better solution, it still lets space for user to
> choose which one he wants to use (more output formats, but slower vs. only
> limited formats but no overhead).
>
>
Well, we will see if my solution is possible. The first difficulty is to
implement the base driver 'lock' operation.
A device is locked when it is opened so we have to call the 'open'
operator of the base driver with the /dev/video0 inode.
I don't know how to do this yet from another driver using the
video_device structure.
The initial code in the repository may be wrong. I just initiated the
files to start with something concrete to patch.
There are many other points to implement: the helper daemon interface,
the helper daemon itself, and the decompression library.
If you look at all the SDs, you will find all messages exchanged with
the helper daemon.
I don't know what is the best implementation for exchanging messages
with the helper daemon: read/write or ioctl?
I know that the data exchange must be mmapped between the driver and the
daemon for performance.
The library shall be put in the v4l-dvb/v4l2-apps/ directory. There is
already a lib that can be used to interface with the v4l2 extended driver.
The helper daemon itself shall be put in v4l-dvb/v4l2-apps/ too. We can
create a daemon/ directory to put the helper daemon code.
>> I am contacting some webcam developers to join and help us to share the
>> ideas and code.
>>
>
> Great. When we have consensus, could I get write access to your repo or do you
> want me to post patchsets or?
>
In fact some developers have already joined by themselves, welcome :)
Patches should be posted on the ML for comment, then I will put them in
my repository as soon as they are approved.
Of course each patch will be signed-off-by the author and put in the
repository as is.
You will find the procedure that details all that in the wiki:
http://www.linuxtv.org/v4lwiki/index.php/How_to_submit_patches
> thanks,
>
Cheers,
Thierry
v4l2-library initiated.
A new v4l2 library is initiated to implement userspace decompression algorithms that cannot fit in kernelspace.
Some multimedia peripherals cannot provide video pictures in a well known format (like YUV, RGB, ...).
They provide compressed video pictures and the algorithm to uncompress them may be complex or may have a proprietary license.
Complex algorithm are forbidden in kernelspace so we need to implement them in userspace.
In a first step, this v4l2 library will provide a way to uncompress video pictures in userspace to ease the applications' labour.
A first solution is specified here: http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary
A first implementation is started here: http://linuxtv.org/hg/~tmerle/v4l2_extension
We invite any concerned driver developer or application developer to suscribe to the specific v4l2-library mailing-list in order to participate to this project.
To suscribe to this ML, go to the v4l2-library mailing-list http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l2-library
Future evolutions of this library could provide other features beyond video decompression, that would require userspace processings.
Let's have fun!
Cheers,
Thierry.