[mythtv] Re: [mythtv-commits] mythtv commits
bjm at lvcm.com
Fri Sep 19 13:34:23 EDT 2003
Isaac Richards wrote:
> On Thursday 18 September 2003 08:12 pm, Bruce Markey wrote:
>>Isaac Richards wrote:
>>>It just seems that channel changing slowed down quite a bit from these
>>>changes, is all.
>>Ya, it's tough because it needs about two seconds of data in
>>the pipeline to avoid stalling (ymmv). It's a combination of
>>the delay while waiting for the first frames to arrive, plus
>>a few pauses whenever new frames aren't ready, before it builds
>>a sufficient time gap. On the bright side, I can now compare
>>myth LiveTV with real PIP on my TV and see that myth is staying
>>close to realtime over long periods. It used to fall farther and
>>Anyway, now that the stuttering isn't a big problem I've trimmed
>>it to 4 frame intervals as a compromise. It may stutter a little
>>more in the beginning but it may start up little faster.
> How's things look on your machine with pvr-250 files and the 'extra audio
> buffering' enabled, if you make it require fewer prebuffed frames?
Pretty much the same any way I cut it.
Each channel change for the pvr-250 takes a little over 1.5sec
on average before EnoughPrebufferedFrames() is satisfied. For me,
this is the same with or without 'extra audio buffering', higher
or lower values for kPrebufferFrames or any reasonable value
for the prebuffering usleep in NVP. With the current parameters,
it rarely stutters after playback starts.
For comparison, with bttv cards it averages 1.1sec before playback
starts but there are some more prebuffering pauses in the first
few seconds on about 1/3 of the channel changes.
I'm a little confused by the question so maybe I missed what
you are looking for. The sleep that I changed in NVP determines
how often it checks if EnoughPrebufferedFrames() is true. It is
kPrebufferFrames that is the number of required prebuffed frames.
Changing either of these seems to have very little impact on how
long it takes for playback to start after a channel change.
I think it's like turning the spigot on a hose and waiting for
water to come out the nozzle. What's hosed here (I couldn't
resist ;-) is that the encoder starts and the player sends off
its first RequestBlock. The backend can't finish its first
WriteBlock until there is a full block of data in the ringbuffer
from the encoder. ReadBlock has to wait until there are enough
bytesAvailable on the socket before the data can be handed off
to the read ahead thread which has readsallowed = false this
whole time. Once the read ahead thread has fill_min bytes it
can hand over the data to be decoded into the vbuffers. Once
the video playback loop sees that EnoughPrebufferedFrames() is
true then playback can start.
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.
More information about the mythtv-dev