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

[Harish Surana]

I hope you would like to have a look on this article

http://labs.nokia.com/blogs/2008/11/28/videos-get-pimped/



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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100218/226fa62a/attachment.html