[mythtv-commits] Ticket #9223: Sluggish menu when watching a recording
MythTV
noreply at mythtv.org
Wed Feb 9 05:14:23 UTC 2011
#9223: Sluggish menu when watching a recording
-------------------------------------+--------------------------------
Reporter: glemsom@… | Owner: markk
Type: defect | Status: infoneeded_new
Priority: minor | Milestone: 0.24.1
Component: MythTV - Video Playback | Version: 0.24-fixes
Severity: medium | Resolution:
Keywords: sluggish menu | Ticket locked: 0
-------------------------------------+--------------------------------
Comment (by markk):
Replying to [comment:29 dgatwood@…]:
> Ah. Looks like I was too quick to assume that this was the same issue
as in the later builds. Now that I've rolled back to the November build,
I'm seeing the horribly sluggish menu performance. With the January
build, playback system is completely uncontrollable. These might or might
not be related issues.
I'm pretty sure it's the same issue, just manifesting itself in a slightly
different way (or more/less extreme at least).
Anyway, thanks for your comments. They've helped clarify my own thoughts
and have largely confirmed my suspicions. Unfortunately there probably is
no easy and or quick fix.
With the OSD re-write (that went into the 0.24 release), the threading
model for video playback was changed. Previously there were separate
threads for both video playback and decoding. With the OSD using
libmythui, and hence QWidgets, it needed to operate within the main thread
and hence the extra video playback thread was removed (it also prevented
some nasty X related crashes).
It's fair to say we're still picking out some of the unexpected side
effects of that change.
There are still various actions that can and do block for too long but in
terms of steady state video playback without user interaction, there are 2
areas that will obviously block for significant periods - deinterlacing
and video sync.
The effects of deinterlacing are easy enough to eliminate for test
purposes by disabling deinterlacing :)
Video sync is trickier but a quick hack into
BusyWaitVideoSync::WaitForFrame and breaking out the usleep into smaller
chunks with a call to qApp->processEvents() (or indeed some form of loop
with qApp->processEvents() and a continuous check of CalcDelay()) would
probably be interesting/informative.
FYI, when video is being played, the main loop is in tv_play.cpp, line
298. Essentially that processes application events and then prepares and
displays one frame.
There are other quicker fixes that can probably go in around keypress
handling in the TV class but I'm quite sure they're not the root cause
here.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/9223#comment:30>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list