PLAY/PAUSE delay regression

[stuartm]

The time before the PAUSE action being received and the video actually pausing has regressed in trunk, there is a noticeable delay of a second or more.

This becomes even greater when rewinding, or fast-forwarding at a speed greater than 3x where it then takes several seconds to react. This means that even with the seek compensation you resume playback well past the point you were aiming for.

[markk]

I'm not seeing this in any of 5 different frontends running r26274

[stuartm]

Guess I'll have to debug it then.

[stuartm]

I'm no longer able to consistently reproduce this and so it's unlikely that I'll be able to fix it for 0.24. I've see no changes which might have fixed it, so I can only assume that the bug still exists but is dependant on a variety of factors. To be clear, I'm still a delay in exiting from Rew/FF, it just isn't the several second delay that it was earlier.

There are some general problems with seeking anyway, Rewinding at 3x seems to instead move at 10x, in 6 seconds it will move a whole minute.

[stuartm]

Seems I can reliably reproduce with certain samples and both Mark and Taylor can too. Mark indicated that this was a more serious bug than first thought since it appears that the player timer is being delayed/blocked, so I'm moving it to a blocker for 0.24.

[anonymous]

The attached patch should improve keyboard response time when fast forwarding/rewinding. Fundamentally those large seeks are however blocking the UI thread - so I can't see a way of improving this any further.

[markk]

(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