[mythtv] A need for advanced player settings

[Mark Kendall]

On 27 May 2011 22:03, 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
> here:

Apologies for the late response. Can you provide a link where we can
download the problematic file? From memory, matroska doesn't take well
to being clipped randomly so I'm assuming it will need to be the whole
thing.

> http://www.mythtv.org/pipermail/mythtv-users/2011-May/314816.html
>
> 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.

This does tie into some issues that a couple of people have been
trying to debug in the last couple of weeks. There was a suggestion of
incorrect bitrate detection and/or updates with one file and it
obviously ties up with the symptoms.

> 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?

I'll reserve my opinion on the need for any custom settings until the
issue is well understood but my gut feeling is that they won't be
needed. Between any potential ringbuffer fixes, the readahead thread
operating as expected and potentially increasing the number of video
buffers marginally, the code should be able to deal with it. (Though
admittedly, I'm not sure what the worst case 'range' is for variable
bit rate material).

regards

Mark