[mythtv] Conversion in the background, can it reduce system requirements?

[Geoffrey Hausheer]

On Tue, 8 Apr 2003 22:15:48 -0400, "Jay R. Ashworth jra-at-baylink.com
|mythtv/1.0-Allow|" <n4udhd23oh0t at sneakemail.com> said:
> On Sat, Apr 05, 2003 at 07:01:02PM -0600, Pyroman[FO] wrote:
> > Ive read on this list about adding a feature to convert files in the
> > background when there are no recordings or live TV watching going on. 
> > What I want to know is, could it be used to let low-powered machines
> > record TV?  I know with WebVCR+, I could record VCD quality divx5/mp3 avi
> > files just fine with the conversion feature, by recording to a huge MJPEG
> > with uncompressed audio file on the fly, then converting later.  This was
> > an Athlon 600, an hour worth of video would be about 3GB, then get
> > converted down to about 300-500MB.  My lowly little machine couldnt handle
> > realtime divx5, but conversion allowed it to keep up.
> > 
> > A store file could be kept, similar to the LiveTV buffer, and once it
> > filled (i.e. too many shows have been recorded in a row), it would stop
> > recording and start recording like it does now, or stop recording and just
> > convert the files it has.  The user could control all of this through the
> > setup.  I dont really have time to work on this, but does anyone else
> > think this is a good idea?
> 
> I just asked a different permutation of this question; perhaps we
> constitute a quorum.  :-)
> 
> Cheers,
> -- jra

I've been working on this (and in fact have it working on my system,
though it is still pretty crude), and can answer as follows:
This is basically just a tradeoff between hard-drive and cpu.

It will let you encode divx quality at 640x480 on any cpu that can do
capture at that res (I've been told that using hufyuv compression is
best, since RTJpeg doesn't store the right data to do good
motion-compensation, but I have not tried to validate this yet)

However, it means you need enough disk space for both the uncompressed
(or lightly-compressed) data as well as the new compressed stream for
every show that is not yet encoded.

Since, in theory, we'll want multipass encoding, the transcoding can't
start until the recording of a show stops.  that means that if you record
3 2-hour movies in a row (as I recently did for 'Children of Dune') I
need enough disk space for 6 hours of rtjpeg (or whatever) movies at best
quality, as well as the final compressed form.

So my setup is that i have about 40GB for 'temporary' data, and 160GB for
final-storage.

at RTJPEG quality 255 at 640x480, I believe it runs about 10GB/hour, and
on my 1.6GHz machine, I can encode to ~divx quality in about 1/2 real
time, so I can record as many 2-hour movies back-to-back from a single
encoder as I like, but don't have enough space to do the same with 3hour
movies, nor to use two encoders simultaneously for more than 2hours.

With a slower processor, the temporary disk requirements skyrocket.

There is also a secondary memory issue.  Since multiple threads are
runing at the same time, you can suck up a lot of memory pretty quickly,
so I don't think I'd want to use the transcoder on a machine with less
than 256Megs of RAM.

I hope this helps.
.Geoff