Date: Sat, 28 Jun 1997 12:44:44 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Guido van Rooij <guido@gvr.win.tue.nl> Cc: Steve Passe <smp@csn.net>, multimedia@freebsd.org Subject: European Channel Tuning (was Re: fxtv patches) Message-ID: <19970628124444.04368@ct.picker.com> In-Reply-To: <199706281526.RAA01312@gvr.win.tue.nl>; from Guido van Rooij on Sat, Jun 28, 1997 at 05:26:09PM %2B0200 References: <19970628104127.24586@ct.picker.com> <199706281526.RAA01312@gvr.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
(I'm CCing Steve since he might have some info to add, in particular where
the best place to put the channel-to-string mappings for Europe is.
Guido van Rooij:
|Ah ok. Btw I have been thinking about solving the `plus channels'
|problem, and I think what I want to do is this:
|In stead of having a numeric channel field, have a string field.
|In you resources you can specify which channels you have and either
|their channel no. or their frequency. If you do not set a channel
|name you'll just get your old number back. What do you think?
|
|The reason that I want something like that is that in Europe we
|do not have channel numbers as identifiers but channel names.
|Hmm..now that I think of it: I would rather see a nnew file, lets say
|.fxtv-channels, in stead of resources. Anyway, I'd like to know
|what you plan to do with fxtv and if my views fit in there ;-)
Well, from what you said, it sure sounds like there's a need for
frequency-to-string mappings as opposed to frequency-to-channelnum
mappings. Glancing down in brooktree848.c and searching down for "Western
European", I assume something like the names on the rightmost column of the
commented-out table are what you're talking about.
Let me ask a few more questions to get a handle on the specifics so we can
determine the best place for this table.
If I understood, there are no "channel numbers" in Europe, just channel
names. So I assume the channel numbers in the driver are pretty well
arbitrary.
Also, can we assume that the channel names in a frequency-to-name mapping
table are constant for a particular broadcast standard? (e.g. a specific
frequency is always identified as "N21" or "E1").
If so, it seems like we should either:
1) keep the arbitrary channel numbers in the driver for the existing
interface, and add a new driver interface so it can tell apps
what the ad-hoc channel number -to- name mappings are (e.g. #1 ==
"N21", #2 == "E2"), OR
2) Modify the driver interface to accept a channel string specifier
instead of (or in addition to) the existing channel number
specification interface (for US, string would just be chan number
in string form), OR
3) Instead, have apps manage the name-to-frequency mappings, and have
them talk to the driver in frequencies (for all freq stds, or maybe
just for channel-numberless standards).
Both #1 & #2 hide the app from the mappings from frequencies to channel
numbers/names, which is good if its practical. This is a big plus because
each new app won't have to know how to convert N21 to a frequency.
We may need to resort to #3 if there is enough variability in or space
required for the freq-to-name table such that its impractical to encode
this knowledge in the driver. If so, we should come up with a common
FreeBSD link library so each new bt848 TV app doesn't need to duplicate the
name-to-frequency mappings, but rather can just link with the library and
talk channel names and channel numbers instead of frequencies, as with
options #1 & #2.
|ps: so you know what this is:
|bktr0: ioctl: tsleep error 35 100001c
|I keep getting them everytime when I freeze the window.
Yeah, you'll get this when a single-frame capture (aka CAP_SINGLE, or
freeze frame) fails. This occurs when the driver timed-out waiting on 1 or
2 fields to complete capture, and so it couldn't assemble the frame. Where
I've seen it happen is when the tuner isn't in complete sync with the video
(on weak channels the tuner can sometimes drift off frequency a little).
Looking in my console window, I see that there's one there from earlier
this morning.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970628124444.04368>