Date: Fri, 15 May 1998 06:52:24 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: dnelson@slip.net, multimedia@FreeBSD.ORG, msh@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Subject: Re: BT848 and VBI data Message-ID: <19980515065224.A23116@ct.picker.com> In-Reply-To: <199805150358.FAA01857@labinfo.iet.unipi.it>; from Luigi Rizzo on Fri, May 15, 1998 at 05:58:26AM %2B0200 References: <19980514171530.B18554@ct.picker.com> <199805150358.FAA01857@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo:
|> 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).
"Decoding" is not what I said. Attributing is what I had in mind. I
certainly agree we don't want the kernel doing CPU intensive jobs like
resampling images. However, if it's not inherent in the structure of
Teletext/Intercast datastream, it would be helpful if the kernel could, as
its grabbing data:
AAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCC
attribute the chunks so apps can skip what they don't understand:
<Type 2><Len 17>AAAAAAAAAAAAAAAAA<Type 8><Len 18>BBBB
BBBBBBBBBBBBBB<Type 1> <Len 15>CCCCCCCCCCCCCCC
At the very least, apps need to know when there is a break in the stream so
they can resynchronize. This could happen, for example, because the driver
was acquiring VBI data faster than the app was reading, and the driver had
to overwrite the head in the ring buffer past where the app was reading.
|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
Interesting.
|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.
Yeah, that would be nice. The top level stream encoding scheme should all
be a public standard at least, in a perfect world.
Randall
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?19980515065224.A23116>