[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-video
Subject:    Re: [video4linux] Alex: channels
From:       alexb () jetsuite ! com (Alex Bakaev)
Date:       1998-07-28 18:31:01
[Download RAW message or body]

Bill,
my comments are inline

Bill Dirks wrote:
> 
[snip]
> 
> I agree in principle, but we have to live in an environment with certain
> constraints, and we'd like to expose the functionality in a way that
> mimics familiar paradigms.
> 

Well, I may not understant/know all constraints yet. And that may be a
good thing, because I'm looking at this from the video capture
driver/user perspective, not from perspective of what OS lets/doesn't
let you do. Maybe as a result of this some constraints can be changed ?

> > I think it is useful to introduce a notion of a video/data channel.
> > After the device is open, separate ioctl is issued to open a channel. A
> > channel can be designated for streaming capture or for overlay.
> 
> What about ordinary read() calls? This is the basic functionality. IMHO,
> anything that claims to be a video capture card should support this. The
> other modes are just icing (important for some applications, but not the
> *basic* functionality).
> 

Well, does it make sense to treat a video capture device as a file ? One
doesn't need to issue a bunch of ioctls before using read(), but in case
of video capture you have to. So maybe it's a good idea to go all the
way to ioctls ? Other approach is to implicitly tie read() with one of
the video channels. Devices that doen't support separate fields have
only one video channel.

> > At least 2 more channels are defined for the VBI data, but it may be
> > practical to combine them into one cahnnel.
> 
> The original spec mentioned something about VBI. I didn't look it up,
> and it's beyond the scope of what I attempted to address.
> 

That's a beauty of my proposition - VBI is just another data channel,
with the same rules as video capture. Same structures, same ioctls, just
color format is different.

> > It's logical to assume that each video channel is assigned to a specific
> > video field. But it's possible that field assignments may change. I.E.
> > when capturing a CIF and below, single field is used. When larger image
> > is used, a channel may need to grab the other field, thus making other
> > channel unavailable. Note, that this change can occur only in
> > non-running mode.
> 
> One of my favorite tricks in the Winnov VfW drivers was electronic zoom.
> Capture cards (most of them, I guess, the Winnov was) are programmable
> enough that you can capture just about any sub-rectangle out of the
> frame. Imagine you're capturing 240x180 from NTSC (source is 640x480
> before shrinking). You're capturing from a single field and your source
> rectangle covers the whole field, and you're shrinking the 240 lines to
> 180. As you zoom in you reduce the source rectangle until you are
> capturing 180 consecutive lines and not shrinking (vertically) at all.
> But the user keeps pushing the zoom knob. To zoom in further you switch
> to interlaced capture and now you're capturing a subrectangle out of the
> whole 480 line interlaced image; 90 lines from each field. You keep in
> zooming in, the source rectangle keeps decreasing, until you're
> capturing 90 consecutive lines from each field. The user zooms in and
> out, the driver switching between interlaced and non-interlaced capture,
> it's seamless. It works while you're streaming. (If it was already
> interlaced when unzoomed, of course, no switching occurs.)
> 

O.K. The restriction about non-running mode only can be dropped. It's up
to the driver to implement or not implement this.

> I haven't spec'ed pan-tilt-zoom in, but I hope it's at least be possible
> without violating the spec. Something for us to think about.
> 
> > Thus a video channel must have the following capability flags: channel
> > can capture odd field/even field/interlaced fields/alternating fields
> >
> > VIDCHAN_ODD   video channel can capture odd fields only
> > VIDCHAN_EVEN  video channel can capture even fields only
> > VIDCHAN_INTERLACED video channel can capture odd and even fields,
> > interlacing them                    automatically
> > VIDCHAN_ALTERNATING video channel can capture odd and even fields,
> > alternating them
> 
> One thing I haven't addressed in my specs (but I planned to) is the
> different ways to deal with interlaced video. We should try to do these
> different modes that you and Richard Guenther mention. We have to
> remember also that not all devices may be interlaced. Maybe it should be
> one of the capability flags.
> 
That's what the above flags are for.

> My gut feeling is that channels like you describe isn't going to be
> practical. Video is one channel. VBI could be another channel, in fact
> multiple channels for different VBI lines. But find out what VBI drivers
> exist already.
> 

But you can have 2 destinations for the video ( capture and overlay ). I
think idea of video channels follows the nature of video signal we have
today and is portable into digital realm.


Alex
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

[prev in list] [next in list] [prev in thread] [next in thread]