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

List:       linux-video
Subject:    Re: [video4linux] Alex: channels
From:       Bill Dirks <dirks () rendition ! com>
Date:       1998-07-28 1:18:51
[Download RAW message or body]

Alex Bakaev wrote:
> 
> This is a big post, sorry :)

No problem, but I will break up my reply into multiple threads by
subject. This will be a little unwieldy because the topics are
interrelated, but it's even more unwieldy to have five conversations all
jammed together.

> My opinion is that any type of video capture should be made more or less
> uniform and orthogonal. The less destination and data type -specific
> ioctls exist, the better and simpler the API will be.

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.

> 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).

> 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.

> 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.)

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.

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.

Bill.
------------
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]