Hi Pavan, Thanks for the information, it sounds as though the Qt Mobility APIs will support most of the behaviour I described.
In terms of using different IAPs for different streaming protocols, there are a couple of situations where this may be required: 1) Some IAPs may not support specific protocols. For example, the vodafone network in the UK has limited support for RTSP streams (see http://www.theregister.co.uk/2010/06/18/vodafone_rtsp/). It may therefore be preferable to use WLAN as a default access point for RTSP streams, but a mobile network access point as the default for HTTP requests. 2) A backend implementation may use different mechanisms to access data using different protocols. For example, the Symbian backend for Phonon uses RDownload to access HTTP URLs, and MMF to access RTSP URLs. The preferred "default" IAP in each case may be different. Although providing a list of network access points in priority order to QMediaPlayer could be used to work around these situations, it may be more efficient if it was possible to specify when a given IAP should be tried first. Best Regards, Ruth ________________________________________ From: Kumar-Chikkala Pavan (Nokia-MS/Bangalore) Sent: 16 January 2011 17:07 To: Sadler Ruth (EXT-Accenture/UnitedKingdom); [email protected] Subject: RE: Network connections and multimedia streaming Hi, Yes, we are almost there with Qt Mobility API (1) can be achieved using QNetworkSession and QNetworkConfiguration (2) can be achieved using QMediaPlayer::setNetworkConfigurations. This support is just added and will be released in Qt Mobility 1.2 (3) Client can pass set of network access points in priority order to QMediaPlayer.When initial connection fails, backend will try opening the connections in the same order till it is successful. If client wants user to choose the next access point each time a connection fails, it can pass only one access point to QMediaPlayer each time. Could you please elaborate your point on difference in handling of connections for different media streaming protocols? Regards, Pavan ________________________________________ From: qt-mobility-feedback-bounces+pavan.kumar-chikkala=nokia....@qt.nokia.com [qt-mobility-feedback-bounces+pavan.kumar-chikkala=nokia....@qt.nokia.com] on behalf of ext [email protected] [[email protected]] Sent: 13 January 2011 20:14 To: [email protected] Subject: [Qt-mobility-feedback] Network connections and multimedia streaming Hi there, I’ve recently been looking at an issue in the QT Phonon Multimedia backend related to the network connection used when streaming media. It is possible (on Symbian) to get in to a state where the phone has a valid network connection, but requests to stream media using the default connection fail, as that network connection is not set as the default for multimedia. There is also a slight difference in handling of connections for different media streaming protocols (http or rtsp). I understand that the Bearer Mobility APIs should allow the network connection used by an application to be controlled. I’m not really familiar with these APIs, but ideally, I think that the Qt-mobility APIs should: 1) Allow querying/setting of default network connections (including allowing setting of separate default connections for MM streaming protocols) 2) Allow applications to override the default bearer to be used for specific functionality (e.g. via QMediaPlayer), again all protocols should use the specified bearer 3) Handle failures using the initial bearer (either default or client specified) with consistent, documented behaviour (either raise an error, or fall back to an alternative bearer). Does this sounds like the desired behaviour? To what extent is this behaviour currently supported through the existing Qt-mobility APIs and backend implementations? Best Regards, Ruth _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback _______________________________________________ Qt-mobility-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-mobility-feedback
