Opened 3 years ago

Last modified 17 months ago

#12907 assigned Bug Report - General

Shaking while picture panning on Raspberry Pi

Reported by: Josh Rosenberg <mythtv@…> Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: Ports - rPi Version: 0.28.0
Severity: medium Keywords:
Cc: mythtv@… Ticket locked: no

Description

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.

Change History (7)

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by Peter Bennett

comment:3 Changed 2 years ago by 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

comment:4 in reply to:  3 Changed 2 years ago by 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.

comment:5 Changed 2 years ago by 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.

Last edited 2 years ago by Peter Bennett (previous) (diff)

comment:6 Changed 2 years ago by 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.

comment:7 Changed 17 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Status: newassigned
Note: See TracTickets for help on using tickets.