On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Tue, 24 Feb 2009, kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
<big snip>
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905 cameras are not "notebook webcams." They are cheap,
consumer entry level dual-mode cameras. They can be used as hand-held still
cameras, to shoot still photos, and they can also be used as webcams. When
sold, they usually came with some kind of mounting device that could hold
them rigidly for webcam use. There are lots of similar cameras. Mercifully,
not all of those others have the problems of the sq905, which have led to
the present impasse.
If
you think about non-notebook webcams [1] or about security cams, you'll
see that the only way for you to have the flipping information is inside
some userspace file.
However, there are obvious differences. For those cameras the question
might well come up about how to control the movement of the camera, or, at
least, to be aware of which way the camera is pointing. For these, the
topic is an inherent property of the particular model of the camera -- or a
defect, if someone wants to say so. Since the property is not determined by
USB number, it is inherently impossible outside of the module to create a
table which contains the needed information.
My intention here was to re-focus attention on the original problem which
brought up the current discussion, and to that end the problem must be
clearly understood. To have the flipping information inside some userspace
file might solve some other problem and may be a generally very good idea.
But it will not, can not, and never will be able to solve this problem.
For example, I have here one video input bttv board with 16 cameras,
connected on 4 bttv chips. I have also a Pelco camera, that has just one
support socket. Depending on the place you mount it, the camera has to be
rotated by 180 degrees. It can also be useful to mount it rotated by 90
degrees.
Good. So one needs external controls and userspace tools. Did I ever say
that such things should never be done? No. All I said was that there is a
problem, presently on the table, and those kinds of things are not, can not
be, never were, and never will be solutions for _this_ problem.
After mounting the cameras, no matter what apps you are using (a
streaming video app to broadcast it via internet, a security app, etc),
the rotation
information for that input, on that particular PCI, bus won't change.
As we've standardized the VIDIOC_QUERYCAP bus_info, now, the information
for the camera at input 3 of bttv hardware at PCI addres 03:00.3 is
unique. It is also unique the same information for a notebook mounted
webcam (since the USB bus ID won't change for that devices).
Errrm... Again, the cameras in question here are not notebook mounted
webcams.
So, if we standardize where this information is stored, for example, at
/etc/libv4l and/or at ~/.libv4lrc, and let libv4l handle such info, this
will be something consistent for all applications using libv4l. Other
apps that might not want to trust on libv4l can also read the info at the
same file.
Sorry, this will not work here. It may solve some other problem, but not
this problem. Or, if one wants to "store" the information there, I don't
care, really, but then there needs to be a way to get the information from
the module, where it is, and get written into said table, which is where
you want it, and this needs to happen every time an sq905 camera gets
plugged in -- without pestering the user about the matter every time that
such a camera gets hooked up.
Comparison: I have tossed a coin. Is it going to come up heads? Or tails?
It is possible to know which, because the coin has been tossed. It would
not even be cheating to look at it, or allow someone who did look at it, to
pass to us the information. But we are not going to look, and if someone
tells us we will not listen because we have not agreed on what language to
use for communication. Instead, we will put a guess about the outcome into
a table. We will make it a nice table, which can be revised using nice GUI
tools, so it is easy for the user. So if our guess is wrong let the user
fix it. Then next time we toss the coin the table entry will be right
because either it was right before, or now someone fixed it???
So, I really think that this should be part of the approach.
I was not even addressing what should or should not be part of the approach
to some other problems. My point was that such discussion is not germane to
the problem of how to pass on the correct orientation of the sensor, for
the sq905 cameras. There are lots of other problems out there to solve. No
denying that.
Also an overview is often very helpful. Also trying to visualize what might
be needed in the future is helpful. All of this can be extremely helpful.
But not everyone can see or imagine every possible thing. For example, it
seems that some of the best minds in the business are stunned when
confronted with the fact that some manufacturer of cheap electronics in
Taiwan has produced a lot of mass-market cameras with the sensors turned
upside down, along with some other cameras having the same USB ID with
different sensors, which act a bit differently. Clearly, if such a thing
happened once it can happen again. So how to deal with such a
problem? Something similar or worse will surely come up again.
I agree that we should have a way to get a hint about a camera rotation,
if this is somehow provided by reading at the hardware.
[1] Normal webcams can be mounted on some hardware and have some
orientations that would be different than expected. I've seen this before
on some PC-based harware where the camera is enclosed inside the clause,
like on Automatic Transfer Machines. Also, the user may want to use the
camera on an inverted position, to make easy to fix it somewhere.
Again, these are in fact separate issues. The fundamental issue required
for supporting the sq905 cameras is that an agreed-upon method must exist
by which precisely two pieces of information can be passed along by the
module. Which of the two pieces of information is relevant and needs to be
sent along is, alas, only known from within the module. That is the
backdrop for the entire discussion. As far as I know, this thread would not
exist if that need had not come up. These two pieces of information are,
precisely, "frame data requires flipping across a horizontal axis unless
camera is upside down" and "frame data requires flipping across a vertical
axis unless camera is held up to a mirror"
So, what do these two deep questions, which confound the assembled wisdom
of an entire list of Linux video developers, have to do with tables in
userspace? None that I can see, unless someone wants to provide a mechanism
for the information, having been collected in the module, to be available
to the table in userspace.
I'm not saying that userspace tables would solve all problems. I'm just
saying that this should be part of the solution.
I meant what I said. I do not see how that tables in userspace carry any
relevance at all to this particular problem. Perhaps I am dense. Might
tables in userspace help with the solution of some other problems? Well,
yes. But then we are discussing those problems, not this one.
For sure we need to have a way for retrieving this information for devices
like the sq905 cameras, where the information can't be currently be
determined by userspace.
Yes, indeed. Except for just one word, "currently." It does not fit here.
The matter is not one of present inability, just because we are not clever
enough. The logic of the situation is inexorable. Well, in part I take
that back. If the operating system were fundamentally redesigned, making
it possible to run a video device completely in userspace, then and only
then the needed information could be determined by userspace. But I do not
expect that will happen very soon.
In the case of sq905, this information is static, right?
Yes. Exactly. You get the data the way it came out. That's it. No choices
about that are possible. Precisely how the data came out depends only on
the camera. An inquiry to the camera before streaming is started can
provide the relevant information.
If so, IMO, the
better approach is to use a flag at the v4l2_input, as already discussed in
this thread.
OK.
Theodore Kilgore
--
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
