[mythtv] Dynamic Ringbuffer and prebuffering pauses.

[Bruce Markey]

Stuart Auchterlonie wrote:
> Been doing some testing and tuning of the dynamic ringbuffer.

Great.

> On some of the HD content I have the ringbuffer decreases are
> too aggressive given the transistion from low activity scenes
> to high activity scenes. Tweaking the point at which the
> ringbuffer decreases alleviates this problem.

What if there is a prolonged dark scene? the size would cycle
down anyway so if it is, in fact, draining the read ahead buffer,
it may be a matter of ramping up the size more quickly.

Two things to consider, in reverse order. First (actually
last) are there really pauses as a result of the read ahead
buffer hitting empty? The target time is ~300ms but it could
read 30ms or faster. Even if it is reading smaller blocks
temporarily when there is a burst, it should still be ahead
of the game while it ramps up. Remember, this is topping off
a 3MB blob of data in memory pre-fetched to be available to
the decoder. You could print out "used" or "totfree" around
line 843 of RingBuffer.cpp:

        totfree = ReadBufFree();
        used = kBufferSize - totfree;

And see if it falls below, say, 512K or if it stays above
2.5MB. I'd be curious to see your result with HD files where
there are dramatic changes. The three goals here are 1) don't
request excessive data at a seek reset (rapid seeking), 2)
keep the buffer full and prevent it from draining, and 3) don't
have excess data requests pending on the network when the
next seek is requested.

Second (but check this first ;-), if you are seeing pauses
when the scene goes dark, make sure you are watching pre-
recorded or live after pausing. If you are near real time
in live, it will always pause when the scene goes dark.

When live starts or the channel changes, the encoder has
to start grabbing frames and compressing them, Whether it
is hardware or software encoding or even grabbing HD data,
the data isn't written to the disk until there is a blocks
worth of data to write. This is handed of to the I/O system
to be written. Mythfrontend is waiting for the I/O system
to give it data from this new file. Once there is enough
data to read, it goes into memory available for the decoder.
As the decoder gets data it decodes frames 1 and 2. The player
is waiting for frames to play, however, it can't unpause if
there are only two frames or it would play those two frames
then stop again. It needs to have more than a handful available
in order to unpause and have a reasonable expectation of
continuing. Waiting for too few frames increases the chance
that it will pause again soon, Too many takes an average of
1/30sec longer per frame until unpausing. You may notice that
sometimes there will be one or two pauses after a channel
change. That's because the last time I touched this, I targeted
the middle ground that half the time it may pause once.

<soapbox>