[mythtv] A need for advanced player settings
adeffs.mythtv at gmail.com
Tue May 31 17:43:47 UTC 2011
On Fri, May 27, 2011 at 10:03 AM, Kyle Rose <krose at krose.org> 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
> 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:
> (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.
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette -
More information about the mythtv-dev