[mythtv-users] Frames per second?

[Bruce Markey]

Ray Olszewski wrote:
> At 09:38 AM 4/22/2003 -0500, Robert Kulagowski wrote:
> [...]
> 
>> Sure; write something up and I'll look at getting it included in the
>> HOWTO.
> 
> 
> Try this (in an appropriate spot in section 3.2) --
> 
> If your video-capture card uses the bttv kernel module (the common ones 
> do), you will want to be sure that when it loads, it loads with the 
> option "gbuffers=16" or "gbuffers=32" (exactly how to do this is a bit 
> distribution-specific). These settings give the bttv module enough 
> buffer space to store 16 or 32 capture frames, instead of the default 
> value of 2. The added buffering helps to minimize frame loss at times 
> when the capture stream is changing rapidly (fast pans, for example) in 
> ways that slow down the encoding process.

I've seen "gbuffers=32" posted often recently and have been
biting my tounge but if it might go in the docs I guess I
should speak up ;-).

This could be a huge number if there was no trade-off but
there is. Each buffer allocates about 2MB so 32 would need
64MB if they were all used. The need for additional memory
may cause virtual memory paging to occur which would kill
performance. As memory thrashes, the buffers fill causing
the need to page them in and... well, you get the idea ;-).

I've been happily using "gbuffers=8" since long before
discovering MythTV. If the encoder can't keep up with the
incoming frames, no number of buffers will save it (see
Lucy in the chocolate factory), it will just keep a longer
backlog while it drops frames. If it can keep up and there
are a few difficult frames or latency due to the process
scheduler, I/O events, etc. it could get a few frames
behind and still catch up. I doubt that it would fall more
than a second behind very often but still catch up without
dropping frames.

However, I haven't done any specific testing (yet ;-) to
see how much buffer space is needed to handle normal
behavior. I'm not even sure that there is one to one
relationship between number of buffers and number of frames
(the buffers are chuncks of memory and the framesize depends
on the resolution, etc.).

Still I'd think that 8 is a big win over the default of
2 and would fix the vast majority of problems. Higher
numbers may cause memory paging (unless you have lots
of spare memory) to handle the few remaining border cases.

--  bjm