PLAY/PAUSE delay regression

Description

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.

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.

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.

Changed 10 years ago by markk

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.

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.