[MPlayer-users] TV-recording with mencoder, "video-buffer full"

[D Richard Felker III]

On Sun, Feb 27, 2005 at 08:42:23PM +0100, The Eye wrote:
> thanks for the ultra-fast reply!
> 
> On Sun, Feb 27, 2005 at 02:33:10PM -0500, D Richard Felker III wrote:
> > On Sun, Feb 27, 2005 at 08:18:19PM +0100, The Eye wrote:
> > > Hi list.
> > > 
> > > I searched through the list-archives and also googled through the docs
> > > and didn't find this anywhere so I hope it is OK asking here.
> > > 
> > > I often record stuff from my saa7134-based TV-card with a command like:
> > > 
> > > mencoder tv:// \
> > >  -tv driver=v4l2:width=768:height=576:amode=1:adevice=/dev/dsp1 -oac \
> > >  mp3lame -lameopts cbr:br=96 -ovc lavc -lavcopts \
> > >  vcodec=mpeg4:vbitrate=2000 -vf crop=698:558:12:2,scale=640:480,pp=lb /
> > >  -endpos 1:00:00 -o somefile.avi
> > >
> > > btw if anything about this is stupid, please tell me.
> > 
> > It is.
> > 1. NEVER rescale interlaced video vertically. You can do this after
> > deinterlacing, but not before.
> 
> ok, so I should change the order of pp=lb and scale, apart from all
> other considerations?

Yes.

> > 2. Why are you capturing at 768-width then cropping to 698, then
> > scaling down to 640? Instead, just set the capture width such that,
> > after cropping, the final size will already be 640. This will be a LOT
> > faster.
> > 
> 
> ah, OK. Hmmmm. I'm right now trying to remember why I set it up that
> way. I guess the original width and height statements in the -tv options
> came from me somehow remembering that this is supposed to be the PAL
> size. the cropping was simply removing the overscan stuff (i.e. the
> parts that are black). And iirc I was scaling it because after simply
> using the cropped picture, the width/height ratio was somehow wrong,
> i.e. it was elongated in the vertical direction.
> 
> So I'm guessing I originally somewhere did something wrong, and then
> corrected the mistake in the wrong place, thereby introducing yet
> another layer of speed drag.

It's not that you did something "wrong" to begin with. PAL is 576
lines (288 lines per field), but there's no such thing as a horizontal
resolution in video. You get to pick how many samples you want to take
horizontally, and for the sake of speed it's best to choose so that,
after cropping, you have the exact number you want without doing any
scaling.

> Hmmm. Never used mp2. Which bitrate would be recommendable for good
> TV-watching experience without noticeable defects? Or which mp2 bitrate
> is sort of comparable with 96 kbit/s of an mp3?

I don't know, but assuming you don't care about size, i'd use
something like 160-192 just to be safe. The mp2 encoder in lavc isn't
very advanced so it needs a fairly high bitrate for good quality.

> When nothing problematic is running, it takes about 60% here.
> 
> I just realized the possible culprit. There seems to be some problem
> with the jabber implementation of centericq (an ncurses messenger-client
> I use), which sometimes drives CPU usage up to 98%. I guess that would
> be the problem. So maybe I should just use your recommendations above
> and also stop centericq whilst recording.

Ah, ok. :)
By the way, running centericq "nice" could keep it from taking cpu
time away from your encoding.

> Note: I am usually recording stuff to be watched just once and not
> stored. So I don't particularly care about disk storage capacity needed,

OK. If you want lower cpu usage then, you could use a simpler codec
(e.g. mjpeg) or disable motion estimation (vme=0), or use mp2 or pcm
audio. But it sounds like the problem was just a broken program
bogging down the system, so you probably don't need that.

Rich