| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symbian^3 introduces a new compositing graphics subsystem in which
non-UI content such as video is provided by client applications via
graphics surfaces.
This patch modifies the video playback part of the Phonon MMF backend
so that, on devices which use the new graphics architecture (NGA),
video is rendered to a surface. On devices which use the legacy
graphics architecture, the existing video rendering path, which uses
Direct Screen Access (DSA) is maintained.
On NGA devices, video playback applications do not deal with surfaces
directly; instead, they use a new MMF client API called
CVideoPlayerUtility2. The implementation of this API takes care of
creating a graphics surface, registering it with the window manager,
and directing the output of the video decoder into this surface.
CVideoPlayerUtility2 inherits from the legacy video playback API,
CVideoPlayerUtility, deprecating certain functions and adding new ones.
The main changes involved in modifying CVideoPlayerUtility client code
to instead use CVideoPlayerUtility2 are:
1. CVideoPlayerUtility requires a window handle to be provided at
object construction time.
The CVideoPlayerUtility2 constructor does not take a window
handle; it is provided by the client later via the
SetDisplayWindowL function.
2. CVideoPlayerUtility requires the client to provide an absolute
screen rectangle at construction time, and then to call
SetDisplayWindowL whenever this rectangle changes due to either
window repositioning or resizing.
CVideoPlayerUtility2 requires the client to provide a display
rectangle which is relative to the display window. This
rectangle must be updated via SetVideoExtentL /
SetWindowClipRectL when the window is resized, but no update is
required when the window is repositioned - the compositing
window system takes care of repositioning the video content on
the screen.
3. CVideoPlayerUtility requires the client to paint transparent
black into the region of the window in which video will be
displayed. CVideoPlayerUtility2 does not require the client
to paint the video window.
In order to accomodate these differences, the existing VideoPlayer and
VideoOutput classes are replaced with AbstractVideoPlayer and
AbstractVideoOutput respectively. These abstract base classes
encapsulate functionality which is common between the DSA and surface
rendering client code. Because CVideoPlayerUtility2 inherits from
CVideoPlayerUtility, AbstractVideoPlayer is able to hold a pointer to
CVideoPlayerUtility, via which it controls functionality which is not
affected by the details of the rendering path, such as play/pause/stop,
seek and metadata access.
The three areas of divergence listed above are encapsulated in the
derived classes DsaVideoOutput/SurfaceVideoOutput and DsaVideoPlayer/
SurfaceVideoPlayer. Of the three, (1) and (3) are fairly
straightforward. For DSA video playback, the need to respond to
changes in video widget absolute screen position in (2) necessitated
the AncestorMoveMonitor class, which installs an event filter on each
ancestor of the video widget. This class is not required for surface
video playback and is therefore removed from the surface-rendering
code path.
Selection of either the DSA- or surface-rendering code path is done
at qmake time, via the exists(...) check introduced in mmf.pro. This
checks for existence of the header in which CVideoPlayerUtility2 is
defined; if this file is found, surface rendering is selected,
otherwise the DSA rendering version of the backend is built. Note that
this approach is not completely robust, since it is possible for an
environment to include the videoplayer2.h header and yet be configured
to use the legacy graphics subsystem. This could be dealt with by
instead performing the check for surface support at configuration time,
building and executing a small Symbian program which will return
different output according to which of the two graphics subsystems is
in use.
Task-number: QTBUG-8919
Reviewed-by: Frans Englich
|
|
|
being moved.
Because QWidget::moveEvent is only called when a widget moves relative
to its parent, a widget's absolute screen position may change without it
receiving a moveEvent (for example, as a result of its parent being
moved).
The MMF video playback API on Symbian v9.4 requires, in addition to a
window handle, an absolute screen rectangle. Changes in the video
widget's absolute screen position therefore need to be propagated
into the MMF.
This change introduces a new object, AncestorMoveMonitor, which
installs an event filter on the QCoreApplication instance. A
VideoOutput object registers with the AncestorMoveMonitor, which
listens on its behalf for MoveEvents and ParentChangeEvents directed
at any of the ancestors of the VideoOutput. MoveEvents trigger a
callback to the VideoOutput instance, which then notifies the MMF of
the new screen rectangle. ParentChangeEvents cause the
AncestorMoveMonitor to update the ancestor list associated with the
target VideoOutput instance.
The video position now tracks that of the associated widget, but there
are two problems which require further investigation:
1. The video window lags behind. This may be an unavoidable
consequence of the fact that setting a new screen rectangle causes the
MMF to tear down its DSA session and start a new one; this is known to
block the window server and take some time to complete.
2. Artifacts are visible around the edges of the moving video widget.
Task-number: QTBUG-4787
Reviewed-by: Frans Englich
|
