On 02-Jun-01 Gerd Bitzer wrote:
>> So youd have a really skewed mode :)
>
> Yeah, but for the subtopic of even and odd lines I agree with Jonathan,
> which answered a little later.
*nod* I looked at the code, and the current driver allows for a mix of
capturing and preview, and both even and odd frames can used for either
purpose (of course, grabbing both even and odd frames does not allow direct
preview anymore).
> And the question is already, what is the resolution of the picture xawtv
> delivers. Not all 625 lines are represented in xawtv's window (I think
> because of the vertical sync impulse inside the FBAS signal),
*nod* the 50 lines are used during the vertical retrace of the beam.
> but which
> is the exact number of lines, are it really 575,
yes; and you really have 287.5 lines per frame (the even frame stops halfway
a line at the bottom, and the odd one start halfway at the top, or vice
versa, can´t remember right now).
> is this number constant when changing from station to station or does it
> change,
no, this is STANDARD, one of the few that actually are implemented to the
letter:) TV studios use extremely high precision chrystals for their timing
signals. On occasion, I´ve been watching TV with interference (ghosts) from
another channel. The ghost image would slowly drift left or right, rolling
around the screen. It would take on the order of an hour to scroll a whole
frame this way; that´s 0.02 seconds difference after 3600 seconds of
operation at 50 Hz = 0.11 ppm; not bad.
NB: switching standards (PAL/NTSC) does of course change the number of
lines; SECAM uses the same timing as PAL; only its color information is
coded differently.
> and how much pixels per line are depicted horizontal ?
That question is a bit more difficult to answer... The TV signal is an
analog signal, so if you look at a single line you can´t really count
pixels. However, the signal is limited in bandwidth, and I think that´s good
enough for some 400 lines (that is, 400 on/off transitions per visible
region of the line).
> Is it possible to get exact values ?
Yes; you just have to find the right docs; I couldn´t find anything at the
Internet so far, but a good book on television and/or VCRs should give the
exact data (but trust me, that´s more than you want to know!)
> Syncing would be the best resolution IMHO, but I'm in doubt that this
> could be realized.
It would require hardware sync between video card and TV card. The biggest
problem is that the TV signal is external, and cannot be told when to sync;
neither can video cards, as far as I can tell. A ´software´ sync (if at all
possible) would also be hampered by IRQ latencies.
> When syncing could not be realized, would it be better to tweak an X11
> mode with an even multiple vertrefresh of the TV vert framerate (say 100
> Hz because of the capabilities of most monitors) or does this not matter
> at all ?
Well... it could help. But the video card reads the video memory twice as
fast as the bttv fills it (assuming 100 Hz). So it will always ´catch up´
with the bttv card. By trying to synch the two, you would fix this
takeover point on your screen, which is probably even more annoying (or,
considering you never get the frequencies 100% right, the catchup point
would slowly scroll!)
> Exact:-). All 100Hz TV's (which do a double buffering to realize this
> doubling of the vertical framerate) incorporate a kind of motion
> compensation to reduce/eliminate this kind of distortion, and it seems
> that this could also be done in software (Dscaler)
...but that would kinda defeat the use of a hardware solution to deliver
live Tv images to your screen :) Such compensation would be necessary if you
wanted to grab high quality videostreams (Linux DVD editor? who knows!), but
that requires a lot of software and CPU cycles anyway.
> The load on the PCI/AGP bus, another point, even when we see todays
> discussion of Bugs in VIA's Southbridge regarding higher loads on the
> PCI bus. Wouldn't it then not be the better way to use the least
> possible fullscreen resolution, either for minimizing the busload and
> for minimzing the timeoffsets between even and odd lines ?
*nod* After I switched my videocard from PCI to AGP, I could watch
fullscreen (bttv´s full screen) without trouble; before that heavy movement
would leave stripes and all kinds of artefacts. Using a 16 bit mode
video might help as well (needs only half the data!)
> Not complete, further discussion required for further clarification ;-)
Beware, I´m a programmer with a soldering iron :)
- Nemosoft
-----------------------------------------------------------------------------
Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000
URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight <<
