good statement, the absolute goal should be that enduser applications can
handle videostreams as easy as possible. This is currently not given.
For example I have devices which work with ekiga, and some devices
which don't work with ekiga.
Why so? Ekiga already uses a rather big library for handling videodevices.
Another point is why doesn't tvtime support digital audio?
People have to run sox in the background to get any sound piped from
the corresponding dsp node to the soundcard, and also this is no general
way. So first people have to look up what the correct audio node of their
TV device is... (there are small scripts available which lets the users select)
But I also think this should happen automatically.
There are many devices out there which don't even include all ioctl calls
which are documented in the specs.
And since sometimes the API needs to be updated a library could handle this
in a better way.
I see the whole v4l-dvb project as half way done at the moment because of
the unflexibility of the whole system.
this is just a thought, I think a pluggable mechanism would be nice for that.
The library could query the device about it's capabilities and if it returns a
non standard videoformat just add a mechanism for loading the corresponding
videocodec if available.
yes, this would always be the optimal way
yes I also agree with that.
I would prefer to abstract the ioctl calls from the media applications
if possible.
Sometimes API changes are unavoidable and even make sense instead of
carrying around old crufted mechanisms, and since there's currently not a
single TV application out there which supports all available devices it would
make more sense to work on a better infrastructure for all that.
yes there are many ways. I like the idea of such a library because it could
even allow to integrate complete userspace drivers in certain cases.
I posted a link within that thread that there's a driver which intercepts all
ioctl calls and which is completly done in userspace. By using a library
the LD_PRELOAD hack wouldn't even be needed and that device could be
integrated flawlessly into a video infrastructure.
I know that such a userspace driver would be slower than the inkernel driver
although I think it's up to the developer what he wants to do.
ndiswrapper is quite different, I still nativly compile the code on Linux and
even the sources are available.
I just tried to integrate a newer kind of module, as for me I don't want to
rewrite the algorithms of drivers which I'm able to reuse in userspace,
the example which I have here right now even uses C++ in userspace
and all I do is to use the API of these sample sources and package everything
into such a userspace library which can directly be used by the driver.
It's not my job to reinvent the work of companies (and I'm not even
interested in that) if they agree with delivering code which can be easily
integrated, as for me it's reaching the goal by the shortest path first
approach.
Although there are 2 projects going on at the moment, my one is capable
of pushing some drivers to userspace, the other one is still in progress and
I don't know when it will be finished (since I don't even work on that)
During that time the driver will internally depend on the kernel to userspace
bridge; As soon as the userspace drivers can be plugged to the media library
infront of the devicenodes I intend to remove the kernel-userspace stub..
but this might take a while if not several months.
Markus
-
