Opened 11 years ago

Closed 11 years ago

#8630 closed patch (fixed)

Unreliable QTimer in NupplePlayer

Reported by: Vitold <…> Owned by: Janne Grunau
Priority: minor Milestone: 0.24
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords: QTimer NuppelPlayer
Cc: Stuart Auchterlonie Ticket locked: no


I am using mythfrontend on OSX 10.6.4. I have built the frontend r25165 against qt-4.6.3. I got choppy vidéo.

After some debugging, I've found that the QTimer(0) trigger the timeout event in an unreliable way.

So, as recommended by the qt documentation, I switched the QTimer(0) to QThread and the video is fine now.

Attachments (1)

QTimer.patch (2.2 KB) - added by Vitold <…> 11 years ago.

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by Vitold <…>

Attachment: QTimer.patch added

comment:1 Changed 11 years ago by stuartm

Component: MythTV - GeneralMythTV - Video Playback
Milestone: 0.23-fixesunknown
Owner: changed from Isaac Richards to Janne Grunau
Priority: majorminor
Severity: highmedium

Thanks for the patch. In future please read the TicketHowTo before opening a ticket.

comment:2 Changed 11 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added
Milestone: unknown0.24

comment:3 Changed 11 years ago by anonymous

I can't currently comment on OS X but this patch will almost certainly cause sizeable problems for linux and windows builds for 2 reasons:-

  • the thread 'model' in NuppelVideoPlayer? is very much geared towards known playback and decoder threads, to the extent that the thread id's are used to ensure the correct behaviour in places (mostly around the pause/unpause code). Adding a third thread is likely to cause some unexpected results. No doubt fixable but not necessarily straightforward.
  • the video playback thread is now deliberately the same thread as the main UI thread following the OSD port. If the video event loop is triggered from another thread, at best Qt will complain and at worst the frontend will crash persistently due to, amongst other things, non-serialized calls to X.

We really need to figure out the underlying cause of the problem.

comment:4 Changed 11 years ago by anonymous

I can also confirm this. After trunk-rev24972 playback becomes choppy. Tested on an iMac G5 and a macbook. While troubleshooting on my macbook, i figured out downgrading to qt-4.4-mac instead of 4.6 seems to solve the problem for r24972.

System info:

iMac G5 OSX 10.5.8 (PPC) (Xcode v3.1.4)

macbook OSX 10.5.8 (Intel C2D) (Xcode v3.1.4)

comment:5 Changed 11 years ago by markk

Resolution: fixed
Status: newclosed

(In [25538]) Replace the QTimer in PlayerTimer? with a custom event type.

Video playback currently relies on a special case QTimer event that calls the playback loop once all other events have been processed in the main event loop. This is, for reasons unknown, broken on OS X and Qt 4.6.

So instead just use our own playback event to trigger the playback loop and send a new one at the end of each iteration. This should, in theory at least, mimic the current behaviour without the QTimer reliance (which seems to be causing problems at different times on different platforms).

Tested on Ubuntu 10.04, OS X 10.5, OS X 10.6 and windows vista without issue.

Closes #8630.

Note: See TracTickets for help on using tickets.