[Coco] Re: Help - There that got your attention.

[Brett K Heath]

> Brett K Heath wrote:
>
> > Video streams in linux?
> >
> > google on the following names
> >
> > cinelerra
> > (a full blown quicktime based recording and post production facility)

> I had this up and running just before I went to supper. Could not figure
> how to make it reconize my video capture card.

On the record panel in the preferences dialog under the settings menu set
the input to Video4Linux and the path to /dev/video0. There may also be a
setting somewhere to select between various inputs to the card
(composite, RF, whatever. RF is usually called Television). To be honest I
think transcode or videolan are going to be a better bet for what you
need.

> > transcode
> > (a modular and very flexible command line tool that can do capture,
> > denoise, encoding, translation between various codecs and container
> > formats, and a few dozen other things)
>
> Have this but it did not show  up in a search using 'apropos'.
> > VideoLan
> > (A set of tools designed to do network video streaming under linux)
>
> Have this. Been working most of the day trying to get it to access my
> video capture card.

Do you have any apps running that do recognize your capture card?
If not you probably need to install and/or configure v4l (or v4l2). Do an
lsmod and see if the bttv driver is loaded.

> >
> > I'm most familiar with transcode and cinelerra (cinelerra is the successor
> > to Broadcast 2000).
>
>
> This is the third flavor of linux I have tried to run Cinelerra  on and
> still have not been successful.
> Transcode: I don't need to edit anything. What I need to do is take the
> image from my camera and give it directly to you over the internet.

I've used transcode and cinelerra under SuSE (8.3), and transcode and
videolan under debian. Though I haven't actually finished setting debian
up and haven't gotten transcode fully functional there yet (it works, but
some of my preferred codecs don't). I had trouble getting videolan to
recognize my card (also a hauppage) too but didn't spend much time playing
with it.

> My camera is a Sony Hi8 camcorder.  No USB. My TV capture card is
> Hauppage Win. Uses 'bttv' driver. I have 2 computers with Sempron 1.6
> CPUs and 1 gig memory chips. I have a 200gig HD I can install in 1 if
> needed. Sound will be added later when I get the video tested.

Sorry, I don't know from cameras. 200 gig (with the right filesystem) is
big enough to record and process several hours of broadcast quality raw
video at 352x480. Half width recording doesn't cause any noticeable
degradation in horizontal resolution. As others have mentioned the real
killer is the sheer bandwidth of raw video. Encoding can reduce this by a
factor of 10 or 20. Unfortunately the real time requirement pretty much
means that any encoding be done in hardware.

The MythTV project has drivers that can talk to the hardware encoders
found on the Hauppage PVR 250 and 350 cards, I suppose the output could be
sent to either transcode or videolan but really don't know.

I mention this because access to hardware encoding is going to make
everything else _much_ easier and also allows you to avoid licensing
issues if you decide to make a DVD later.


> I have had success with 'camstream' and 'webcam'. But they can only
> upload an image every 1 second and that looks kind of jerky.
>
> If you were going to use transcode, how would you construct your command
> line?

Those options are a little overwhelming aren't they:-)

For my situation I wrote a set of scripts that tweak the parameters on
three basic transcode commandlines, one to record, one to filter/denoise,
and one to encode. In principal these three functions can be combined into
one command but your likely to lose lots of frames if your encoder is
running at the same priority as your capture.

Here's a simplified version of my record command.

transcode -i /dev/video0 -x v4l -g 352x480 -f 29.970,4 -p /dev/dsp\
-u 32 -J pv -j 0,10,0,6 -y yuv4mpeg -m\
dummy_audio.avi -o dummy_capture_video.yuv4mpeg

The important options are -i (input source), -x (video input driver name),
-y (output codec name), and -o (output filename). Though this is set up to
record sound and video seperately some formats (such as quicktime) will
put them into the same file and you can eliminate the -m. The -u 32 tells
it to  a 32 deep frame buffer (you have to load the module with "modprobe
bttv gbuffers=32" to make this work). -J pv puts up a preview window so
you can see what things look like, if that doesn't work try -J preview
which uses a different overlay method.

Start with the -i -o and -x -y options, most everything else can be
autodetected. Tweak those until you get something workable.
After that you can build up what you need incrementally.

It needs to be compiled seperately and it's a bit of a pain to get it
working but I reccomend nvrec as the recording module. It's fast, good,
and it can use all of those 32 buffers to virtually gaurantee no dropped
frames.

If you want to use nvrec or, for example, record to a quicktime file that
can be read by cinelerra, I can help with the right options.

> > The real problem is that unless you have a hardware encoder or a truly
> > monster machine you have to capture raw, and this eats disk space at an
> > incredible rate (we're talking tens of gigabytes an hour, or more).
>
> As I stated above, this needs to pass as straight through as possible.
> Real time.

Raw video goes by at something like 30-60 megabytes a second. High quality
mpeg2 streams at something like 4-8 megabytes a second. Lower quality,
lower resolution and mpeg4 encoding will each reduce this significantly.
In my experience mpeg4 encoding is faster than mpeg2. You _might_ be able
--with reduced resolution, quality, and framerate-- to do a single pass to
avi and just keep up on one machine.

Sorry to run on, hope this helps.

Brett K. Heath