Hal MacArgle wrote:
On 08-01, Ray Olszewski wrote:
Hal MacArgle wrote:
On 06-17, Ray Olszewski wrote:
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 $filename
replacing $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.)
This should be directed to Ray I guess but was wondering what
speed CPU he uses with the above to get 29.97fps without pauses and
if the HD is UDMA100?? (NTSC tapes, sound-card line in audio and bttv
BT878 capture card..
I do video capture on two different machines. I've only done tape
transfer on the higher quality of the two, which is also my main
fileserver. Its specs are:
Athlon64 3000
1 GB DDR 400 (3200) RAM
main HD is a Seagate 300 GB drive, I think UDMA 100 (maybe 133),
with (of course) DMA enabled
kernel 2.4.27, compiled for Athlon, Debian-Sid install
And all the stuff you put in parentheses represents correct assumptions
about my setup:
Soundblaster sound card (es1371 driver)
AverMedia TV card (bttv driver), with jumper cable to sound card
several different VHS-NTSC VCRs
OK, thanks Ray.. You're way update of my 1.3gHz Duron and 1gB
PC133 SDRAM.. Trying all capture schemes that I can I've deduced that
I have to be content with a max of 20fps and 384x288.. No matter CLI
or X11 run.. I'll try to fit an Athlon supported by the MB. Specs say
2.6 IIRC, or live with what I have.. <grin>
Well ... yes and no. You had specifically asked about what I used for
capturing from tapes. Prior to getting the Athlon (just this year), I
for several years used the app "vcr" on a 1 GHz Pentium-3 machine with
768 MB or 1 GB (I forget) of P133 RAM. vcr used different codecs from
mencoder, but it used more CPU cycles whenever I tried the two on the
same equipment ... and it handled off-the-air captures just fine (used
about 35% of CPU cycles on the P3).
Meanwhile a real head scratcher: Running SpinRite on both
HD's, Duron machine, I get 2600kBs sustained transfer on one HD and
8800kBs on the other, both UDMA100's with identical BIOS settings..
Checking on a much older machine with an UDMA66 HD; I get 4700kBs??
Back to the drawing board on that one, eh? I'm sure I used the "slow"
machine and that may be my biggest problem.. I should keep better
notes..
Offhand, I don't recall what CPU use I see when transferring tapes (I
haven't done any recently). Recording off the air (analog cable,
actually), it's under 10%.
CPU usage has been 10% or less here so I wonder if a CPU
speed up would really help??
I assume we are talking about the same thing -- *total* CPU use as
reported by "top" up at the top (that is, 100% - "idle" percent).
**NOT** process-specific CPU use, or just "user" use (actually, recent
versions of top seem to have changed the labels to be less readable, so
for them I mean id = idle, us = user). Especially when you have X
running, context switching can be a big part of CPU load, and
proces-specific CPU use doesn't pick this up.
If we are talking about the same thing, then I'm impressed at the
efficiency of your encoding system. And then you're right to doubt that
a faster CPU would help. In that case, I *think* the next thing I'd
check is interrupts ... when doing video, I always make sure that I'm
not IRQ sharing anything involved in the capture process ... the bttv
card, the sound card, or (unlikely) the hrad disk. In my case, the NIC
too, since I'm accessing the capture host remotely, over ssh.
For off-the-air capture, my other machine is a Celeron 1.7 GHz, with 256
MB RAM, some UDMA100 hard disk, and the same sound and TV cards. Taping
off the air (digital cable this time), it only runs at about 20% CPU use
.. but tapes are noisier than my cable feed, so they place more demand
on the codec, so I don't know if this machine would do tapes well.
Note, though, that I only capture at 320x240. I've tried 640x480 but run
into problems there, for reasons I don't really understand (not CPU
limits, at least not on the Athlon ... maybe problems with deinterlacing?).
All capture trys here at full DVD size of 720x480, 29.97 NG
of course..
Based on my experience, I'd doubt that a 1.3 GHz CPU is up to doing
real-time capture at that size. My 1 GHz P-3 sure wasn't ... it dropped
frames if I tried 640x480x29.97. If you're doing this and seeing 10%
total CPU use, either something is very odd or you know some trick I don't.
One query about mencoder? Whilst recording I get two reports;
"0min" and "0mb".. Should they not report what's recording? Needless
to say I've not gotten mencoder to work yet for capturing.. In other
words when recording shouldn't both of them increment? Thanks..
I'm not *quite* sure what you are asking. I just checked, though, and my
mencoder (while doing a short off-the-air test capture) displays to the
screen like this:
++++++++++++++++++++++
Pos: 38.2s 1144f ( 0%) 30fps Trem: 0min 0mb A-V:0.000 [819:128]]
++++++++++++++++++++++++
The s (seconds) and f (frames) values increment steadily, at the rates
you'd expect, but not the others (min and mb). Then at the end, I get
this output:
++++++++++++++++++++++
Flushing video frames
CBR audio: 16000 bytes/sec, 576 bytes/block
Writing AVI index...
Fixing AVI header...
ODML: Aspect information not (yet?) available or unspecified, not
writing vprp header.
Video stream: 802.869 kbit/s (100358 bps) size: 12045047 bytes
120.020 secs 3595 frames
Audio stream: 128.000 kbit/s (16000 bps) size: 1919808 bytes 119.988
secs
MJP: returning!
++++++++++++++++++++++++++++++
Hope this helps, Hal. I'd also recommend that you try the exact command
I provided above and see what that does for you, if you're having
trouble with mencoder itself. Or, even better, try this one (it will
record off-the-air, if your vidcap card is receiving TV signals and it
tuned to a valid channel) to see if the problem is specific to use of
the VCR:
mencoder tv:// -tv driver=v4l:device=/dev/video0:input=0:\
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 $filename
Change the 320 and 240 to 384 and 288 (the PAL numbers) of you're on a
PAL setup, but otherwise leave it as is, at least for a test, and see
what you see in mplayer or xine or whatever you use to watch recordings.
-
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
