[mythtv-users] MythTV Raspberry Pi2 frontend testers

[Lawrence Rust]

On Mon, 2015-11-30 at 11:25 -0800, Tom Harris wrote:
> On Mon, Nov 30, 2015 at 11:19 AM, Dan Wilga <
> mythtv-users2 at dwilga-linux1.amherst.edu> wrote:
> 
> > On 11/30/15 2:02 PM, Lawrence Rust wrote:
> >
> >> On Sat, 2015-11-28 at 11:39 -0500, Peter Bennett (cats22) wrote:
> >>
> >>> On 11/27/2015 03:46 PM, Lawrence Rust wrote:
> >>>
> >>>> I'm missing something. I've tested a number of videos, monitors &
> >>>> resolutions and haven't see any jerkiness with eglfs playback. So a
> >>>> small favour, would you run a test with the most jerky video that you
> >>>> have and post me the mythfrontend log with '-v playback --loglevel
> >>>> debug' args. It would also be extremely useful to test a video that
> >>>> causes problems so is it possible to download it from somewhere?
> >>>>
> >>> Mythfrontend log with those parameters is here
> >>> https://dl.dropboxusercontent.com/u/45325311/mythfrontend.log
> >>> This is on the 1280x1280 DVI screen and analog audio. First build (I did
> >>> not yet install the new build from today).
> >>> In that log, I played the recording from timestamp 11:22:52 to 11:23:22.
> >>> During that 30 seconds the audio is choppy and the video jerky.
> >>>
> >>> The recording is many Gigabytes, so I extracted the first 2 minutes
> >>> using ffmpeg. This only extracts video and one audio track, no sub
> >>> titles. Playing this 2 minute video through Mythtv Videos gives the same
> >>> jerkiness.
> >>> The file is here
> >>> https://dl.dropboxusercontent.com/u/45325311/News_Extract_2min.mpg
> >>>
> >> Peter,
> >>
> >> Many thanks for the logfile and recording.  I can now reproduce the
> >> jerkiness that you describe.
> >>
> >> Unfortunately, it would appear that the problem is largely h/w related.
> >> The recording is MPEG2 1920x1080i 30Hz which is saturating the GPU.  The
> >> key point is the log lines 'Waiting for video buffers' which indicate
> >> GPU overload.
> >>
> > If all else fails, it might be viable for some users, especially those
> > with more modern TVs, to have Myth output at 30 Hz refresh and have the TV
> > deinterlace instead of the Pi2. Tvs these days are doing a better and
> > better job of it.

Deinterlacing doesn't present a great load to the RPi's GPU.  It is
integrated into the video renderer's output pipeline and at worst adds
some extra latency.  You can try this by selecting a different
deinterlacer from the on-screen menu.

> Is the video decoding handled differently in X mode?

No, it's identical.  However, in EGLFS mode Qt acquires EGL resources
for the GUI which impacts free GPU memory and overhead.

>   For me, X Windows
> playback of 1080i content was fine in mythfrontend.

I think that you are just fortunate.  The video clip that Peter Bennett
provided plays equally badly for me in xcb or eglfs mode.

What I did find that improved matters was to change the decoder from
openmax to ffmpeg with 4 threads.  At first this seems counter-intuitive
but it moves the decoding burden from the over-worked GPU onto the
under-utilised CPU.  Using this method the clip plays back smoothly.

Also, as expected, over-clocking the GPU improves smoothness of
playback.

> Also, I think Kodi uses EGLFS, and playback of 1080i MPEG2 content is
> perfect there.

I believe Kodi borrowed from omxplayer which uses a single OpenMAX
pipeline from decoder to video renderer which shares buffers and avoids
copying.  Myth currently requires the separation of the decoder from the
renderer and so causes two video buffer copies - one each for the GPU
and CPU.  For a 1920x1080 frame this is a significant burden that causes
memory contention.

I will investigate ways of integrating the decoder and renderer so that
they use a single OpenMAX pipeline.  Unfortunately this is not trivial
because of the current assumption that ffmpeg is the only provider of
hardware accelerated decoding i.e. VDPAU, VAAPI, DXVA2 etc.

-- Lawrence Rust