Pinnacle and Dazzle
in [UK Linux]
|
Prev: Permission Denied On USB Hard Drive
Next: The Linux experience - ugly, bad, and good - Re: Random Hesitations: The new threat to windummy productivity in the office
From: Andy Furniss on 2 May 2010 16:33 Davey wrote: > Cpu(s): 89.4%us, 10.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, > 0.0%st > > Note that the rise to 89% is after it has stopped! OK so this is the problem - instead of running top -b | grep Cpu run top -b > top-out which will output lots more info to a file called top-out, which you can look at to see what is eating all that Cpu. The reason user rises when you quit is because the system usage falls - you had 0% idle throughout, so it's just not going to work unless you can sort whatever user process is eating CPU. >> Oops, my mistake I should have said -ofps 25 >> >> If you are running out of CPU then it's not going to help anyway :-( > > Next attempt, with the better ofps setting: Now that you know the problem is CPU forget about -ofps 25 and use 30000/1001. FWIW I just connected up a VHS to my card and did a 60 sec test - 578x720(a)25fps like you using yuy2 and this is what top says for me. Athlon 2500 CPU @ 2.1Ghz, file system is xfs and you can see the only time I come close to running out is when it writes to my old ide disk. Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 61.0%id, 38.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 16.3%us, 2.0%sy, 0.0%ni, 35.5%id, 46.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 39.4%us, 2.0%sy, 0.0%ni, 58.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 41.3%us, 1.3%sy, 0.0%ni, 57.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 39.5%us, 2.0%sy, 0.0%ni, 58.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 38.0%us, 1.7%sy, 0.0%ni, 60.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 39.5%us, 1.3%sy, 0.0%ni, 59.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 36.9%us, 2.0%sy, 0.0%ni, 61.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 40.7%us, 2.0%sy, 0.0%ni, 57.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 40.7%us, 1.3%sy, 0.0%ni, 58.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 38.9%us, 1.7%sy, 0.0%ni, 59.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 41.3%us, 1.3%sy, 0.0%ni, 57.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 43.4%us, 2.6%sy, 0.0%ni, 7.9%id, 45.7%wa, 0.3%hi, 0.0%si, 0.0%st Cpu(s): 42.1%us, 1.7%sy, 0.0%ni, 56.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 37.5%us, 2.3%sy, 0.0%ni, 60.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 40.9%us, 1.7%sy, 0.0%ni, 57.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 34.9%us, 2.3%sy, 0.0%ni, 62.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 40.5%us, 1.7%sy, 0.0%ni, 57.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 41.5%us, 1.7%sy, 0.0%ni, 56.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 40.4%us, 1.3%sy, 0.0%ni, 58.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 42.0%us, 1.0%sy, 0.0%ni, 57.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 23.6%us, 1.7%sy, 0.0%ni, 74.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu(s): 1.3%us, 0.7%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
From: Davey on 2 May 2010 18:07 On Sun, 02 May 2010 21:33:21 +0100 Andy Furniss <spam(a)andyfurniss.entadsl.com> wrote: > Davey wrote: > snip OK. The useful part of top-out while running mencoder shows: top - 17:59:13 up 4:33, 3 users, load average: 1.79, 1.73, 1.43 Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie Cpu(s): 86.8%us, 8.9%sy, 4.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st Mem: 444296k total, 270484k used, 173812k free, 7964k buffers Swap: 1309256k total, 171560k used, 1137696k free, 127924k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5615 david 20 0 75632 4988 4900 S 92.5 1.1 252:15.29 mencoder 13509 david 39 19 83160 16m 7288 S 4.3 3.7 0:00.93 gnome-video-thu 11 root 15 -5 0 0 0 S 1.0 0.0 1:03.32 kacpid 4285 root 20 0 214m 27m 4092 S 0.7 6.2 3:58.02 Xorg 12 root 15 -5 0 0 0 S 0.3 0.0 0:16.41 kacpi_notify 5073 david 20 0 29068 3976 2124 S 0.3 0.9 0:27.04 compiz.real 5258 david 20 0 39836 7888 3064 S 0.3 1.8 0:58.31 gnome-terminal 13311 david 20 0 2452 740 460 R 0.3 0.2 0:01.48 top 1 root 20 0 3084 272 220 S 0.0 0.1 0:01.12 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.06 ksoftirqd/0 and after it stops working: top - 17:59:16 up 4:33, 3 users, load average: 1.80, 1.73, 1.43 Tasks: 135 total, 1 running, 133 sleeping, 0 stopped, 1 zombie Cpu(s): 84.0%us, 11.7%sy, 4.3%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 444296k total, 262260k used, 182036k free, 7964k buffers Swap: 1309256k total, 171556k used, 1137700k free, 127936k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5615 david 20 0 75632 4988 4900 S 87.0 1.1 252:17.91 mencoder 13509 david 39 19 0 0 0 Z 4.3 0.0 0:01.06 gnome-video- <defunct> 4285 root 20 0 214m 27m 4092 S 2.0 6.2 3:58.08 Xorg 11 root 15 -5 0 0 0 S 1.0 0.0 1:03.35 kacpid 5258 david 20 0 39836 7892 3064 S 1.0 1.8 0:58.34 gnome-terminal 851 root 16 -4 2360 364 256 S 0.7 0.1 0:00.89 udevd 13525 david 20 0 29384 4012 2848 D 0.7 0.9 0:00.02 mencoder 12 root 15 -5 0 0 0 S 0.3 0.0 0:16.42 kacpi_notify 4963 david 20 0 3196 1148 488 S 0.3 0.3 0:01.05 dbus-daemon 4998 david 20 0 37156 3544 2452 S 0.3 0.8 0:04.50 gnome-settings- 13311 david 20 0 2452 740 460 R 0.3 0.2 0:01.49 top 1 root 20 0 3084 272 220 S 0.0 0.1 0:01.12 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 I'll try the reduced frame rate in a moment. -- Davey.
From: Davey on 2 May 2010 18:22 On Sun, 02 May 2010 21:33:21 +0100 Andy Furniss <spam(a)andyfurniss.entadsl.com> wrote: snip Bingo! By a) shutting down everything else that wasn't needed, and b) by modifying the width/height values, I finished up with a 60-sec file of watchable video. For the first time, the seconds counter while running was true, as opposed to lagging behind. Last command: david(a)david-laptop:~$ mencoder -vf scale=-1:-1:1,harddup -of lavf -oac pcm -ovc lavc -lavcopts vcodec=mjpeg -ofps 30000/1001 -o testfile3.avi tv:// -tv driver=v4l2:norm=NTSC:device=/dev/video1:width=540:height=360:outfmt=yv12:audiorate=48000:immediatemode=0:forceaudio:adevice=/dev/dsp1:volume=2000 So now that I can record, apparently, successfully (I'll try a long run later), the next stage is to turn it into a form that can eventually be transferred to DVD. Enough for one day, but a success!! Thanks again. -- Davey.
From: Tony Houghton on 2 May 2010 19:04 In <hrktvt$oj5$1(a)n102.xanadu-bbs.net>, Davey <davey(a)example.invalid> wrote: > By a) shutting down everything else that wasn't needed, and b) by > modifying the width/height values, I finished up with a 60-sec file of > watchable video. For the first time, the seconds counter while running > was true, as opposed to lagging behind. > > Last command: > david(a)david-laptop:~$ mencoder -vf scale=-1:-1:1,harddup -of lavf -oac > pcm -ovc lavc -lavcopts vcodec=mjpeg -ofps 30000/1001 -o testfile3.avi > tv:// -tv > driver=v4l2:norm=NTSC:device=/dev/video1:width=540:height=360:outfmt=yv12:audiorate=48000:immediatemode=0:forceaudio:adevice=/dev/dsp1:volume=2000 > > So now that I can record, apparently, successfully (I'll try a long run > later), the next stage is to turn it into a form that can eventually be > transferred to DVD. > Enough for one day, but a success!! I don't understand why you've had this performance problem. It's a P4 system isn't it? Have you tried encoding straight to mpeg2video instead of mjpeg? Mencoder/ffmpeg's MPEG2 encoder doesn't need much CPU power. I've managed to encode 720x576 MPEG2 from an analogue TV card which didn't have its own encoder, on a modest system (IIRC it was an AMD "1500" of some sort, I thought it was a Duron, but there doesn't seem to have been such a model according to Wikipedia). I had tried DV because I thought the lower compression would mean lower performance demand, but I was completely wrong. That might have been down to disk rather than CPU performance though. Whatever the reason, maybe there's a similar unexpected performance issue with mjpeg. I even transcoded from MPEG4 to MPEG2 on the fly on a 1.2GHz P3 Celeron (may even have been something slower) so I could watch something on a DXR3. -- TH * http://www.realh.co.uk
From: Davey on 3 May 2010 11:02
On Sun, 2 May 2010 23:04:04 +0000 (UTC) Tony Houghton <h(a)realh.co.uk> wrote: > In <hrktvt$oj5$1(a)n102.xanadu-bbs.net>, > Davey <davey(a)example.invalid> wrote: > > > By a) shutting down everything else that wasn't needed, and b) by > > modifying the width/height values, I finished up with a 60-sec file > > of watchable video. For the first time, the seconds counter while > > running was true, as opposed to lagging behind. > > > > Last command: > > david(a)david-laptop:~$ mencoder -vf scale=-1:-1:1,harddup -of lavf > > -oac pcm -ovc lavc -lavcopts vcodec=mjpeg -ofps 30000/1001 -o > > testfile3.avi tv:// -tv > > driver=v4l2:norm=NTSC:device=/dev/video1:width=540:height=360:outfmt=yv12:audiorate=48000:immediatemode=0:forceaudio:adevice=/dev/dsp1:volume=2000 > > > > So now that I can record, apparently, successfully (I'll try a long > > run later), the next stage is to turn it into a form that can > > eventually be transferred to DVD. > > Enough for one day, but a success!! > > I don't understand why you've had this performance problem. It's a P4 > system isn't it? Have you tried encoding straight to mpeg2video > instead of mjpeg? Mencoder/ffmpeg's MPEG2 encoder doesn't need much > CPU power. I've managed to encode 720x576 MPEG2 from an analogue TV > card which didn't have its own encoder, on a modest system (IIRC it > was an AMD "1500" of some sort, I thought it was a Duron, but there > doesn't seem to have been such a model according to Wikipedia). I had > tried DV because I thought the lower compression would mean lower > performance demand, but I was completely wrong. That might have been > down to disk rather than CPU performance though. Whatever the reason, > maybe there's a similar unexpected performance issue with mjpeg. > > I even transcoded from MPEG4 to MPEG2 on the fly on a 1.2GHz P3 > Celeron (may even have been something slower) so I could watch > something on a DXR3. > If you go back in the thread, you will see that I am floundering in a world I know little about. I had never used mencoder, and had only used mplayer to, well, play short videos, and had never used mplayer from the command line. From the beginning of this process, throughout which Andy Furniss has been supremely helpful and patient, I have welcomed and tried all and every suggestion, and built on those where I have been able to. Quoting a load of references that mean little or nothing to me, with the "It works for me" ref., is not helpful. Sorry if that's harsh, but Andy has been extremely helpful and has guided me. I am receptive to all suggestions which steer me in the right direction, but "I even did so-and-so" does not do that. I can get that kind of help in other groups. Now, if you make suggestions in a manner which is useful to me, the non-power programmer here, I am happy to try them. I will take your suggestion to try mpeg2video when I next connect everything up again. Remember, I used to use Windows exclusively, and have only recently switched over to Linux, and there are still things which I have trouble doing as easily as in the old days. Such as using the Dazzle, which with XP was literally, 'plug it in, pop a blank DVD in the tray, press 'Start Recording', and come back in an hour'. -- Davey. |