[mythtv] A need for advanced player settings

[Kyle Rose]

For reference, my main front end and back end are running on the same
machine, a Zotac barebones with an Atom processor.

I have spent the last 3 days trying to slay some short pauses in
MythVideo playback that I assume are similar to what was described
here:

http://www.mythtv.org/pipermail/mythtv-users/2011-May/314816.html

I tried the following:

(1) Turn off hyperthreading. My first theory was that CPU contention
from the HT cores was keeping some important thread from making
progress, especially since I saw kworker processes using 100% of the
CPU for a second at a time several times a minute (as it turns out,
decrypting a krb5p payload). This change did nothing.
(2) Tweak NFS. I futzed with the rsize/wsize and actimeo settings, and
switched from krb5p to krb5i. Again, no change.
(3) Force the NIC to 100Mb/s mode, under the theory that readahead
requests at 1Gb/s were saturating the bus in this poor machine. Again:
nothing.
(4) Move the file to the local machine, which is running on an Intel
SSD, in order to eliminate all off-machine variables. Alas, no change.

At this point, I was forced to the conclusion that the problem was
data exhaustion in the front end rather than a hardware constraint. I
tried forcing backend streaming as a hack, in hopes that this would
force the combination of front end/back end to cache more of the file.
This did not solve the problem either. I tried upgrading to trunk,
which also had no effect.

The only change that worked was to increase the read-ahead of the ring
buffer. Specifically, I upped the size of the ring buffer to 32MiB and
then increased the fill threshold to half of that (/2 instead of /4).
Those settings might be overkill, but for the first time the file
streamed smoothly from start to finish.

Through a perusal of the archives, I've read substantial opposition to
providing advanced player settings to allow users to tweak this stuff,
but sometimes there is no other solution. The problematic file in
question is an encoding of BSG S03E10 "The Passage", which is the
highest variable bitrate encoding I have in my library. The reason why
this file in particular causes the default settings to fail is that
the intelligence in ringbuffer.cpp to decide how much data to cache
cannot predict the future based on the past: the pauses always occur
when there is a change in the on-screen image from one of low motion
and low noise to one of high motion and high noise. (For those
familiar with this episode, it's when the scene changes from one
depicting people aboard Galactica talking to one in the star cluster:
there is nearly always a stutter at this transition with the default
player settings.)

But to be clear, I'm not saying that the default settings should be
changed, or that there needs to be better intelligence. I'm saying
that without prebuffering an unbounded amount of data or being able to
seek ahead in the input file to monitor the timecodes in the upcoming
data (something that is not possible while streaming), it is
impossible to know how much data you're going to need, which means
users need to be able to tweak this stuff based on their own
libraries. Anything else is asking the impossible of the code.

Ideally, what should happen is that the player should know the maximum
bitrate of the file being played and always cache at least (say) 1.5
seconds at that bitrate. I don't know if Matroska or MP4 containers
have this information available, and surely it is impossible to know
this for live content. That said, providing a menu to allow users to
tweak the buffer settings with a large warning that this will screw up
one's seek performance would at least keep me from having to compile
this thing from source every time I need to upgrade.

Thoughts?

Kyle