[MPlayer-users] encoding is slow, is it normal for my system?

[Daniel Moreno]

Diego Zuccato wrote:

> About speed... I couldn't find any info in the FM, so I ask (feel free
> to tell me I need better glasses O:-) ).

I guess they asume you know that encoding is generaly slow.

> What is the minimum system to acquire video+audio at 768x576x25fps (or
> whatever is PAL) and dumping it on disk (so that about 5-6MB/s is't "too
> much") ? And to reduce it to about 3MB/s ?

:-m
Let's see... 768x576x25x12/8 (assuming you capture in YV12 or similar) 
gives us... nearly 16 Mbs/second. So... you're not likely to save it 
rightaway to disk unless you have a scsi raid or something.

So you have to use compression. The first I'd try would be mjpeg (using 
libavcodec) since it's suppoused to be the easier to compute. Anyway 
you'll find it's not as fast as you'd like, probably. (When I used 
nupplevideo I could capture 384x576 or 768x288 on my P2-266 without much 
problems, but I'd say this is nearly the maximum my system would be able 
to do. One of these days I have to start playing arround with mencoder 
for realtime compression)

As far as I know, you can get a 5 Mb video stream by passing 
vbitrate=40960 to lavcopts. (i know this parameter has a limit, don't 
know if this value is in the valid range, it's somewhere in some manual)

If you want 3 Mb/sec... vbitrate=24576 (3*1024*8). Althought... when I 
tried to use mjpeg to compress a video I found this didn't give accurate 
results. So I'd try just using fixed quantizer, just like many mjpeg 
cards do.

If you want to compress to divx... that's going to be harder. Of course 
you should first try ffodivx without vhq. You could also try divx4/5 
with -pp 0. But with -pp 0 that's not too diferent from a slow mjpeg codec.

I hope this gives you some basic ideas about capturing so that you can 
experiment by yourself and find the best solution for your system.

-- 
Daniel Moreno - ComaC
Port pa'Linux del FinalBurn: http://fblinux.emuunlim.com/