[mythtv] A need for advanced player settings

[Lennart Sorensen]

On Fri, May 27, 2011 at 10:03:11AM -0400, Kyle Rose wrote:
> 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?

You run both the front and backend on something as slow as an atom?
I am impressed.  I wouldn't try that.

Does your video card have any ability to help with the decoding or is
the poor atom stuck with all the work?

Which kernel version and filesystem?  I know ext3 had some performance
issues in the past that were fixed in more recent kernels, although not
all of them of course.  Of course NFS shouldn't really be related to that.

-- 
Len Sorensen