Re: Cinelerra--Video Editing??
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hal MacArgle wrote:
On 06-16, Ray Olszewski wrote:Hal MacArgle wrote:Can I back track and interject another query? Why can't I capture set to 29.970?? What would be the stumbling block; the HD writes?? I have that machine dedicated to video only with all the daemons I know removed.. Afraid to remove more for fear I'll really upset the apple cart.. Maybe a complete kernel rebuild could be in order??OK. I see two possibilities: CPU and hard disk. (In writing this, I assume "can't capture" and "doesn't like" means too many dropped frames.)Wrong phrasing as I now find it does capture at 29.970 both using xawtv or streamer, CLI, that reports A/V: as no more than 0.001 during playback using mplayer, but when the file stops it jumps up to 0.015 or so at the very end of a run.. Keeping better records I see that the xawtv capture files are 403mB/min compared to the <30mB/min using streamer; same other parameters, size, rate, etc.. Top reports 6-7% cpu usage with xawtv or 37-39% with streamer..
Wrong number; you want to look at total CPU use, not CPU use assigned to the program explicitly by the kernel. (You say something about this later.) Overhead use can be caused by a program but assigned to another program ... with xawtv, X itself is the prime candidate ... or to the kernel ... so it shows up as system use, not user use. For A/V stuff especially, the only good way to figure things out is by comparing total CPU use, as reported by top, with the relevant app running and not running.
But I think the CPU numbers you report look okay, if I understand them right. The versin of top I use reports CPU use this way:
Cpu(s): 0.0% user, 0.0% system, 0.0% nice, 100.0% idleIf you are saying that the last number is still in the 60-70% range when capturing, than CPU load is not the problem.
HDParm reports DMA (on).. On playing back I note all the xawtv captures are reported: "Badly interleaved file -- switching to -ni mode," by mplayer.. That line is not reported playing back streamer grabbed files.. I doubt if this has much to do with the original posted problem though.. Just guessing and reading more: Wonder if a bad interleave; meaning a bad multiplex??, could be a problem withCinelerra but not mplayers' viewing??
Ok. 404 MB/minute is about right for completely uncompressed capture, figuring 320w x 240h x 24-bit-color x 29.97fps x 60 seconds. And that's high enough that your disk drives might not be able to keep up with it. Check (time a large cp that involves really moving the files, not just changing directorry entries) to be sure.
The streamer files are compressed somehow ... maybe to mpeg2 (the size seems about right for that)? Or maybe high-quality mpeg4 (here I capture at about 10 MB/minute, but that's via an explicit setting in mencoder). In any case, streamer-size files shouldn't overload disk I/O.
Since you are using mplayer anyway ... have you tried using mencoder for the captures? Try a command something like this (assuming you're capturing from tapes via NTSC video and sound-card audio):
mencoder tv:// -tv driver=v4l:device=/dev/video0:input=1: \ immediatemode=1:forceaudio:adevice=/dev/dsp:norm=NTSC \ :audiorate=32000:width=320:height=240:fps=29.97 \ -oac copy -oac mp3lame -lameopts preset=medium \ -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=9 \ -ofps 29.97 -endpos $whichtime -o $filenamereplacing $whichtime (number of seconds to record) and $filename with appropriate values. (Your bttv card may require input=3, but you'll know that from using it with xawtv and streamer.)
output of "free"I didn't check that except to note that the 1.0gB swap file was not used at all.. One puzzler though is that total memory is listed as 902616, when BIOS reports the actual 1.25gB of fitted memory.. Free says used=880976 and free=21640 idling?? That doesn't look right to me.. Herewith anyway: ------------------------------------------------------------------------------ total used free shared buffers cached Mem: 902616 880976 21640 0 7096 841912 -/+ buffers/cache: 31968 870648 Swap: 1004052 0 1004052 ------------------------------------------------------------------------------
Someone else already pointed out that you need a kernel that supports high-memory to go above 900 MB or so.
Your concern about RAM used comes from looking at the wrong line. You want to watch the second line, which reports 32 MB used and 879 MB free.
The difference is in cache and buffer space. The Linux kernel (most any modern kernel, I think) leaves recently-used programs and files in memory, as long as the memory isn't needed for something else. As a consequence, over time a Linux host will fill up any imaginable amount of RAM, using the measure on the first line ... video capture is particularly good at this.
The Gentoo FAQ has a particularly good discussion of all this stuff. Read it at
http://gentoo-wiki.com/FAQ_Linux_Memory_Management [...] - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs