One thing I've noted, on really noisy TV stations, I capture them as either rgb24 or mjpeg, it doesn't matter, the encoding seems to be OK but the playback of the divx encoded result bogs down or starts skipping frames and looks horrible. The originals play very fine with xanim +Av100 +Sr. Of course the originals started out as half-gig files. I suspect a noisy picture requires some avifile tweaking.
Xanim is the only program I have that seems to do real-time
scaling. Xtheater does fullscreen perfect but only with
640x480 video which is about all my processor can handle.
30/Mar/2002
Addendum, aviplay from avifile is excellent, it works with
scaling, fullscreen and will operate any brightness, contrast
etc controls if the codec allows it. Good stuff
On clean stations, VCR output with unstreached or uncopy guarded tape, dvd sans macrovision (try decss/stripper) etal, this encoder front end works marvelously. In fact in some cases I get better than 30fps (320x200) conversion speed, I'd love to hack this functionality into xawtv's streamer program, recording a 2.5 gig file then finding out there's a 2gig limit is quite frustrating. A two hour mjpeg'd file at 30fps goes way over 2gigs, so I've been doing it in 30min chunks. With divx I could do it in a quarter of that size.
A digital stripper does wonders for copyguard,
for a digital version check Nuts and Volts magazine for
an advertisement. Panasonic at one time slipped one of these in
their vcrs (or something damned well as good), circa 1986/7.
They never admitted it though and didn't -quite- point it out
on their schematics but the tape output went through a
hairball 'integrated video/audio demux' and came out pristine
to both the RF modulator and the video output. Audio was mono
(no-hifi) but perceptibly better than many vcrs at that
time. I doubt that they still do this and I hate the mech in
current models -> circa 1995->current.
To make your own grab a back issue of Radio Electronics
(became Electronics Now, in this incarnation it may be dead
and good riddance as it had none of RE's flair or
intelligence).
I had built one that would take the color burst and generate
the horizontal and vertical timings clocked from that. I do
not remember if it required a custom programmed chip, I think
so as that's how I think RE made extra money. I just bought
the unassembled kit. No tuning or adjustment required
if I remember right.
That kit was quite cool, kills closed captioning as it blindly
striped everything in the sync interval, but proof against
macrovision. The Radio electronics one I think was called a
"universal descrambler".
Since NTSC is Never The Same Color, most scrambling and
copyguard schemes at that time either hide or damage the sync
signals as they could not touch the colorburst. My UD on one
cable scheme that deleted the sync and rebroadcast it on
another carrier, descrambled it perfect. I used it and a cable
ready vcr's video output instead of their box since their
boxes were not digital and were never aligned right.
Now if any enterprising soul could decode the output from a
TV card generating a colorburst from what ever color scheme
is used, then clock that down to horizontal and vertical
you'd have a universal descrambler.
If the tv card actually GAVE you color burst or you are able
to sync some sort of clock off of what ever it did give...
This would be cool but it'd require
grabbing video, it will be distorted
generating sync either from the video stream calculation
or getting the colorburst and generating H&V sync
then displaying or storing the captured video frame
synced with the calc'd sync.
Capturing it, crunching it and storing it for later viewing
would be cool, real time would be swell. bttv would
need to be patched to not mute video and audio, I think
mute to blue screen can be turned off, I know that audio
muting can be turned off with a minor hack.
Avifile defaults some things, especially the file creation mask. I've not been able to figure out how to get it to NOT leave the resulting created file chmod'd as +x. This IMHO is a security flaw.
Avifile exports floats but expects incoming ints. So you have to just pass the float and have gcc howl about it, or do some hairy float to integer casts to int/intmax_t and/or integer math as I have done. I suspect that you can just slap an (int) in front of it but did not see that as correct as I do not know how gcc would handle it.
Maybe some kind soul would send me a 'HOWTO handle float / double / steak / shake conversions to short/int/long int/long long int / intmax_t / uintmax_t and vice-versa properly' preferably for a Redhat Linux v7 system which shouldn't matter but does. Please include complete compilable programs with those magical things called comments, toke something that causes verbal diarrhea if that will help, I can always find and replace the giggles.
For a budding programmer, silly 'known' stuff is very murky and unknown.
Such as the outdated libc info docs that DO NOT state that you must include inttypes.h to get all the features mentioned for stdlib.h, stdint.h is of course ASSumed as well. BTW these headers include the integer division routines, div ldiv imaxdiv but I think not lldiv.
While the libc info pages state that lldiv is there, it does not appear to be by default or I'd have used it. Something to do with ISOC99 being defined. Didn't pursue this, I've probable made the code noncompliant by using imaxdiv, it appears to be exactly the same as lldiv.
AFAIK the gcc info pages state that / rounds to zero and that the div ldiv etal are redundant. I find that these work a bit differently than stated. div/ldiv and friends seem to round UP, don't know what exactly is meant by rounds toward zero, gcc rounded down but this was the dividing a float/int int/float hairball and the data that is extracted from the avi's or mpeg's is fairly simple.
Gimme a man page with a simple compilable program for each function any day.
/mantra on/ info sux, info sux, info sux. /mantra off/
PS: Yea, I'm a bit liberal with the hairball expletive.