[mythtv-commits] Ticket #8843: PLAY/PAUSE delay regression

[MythTV]

#8843: PLAY/PAUSE delay regression
-------------------------------------+--------------------------------------
 Reporter:  stuartm                  |           Owner:  markk     
     Type:  defect                   |          Status:  closed    
 Priority:  blocker                  |       Milestone:  0.24      
Component:  MythTV - Video Playback  |         Version:  Trunk Head
 Severity:  high                     |      Resolution:  Fixed     
 Keywords:                           |   Ticket locked:  0         
-------------------------------------+--------------------------------------
Changes (by markk):

  * status:  assigned => closed
  * resolution:  => Fixed


Comment:

 (In [26869]) Improve MythPlayer's responsiveness to actions when fast
 forwarding and
 rewinding.

 A little history:-

 - The OSD re-write moved media playback into the main UI thread to
 ensure QObjects behave correctly and to avoid interacting with the X
 server in a unsafe manner.
 - We can't block the main UI thread and hence can no longer use a simple
 loop for playback and need to plug into the main Qt event loop.
 - The simple loop was initially replace by using a QTimer with a zero
 timeout to trigger displaying the next frame (the zero timeout is a
 special case that processes the timer event once all other events have
 been cleared).
 - The behaviour of QTimer has changed in Qt 4.6 and it no longer
 delivers playback events as fast as previously - with an obvious impact
 on performance.
 - The QTimer was replaced with a custom player event type.
 - To ensure playback performance is maintained, we queue up several of
 these player events and hence minimise any delay between displaying one
 frame and the next.
 - When fast forwarding and rewinding, the main UI thread can be blocked
 for significant periods of time (due to the frequent seeks and the
 change to the screen update period).
 - If up to 3 player events are queued during fast forward/rewind then
 the delay before an action is processed can be measured in seconds.

 ... so when fast forwarding/rewinding, drop the number of events in the
 queue to one.

 This is not a perfect solution as there can still be a noticeble delay
 and it would be much better if we actually knew what was happening in
 the main event loop and/or had the ability to customise it for our
 needs.

 Closes #8843

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/8843#comment:10>
MythTV <http://www.mythtv.org/>
MythTV Media Center