[mythtv] Re: [mythtv-commits] mythtv commits

[Bruce Markey]

Isaac Richards wrote:
...
> I was just wondering, since turning on the 'extra audio buffering' setting 
> should allow fewer frames to be prebuffered (ie, it allows stuff with the 
> cle266 decoder -- only 4 video frames allowed, and xvmc -- only 8 video 
> frames allowed, to play back without audio stuttering).  Figured it might 
> help the software display case as well, if it'd allow us to drop down the 
> required number of prebuffer frames.  But, since it doesn't really speed 
> things up at all, ah well.

I see. This is kind of why I didn't want to muck with the
number of frames (which someday may need to vary from decoder
to another) and chose instead to lengthen the sleep before the
output loop checks to see if it can continue.

>>The majority of the time is waiting for frames to show up in
>>the vbuffers. Playback starts a relatively short time after the
>>vbuffers start to fill. I'm guessing the biggest bottleneck is
>>the wait for 256000 bytes to be encoded before the first
>>WriteBlock can be sent.
> 
> 
> Is it really waiting for that much to write?  I don't think it is..

I've come to assume that pretty much everything you say is correct
so I won't dispute this ;-). I was thinking the RequestBlock
size is 256000 and that WriteBlock wouldn't flush until it had a
full block. However, it looks like FileTransfer::RequestBlock
tries to send whatever data it gets from rbuffer->Read ASAP.

--  bjm