[mythtv] Automatic frame-rate switching on Fire TV

[Mark Kendall]

On Sat, 16 Nov 2019 at 14:45, Paul Gardiner <lists at glidos.net> wrote:
>
> One thing I've always loved about MythTV on my nvidia ION based frontend
> and hated about using Netflix and Amazon Prime on my Fire TV is
> automatic frame rate matching (well that on my frontend, and the lack of
> it on Fire TV). However, I've recently read this:
> http://www.aftvnews.com/explanation-of-the-new-frame-rate-matching-feature-on-the-amazon-fire-tv/
> and realised that I may be seeing the problem partly because my Fire TV
> box is very old. Can anyone tell me if the Mythfrontend app supports
> this when running on modern Fire TV sticks?

The myth code has no support for switching the display frame rate on
Android - although I'm sure it is possible. (and the relevant settings
should probably be disabled if frame rate switching isn't available on
any given device/platform).

What Android and/or MediaCodec do is a different question however.
MediaCodec is a bit of a black box when it come to functionality. You
don't really know what you are going to get back from the decoder.
Whether under the hood there is any display configuration is also a
relative unknown.

If your device is changing the display frame rate at any point, you
would mostly likely see the usual display blanking for a short period
of time while it resets. I've never seen this on the Shield.

Android/MediaCodec also has a different render path - can't remember
the name of it atm (something like protected path??). Using this
route, the OS effectively takes ownership of the media  and handles
everything - so it is conceivable that apps using this path will see
different results (e.g. support for HDR material on Shield). MyhTV
does not use this approach.

> (I've lied a little: actually my nvidia ION based frontend has recently
> lost this feature. I'd also love to know how to correct that.)

Something changed with more recent Nvidia drivers and what is returned
by libxnvctrl. I couldn't pinpoint the issue exactly as I didn't have
a 'before' and 'after'.

Anyway - it is fixed in the 2019-render branch - and hopefully the new
code is a little more robust.

Regards
Mark