[mythtv] Multi-pass encoding (was: [PATCH] Add new MPEG4 encoding options)

[J.D. Bakker]

At 19:53 -0600 28-03-2003, Geoffrey Hausheer wrote:
>On a slightly different topic, what I'd really like to do is encode with
>rtjpeg or perhaps a lossless codec (doesn't NuppelVideo have one of
>these?) and do recompression with mpeg4 and more advanced options
>(perhaps multi-pass) in the background.  I'm just beginning to look at
>this, and it looks painful, but I think it would be a neat feature.  One
>thing at a time though.

IMHO multi-pass coding would be a very valuable addition to MythTV at 
this point. Multiple tuner cards can easily generate more data than 
even the fastest (current) CPU can run through an MPEG4 coder at high 
resolutions. Even with hardware MPEG2-cards on the horizon it makes 
sense to allow for transcoding.

Separating the encoding options is a possible first step. In most 
situations an end-user could care less which coding options are used; 
having general classes ("stereo movie", "bottom shelf storage") would 
be enough for Joe Public (or me, for that matter). These classes 
could expand to single-stage or multi-stage encodings.

Once the classes are defined I do not see major obstacles for the 
transcoding. The moment the recording ends a (nice 19) background 
transcoding session can start to a temp file; this should not impact 
systems with modern hard disks. Once the transcoding is finished and 
there are no users watching the recording, the new file can 
atomically replace the old one.

AFAICT people want advanced codecs like MPEG4 to reduce storage size, 
right ? In most cases it should not matter if a larger temp file is 
used in the process.

I see only three corner cases: (a) the remote frontend is too slow 
for the stage-2 codec, (b) the network is too slow for the stage-1 
stream (in the case of LiveTV or playback before the second stage has 
finished) or (c) the user records more shows than the stage-2 codec 
can keep up with.

Personally I don't think (a) is too much of an issue. The stage-2 
codec can easily handle some of the 'hard' front end tasks (I am 
thinking of deinterlacing). Besides, our experiments with video on 
low-power platforms shows that (within a codec class) decoding CPU 
load tends to go *down* when there are less bits per frame. Shifting 
complexity to the backend is a Good Thing.

(b) may be a mixed blessing for wireless setups. When running over 
Ethernet, a $40 Fast Ethernet Switch solves this problem, as well as 
lots of others.

IMHO (c) is only a problem for people with Celeron/600 backends, or 
*serious* couch potatoes.

And yes, I am actually willing to write some code for all this, if 
this were the Way To Go.

JDB
[who also has a thesis to finish...]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/