[mythtv-commits] mythtv commit: r11834 by bjm

mythtv at cvs.mythtv.org mythtv at cvs.mythtv.org
Tue Nov 28 18:32:43 UTC 2006


      Author: bjm
        Date: 2006-11-28 18:32:42 +0000 (Tue, 28 Nov 2006)
New Revision: 11834
   Changeset: http://cvs.mythtv.org/trac/changeset/11834

Modified:

   trunk/mythtv/libs/libmythtv/RingBuffer.cpp

Log:

Use an adaptive blocksize algorithm for the readahead buffer
block requests, Rather than a static blocksize based on a
questionable estimated bitrate, this adapts the blocksize
based on how often reads are requested and finds an adequate
size for any type of file.  This is so that reads over the
network will be efficient for any video file size or bitrate
and any seek pattern such as high speed FF/Rew.

The read ahead buffer is increased from 2.5MB to 3MB and the
max blocksize to 640KB up from 512KB. The blocksize starts at
32K after each seek and changes by increments of 32K.

The advantage of a small starting block size is that at 20X or
60X FF/Rew, only one frame is displayed then another seek.  By
using small blocks it doesn't need to request excess data for
each frame. I think there is also an advantage for LiveTV in
that the first 32k can be grabbed and fed to the decoder
rather than having to wait for a larger block to fill from
newly encoded video but this may be more theoretical than
anything that would be noticed.

If playback is continuing, blocks are requested as fast as
possible. The blocksize is also growing rapidly until the 3meg
read ahead buffer is full. At that point, reads are only
needed to top off the buffer. If the avg time between requests
is less than 0.2sec, the blocks grow or they will shrink if the
avg time is over 0.4sec. A "-v playback" message logs when the
size changes. An interesting effect is that this can change as
the video changes. A sudden increase in motion will increase
the blocksize and a dark scene will shrink to keep data moving
at a steady pace.





More information about the mythtv-commits mailing list