Alberto> My questions are :
Alberto> 1) SANE is not planned to have mapped access of devices in
Alberto> the filing system. Everything is accessed from functions,
Alberto> like networking in Linux, not via devices mapped in the
Alberto> filing system, like sound. Am I wrong ? Is mapped access
Alberto> planned for the future ?
There are no immediate plans for adding mapped access to the SANE API.
Is there a particular application you have in mind that you're asking?
Alberto> 2) What SANE wants to be ?
SANE is meant to support any (raster) image acquisition device,
including video cameras and/or frame grabbers. Apart from the qcam
backend, there are no drivers for video devices, however. So, in
terms of implementation, the focus certainly has been on scanners.
But if somebody were to come along to do some nifty video-related
work, it would be all for the better.
Alberto> I'm reading the SANE code. As far as I've understood links
Alberto> to remote resources are made via TCP to provide images
Alberto> without any error. Animations from Quickcams are sequences
Alberto> of images one after the other. This is perfect for scanned
Alberto> images (= TWAIN)
Alberto> If you want to develope something bigger, I mean SANE =
Alberto> TWAIN + VIDEO, things must be different.
Alberto> The technology you use now is perfect for scanners and
Alberto> LOCAL streaming video or over an UNUSED network due to with
Alberto> bandwidth.
Alberto> If we want to make SANE the standard also for moving images
Alberto> (Quickcams via USB and Digital Video via FireWire are
Alberto> coming !) and video-conferences, I suggest to use also UDP
Alberto> (frames lost are not so important in video conferences, you
Alberto> must adapt to avaible bandwidth).
It is useful to distinguish the SANE API from the code that you get
with the sane distribution. Just because the current net backend uses
TCP for transmitting the image data doesn't mean that you can't write
a backend that were to use UDP, for example. Indeed, the SANE API
documentation is very clear that there is nothing that forces the use
of TCP.
Actually, it would be quite easy to adapt the current net backend to
optionally transmit image data via a non-reliably protocol such as
UDP. E.g., the backend could supply its own option that would let the
user select between a reliable and unreliable transport protocol.
This certainly would be a useful feature.
Alberto> Every video source should provide data in three formats :
Alberto> 1) Best quality=zero compression, for local playback,
Alberto> recording or video editing.
Alberto> 2) Good quality=small compression, for playing across fast
Alberto> networks like ethernets.
Alberto> 3) Minimal quality=big compression, for playing across slow
Alberto> lines like analogical or 64K ISDN lines.
Neither SANE nor the SANE network protocol currently support
compressed image data. It's something that is planned for the next
major revision of the SANE API, however (see file LEVEL2 in the SANE
distribution).
Alberto> Do you think SANE should be split in two different projects
Alberto> ? One for sanners and one for Quickcams ?
I don't think that would be advantageous at this point. SANE
certainly isn't yet perfect for video (neither is it for scanners, for
that matter ;-), but I don't believe that there are any unsurmountable
hurdles that would prevent it from becoming so---it's more a matter of
someone finding the time to make the necessary extensions/changes.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com