| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Phonon API does not provide any way for the client to specify
which network connection should be used for streaming playback.
If the application already has a connection open, using a bearer
other than the default (e.g. using WiFi when the device default is
GPRS), it may be desirable to use it for streaming, rather than
allowing the Phonon backend to open a second connection on the
default bearer.
This patch adds a custom property on the Phonon::MediaObject,
called InternetAccessPointName. The client can specify the IAP
which Phonon should use by setting this property.
Note that support for this property is only provided in the Phonon
MMF backend.
Task-number: QTBUG-11436
Reviewed-by: Gareth Stockwell
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
downloadmgrclient.h is not found on S^4 baselines, causing a build
failure. This commit is a temporary workaround, which disables
progressive download support if the header is not found.
The correct solution is to determine whether the RHttpDownloadMgr
definition has moved, and if so, to modify the .pro file to
include the new path.
Task-number: QTBUG-10769
Reviewed-by: TrustMe
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
A recent change meant that, if the user set a volume level before
loading a clip into the MediaObject, that initial volume level was
not applied to the audio output.
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
| |
Previously, the MMF backend simply swallowed a call to pause() when in
StoppedState. However, the stopToPause step in tst_mediaobject requires
the backend to emit a stateChanged signal when this happens.
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
| |
This behaviour is required by the testPauseOnFinish step in
tst_mediaobject.
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If MediaObject::play() is called while the object is in LoadingState,
playback will start once loading is completed. Previously, the
Symbian backend at this point emitted two stateChanged signals - first
to StoppedState and then to PlayingState.
The testPlayOnFinish step in tst_mediaobject requires that only one
state change occurs: directly from LoadingState to PlayingState.
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
| |
Fixes testPrefinishMark step in tst_mediaobject.
Task-number: QTBUG-9339
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that, after a call to CMdaAudioPlayerUtility::SetPosition,
the reported position values are slightly lower than they should be.
This, combined with the fact that the backend emitted aboutToFinish
from its timer tick slot, means that the aboutToFinish signal is
sometimes not emitted at the end of an audio clip, if the position
has been advanced by seeking during playback.
This patch adds a check in the implementation of the
MMdaAudioPlayerCallback::MapcPlayComplete callback - if, at this point,
aboutToFinish has not been emitted, it is emitted now.
Task-number: QTBUG-9368
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
|
| |
The following source types are handled in MediaObject::createPlayer
Invalid, Disc, Stream, Empty
The code removed in this patch is therefore never executed.
Reviewed-by: Frans Englich
|
| |
|
|
|
| |
Task-number: QTBUG-6214
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
| |
The main changes are:
1. MediaObject emits prefinishMark at the appropriate instant
2. MediaObject emits aboutToFinish at the appropriate instant
3. MediaObject switches to next source when playback completes
Task-number: QTBUG-6214
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Modified the sequence of calls made to the MMF APIs when seeking
during ongoing playback. This fixes a bug found during early testing
of streaming playback, whereby playback would not resume following
the seeking operation. This was due to an interaction between the
pause / seek / play operations, and the buffering callbacks received
from the MMF, which caused the backend to enter an incorrect state.
Task-number: QTBUG-4660
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When clips are buffering (either at the start of playback, or
during playback, when buffer levels drop due to e.g. CPU, file system
or network load), the backend receives notification from the MMF.
While buffering is ongoing, the backend periodically queries the
filling status and emits a signal.
Task-number: QTBUG-4660
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the MIME type of the stream cannot always be deduced from the
URL, we assume that it is a video stream. This is based on the
assumption that the video controllers will be capable of parsing
the container formats for audio-only, as well as video clips. Note
that this assumption may not hold on all devices.
Note that most implementations of the MMF client APIs do not support
HTTP streaming (a.k.a. progressive download). The backend has therefore
only been tested with RTSP streams - see the JIRA entry for further
details.
Task-number: QTBUG-4660
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
| |
When the mediaplayer receives a state change into the ErrorState, it
calls pause() on the media object. Previously, this caused the
backend to transition into PausedState. When the mediaplayer subsequently
called errorString() to retrieve the error message, an empty string was
returned because the backend was no longer in the ErrorState.
Task-number: QTBUG-4994
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
|
|
| |
Note that changing Utils from a namespace into a class, and then
using Q_DECLARE_TR_FUNCTIONS in the class declaration, was necessary
in order to be able to call tr(...) from the implementation of
Utils::symbianErrorToString.
Task-number: QTBUG-4994
Reviewed-by: Oswald Buddenhagen
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
| |
When qmediaplayer receives a stateChanged(ErrorState) signal, it first
displays a dialog, and then calls pause() on the media object. This
change allows that pause command to be executed on the underlying MMF
client API.
Reviewed-by: Frans Englich
|
| |
|
|
|
| |
Task-number: QTBUG-4662
Reviewed-by: Frans Englich
|
| |
|
|
|
| |
Task-number: QTBUG-4777
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug introduced by 58efa8aa, which meant that, when a new
clip was opened:
1. Playback did not start automatically
2. The current volume setting in the app UI was not applied to the
MMF client API
Task-number: QTBUG-4999
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Errors reported via:
* the DummyPlayer didn't work due to it not doing the usual state
transitions/emission
* MediaObject::setSource() due to errors being emitted
before connections being set up.
* A general state bug.
Task-number: QTBUG-4752
Reviewed-by: Gareth Stockwell
|
| |
|
|
|
| |
sed -i -e 's/\t/ /g' `find -name "*.cpp" -or -name "*.h" -or -name
"*.pro"`
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
mmfphonon
Conflicts:
src/3rdparty/phonon/mmf/abstractplayer.cpp
|
| | |
| |
| |
| | |
Volume changes made before playback starts are now correctly propagated.
|
| |/
|
|
|
|
|
|
|
|
|
| |
This brings tst_MediaObject to 15/7, from previously not running. Changes
involves:
* Skipping .qrc related tests
* Loading/mimetype detction from file:/ URIs
* State fixes
* As part of previous point, move state and error handling down in
AbstractPlayer.
|
| |
|
|
| |
Addresses review comment.
|
| | |
|
| |
|
|
|
| |
MediaObject deals with an AbstractPlayer, so make sure we have the signals
declared in that base class, instead of individually in each sub-class.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This was causing the stateChanged signal not to propagate up to the Phonon client. In the case of the mediaplayer demo, this causes the app not to show() the ancestor of the VideoWidget, resulting in the layout not being updated when the clip has been loaded.
This means that the hack to explicitly call show() on this ancestor from the backend has been removed.
Now the layout is correctly updated, but the size of VideoOutput::winId()->Rect() is still incorrect, so the hack to hard-code the screen rectangle passed to CVideoPlayerUtility is left in place.
|
| | |
|
| |
|
|
|
|
| |
list.
This was due to the backend returning an incorrect initial state value. Phonon::MMF::AbstractMediaPlayer::GroundState is now correctly mapped to Phonon::LoadingState. (Previously it mapped to Phonon::StoppedState).
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Now loads, prepares and plays a clip, but the video is not visible because it's not yet wired up to a VideoWidget.
Video 'playback' can be tested using the demos/mediaplayer application, but the menus are not displayed properly, so a video clip filename must be hardcoded in main.cpp and passed to the MediaPlayer constructor.
|
| | |
|
| |
|
|
| |
and AudioOutput
|
| | |
|
| | |
|
|
|
AbstractMediaPlayer
|
