Shaking while picture panning on Raspberry Pi

[Josh Rosenberg <mythtv@…>]

In sports programs where there is rapid panning of the picture, the video sometimes shakes on a Raspberry Pi 3. The same video plays perfectly smoothly on an amd64 with VDPAU.

[Peter Bennett]

I looked into whether there are missing or late frames while playing the clip. There are 60 frames per second and one or two frames each second is 1 ms to 16 ms late. Other frames are correct within 1 ms. When one is late the following frame or frames are speeded up to compensate. No frames were dropped. At 60 fps the frames are one every 16 ms.

I do not know if this is enough to cause the visible shudder during panning.

By comparison, the same video on an AMD64 front end has all frames at the correct time within less than 0.1 ms.

I think the uneven rate on the Raspberry Pi may caused by the large amount of processing that is done during each frame. Also multiple threads are running in the frontend apart from the playback thread, and with the slow processors these could be causing some delay occasionally.

[Peter Bennett]

Sample Video URL ​https://www.dropbox.com/s/2cdc8zg1mkdwci6/panning.ts?dl=0

[bhuffman@…]

I don't know what video card the AMD64 had, but I wonder if this might be caused by the video sync timing source. Without either DRI or RTC, it falls to "usleep with busy wait", which as I recall isn't very good and can definitely result in tearing.

From "mythfrontend -v playback": 2017-04-05 22:27:38.108857 I VSYNC: DRMVideoSync: Could not open device /dev/dri/card0, No such file or directory 2017-04-05 22:27:38.108922 E VSYNC: RTCVideoSync: Could not open /dev/rtc:

eno: No such file or directory (2)

2017-04-05 22:27:38.110083 E X11 ModeLine? query returned zeroes 2017-04-05 22:27:38.141215 I Player(1): Video timing method: USleep with busy wait

[Peter Bennett]

Replying to bhuffman@…:

I don't know what video card the AMD64 had, but I wonder if this might be caused by the video sync timing source. Without either DRI or RTC, it falls to "usleep with busy wait", which as I recall isn't very good and can definitely result in tearing.

This bug is for Raspberry Pi with is armhf not amd64 and uses a built in broadcom video adapter. This issues are different here.

[Peter Bennett]

Without major architectural changes, MythTV may not be able to offer any improvements to this.

One possibility we may perhaps consider is to support an external player in MythTV for playing recordings and videos. omxplayer is able to play the sample video perfectly smoothly, but it uses a synchronization method that is different from and incompatible with MythTV's built in player. If the user is prepared to give up the MythTV OSD and some of the playback features, a 100% smooth playback may be possible by running omxplayer from within MythTV. There are many challenges to overcome to get this to work.

[Krisbee@…]

If I recall, mp4s didnt exhibit this behavior - so a post job that converts using handbrake is easily done - however that does take backend resources and doesnt work for live/semi-live playback.... Kodi doesnt have this issue, so the plugin is another alternative. I think the smaller the tv, the less noticable it is.

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues