CR: RTSP, RTP and 3GPP Adaptation fixes

Milko,

My comments:

1) When adding/removing UINT32 sequence numbers to
   m_ResumeRequestPendingReplyList, why not just
   store them in the void* rather than allocating
   and deleting a UINT32 every time? Not a big deal,
   but it seems like a needless allocation.
2) Did you want to keep this?

   +    // ulTimeToRewind = 0;  MBO Test

Rest looks good.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: helix-client-dev-bounceshelixcommunity.org 
> [mailto:helix-client-dev-bounceshelixcommunity.org] On 
> Behalf Of Milko Boic
> Sent: Tuesday, November 14, 2006 2:36 AM
> To: protocol-devhelixcommunity.org; 
> helix-client-devhelixcommunity.org
> Subject: [Helix-client-dev] CR: RTSP, RTP and 3GPP
Adaptation fixes
> 
> Modified by: milkoreal.com
> Date: 11:13:06
> Project: Atlas
> 
> Synopsis: RTSP, RTP and 3GPP Adaptation fixes
> 
> Overview:
> This submission includes enhancements and fixes to a
number of RTSP 
> protocol related defects:
> 
> -> Enabled logging in rtsp protocol library
> 
> -> Properly handled PLAY reponse to PLAY request
issued for 
> resumption of 
> playback not to be isunderstood for PLAY response
received on 
> seek.  Previously, the following sequence of RTSP
commands caused 
> mishandling in the transport buffer due to improperly
set 
> first sequence 
> number and thus resuting in freeze of audio or video
playback 
> or freeze in 
> both.  The freezing occured due to inclusion of stale
data 
> into poset seek 
> packets.
> 
> PAUSE
> 
> PAUSE resp
> 
> PLAY  (resume)
> 
> PLAY  (seek)
> 
> PLAY resp (resume)
> 
> PLAY resp (seek)
> 
> The correction records PLAY command sequence numbers 
> represeting resumption 
> (as opposed to seek) and handles the response
differently.
> 
> -> In RTP transport removed time-out for receotion
of play 
> response.  If 
> play response is not received, playback will not start.
 Any 
> pre-start 
> packet queueing is limited to the set transport buffer
byte limit.
> 
> -> Corrected handling of 3gpp alternate streams. 
The parsing 
> logic did not 
> properly set RTPPayloadType if an alternate stream was
chosen.  This 
> resulted all incomming RTP packets to be rejected due
to not 
> matching the 
> RTP payload.
> 
> -> Corrected handling of fast start on RTP streams
with RTSP 
> pipelining 
> enabled.  Previously, the code crashed in attempt to
set FastStart on 
> transport streams not yet set-up.  This occured to RTPS
pipelining 
> optimizations which allowe playback engine to proceed
with 
> set-up prior to 
> all streams setting up porperly.  The fix account for 
> possibility of fast 
> start being communicated to a transport stream prior to
it 
> being fully 
> set-up and deferes needed action until full set-up is
accomplished.
> 
> -> Properly handled pipleined seek messaged in
RTSP/RTP by 
> keeping track of 
> outstanding seeks in transport and ignoring RTP info
for 
> intermediate seeks:
> PLAY (seek1)
> 
> PLAY (seek2)
> 
> PLAY (seek3)
> 
> PLAY resp (seek1)
> 
> PLAY resp (seek2)
> 
> PLAY resp (seek3)
> 
> -> Updated few log statements in client audio
services and corrected 
> sequence of
m_Owner->CheckIfLastNMilliSecsToBeStored() 
> invocation thus 
> resulting on proper communication of
NMilliSecsToBeStored on stream 
> creation.  This only correctes asserts in certain
cases.  No 
> known defects 
> are associated with this change.
> 
> 
> Files Modified:
> /client/audiosvc/hxaudply.cpp,v
> /client/audiosvc/hxaudstr_new.cpp,v
> /protocol/rtsp/rtspclnt.cpp,v
> /protocol/rtsp/pub/rtspclnt.h,v
> /protocol/sdp/sdpmdparse.cpp,v
> /protocol/transport/common/system/rtsptran.cpp,v
> /protocol/transport/common/system/transbuf.cpp,v
> /protocol/transport/common/system/pub/rtsptran.h,v
> /protocol/transport/common/system/pub/transbuf.h,v
> /protocol/transport/rtp/rtptran.cpp,v
> /protocol/transport/rtp/pub/rtptran.h,v
> 
> 
> Image Size and Heap Use impact (Client -Only):
> Insignificant.
> 
> Platforms and Profiles Affected:
> All
> 
> Distribution Libraries Affected:
> none
> 
> Distribution library impact and planned action:
> n/a
> 
> Platforms and Profiles Build Verified:
> win32-i386-vc7, helix-client-all-defines
> 
> Platforms and Profiles Functionality verified:
> win32
> 


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev