[Qt-interest] QSlider::setValue() causing delays in QTimer event delivery

[Josiah Bryan]

Andrew Hodgkinson wrote:
> On 16/02/2010 17:08, Josiah Bryan wrote:
> 
>> I've got an odd problem. See, I've got a video player (using ffmpeg as
>> the backend) that sets a QTimer to trigger the next frame update.
> 
> I'm surprised nobody's responded so I'll have a go! I'm far from an 
> expert in this area, but my first response was surprise that you would 
> have application level code manually set its own timer to try and update 
> video frames. Surely the Phonon video widget should be doing this? I 
> wouldn't expect an application to have to do anything even close to that 
> low level just to play video. If forced to take the approach, I would be 
> most seriously concerned about the performance implications.

No doubt, you're correct. However, I'm not using Phonon for the video 
decoder - I'm using the ffmpeg libraries directly (libavcodec et al).

Why am I not using Phonon, you ask? I'm not using ffmpeg because I enjoy 
pain and agony that comes with writing time-sensitive things like video 
players - no, the *only* reason I'm not using phonon is because the 
Phonon::VideoWidget doesn't "play nicely" when used in a QGraphicsView, 
even when using an OpenGL viewport for said view. Specifically, cross 
fading between two video widgets (e.g. change the opacity of the graphic 
item proxy of one widget from 0...1 while doing the opposite on the 
other widget, causes playback to halt, pause, and/or stutter. Often 
playback takes a moment or two to resume after the cross fade has finished.

Since the program I'm working on is a presentation-type program, 
smoothly transitioning from one "slide" (e.g. video+text over top) to 
the next is intrinsic to "correct" operation - I'd rather not have to 
"cut" (no cross fade) between slides just because phonon can't handle 
cross fades. Thus, for the time being, I'm using ffmpeg backend pumping 
frames to a QGraphicsItem that doess it's own painting - and handles 
cross fading with little to no problems at all.

>> I've also got a QSlider on the GUI that polls the video decoder for the
>> clock position and updates a QSlider with the current video position via
>> setValue. The polling of the video decoder is also done via a QTimer.
> 
> The word "polling" also gives cause for concern. Polling solutions are 
> inherently inefficient. The MediaObject in Phonon provides a "tick" 
> signal which looks like it's designed explicitly to allow you to update 
> your GUI if you want to use a custom progress display. This is emitted at 
> caller-configurable intervals.

Granted - I totally agree with you, especially if I was using Phonon 
underneath. However, since I'm not using phonon, the only question here 
is why the QSlider delays timer delivery when calling setValue(x) - 
regardless of whether I got "x" by polling or from a signal, the fact 
still remains that QSlider causes a greater than 100ms delay in QTimer 
deliveries. For ANY sort of user interface animation (not just low-ms
"animation" like video), a change in more 100ms of an event delivery 
will be noticeable. Yes, I know QTimer is unreliable at low delays (like 
<10ms on windows, etc) - but to be within 100ms of the requested time - 
is it really messed up that badly by QSlider::setValue()?

> ...
> In your case, it seems that the QSlider update code is really pretty 
> slow. Since this is delaying QTimer, I assume your application is single 
> threaded. Qt isn't getting around to processing events and emitting your 
> next timer signal until that update is complete. The standard (if IMHO 
> rather depressingly heavyweight / complex) answer would be to split your 
> application into a GUI thread and a timer thread, although quite how 
> you'd then get the video frame to update at the same time as your GUI 
> thread is busy updating the QSlider isn't clear - since *both* are in 
> fact part of the GUI. At least the QTimer API documentation has useful 
> information on mutlithreaded uses in the "detailed description" section 
> to get you started.
> 
>    http://qt.nokia.com/doc/4.6/qtimer.html#details
> 
> Perhaps these kind of emerging multithreading / reentrancy issues are 
> further indications that really the video widget ought to take care of 
> updating itself, leaving your application to only have to worry about the 
> QSlider. If your Phonon backend doesn't allow this, now might be a good 
> time to consider adding support there, to solve the problems you're 
> having further up the software stack.

I'd love to be able to pump frames directly to the video card and bypass 
the GUI thread all together - but I know of no way in Qt to update the 
screen from outside the GUI thread. Even something as simple as updating 
an OpenGL texture from outside the GUI thread - I don't think that's 
even possible. (Please do correct me if I'm wrong!)

Basically, I don't know of any way to have one thread manage the 
complete video pipe (e.g. update the screen independent of the GUI 
thread), apart from running the video decoder/player in a completely 
separate *application* and embedding the player window over top of my 
window by absolute positioning on the screen. Of course, if I was going 
to do that, I would (a) have to sacrifice cross fading and (b) I could 
just use Phonon and not have to use an external app, since the only 
reason to not use phonon is to be able to cross fade!

If anyone is curious, the application in question is 'dviz' on google code:

http://code.google.com/p/dviz/updates/list

The relevant video code is in /trunk/src/qvideo:

http://code.google.com/p/dviz/source/browse/#svn/trunk/src/qvideo

But not necessary to look at all that if you're not interested - my main 
concern is primarily why does QSlider interrupt timer delivery for so 
long. That's what I'd like to trouble shoot primarily. That is, unless 
someone can jump subjects and tell me how to get phonon to "play nice" 
in a QGraphicsView and allow me to cross fade it (change opacity) 
without it pausing/stuttering/etc.

Thanks everyone for your time and patience!
Regards,
-josiah

-- 

-=-=-=-=-=-=-=-=-=-=-=-=-
Josiah Bryan
Productive Concepts, Inc.
jbryan at pciint.com
(765) 964-6009, ext. 224