Re: CPU recommendations for tc

Francesco Romani wrote:
> On Sun, 2008-03-02 at 19:55 -0600, Carl Karsten wrote:
>> It looks like I need way more CPU power than I expected.  I was hoping to just 
>> stream to external usb disk using P3 laptops and encode later, but then usb/disk 
>> IO becomes a bottleneck.  (I think it is the usb, might be the drives I am 
>> currently using.)
> 
> Please try this recipe before acquiring new hardware:
> 
> [other options] -y ffmpeg -F mjpeg -N 0x1 -w 3000 -o something.avi
> 

Hmm, this is looking pretty good.

>> So I want to ask my local hardware guy to build me a box (5 actually) 
>> specifically for usb->transcode->local sata.  As long as I am doing this, I may 
>> as well get enough CPU to encode on the fly.
>>
>> The hope is to capture:
>> /dev/video 1024x768 x24-bit @ 12 fps
>> /dev/dsp mono voice, so low bandwidth is fine.
>>
>> I want the video saved in a lossless format.  (jpeg screenshots are ugly.)
> 
> Something to try, in not a particular order:
> - the command line above (give it a spin at least, ffmpeg usually gives
> good surprises ;) )
> It's lossy, yes, but with a sufficiently high bitrate you will not
> notify artifacts, and it is pretty good for later processing.
> - -y ffmpeg -F huffyuv
> lossless, will eat A LOT of bandwith
> - -y lzo
> roughly the same as above
> - -y ffmpeg -F ffv1
> lossless, fairly good compression, HIGHLY cpu intensive, suited only for
> temporary storage
> 
> Always use constant sized/rated audio -N 0x1 (PCM, uncompressed) unless
> you are forced to do othwerwise, this will save A LOT of sync problems,
> even all of them.
> Always prefer an intra-only codec (MJPEG,...) if you plan to do later
> processing (even just cutting!)
> 
>> If I can, I want the video compressed on the fly.
>> I want the audio saved in the same file, and hopefully with no sync issues.
> 
> All above suggestions should satisfy this requisite.
> Avoid h264 as storage format, this will eat your cpu.
> 

good to know.


>> Anyone know what kind of hardware will or won't do this?
> 
> I've a pretty old (for this kinds of tasks) athlon64 3200+ single core,
> it's ultra-low end in march 2008 and it can still handle this task just
> fine (see video4linux examples in the wiki for details). I guess any
> modern dual core, saving maybe the hyper-cut-down chepaes
> semprons/celerons will handle this kind of this just fine.
> 
> Speaking about old hardware, I guess you'll need a P4 2.8 GHz or better
> and any athlon64, single/multicore. 1 GB ram will be enough, but do not
> understimate hard disks and the I/O controller on the chipset.
> 
>> Anyone have the math to support that I can't stream that much uncompressed A/V 
>> over a USB2 connection?
> 
> uncompressed is mostly out of business because it will eat storage (and
> bandwith of course, but do not understimate the storage problems) space
> way too fast, unless you have terabytes of spare storage you'll need
> some kind of compression.
> 
> Anyway, for the record:
> 1024x768x24 (frame) x 10 (fps) = 23592960 BYTES/second ~= 22.5
> MegaBytes/second
> + audio: 44100 samples/second * 16 bits/sample * 1 channel ~= 86
> KILOBytes/second (negligeable)
> 
> 8 hours storage (very likely for a conference) = 28800 seconds
> 
> 22.5 MiBps * 28800s ~= 648000.0 MiB ~= 632 gigabytes at DAY.
> 

Sounds about right.  I do have 6tb of storage space.  but that has to be enough 
for 4 rooms * 3 days * 8 hours, so more than 6gb.  ouch.

Carl K