[mythtv-users] MythTV Raspberry Pi2 frontend testers

Lawrence Rust lvr at softsystem.co.uk
Mon Nov 30 19:02:34 UTC 2015


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.

I hadn't seen the problem before because in the UK, HD streams are H264
1920x1080i 25Hz which reduces the bandwidth sufficiently to avoid GPU
overload.  I did notice that with UK HD streams, bringing up the debug
data screen caused frames to be dropped.

It may be possible to more closely couple the decoder and renderer and
possibly save a CPU frame buffer copy.  This may reduce CPU/GPU memory
contention and improve the situation.  But we have to accept that HD
video is pushing the Pi's capabilities.

H264 significantly reduces video data rate compared with MPEG2 so I
suspect that there may be an element of network load affecting this.
The Ethernet chip is USB connected so may well be interfering with GPU
memory access.

You can increase the GPU performance and reduce the jerkiness by adding
this snippet to /boot/config.txt:

core_freq=450
gpu_freq=300
sdram_freq=467
over_voltage=2

Or an even faster GPU (maybe less stable): 

core_freq=500
gpu_freq=333
sdram_freq=467
over_voltage=2

The jerkiness also demonstrates a lack of sophistication in the A/V sync
code.  IMHO there are could be some significant improvement in the way
sync is achieved and lock maintained.  A project for another day
perhaps.

-- Lawrence Rust



More information about the mythtv-users mailing list