Pauses in playback

[krose@…]

From my post to the mythtv-dev mailing list, edited:

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

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.

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 does not correctly 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.)

A 750 MB prefix of this episode is here, for a few more days:

​http://freesrv2.largefilesasap.com/download.php?file=YzRiNDJmOTEzNjk4ODJhMjcyODQxNmEzYjVhMmIxNmQvMjAxMTA1MzAyMDEyNDI1MDMzNjA4NDc5NDIubWt2X19TRVBfXzE5NzIwNw==

[markk]

Ref:-

6706f5d1 708f5c88 031b9a4d 78cf692a 88a9cbb1 58d2ca04 1e4a61b8 feafcfc8 933cd944 bff85941 88f3e77f 412ceac0 941bf053 d9506371

[markk]

In summary, this should now be fixed in trunk.

The key commit is probably d9506371, which made the buffer size dynamic and bumps it up significantly under certain situations. As mentioned in that commit, the 'intelligence' behind the buffer size assumptions could probably be improved significantly but playback should now be smooth under the most testing of situations (at least until someone re-encodes that same clip to 1080p60!)

It's also worth mentioning that there is a new OSD screen in master that displays real time playback data that should prove invaluable debugging any similar issues in the future.