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

The Eye mhellwig at gmx.at
Sun Feb 27 20:42:23 CET 2005


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?

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


> > Anyway, 9 times out of 10, this works just perfectly. But once in a
> > while, I get lots of errors like
> > Video-buffer full, dropping frame
> > 
> > and in the resulting file, audio and video are _badly_ out of sync (like
> > 20-30 seconds out of sync).
> > 
> > Questions: what is the cause of this? What exactly does "video-buffer"
> > in this context mean? Is it some part of the tv-card or something else?
> > Because in this case nothing should go via video-card, or am I wrong?
> 
> It means your cpu is too slow, and it's getting so far behind that it
> will never catch up.
> 

Oh. whoops. So I guess my claim that nothing else dragging on the system
running at the same time must have been a mistake *ponders*

> > And of course: what can I do to stop this from happening?
> 
> Capture at a lower resolution or with less filters, etc. Another good
> option would be to capture audio as raw pcm (to be reencoded to mp3
> later) or as mp2 (with -oac lavc -lavcopts acodec=mp2:...), since lame
> is atrociously slow.
> 

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?


> > As far as I can tell, nothing that is a drag on CPU or memory is running
> > on this machine whilst running the recording, I even make a point of
> > stopping X before starting the recording ...
> 
> Yes, but your command line needs an insanely fast cpu to encode
> realtime..
> 

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.

Thanx for any other tips somebody might have.

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,
it's just that I sometimes wanna watch stuff that's on when I'm not at
home. OTOH stuff that needs filters not while recording but playing is
not good either cos I'm not always watching on this fast machine (which
does the encoding) but also on a very slow old PC at my girlfriends
place which just barely manages to play an avi without any filters.

-- 
Michael Hellwig  aka  The Eye                 olymp.idle.at admin
check out http://homepage.uibk.ac.at/~csaa5128 for gpg public key
        and don't hesitate to look at http://laerm.or.at




More information about the MPlayer-users mailing list