headers
Brian J. Murrell | 22 Mar 2002 00:43
Picon

Re: [V4L] Re: fbtv from an xterm

On Thu, Mar 21, 2002 at 11:03:48PM +0000, Gerd Knorr wrote:
> 
> fbtv expects the tty being really a linux console and this is needed for
> console switch handling (i.e. turn off the video if you switch to
> another vt, ...).

Understood, and a great feature if the console is interactive.  But
this is a "set-top" type of box.  No monitor (other than the TV) and
no keyboard.  Could a switch be added to support a "not-using-console"
mode?

Maybe I will take a look into this when I find a moment.

> Why don't you setup X11 multiheaded and run xawtv on the second screen?

Yuck.  I am trying to avoid X.  First of all, there is no way to get
BES enabled TV-Out on the G400 with X and I really don't want the
overhead of an X server.

> I'd expect that works better.

Yes, even fbtv wants to be able to call v4l-conf which wants access to
the X server.

b.

--

-- 
Brian J. Murrell
Permalink | Reply | 1 comment |
headers
Mark McClelland | 22 Mar 2002 00:59
Picon

Re: [V4L] editing?

Billy Biggs wrote:

>   I think you're right though.  Instead of doing a libv4l that nobody
>would use, we should work on having lots of libs with inconsistent
>interfaces, but at least the code would be shared.
>

How about a minimal libv4l with a consistent interface for the other 
libraries to "plug in" to? That way, libv4l would provide a standard 
mechanism without enforcing the "policy" of a particular deinterlacer, 
scaler, etc...

--

-- 
Mark McClelland
mmcclell <at> bigfoot.com

_______________________________________________
Video4linux-list mailing list
Video4linux-list <at> redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 6 comments |
headers
Wan Tat Chee | 22 Mar 2002 02:02
Picon
Gravatar

Re: [V4L] Flyvideo 3000

Gunther,

Gerd's saa7134-0.1.5 (the March 11 snapshot) doesn't change the way
that FlyVideo3000 works. The main differences are with the FlyVideo 2000
support, as all my audio input comes via LINE2 of the SAA7130.

It looks like you have a similar TV Tuner block to mine (except for the
FM Radio). How did you manage to get it to work with the existing
definition for FV3K? Did you modprobe the tuner type manually?

Do you have external audio in (and muting/unmuting) working?

T.C.

On Thu, 21 Mar 2002, Gunther Mayer wrote:

> Date: Thu, 21 Mar 2002 17:51:51 +0100
> From: Gunther Mayer <Gunther.Mayer <at> t-online.de>
> To: video4linux-list <at> redhat.com
> Cc: Wan Tat Chee <tcwan <at> cs.usm.my>
> Subject: Re: [V4L] Flyvideo 3000
>
> Robert Reid wrote:
> >
> > TC and all,
> >
> > On Thu, 21 Mar 2002, Wan Tat Chee wrote:
> ...
> >
> > My 3K doesn't have FM Radio as an option either so I haven't tested the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joe Burks | 22 Mar 2002 02:09

Re: [V4L] editing?

On Thursday 21 March 2002 09:03 am, Downes, David wrote:
> I've been following the discussion with interest and if I've understood the
> various posts correctly the problem is that some applications don't do
> gamma correction etc which is required by some users.  As far I understand,
> it is the case that all kernel drivers should ideally be as minimal as
> possible while providing a suitable standardised cross device interface
> and, possibly non-standard access to unique hardware capabilities
> (definitely a difficult compromise :-)  One solution is to provide a common
> library for applications to use in user space to provide the requested
> video manipulations i.e. make the library easy to incorporate and hope most
> applications make use of it.

Here's the arguments that I think are getting lost in the discussion:

1) A "correct" v4l application is supposed to be able to decode 18 different 
color space encodings.  I know of no v4l app that is "correct".  A library 
which can convert all 18 color spaces to one (RGB) or two (RGB, YUV) formats 
would be of value.

2) There are some adjustments that a driver writer knows needs to be done 
with images from their device in order to get a good image, but cannot do it 
in kernel space and have no way of communicating this information to an 
application.

