Move the backend specific documentation into a nicer place.
We really don't need to bore the 99.9% of people who won't care. And it's certainly not more important than camera. Reviewed-by: Derick Hawcroft (cherry picked from commit 51e3a1bc45ffc2688fcd3949216aedda4c41bf81) Change-Id: I8add47e42c2c06bf5e16f406604a19531af6901e Reviewed-on: http://codereview.qt-project.org/5501 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Michael Goddard <michael.goddard@nokia.com>
This commit is contained in:
Michael Goddard
committed by
Qt by Nokia
Qt by Nokia
parent
589b2e3adf
commit
26d8bedc39
@@ -190,7 +190,7 @@ either on a double click or on a particular keypress.
|
||||
|
||||
\snippet ../../demos/player/player.cpp 2
|
||||
|
||||
|
||||
\omit
|
||||
\section2 Radio
|
||||
|
||||
QRadioTunerControl is a pure virtual base class that will be the basis for
|
||||
@@ -198,79 +198,7 @@ any platform specific radio device control. When the functions are
|
||||
implemented the developer will be able to quickly produce an application
|
||||
that supports the typical uses of an FM radio including tuning, volume,
|
||||
start, stop and various other controls.
|
||||
|
||||
\section1 Extending the API for Symbian and Maemo
|
||||
|
||||
|
||||
For the developer who wishes to extend the functionality of the Multimedia
|
||||
classes there are several classes of particular importance. The default
|
||||
classes are QMediaService, QMediaServiceProvider and QMediaControl.
|
||||
|
||||
Basically, the idea is that to use the Multimedia API you would use these
|
||||
three classes or classes derived from them as follows
|
||||
|
||||
\list
|
||||
\o \l QMediaServiceProvider is used by the top level client class to request a service. The top level class knowing what kind of service it needs.
|
||||
|
||||
\o \l QMediaService provides a service and when asked by the top level object, say a component, will return a QMediaControl object.
|
||||
|
||||
\o \l QMediaControl allows the control of the service using a known interface.
|
||||
\endlist
|
||||
|
||||
Consider a developer creating, for example, a media player class called MyPlayer.
|
||||
It may have special requirements beyond ordinary media players and so may
|
||||
need a custom service and a custom control. We can subclass \l QMediaServiceProvider
|
||||
to create our MyServiceProvider class. Also we will create a
|
||||
MyMediaService, and the MyMediaControl to manipulate the media service.
|
||||
|
||||
The MyPlayer object calls MyServiceProvider::requestService() to get an
|
||||
instance of MyMediaService. Then the MyPlayer object calls this service
|
||||
object it has just received and calling \l {QMediaService::requestControl()}{requestControl()}
|
||||
it will receive the control object derived from QMediaControl. Now we have
|
||||
all the parts necessary for our media application. We have the service
|
||||
provider, the service it provides and the control used to manipulate the
|
||||
service. Since our MyPlayer object has instances of the service and its
|
||||
control then it would be possible for these to be used by associated classes
|
||||
that could do additional actions, perhaps with their own control since the
|
||||
parameter to requestControl() is a c-type string, \i {const char *}, for the
|
||||
interface.
|
||||
|
||||
|
||||
\section2 Adding a Media Service Provider
|
||||
|
||||
The base class for creating new service providers is \l{QMediaServiceProvider}.
|
||||
The user must implement the \l{QMediaServiceProvider::requestService()}{requestService()}
|
||||
function
|
||||
|
||||
\code
|
||||
QMediaService* requestService(const QByteArray &type, const QMediaServiceProviderHint &hint);
|
||||
\endcode
|
||||
|
||||
The details of implementation will depend on the provider. Looking at the
|
||||
class \l QMediaServiceProvider for the default implementation. Notice that
|
||||
\l {QMediaServiceProvider::requestService()}{requestService()} uses the
|
||||
\l QMediaServiceProviderHint to look for the appropriate plugin and then to
|
||||
insert it into the plugin map. However, for a specific service provider there
|
||||
is probably no need for this approach, it will simply depend on what the
|
||||
developer wants to implement.
|
||||
|
||||
Other methods that may be overloaded
|
||||
\code
|
||||
void releaseService(QMediaService *service);
|
||||
|
||||
QtMediaServices::SupportEstimate hasSupport(const QByteArray &serviceType,
|
||||
const QString &mimeType,
|
||||
const QStringList& codecs,
|
||||
int flags) const;
|
||||
|
||||
QStringList supportedMimeTypes(const QByteArray &serviceType, int flags) const;
|
||||
|
||||
QList<QByteArray> devices(const QByteArray &serviceType) const;
|
||||
|
||||
QString deviceDescription(const QByteArray &serviceType, const QByteArray &device);
|
||||
\endcode
|
||||
|
||||
The choice of what needs to be done depends on what the developer wishes to do with the service.
|
||||
\endomit
|
||||
|
||||
|
||||
\section1 Camera Support
|
||||
@@ -376,37 +304,6 @@ the operation can be cancelled by calling
|
||||
cancellation can be done by calling \l {QCamera::unlock()}{unlock}(QCamera::LockFocus).
|
||||
|
||||
|
||||
|
||||
\section2 Camera Controls
|
||||
|
||||
\table
|
||||
\header
|
||||
\o Control Name
|
||||
\o Description
|
||||
\row
|
||||
\o camera
|
||||
\o The interface for system camera devices
|
||||
\row
|
||||
\o exposure
|
||||
\o Includes: flash mode; flash power; metering mode; aperture; shutter speed, iso setting
|
||||
\row
|
||||
\o focus
|
||||
\o Includes: optical zoom; digital zoom; focus point; focus zones
|
||||
\row
|
||||
\o image processing
|
||||
\o White balance; contrast; saturation; sharpen; denoise
|
||||
\row
|
||||
\o locks
|
||||
\o Handles the locking and unlocking of camera devices
|
||||
\endtable
|
||||
|
||||
|
||||
\section2 Classes
|
||||
\annotatedlist camera
|
||||
|
||||
|
||||
|
||||
|
||||
\target qtmultimediakit examples
|
||||
\section1 Examples
|
||||
|
||||
@@ -440,14 +337,18 @@ using the QML plugin. Video recording is not currently available.
|
||||
|
||||
\section1 Reference documentation
|
||||
|
||||
\section2 Main classes
|
||||
\section2 Main audio and video classes
|
||||
|
||||
\annotatedlist multimedia
|
||||
|
||||
\section2 Camera classes
|
||||
|
||||
\section2 Classes for service implementers.
|
||||
\annotatedlist camera
|
||||
|
||||
\annotatedlist multimedia-serv
|
||||
\section2 Advanced usage.
|
||||
|
||||
For developers wishing to access some platform specific settings, or to
|
||||
port the Qt Multimedia APIs to a new platform or technology, see \l{Multimedia Backend Development}.
|
||||
|
||||
\section2 QML Elements
|
||||
\list
|
||||
|
||||
126
doc/src/multimediabackend.qdoc
Normal file
126
doc/src/multimediabackend.qdoc
Normal file
@@ -0,0 +1,126 @@
|
||||
/****************************************************************************
|
||||
**
|
||||
** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
|
||||
** All rights reserved.
|
||||
** Contact: Nokia Corporation (qt-info@nokia.com)
|
||||
**
|
||||
** This file is part of the documentation of the Qt Toolkit.
|
||||
**
|
||||
** $QT_BEGIN_LICENSE:FDL$
|
||||
** GNU Free Documentation License
|
||||
** Alternatively, this file may be used under the terms of the GNU Free
|
||||
** Documentation License version 1.3 as published by the Free Software
|
||||
** Foundation and appearing in the file included in the packaging of
|
||||
** this file.
|
||||
**
|
||||
** Other Usage
|
||||
** Alternatively, this file may be used in accordance with the terms
|
||||
** and conditions contained in a signed written agreement between you
|
||||
** and Nokia.
|
||||
**
|
||||
**
|
||||
**
|
||||
**
|
||||
** $QT_END_LICENSE$
|
||||
**
|
||||
****************************************************************************/
|
||||
|
||||
|
||||
/*!
|
||||
|
||||
\page multimediabackend.html
|
||||
\brief Information for implementing a new multimedia backend.
|
||||
\ingroup mobility
|
||||
|
||||
\tableofcontents
|
||||
|
||||
\section1 Multimedia Backend Development
|
||||
|
||||
In some cases the available cross-platform Multimedia APIs or implementations are not sufficient,
|
||||
or not immediately available on a certain platform. In some cases the multimedia
|
||||
implementation on a platform might expose certain extra properties or functionality
|
||||
that other platforms do not, or a finer degree of control might be possible. For these
|
||||
cases, it is possible to use extended controls directly.
|
||||
|
||||
In addition, if you plan to port the Qt Multimedia APIs to a new platform, you do
|
||||
this by implementing certain control and service classes, as detailed below.
|
||||
|
||||
\section1 Extending the API
|
||||
|
||||
For the developer who wishes to extend the functionality of the Multimedia
|
||||
classes there are several classes of particular importance. The default
|
||||
classes are QMediaService, QMediaServiceProvider and QMediaControl.
|
||||
|
||||
Basically, the idea is that to use the Multimedia API you would use these
|
||||
three classes or classes derived from them as follows
|
||||
|
||||
\list
|
||||
\o \l QMediaServiceProvider is used by the top level client class to request a service. The top level class knowing what kind of service it needs.
|
||||
|
||||
\o \l QMediaService provides a service and when asked by the top level object, say a component, will return a QMediaControl object.
|
||||
|
||||
\o \l QMediaControl allows the control of the service using a known interface.
|
||||
\endlist
|
||||
|
||||
Consider a developer creating, for example, a media player class called MyPlayer.
|
||||
It may have special requirements beyond ordinary media players and so may
|
||||
need a custom service and a custom control. We can subclass \l QMediaServiceProvider
|
||||
to create our MyServiceProvider class. Also we will create a
|
||||
MyMediaService, and the MyMediaControl to manipulate the media service.
|
||||
|
||||
The MyPlayer object calls MyServiceProvider::requestService() to get an
|
||||
instance of MyMediaService. Then the MyPlayer object calls this service
|
||||
object it has just received and calling \l {QMediaService::requestControl()}{requestControl()}
|
||||
it will receive the control object derived from QMediaControl. Now we have
|
||||
all the parts necessary for our media application. We have the service
|
||||
provider, the service it provides and the control used to manipulate the
|
||||
service. Since our MyPlayer object has instances of the service and its
|
||||
control then it would be possible for these to be used by associated classes
|
||||
that could do additional actions, perhaps with their own control since the
|
||||
parameter to requestControl() is a c-type string, \i {const char *}, for the
|
||||
interface.
|
||||
|
||||
|
||||
\section2 Adding a Media Service Provider
|
||||
|
||||
The base class for creating new service providers is \l{QMediaServiceProvider}.
|
||||
The user must implement the \l{QMediaServiceProvider::requestService()}{requestService()}
|
||||
function
|
||||
|
||||
\code
|
||||
QMediaService* requestService(const QByteArray &type, const QMediaServiceProviderHint &hint);
|
||||
\endcode
|
||||
|
||||
The details of implementation will depend on the provider. Looking at the
|
||||
class \l QMediaServiceProvider for the default implementation. Notice that
|
||||
\l {QMediaServiceProvider::requestService()}{requestService()} uses the
|
||||
\l QMediaServiceProviderHint to look for the appropriate plugin and then to
|
||||
insert it into the plugin map. However, for a specific service provider there
|
||||
is probably no need for this approach, it will simply depend on what the
|
||||
developer wants to implement.
|
||||
|
||||
Other methods that may be overloaded
|
||||
\code
|
||||
void releaseService(QMediaService *service);
|
||||
|
||||
QtMediaServices::SupportEstimate hasSupport(const QByteArray &serviceType,
|
||||
const QString &mimeType,
|
||||
const QStringList& codecs,
|
||||
int flags) const;
|
||||
|
||||
QStringList supportedMimeTypes(const QByteArray &serviceType, int flags) const;
|
||||
|
||||
QList<QByteArray> devices(const QByteArray &serviceType) const;
|
||||
|
||||
QString deviceDescription(const QByteArray &serviceType, const QByteArray &device);
|
||||
\endcode
|
||||
|
||||
The choice of what needs to be done depends on what the developer wishes to do with the service.
|
||||
|
||||
\section2 Classes for service implementers.
|
||||
|
||||
\annotatedlist multimedia-serv
|
||||
|
||||
*/
|
||||
|
||||
|
||||
Reference in New Issue
Block a user