Hi all,
>
>       When 30fps rates are mentioned they are almost always talking about
>       352x240 (VCD) MPEG-1 and _not_ 720x480 (DVD).

Steven is dead right.   I can get around 10fps for DVD with interlace support 
on my 2100+ Athlon box with another machine doing the "lav2yuv"-ing the 
encoder set for high speed.  For pure progressive stuff I can get 15fps.   
However, I don't think there is a machine available that is *twice* as fast.


> > Is mplayer as scaler faster then yuvscaler ? (with
> > cropping/letterboxing/filter)
>
>       It is very rare (on my systems) to see yuvscaler use more than 10% or
>       so of the cpu (as estimated by 'top')
>
> > Is a normal homenetwork (100Mbit) fast enough for scaling on a different
> > machine ? ( 500Mhz Athlon  for scaling and so on, 1,1 Ghz Duron for
> > encoding).

Splitting the work across a 100Mbit network works *wonderfully*.  My 
favourite script for DVD encoding looks like this:

mkfifo vid.m2v aud.mp2
rsh -n bottom "lav2yuv /mnt/capture/avi/$1.eli  | yuvscaler -v 0 -I 
ACTIVE_704x560+8+16" \
  | /usr/local/bin/buffer -b 16m \
  | mpeg2enc -f 8 -b 6000 -z t -q 5 -N -I 1 -4 2 -2 2 -o vid.m2v &
rsh -n bottom "lav2wav  /mnt/capture/avi/$1.eli  | mp2enc -s -b 320 -o -" \
  | /usr/local/bin/buffer -b 1m > aud.mp2 &
mplex -f 8 -M -S 680 vid.m2v aud.mp2 -o /mnt/archive/tmp/$1.%02d.mpg

Note the use of "buffer" to buffer after the remote-pipe so that the 10MB/sec
peak speed doesn't become a bottle-neck.

Unfortunately, this mega-useful little utility isn't a standard part of most 
Distro's.  On Debian there's different "buffer" that is used for tape archive 
handling...



> > An encoding speed of 20 fps would make me fairly happy, as the encoding
> > queue is far better on linux then on an other OS where there
> > fast&expensive
>
>       I wonder how the hardware encoders (found in the DVD recorders) manage
>       to get 30fps realtime encoding - 30GHz cpus? :) :)

Easy: they don't use a CPU at all.   All the reall work is done in dedicated 
hardware.   Typically there will be a pipelined sum-of-absolute difference 
engine (usually implemented as a systolic array), pipelined hardware DCT / 
iDCT engine. pipeline block quantisation engine and a hardware DCT 
coefficient engine.  All the controlling CPU has to do (more or less) is DMA 
that frames into the buffers and play with the rate-control / quantisation 
parameters in response to satistics from the encoding engine.

An example from a scaler I recently designed at work should make the 
possibilities of modern semi-custom VLSI ASIC technology clearer.
The scaler is (basically) a 2D FIR filter with 5-taps in each axis.   The 
pipelined  multiplier/adder array impementation runs at 165Mhz with 10-bit 
colour precision and a fully programmable filter kernel.  It takes a fraction 
of  mm^2 silicon in a by  no means start-of-the-art 180nm CMOS process and 
uses a few tens of milliwatts of power and delivers an RGB pixel *every clock 
cycle*.  Hitting 250-300Mhz would be trivial but we never even bothered (165 
was enough for the intended application).

Doing the same calculation to the same precision using MMX on a  modern CPU 
would require approx.  40-60 cycles per pixel.  Even a 2GHz+ CPU 
suitable for heating a family home would be hard pressed to deliver more 20 
mega-pixel/sec.

Of course, its much easier and quicker to program the CPU!

cheers,

        


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to