I keep using gamma for #2 because that is something that cannot be done in 
the general case in the kernel without resorting assembly language because 
there is no available pow() function.  (maybe I'm a lightweight because I 
don't know how to do a simple integer math polynomial approximation of X^Y)

> Is a possible solution to in effect use a V4L dummy driver, which redirects
(Continue reading)

Permalink | Reply | 16 comments |
headers
Alan Cox | 22 Mar 2002 02:24
Picon
Favicon

Re: [V4L] editing?

> This is exactly what I've been saying I think we need.  A user space 
> component to the driver that can manipulate the image until it is good 
> without the application software needing to be changed.

(In fact for some drivers like certain USB cams once you have the user
library structure there might be no point in having a kernel mode part at
all)

> grained controls (which I've never suggested doing away with), most will find 
> the interface more difficult to use than its counterpart in other OS's.  Some 
> tweaking of those finer grained controls has to happen to make the image good.

The windows world does it in user space on the whole. It often tends to
ask the driver "do this feature" and if the driver says "no" then it falls
back to library code.

Incidentally another example of why you don't want gamma in kernel space is
that you sometimes want to be careful the order you do filtering/gamma/scaling

_______________________________________________
Video4linux-list mailing list
Video4linux-list <at> redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 15 comments |
headers
Joe Burks | 22 Mar 2002 02:58

Re: [V4L] editing?

On Thursday 21 March 2002 05:24 pm, Alan Cox wrote:
> (In fact for some drivers like certain USB cams once you have the user
> library structure there might be no point in having a kernel mode part at
> all)

Mmmmm..... (dreaming of day of user space v4l drivers)

> The windows world does it in user space on the whole. It often tends to
> ask the driver "do this feature" and if the driver says "no" then it falls
> back to library code.
>
> Incidentally another example of why you don't want gamma in kernel space is
> that you sometimes want to be careful the order you do
> filtering/gamma/scaling

Absolutely.  But I agree with you that I don't want to do gamma in kernel 
space at all.  I will stand on my soap box and scream to the crowd that 
kernel drivers should be as light weight as possible.

However every time I add something I don't want to do in the kernel to the 
kernel driver, the users of the driver email me congratulatory notes on how 
much better the driver now works with v4l apps.  The current request is for a 
YUV420 color space conversion because apparently gnomemeeting doesn't work 
with RGB24.  I don't want to add that, but I know the end user will be 
happier with the driver if I do, and the time it will take me to put in a 
color space conversion in the driver is likely a small fraction of what it 
will take to get the change into gnomemeeting.

_______________________________________________
Video4linux-list mailing list
(Continue reading)

Permalink | Reply | 14 comments |
headers
Mark McClelland | 22 Mar 2002 04:04
Picon

Re: [V4L] editing?

Joe Burks wrote:

>The current request is for a 
>YUV420 color space conversion because apparently gnomemeeting doesn't work 
>with RGB24.  I don't want to add that, but I know the end user will be 
>happier with the driver if I do, and the time it will take me to put in a 
>color space conversion in the driver is likely a small fraction of what it 
>will take to get the change into gnomemeeting.
>

The time it would take to add that to gnomemeeting would be time well 
spent. There are quite a few cameras that only output RGB (ibmcam and 
se401, to name a couple). The majority of the time would be spent 
writing the conversion function, and that has to be written in either 
case. In fact, ibmcam.h has a YUV->RGB macro that you could probably use.

Also, don't forget about the time you will have to spend dealing with 
angry users after Alan removes the conversion function from your driver ;-)

See this page if you don't believe that will happen: 
http://www.smcc.demon.nl/webcam/driver-reject.html

--

-- 
Mark McClelland
mmcclell <at> bigfoot.com

_______________________________________________
Video4linux-list mailing list
Video4linux-list <at> redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list
(Continue reading)

Permalink | Reply | 13 comments |
headers
Alan Cox | 22 Mar 2002 04:16
Picon
Favicon

Re: [V4L] editing?

> >color space conversion in the driver is likely a small fraction of what it 
> >will take to get the change into gnomemeeting.
> 
> The time it would take to add that to gnomemeeting would be time well 
> spent. There are quite a few cameras that only output RGB (ibmcam and 

I know the gnome meeting guys - they are really responsive and cool
folks. 

_______________________________________________
Video4linux-list mailing list
Video4linux-list <at> redhat.com
https://listman.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
Joe Burks | 22 Mar 2002 05:48

Re: [V4L] editing?

On Thursday 21 March 2002 07:04 pm, Mark McClelland wrote:
> Joe Burks wrote:
> The time it would take to add that to gnomemeeting would be time well
> spent.
> There are quite a few cameras that only output RGB (ibmcam and
> se401, to name a couple). The majority of the time would be spent
> writing the conversion function, and that has to be written in either
> case. In fact, ibmcam.h has a YUV->RGB macro that you could probably use.

I don't think the majority of time would be spent writing the conversion 
function.  I bet I could google for a RGB->YUV or YUV->RGB algorithm and have 
the result converted to code, tested and debugged within an hour.  I think 
the majority of my time would be finding where gnomemeeting does its v4l, and 
figuring out how to change it to support RGB without affecting YUV.

I have no doubt this would be time well spent.  It would benefit people well 
beyond the scope of my little v4l driver.  I also think there are about 100 
projects which could benefit from me investing some time coding for them.  
Unfortunately my days are limited to 24 hours.

The kernel developers are shouting "Keep It Simple Stupid" and keeping the 
kernel drivers as simple as possible.  The application developers are 
shouting "Keep It Simple Stupid" and making the applications as simple as 
possible.

If somebody isn't doing the non-simple stuff, the result is a user experience 
that sucks.  And that's what we have.

That is why I'm lobbying for a user space (middle tier, if you will) driver 
component that will keep the kernel space portion of the driver simple and
(Continue reading)

Permalink | Reply | 11 comments |
headers
Billy Biggs | 22 Mar 2002 07:16

Re: [V4L] editing?

Joe Burks (joe-v4l <at> wavicle.org):

> I don't think the majority of time would be spent writing the
> conversion function.  I bet I could google for a RGB->YUV or YUV->RGB
> algorithm and have the result converted to code, tested and debugged
> within an hour.

  The problem with this argument is that the resulting code will likely
be subtly wrong.  Remember:

  1. Conversion from Y'CbCr->R'G'B' is very lossy
  2. The conversion code is much more complex if you care about quality
  3. There are about a million variants of YUV colorspaces and the V4L
     API isn't sufficient to correctly describe them :)

  So one would imagine that all the webcam apps would do the long, slow,
but accurate conversion code, probably using some expensive processing
filters, and that the playback applications would, where necessary, do
the fast but very inaccurate mmx transforms you see in the DVD apps.

  You'd also expect that eventually the webcam apps would be sharing so
much code with all these expensive filters that eventually they'd do a
library.  Maybe they're all waiting for someone to write this code for
them?  Is that what you're saying?

> That is why I'm lobbying for a user space (middle tier, if you will)
> driver component that will keep the kernel space portion of the driver
> simple and make the kernel hackers happy, make the application side
> simple so they're happy, and make the user experience good.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane