Cinelerra--Video Editing??

I have Cinelerra working and am trying simple editing like removing
extraneous head and tail frames from .vob files that were captured
from VHS or Beta tape with xawtv and converted from it's default .avi
to .vob using videotrans because Cinelerra will not work with .avi
files..

After editing I render the project to a mpeg4 file that views with
the audio out of sync.. I tried both ways: a single .vob file with
muxed audio or separate video, m2v and audio, mp2 files.. If I
render either way without editing, the sync is fine...

I suspect this may be "normal" but can't seem to find any clues on
the Web... Most of the forums I've checked seem to mostly talk about
getting the program running in the first place.. No easy task it
seems.. I didn't "sail" through it either.

Any comments appreciated!! BTW I got one suggestion that I didn't
have enough memory, 512mB; so I upfitted to over 1gB, with no obvious
improvement.. The CPU is a Duron 1.3gHz which should be fast enough
according to most accounts.. I don't think it's the HD's because
rendering unedited files are in perfect sync... TIA.

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

Hal MacArgle wrote:
> I have Cinelerra working and am trying simple editing like removing
> extraneous head and tail frames from .vob files that were captured
> from VHS or Beta tape with xawtv and converted from it's default .avi
> to .vob using videotrans because Cinelerra will not work with .avi
> files..
>
> After editing I render the project to a mpeg4 file that views with
> the audio out of sync.. I tried both ways: a single .vob file with
> muxed audio or separate video, m2v and audio, mp2 files.. If I
> render either way without editing, the sync is fine...
>
> I suspect this may be "normal" but can't seem to find any clues on
> the Web... Most of the forums I've checked seem to mostly talk about
> getting the program running in the first place.. No easy task it
> seems.. I didn't "sail" through it either.
>
> Any comments appreciated!! BTW I got one suggestion that I didn't
> have enough memory, 512mB; so I upfitted to over 1gB, with no obvious
> improvement.. The CPU is a Duron 1.3gHz which should be fast enough
> according to most accounts.. I don't think it's the HD's because
> rendering unedited files are in perfect sync... TIA.
>

Just a couple of questions, Hal. If I follow you right, the sync is
still good after the videotrans step, but fails only after you use
Cinelerra to delete sections of the video (and corresponding audio).
Assuming that:

1. What does the out-of-sync look like? Does it start out sync'd and
drift away gradually and consistently over the length of the edited
video; does it jump in spurts around the deletes (or elsewhere); or is
it consistently off for the length of the video? Or something else I
haven't thought of?

2. Am I right in assuming that you are capturing at standard NTSC speed,
29.97 frames per second? And maintaining that framerate when you do the
videotrans transcode? Assuming a yes ... when do the actual Cinelerra
editing, might you be messing this up somehow (moving from 29.97 to 30
fps, or even to whatever the framerate is for PAL ... 24 fps maybe?)?

Sync problems with captured video aren't rare. Using mencoder here, I
still run into occasional cases where TV shows lose sync during the
commercial breaks, for example. I also run into sync problems,
presumably in the lame mp3 encoder, when I try to change the sampling
rate. And back when I used vcr, it had a drift problem that made sync
noticeably bad after about 2 hours or continuous recording. That said,
though, I never see a sync problem when editing; they always occur at
capture.

Unfortunately (for the purpose at hand), video editing is one of the few
places I find I prefer to use Windows tools, specifically Virtual Dub,
so I can't make suggestions that are specific to Cinelerra.

The suggestion about memory was almost surely a red herring; even
real-time video capture isn't that demanding of memory. (I do my main
capturing on a 1.7 GHz Celeron with 256 MB RAM and UDMA100 hard disks.)
And since this is not real-time processing, CPU speed should also be
irrelevant.

BTW, is the audio file type really "mp2" or was that a typo?

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

On 06-15, Ray Olszewski wrote:
> Hal MacArgle wrote:
> >I have Cinelerra working and am trying simple editing like removing
> >extraneous head and tail frames from .vob files that were captured
> >from VHS or Beta tape with xawtv and converted from it's default .avi
> >to .vob using videotrans because Cinelerra will not work with .avi
> >files..
> >
> >After editing I render the project to a mpeg4 file that views with
> >the audio out of sync.. I tried both ways: a single .vob file with
> >muxed audio or separate video, m2v and audio, mp2 files.. If I
> >render either way without editing, the sync is fine...
> >
> >I suspect this may be "normal" but can't seem to find any clues on
> >the Web... Most of the forums I've checked seem to mostly talk about
> >getting the program running in the first place.. No easy task it
> >seems.. I didn't "sail" through it either.
> >
> >Any comments appreciated!! BTW I got one suggestion that I didn't
> >have enough memory, 512mB; so I upfitted to over 1gB, with no obvious
> >improvement.. The CPU is a Duron 1.3gHz which should be fast enough
> >according to most accounts.. I don't think it's the HD's because
> >rendering unedited files are in perfect sync... TIA.
> >
>
> Just a couple of questions, Hal. If I follow you right, the sync is
> still good after the videotrans step, but fails only after you use
> Cinelerra to delete sections of the video (and corresponding audio).

Yes and bear with me as I detail: videotrans -m ntsc -M
anyfile.avi creates; anyfile.vob. The original .avi file is
76mB and the .vob file is 7.6mB with no discernable quality diff that
I could see viewing with either mplayer or xine.. MPlayer reports the
..vob file as Mpeg12, 29.970fps with 48000 2 channel audio, even
though the original audio was either mono or stereo.. Obviously the
avi file is raw and the vob compressed but in both cases perfectly in
sync..

If I invoke: videotrans -m ntsc anyfile.avi, it creates two
files: anyfile.m2v and anyfile.mp2.. MPlayer reports the video as
MPEG2 and the audio as, 48000 2 channel. (Am OK so far because I read
that MPEG1 is muxed audio and MPEG2 is separate video/audio..)
(Loading these separate files into Cinelerra views in sync, before
editing. Have I checked after editing? Not sure, but I've got to look
into that..)

Cinelerra editing to remove the extraneous head and tail
frames with the picture and sound "locked" together on the time line,
I render to a "quicktime for Linux," as recommended, muxed .mov file,
that views out of sync and MPlayer reports it as a Mpeg4 file, as
expected.. BUT, I note the report as video MP4 and audio 41000 2
channel.. Maybe that's the problem 48000 converted to 41000... Maybe
MP4 can't "handle" 48000??? I've got to check more into this.. (I
just noticed this whilst doing the above for this.)

Why can't I save the edited file as a .vob like the
original?? Good question; wish I knew.. Too bloody many acronyms and
codecs for me I think.. That's for me and Cinelerra to figure out
/or/ possibly, yet another back end??



> Assuming that:
>
> 1. What does the out-of-sync look like? Does it start out sync'd and
> drift away gradually and consistently over the length of the edited
> video; does it jump in spurts around the deletes (or elsewhere); or is
> it consistently off for the length of the video? Or something else I
> haven't thought of?

Only trying small, 5-10 minute run time files, I'm not sure..
Sporadic dialogue makes it hard to tell but it looks like all lip
sync is a fixed offset.. You are probably thinking about dropped
video frames along the way and, again, I'm not completely sure.. I
have so much more to learn.. (I bought a book but it was limited in
scope.) You know the drill; click this, click that...




> 2. Am I right in assuming that you are capturing at standard NTSC speed,
> 29.97 frames per second? And maintaining that framerate when you do the
> videotrans transcode? Assuming a yes ... when do the actual Cinelerra
> editing, might you be messing this up somehow (moving from 29.97 to 30
> fps, or even to whatever the framerate is for PAL ... 24 fps maybe?)?

This is the subject of another quandry: I configure xawtv to
capture "NTSC" instead of it's default PAL.. That's easy.. It, also,
defaults to 12fps but I can change that in increments up to 29.970..
I've found that up to 20fps seems to work OK, over that it doesn't
like.. I've put this anomoly aside for the time being because
videotrans changes any captures to 29.970 default as long as I use
the -m ntsc flag.. Anyway--as mentioned--the captured .avi file and
it's converted .vob file are both in perfect sync before editing..
I've got to think more about 48000 and 41000 sound.. That's got to be
it I think.. Maybe, eh?? My mind is blown... I thought about trying
'transcode' instead of 'videotrans' as well as 'tovid', but I don't
think that's the problem..




