| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Replaced VolumeObserver and VideoOutputObserver interfaces with
signals.
- Added signals for propagating changes in aspect ratio and scale mode
from VideoOutput to VideoPlayer.
- Removed VideoPlayer::getNativeWindowSystemHandles. Interaction with
window system is moved into VideoOutput, so that VideoPlayer is better
focussed on its main task: interacting with CVideoPlayerUtility.
- WId changes, resize and move events received by the VideoOutput
widget cause it to emit a videoWindowChanged signal. This is received
by the VideoPlayer, which triggers a call to updateVideoRect. The
main task of this function is to calculate the scale factors which are
provided to the MMF via CVideoPlayerUtility::SetScaleFactorL. Note
that:
i) This function must be called both before and after the call
to SetDisplayWindowL. For changes in aspect ratio or scale
mode, setting the scale mode after updating the display window
is sufficient. However, testing showed that, when switching in
or out of full-screen mode, two calls were necessary in order
to preserve the correct aspect ratio.
ii) The screen rectangle passed to the MMF is still the full
window extent; it is not the region in which video will
actually be rendered. The post-processor will fill in the
remainder of the window with a background colour (typically
black). If, on the other hand, we passed in the actual video
display rectangle, we would need to do this background painting
in the widget. This in turn would require a change to QtGui:
at present, we can only disable blitting on a per-widget basis
(by setting QWExtra::disableBlit). If we needed to paint the
borders of the video window, disableBlit would need to contain
the actual DSA region, rather than just a single boolean flag.
Task-number: QTBUG-5585
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
|
| |
|
|
|
| |
Task-number: QTBUG-4664
Reviewed-by: Frans Englich
|
| |
|
|
|
|
| |
Moved common code into videoOutputRegionChanged()
Reviewed-by: Frans Englich
|
| | |
|
| | |
|
| |
|
|
|
|
| |
See VideoOutput::transparentFill. This should be called from the paintEvent, having removed the TranslucentWindowBackground hack from the mediaplayer demo.
As yet this has not been tested.
|
| |
|
|
| |
Symbian control / window associated with each widget
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
VideoPlayer
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These hacks, which are enabled using macros in defs.h, are:
PHONON_MMF_HARD_CODE_VIDEO_RECT
VideoPlayer should obtain the screen rectangle into which video rendering will occur, using the CoeControl associated with the video widget (i.e. the VideoOutput object). However, this control always has co-ordinates (relative to its parent) of (0,0)-(100,30), regardless of whether updateGeometry() and show() are called on the widget. So, this macro just hard-codes the screen rectangle to a value which works when the breakfast.mp4 clip is used for testing.
PHONON_MMF_EXPLICITLY_SHOW_VIDEO_WIDGET
In order that the video region does not overwrite the slider and buttons below it, the parent widget of the VideoObject instance must be appropriately re-sized. Debugging showed that both the parent and grandparent of VideoObject are in fact invisible at the time playback begins, so for now we just manually call show() on the grandparent.
Clearly both of these are only temporary measures, for use until the underlying cause of the problem has been determined.
|
| |
|
|
| |
no effect at present
|
| |
|
