Date: Fri, 15 May 1998 05:58:26 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: rhh@ct.picker.com (Randall Hopper) Cc: dnelson@slip.net, multimedia@FreeBSD.ORG, msh@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Subject: Re: BT848 and VBI data Message-ID: <199805150358.FAA01857@labinfo.iet.unipi.it> In-Reply-To: <19980514171530.B18554@ct.picker.com> from "Randall Hopper" at May 14, 98 05:15:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd also be interested in this if it can be implemented generically. That > is, so the data stream (Intercast, Teletext, etc.) can be attributed so > apps can pick out the pieces (chunks) they understand and want, and can > easily skip over and toss the rest. Something like a simple RIFF stream. the frame grabber has no clue on what is inthe VBI lines, so it is the app that must do everything (it makes no sense to put decoding procedures into the kernel). > Probably want a circular buffer for this, which the client can poll at its > leasure. Need some file desc event to signal when the head has overwritten > the tail so the client knows when to reset its reading state. the meteor device driver does this very well. although, if you have a reasonably fast machine, and because VBI info is in a small portion of each field, you can do a data transfer as soon as you get the 'field complete' interrupt and you have about 12-15ms to fetch the data. What i did long ago was to define a new video format (both in the meteor and the bt848 drivers if i remember well) where i got raw samples of the Y component of the video, from each *field*, not interleaved, and from the very first lines (say 2..32) of each field. You have to disable the chroma filters because data carry high-frequency components. Then i just used the read() interface (i had to implement it on the bt848, but now it is probably there) to collect a number of blocks of data (like say 5-10sec.), and then did the decoding in software (losing data in the meantime, but who cares given the nature of the application...) The processing involved sample-rate conversion, a FIR filter to sync with the start of the stream, and then packing bits together and doing high-level decoding. > I don't know anything about either the Intercast of Teletext streams, and > what about those streams is public or proprietary, so I can't really > comment more than that. teletext is an ITU/CCITT standard but it is also documented in a variety of publicly available documents, even online. Intercast format appears to be proprietary. At www.intercast.com they advertise a hardware developer's kit, but price is unknown and the phone number is (503) 274-7240 -- if someone there wants to call and find out how much they ask for this, it would be interesting to know. BTW from the list showing what is in the documentation, there is no reference to the data format. They do have a "VBI decoder" which i suspect is a binary/library only, and is the same thing you get for free with your hauppauge card . The fact that they claim a Pentium-90 is a minimum requirement, and a Pentium2 is recommended, makes me think that the decoding is done in software without any hardware support. A bad thing, considering that had they embedded intercast data in the teletext format (which might well be what they do, and what others also do routinely since the 80's here in Europe) they'd have a nice, low speed stream of bytes from the teletext decoder (a $5 chip) that even a lowly 486 would be able to decode with minimal CPU usage. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805150358.FAA01857>