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
