[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-protocol-dev
Subject:    [Protocol-dev] RE: [Common-dev] CN: EAMO-7NXA4Y Server-controlled
From:       <ext-jesus.1.rodriguez () nokia ! com>
Date:       2009-03-13 22:39:52
Message-ID: B26CC1CBE7B84E4DAC8886E1C12FB3800139BE56 () xesebe102 ! nee ! nokia ! com
[Download RAW message or body]

Checked into CayS221 and CayS210.
 
Cheers,
-JA

________________________________

From: common-dev-bounces@helixcommunity.org on behalf of ext \
                ext-jesus.1.rodriguez@nokia.com
Sent: Wed 2009-03-11 18:17
To: client-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; \
                common-dev@helixcommunity.org; protocol-dev@helixcommunity.org
Subject: [Common-dev] (RESEND) CR: EAMO-7NXA4Y Server-controlled start time(AKA \
ServerStartTime, successor to ApproxSeek)



"Nokia submits this code under the terms of a commercial contribution agreement with \
Real Networks, and I am authorized to contribute this code under said agreement."

Modified by: ext-jesus.1.rodriguez@nokia.com
Reviewed by: milko@real.com
Date: Mar 11, 2009
Project: SymbianMmf_rel
ErrorId: EAMO-7NXA4Y
Synopsis: Server-controlled start time (AKA ServerStartTime, successor to \
ApproxSeek).

Overview:
There are some servers that implement what I will call here "server-side bookmarks"; \
that is, they remember the position a client left a stream in, and resume from that \
point when asked for that stream again. These servers inform the client about that \
bookmark position via the Range: header in an RTSP PLAY response.

This calls for a generalization/revamping of ApproxSeek. At the same time, we feel \
the interface nature of ApproxSeek is no longer needed, since this use case is \
exclusive to RTSP streaming. Therefore, the IHXApproxSeek interface is dropped in \
favour of a sequence that effectively begins in RTSPProtocol, rather than \
HXMMFPlayCtrl.

Solution:
Opposite to what ApproxSeek did, ServerStartTime qualifies whether the \
UseServerStartTime flag is true in the configuration files, while constructing \
RTSPProtocol, not in HXMMFPlayCtrl::Seek. If UseServerStartTime is false (default) or \
unset, the player's timing remains as usual. Otherwise, when Helix receives an answer \
to an RTSP PLAY, RTSPProtocol saves the new range (already implemented in ApproxSeek, \
no change in behaviour there) and will issue the \
HXNetSource::HandleServerStartTimeResponse() callback, which goes all the way up to \
HXPlayer. Here, HXPlayer will inform everyone involved  (CAudioPlayer, SourceInfo, \
HXNetSource, if applicable) of the change.

As the server start time becomes authoritative in this use case, the use of the start \
query string parameter on the client side (for initialization purposes) becomes \
meaningless and even potentially dangerous, depending on the underlying multimedia \
architecture. The initialization procedure should be delayed or redone in such a \
case, but the urgency of this feature forces us to treat this particular condition \
separately.

Modified files:
/common/include/hxcore.h
/common/include/hxhxiids.h
/clientapps/symbianMmf/hxmmfplayctrl.cpp
/clientapps/symbiancommon/config/R1_Mobile_4_0_Factory.cfg
/client/core/hxntsrc.cpp
/client/core/hxntsrc.h
/client/core/hxplay.cpp
/client/core/rtspprotocol.cpp
/client/core/pub/hxplay.h
/protocol/rtsp/rtspclnt.cpp
/protocol/rtsp/pub/rtspclnt.h

New files: None
Image size and heap use impact: Negligible
Module Release testing (STIF): Yes
Test case(s) added: No
Memory leak check performed: Yes, no new leaks introduced.
Platforms and Profiles Build verified: helix-client-s60-32-mmf-mdf-arm, \
helix-client-s60-50-mmf-mdf-arm Platforms and Profiles Functionality verified: armv5
Branch: 221Cays, 210Cays





_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev


[prev in list] [next in list] [prev in thread] [next in thread]