Excuse me if these questions are already answered in the FAQ archive. I
know there was some discussion about /dev/vbi a while ago, but I ignored
it because I wasn't interested at the time. Now I can't seem to find or
access the archives.
I am using "BT878(Hauppauge new (bt878))", i.e. bttv. I also apologize
for not being able to tell you what version of Video4Linux I am using;
hopefully that won't matter. I need to update my system to get to known
version. "uname -a" on the system shows:
Linux wildurp 2.4.0-test1 #3 Wed Aug 16 00:17:55 EDT 2000 i686
unknown
I'm using NTSC composite video in; in this case from a VHS tape, because
we don't have a cable feed here.
Here are my questions and problems:
1) In my app, I stop the video using the usual:
int enable = 0;
ioctl (puv->fd, VIDIOCCAPTURE, &enable);
This works fine, *except* if I open /dev/vbi at some point before doing
this - then the video does not seem to actually be stopped upon return
from ioctl(). For example, if I stop video as above and then clear (to
black) the screen (root) window, I frequently get video over the black
pixels, usually at the bottom of the screen. Only half the video lines
are painted, so I assume I am getting the end of a field. I don't have
to read() from /dev/vbi for this to happen - merely opening /dev/vbi
will cause the problem. I never have this problem if I don't open
/dev/vbi.
Any hints on how to know when the video is actually stopped?
2) To not lose VBI info it seems you must read() from /dev/vbi before
the next field (60 / sec) - or is it frame (30 / sec). Is there a
version where the VBI data is buffered so that will not occur? Also,
you must read 64KB from /dev/vbi even though only some of the lines are
interesting; it would be nice to only buffer some of the lines, e.g.
selected by an ioctl().
Has anyone done anything like this? If not, can someone point me to
what code I would need to modify to do this, perhaps with some hints?
Any driver improvements would of course be GPL.
Thanks in advance,
Peter Kaczowka
www.ucentric.com - contrary to postings in slashdot, not a "hoax
company":-)
