[Qt-interest] Intercepting Phonon VideoWidget frames

[Trenton Tuggle]

You've definitely shed some light!

I've had *some* success, but I'm not sure it's enough to justify this  
approach...

I've tried creating a QWidget-derived container (the source code I  
posted earlier) but it still didn't receive PaintEvents.

My only success so far has been to create a "dummy" GraphicsScene and  
add the VideoWidget to it -- presto!  I can at least render() the  
frames!  Unfortunately, problems appear when I try to do it too  
frequently.  (Say, more than every 20-30 frames of DV at least.  I'm  
using DV because it takes relatively little CPU to decode.)  If I  
render() them more often, I don't get any update to the frame, even  
though Phonon is signaling that playback is continuing.

With the current design of Phonon, perhaps it's best if I wrap my won  
video library with a interface similar to Phonon's, expanded to cover  
my requirements.

In the future, as Phonon gets expanded, probably something like that  
MediaPlayerPrivatePhonon that could emit a signal when updated would  
be useful for those of us wishing to process video.  Maybe somewhat  
like the old PhononInputNode I've found mentioned in the past.

So, for now, all I can contribute is that VideoWidgets can be  
virtually render()ed if they are added to a 'dummy' graphics scene.

I'll keep the list posted with any further success I have!

Thanks all!

-Trent Tuggle <Trent at Tuggle.Org>


On Mar 26, 2009, at 4:46 AM, Richard Moe Gustavsen wrote:

>>> I've been unable to "capture" VideoWidget paint events at all -- it
>>> appears as if it somehow gets drawn outside of a PaintEvent -- but
>>> how
>>> could it then be captured and redirected onto a
>>> QGraphicsViewProxyWidget?
>
> ...
>
>>> Note that my only test case is trying to capture a
>>> Phonon::VideoWidget, so I suppose a possibility is that I'm doing  
>>> the
>>> right things, but VideoWidget somehow bypasses normal stuff for
>>> performance purposes.  I've been looking through the Phonon backend
>>> (Quicktime) code, but it's not apparent how drawing is performed.
>
> To shed some light on your efforts:

...

> When inside Graphics View, we follow the Qt paint engine. This means  
> that we
> schedule paint events for each frame, and use a QPainter to draw  
> them the
> normal way. To check if a video widget is inside Graphics View, we  
> test if
> the videowidgets top-level parent (QWidget::window()) has the
> Qt::WA_DontShowOnScreen attribute set. In effect this means that if  
> you
> create a parentless videowidget, set this attribute, and call show  
> on it,
> you should be able to listen for paintevents, and call functions like
> QWidget::render(...). This work-around is internal, so if you play  
> around
> with it, bear in mind that it may change without further notice.



>
> -Richard
>
> PS: Webkit uses this trick at the current moment. Take a look at
> "MediaPlayerPrivatePhonon.cpp".