> Sync problems with captured video aren't rare. Using mencoder here, I
> still run into occasional cases where TV shows lose sync during the
> commercial breaks, for example. I also run into sync problems,
> presumably in the lame mp3 encoder, when I try to change the sampling
> rate. And back when I used vcr, it had a drift problem that made sync
> noticeably bad after about 2 hours or continuous recording. That said,
> though, I never see a sync problem when editing; they always occur at
> capture.

Too many options and I see much out of sync stuff on the
telly too, so we're not alone... In that business all my life,
analogue, I may be too critical. Who knows.. The Moviola was MUCH
easier...




> Unfortunately (for the purpose at hand), video editing is one of the few
> places I find I prefer to use Windows tools, specifically Virtual Dub,
> so I can't make suggestions that are specific to Cinelerra.

I fetched Virtual Dub at one time but this stubborn Scot
refuses to use any M$ stuff these days.. Oh well, my hang up..
IIRC Virtual Dub is GPL though... Hmmmmm. I'm allergic to M$'s
crashes too..



> The suggestion about memory was almost surely a red herring; even
> real-time video capture isn't that demanding of memory. (I do my main
> capturing on a 1.7 GHz Celeron with 256 MB RAM and UDMA100 hard disks.)
> And since this is not real-time processing, CPU speed should also be
> irrelevant.

You're right and I got to thinking that most Linux video code
was written before the more than 1gHz CPU's were common.. However,
that doesn't stop the Cinelerra group to "recommend" using a box with
2Gb memory, dual 2.0gHz CPU's and a SATA HD... Of course that might be
needed when editing multi video tracks in collages, whatever.. It is
a powerful program, quite professional and is used professionally
too.. If I could find an easier Linux route for my so called simple
means.. Both the HD's in that box are UDMA100's but does Linux know
that?? Another research road.. (When someone recommends something,
why don't they say why?? No complaint intended considering the
thousands of people hours to write that code..)



> BTW, is the audio file type really "mp2" or was that a typo?

No, as mentioned above that's what videotrans labels the
audio file both in my case above and when the files are prepared for
DVD burning as outlined by Chuck..

As usual; APPRECIATE!!

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??

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

Hal MacArgle wrote:
[...]
>>>Any comments appreciated!! BTW I got one suggestion that I didn't
>>>have enough memory, 512mB; so I upfitted to over 1gB, with no obvious
>>>improvement.. The CPU is a Duron 1.3gHz which should be fast enough
>>>according to most accounts.. I don't think it's the HD's because
>>>rendering unedited files are in perfect sync... TIA.
[...]
> This is the subject of another quandry: I configure xawtv to
> capture "NTSC" instead of it's default PAL.. That's easy.. It, also,
> defaults to 12fps but I can change that in increments up to 29.970..
> I've found that up to 20fps seems to work OK, over that it doesn't
> like.. I've put this anomoly aside for the time being because
> videotrans changes any captures to 29.970 default as long as I use
> the -m ntsc flag.. Anyway--as mentioned--the captured .avi file and
> it's converted .vob file are both in perfect sync before editing..
> I've got to think more about 48000 and 41000 sound.. That's got to be
> it I think.. Maybe, eh?? My mind is blown... I thought about trying
> 'transcode' instead of 'videotrans' as well as 'tovid', but I don't
> think that's the problem..
[...]
> You're right and I got to thinking that most Linux video code
> was written before the more than 1gHz CPU's were common.. However,
> that doesn't stop the Cinelerra group to "recommend" using a box with
> 2Gb memory, dual 2.0gHz CPU's and a SATA HD... Of course that might be
> needed when editing multi video tracks in collages, whatever.. It is
> a powerful program, quite professional and is used professionally
> too.. If I could find an easier Linux route for my so called simple
> means.. Both the HD's in that box are UDMA100's but does Linux know
> that?? Another research road.. (When someone recommends something,
> why don't they say why?? No complaint intended considering the
> thousands of people hours to write that code..)

[...]
> 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.)

