| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit integrates the Download class with the media playback
classes in the backend, to implement Progressive Download.
Note that this PDL implementation has one drawback: when video
playback is paused due to shortage of data (i.e. due to the download
being temporarily stalled), the display goes black. This is because,
when the end of the currently-downloaded data is reached, the
playback session is closed. When more data becomes available, the
clip is re-opened, a seek is done to reach the previous playback
position, and playback is re-started. Closing the playback session
closes the video stack's connection to the display, thereby causing
the video widget to go black while more data is buffered.
This is a consequence of the level in the native video stack at which
the Phonon integration is done: managing a network stall without
requiring the playback session to be closed would require integration
below the MMF client API, specifically at the MMF controller level.
Task-number: QTBUG-10769
Reviewed-by: Derick Hawcroft
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backend accesses the resource file path via MediaSource::url().
A small patch to Phonon was required to enable this, because by
default, Phonon passes a QIODevice, rather than the resource file
path, to the backend.
The backend uses this path to create a QResource object, through which
the memory buffer into which the resource file has been read can be
accessed. This buffer is wrapped in a Symbian 8-bit descriptor and
passed to the OpenDesL() function of the appropriate MMF client
utility API.
Playback only works for certain file formats, as the Symbian MIME type
recognizer does not always work. For example, playback of an audio
WAV resource file works, while playback of an MP3 resource file does
not.
Task-number: QTBUG-6562
Reviewed-by: Justin McPherson
|
|
|
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
|