CPU -- For years, I captured on a 1 GHz Pentium-3 system. Using vcr and
compressing to mpeg4 (DivX), a 320x44-x29.97 fps capture took about 65%
of CPU cycles. I tried xawtv briefly, before setting on vcr, but I don't
recall how its CPU load compared (X overhead from context shifts could
make it a *lot* worse than the cli-based app I used). But one thing I'd
recommend your doing is trying to capture at 29.97 fps while watching
CPU load (as reported by "top") in an xterm. If you see it hitting 90%
or more a lot, that's the likely source of your dropped frames. (Do be
sure you use an xterm, not switch over to a vt, since if X overhead is
the culprit, you need the X display to be active to see the effect,
which will show as a high "system" load.)

Drives -- Since you are doing raw capture, you're needing to write a LOT
to the hard disk. You don't report exact numbers, but you do mention a
76 MB file and typical lengths of 5-10 minutes for the fies you capture
at 20 fps. If we assume 5 minutes, that's 15 MB/minute to write, and
moving up to 29.97 fps kicks that up to about 23 MB/minute. That's not
too much of the drives use DMA -- here, mine write something like 2
GB/minute -- but if they don't, it could easily cause problems.

Use (as root) "hdparm" to check this, following this example
(substituting the right /dev/* entry for your setup):

new-flagg:~# hdparm /dev/hdd

/dev/hdd:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 15017/255/63, sectors = 241254720, start = 0

The one you're interested in is (duh!) "using_dma". If it is set to 0,
your drive does NOT currently use DMA. Change that (assuming the drive
supports DMA; you said yours were UDMA100, so they do) with a command
like "hdparm /dev/hdd -d 1".

If neither of these hits the target, post a followup with

the CPU-load numbers from the first test
output of "free"
confirmation or correction of my guess that the problem is dropped frames
what kernel you are using ("uname -a")
what capture device you are using and what kernel module it uses (I've
been assuming some bttv device, but there are others around as well).

At this point, it is hard for me to make any additional suggestions
about the sync problem. When I used vcr, I captured audio at 48000. When
I switched to mencoder, I had to cut it back to 32000 to get proper
sync. So it is certainly possible that Cinelerra has some problem with
integrating 48000 into MP4 ... or it may just be some bad setting in
Cinelerra that you haven't found yet.

On this score, I'd suggest making a video in which it is easy to see how
the sync fails ... maybe a talking head reciting poetry or something of
that sort (I assume you're not set up to record anything truly exact,
like a metronome ticking). A better characterization of the sync problem
could provide some guidance.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

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..
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 with
Cinelerra but not mplayers' viewing??




> CPU -- For years, I captured on a 1 GHz Pentium-3 system. Using vcr and
> compressing to mpeg4 (DivX), a 320x44-x29.97 fps capture took about 65%
> of CPU cycles. I tried xawtv briefly, before setting on vcr, but I don't
> recall how its CPU load compared (X overhead from context shifts could
> make it a *lot* worse than the cli-based app I used). But one thing I'd
> recommend your doing is trying to capture at 29.97 fps while watching
> CPU load (as reported by "top") in an xterm. If you see it hitting 90%
> or more a lot, that's the likely source of your dropped frames. (Do be
> sure you use an xterm, not switch over to a vt, since if X overhead is
> the culprit, you need the X display to be active to see the effect,
> which will show as a high "system" load.)
>
> Drives -- Since you are doing raw capture, you're needing to write a LOT
> to the hard disk. You don't report exact numbers, but you do mention a
> 76 MB file and typical lengths of 5-10 minutes for the fies you capture
> at 20 fps. If we assume 5 minutes, that's 15 MB/minute to write, and
> moving up to 29.97 fps kicks that up to about 23 MB/minute. That's not
> too much of the drives use DMA -- here, mine write something like 2
> GB/minute -- but if they don't, it could easily cause problems.
>
> Use (as root) "hdparm" to check this, following this example
> (substituting the right /dev/* entry for your setup):
>
> new-flagg:~# hdparm /dev/hdd
>
> /dev/hdd:
> multcount = 16 (on)
> IO_support = 1 (32-bit)
> unmaskirq = 1 (on)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 15017/255/63, sectors = 241254720, start = 0

Both drives on my "video" machine same as above except the
geometry of course and multcount is (off).. Can't seem to find what
that really means so I tried one run with it set and didn't notice any
obvious difference.. It seems to be shorthand for Multiple Sector
Count" but what does that mean?? I just noticed that my machines
readahead is 256 (on).. Does that mean anything??



>
> The one you're interested in is (duh!) "using_dma". If it is set to 0,
> your drive does NOT currently use DMA. Change that (assuming the drive
> supports DMA; you said yours were UDMA100, so they do) with a command
> like "hdparm /dev/hdd -d 1".
>
> If neither of these hits the target, post a followup with
>
> the CPU-load numbers from the first test

The above is the cpu% of the program.. The system cpu% is 100
during idle and around 60-70 during a recording.. I wish I knew what
so much of this means in real life..




> 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
------------------------------------------------------------ ------------------
> confirmation or correction of my guess that the problem is dropped
> frames
> what kernel you are using ("uname -a")

Slackware 10.2 with it's "test26.s" kernel; 2.6.13...
Normally 2.4.31 is installed but Cinelerra wouldn't compile using
it.. BTW I went thru all this with FC4 and it's RPM package and was
in worse trouble than now.. Such fun?? Also, tried FC5 and Cinelerra
didn't work at all with it, IIRC..




> what capture device you are using and what kernel module it
> uses (I've been assuming some bttv device, but there are
> others around as well).

I, originally, had an ATI AllInWonder but it's not as well
supported as BrookTree; so I got a BT878 card and am using it.. Am
almost positive I didn't do any Linux capturing with the ATI card,
just viewing.. Some of the files were captured using the program that
came with the ATI card under Win98FE, but I can't remember which
now.. I should start from the beginning again, I think...




> At this point, it is hard for me to make any additional suggestions
> about the sync problem. When I used vcr, I captured audio at 48000. When
> I switched to mencoder, I had to cut it back to 32000 to get proper
> sync. So it is certainly possible that Cinelerra has some problem with
> integrating 48000 into MP4 ... or it may just be some bad setting in
> Cinelerra that you haven't found yet.

You have offered yeoman service and I appreciate that.. As
you know, so much of the features are un-documented expecially the
error reports.. Not complaining, the developers have their hands full
especially with streaming video that's a subject all it's own..
I shouldn't expect to get it mastered in a few hours..




> On this score, I'd suggest making a video in which it is easy to see how
> the sync fails ... maybe a talking head reciting poetry or something of
> that sort (I assume you're not set up to record anything truly exact,
> like a metronome ticking). A better characterization of the sync problem
> could provide some guidance.

That's a good idea and I should really practice my engineer
training better and standardise on one route and, especially, pin
down one problem before I aggrivate it with another.. I've got to
sort out what MPlayers' report really means: Typically for a 3 minute
recording it will report: A: 179.6 V: 180.0 A/V: -0.347.. That,
to me, means the two recording lengths are different but I watch the
A/V dynamically during recording and it never deviates away from
0.000 until the playback stops.. Some times the end is 0.000 but
never predictable, that I can see..

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

Hal MacArgle wrote:

>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
>----------------------------------------------------------- -------------------
>
>
Check if you have "High Memory Support (4GB)" in kerneloptions, there
was something with a ~900Mb limit if not, can't remember exactly.

Just my 2 cents

Greets, Chris



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

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% idle

If 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 with
> Cinelerra 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 $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.)

[...]
>> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

On 06-17, Ray Olszewski wrote:
> 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% idle

OK I have this now. Later on when rendering files I note the
usage around 86%, mp2enc, but the sync problem is now moot, at least
for shorter files. More on this later.. I'll start doing more capture
testing, with the editing problem mostly out of the way, at least
with shorter files..




> 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 $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.)
>

It seems almost every program front ends for mplayer and
mencoder.. I tried using 'tovid' rather than 'movie-to-dvd' converting
the files from .avi to something that Cinelerra could work with..
Either .vob, as I've been using or .mpg created by Tovid.. The
..mpg files are larger but end up with 48000/2ch, 720x540, 32bpp and
29.970.. AND, when edited with Cinelerra I don't lose sync, rendering
them to MPeg4 as a QuickTime for Linux file as recommended by
Cinelerra...(.mov) Your 32000 audiorate requirement for sync puzzles
me especially since your final viewing will be 44100 I suspect.. The
32000, 44100 and 48000 "standards" are confusing; not the sampling
rate per se but why the various programs fiddle with it so much..
32000 is plenty high in the frequency response; most couldn't tell
the difference.. Maybe their animals though, eh?? Why the 48000
standard; who can hear 24kHz?? Overkill??

Apparently there's a ton of different parameters I must learn
with video so I'll be at it for a long, long time.

Glued to "top" I note that swap is never used with anything I
try, so memory seems plenty.. Since I bought it, I'll leave it be
rather than changing back to 512K..




>
> Someone else already pointed out that you need a kernel that supports
> high-memory to go above 900 MB or so.

Yes, Christian wrote and I accessed the URL you mentioned
below that has the complete information.. I don't believe I have to
re-compile the kernel though; maybe later..




> 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.

I'll pay more attention in the future and might learn more..
The cache figure explains much of what goes on with this business..
Amazing stuff..



> The Gentoo FAQ has a particularly good discussion of all this stuff.
> Read it at
>
> http://gentoo-wiki.com/FAQ_Linux_Memory_Management

I was impressed with their site so ordered a live copy of
their latest release.. Peter is using it and says it's good but I'm
still a Slackware person..

Bottom line; I'm in business with my original project until I
can find some other mischief to get into.. Your tutoring has surely
speeded up and flattened my learning curve considerably.. Appreciate!

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Cinelerra--Video Editing??

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..

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

tape transfer with mencoder (was: Re: Cinelerra--Video Editing??)

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

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%.

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?).

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: tape transfer with mencoder (was: Re: Cinelerra--Video Editing??)

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..

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??


> 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..

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..

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: tape transfer with mencoder

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..

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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: tape transfer with mencoder

On 08-02, Ray Olszewski wrote:
> Hal MacArgle wrote:
> >On 08-01, Ray Olszewski wrote:

> >>
> >>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..
>
> 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).

I am now using mencoder, raw, 29.97 320x240 with the
recording smooth but the quality not quite as good as the original
viewed with Xawtv.. Also confusing that the view quality different
between mplayer (svgalib) and mplayer (X11) with Xine (X11) the best
of all.. Record mencoder--play xine.. I'm really confused now.. Got to
be the video card entering into the mix somewhere.. Recording to the
same HD partition as the programs; top reports a toggle'd idle of 75%
to 95%.. Recording to another HD I get a solid id of +- 95% all the
time.. I've decided that "id" is the best indicator, at least for me,
keeping watch on what the CPU is doing..



> 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.

I'm not using the NIC and all work from /root.. Only IRQ's
involved would be the soundcard, I believe.. I've got to study more
about PCI assigned IRQ's.. It never ends, eh?

>
> 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.

No tricks and the more I mess, the less I know.. I
wish the authors would list the defaults better as there are a
bazillion parameters.. I expect that everything enters into the loop
from time to time and I'm lucky to get anything working...



> 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!
> ++++++++++++++++++++++++++++++

You answered the query: 0min 0mb and A/V doesn't change no
matter what.. The ones on the left do, but they also change even if
you're not actually recording correctly.. The Pos: report helpful..
With zero input there's no real indication until you play the file..



> 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

Immense help Ray; getting deeper and deeper.. I'm not
locked to PAL and really can't be in the US.. That 384x288 is default
using Xawtv and can't be changed.. It was good to find that input=0
means "Composite1" as used by many other programs.. My BTTV card
doesn't have a tuner; it's composite and SVideo only..

>
> 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.

I check things with mplayer (svgalib, CLI) and mplayer
(X.org-X11) or Xine (X-11).. All three different and, to confuse
things more, Xine plays back Xaw AVI's with blue flesh tones.. The
"red" adjuster is stuck off.. Plays mencorders OK. I've documented
what I have to do, so no real problem.. It's not getting easier, eh??

Bottom line; I'll be using mencorder as the "standard" now
and see what other mischief I can get into... Appreciate!!!! CLI is
so much better, using vc's to watch and adjust other things, without
getting into too much trouble..

--

Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
..
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs