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

List:       helix-protocol-dev
Subject:    [Protocol-dev] RE: [Nokia-private-dev] URGENT CR: ou1cimx1#862279:
From:       <ext-debashis.2.panigrahi () nokia ! com>
Date:       2011-07-14 5:24:08
Message-ID: 4F1FCFB9A4D47743A214B43D6F2F3B63071920 () 008-AM1MPN1-032 ! mgdnok ! nokia ! com
[Download RAW message or body]

Hi Sheldon,

Thanks for the comments.
Yes, we may lose A/V sync, with a server with correct RTCP sender reports,
but this a trade-off we have considered for streaming to work properly
on these bad servers.
Before we have tried on some other live servers and have not found much
of a drift.

Thanks and Regards,
Debashis. 

-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com] 
Sent: Wednesday, July 13, 2011 6:21 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] URGENT CR: ou1cimx1#862279: OTC - VHA(VF&3)_H264 \
Live streaming trembling every several seconds on N8

With a 'good' live server that does send correct RTCP SR, won't this 
change cause A/V sync problem when playing for longer time? The reason 
that the NPT to NTP mapping is sent in the SR periodically is to counter 
the sync drift between streams. If we only use the first SR, we'll loss 
that ability. Have we tried the change on some other live server for 
longer play? I think a server setup that uses separate microphone  and 
video cam for input probably will show the drift problem.

On the other hand, if the Nokia solution is going to be used only with 
certain server(s) that doesn't use SR for drift adjustment at all then 
this change looks good.

fxd

On 07/13/2011 06:06 AM, ext-debashis.2.panigrahi@nokia.com wrote:
> "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-debashis.2.panigrahi@nokia.com
> 
> Reviewed by:  chris.beale@nokia.com
> 
> RC Id: ou1cimx1#862279
> 
> Date: 07/13/2010
> 
> Project: SymbianMmf_wm
> 
> Synopsis: OTC - VHA(VF&3)_H264 Live streaming trembling every several seconds on N8
> 
> Overview:
> The RTCP syncs that are being reported in Sender report by the content Server are \
> incorrect, which causes the computed packet timestamps to go wrong, while we adjust \
> the RTP timestamps with the received NTP time.  Hence as the presentation time \
> stamps are un-ordered, this causes the stream to tremble every few seconds. Now \
> going for RTCP sync only if (NTP-NTPbase) is greater than NPT time, will lead to \
> frame jumps and ignoring all the Master syncs except the first one for the video \
> stream (slave stream) is causing A/V problems. 
> Fix:
> Therefore merging the same RTCP sync dropping logic has been done in 210CayS on \
> 420Brizo. Whereby we are ignoring all the RTCP syncs except the first one, which \
> should include the master sync and anchor sync for the streams, if any. Also \
> resetting the "m_bRTCPSyncOnceDone" flag if seek is getting called. We can minimize \
> the impact of this change with the check for Server version but it is not \
> straightforward, as this will involve large change in rtsp client and rtp transport \
> to bring in the information, one for setting and another for getting it. 
> Files modified&  changes:
> protocol/transport/rtp/rtptran.cpp
> protocol/transport/rtp/pub/rtptran.h
> 
> Image Size and Heap Use impact: No major impact
> 
> Module Release testing (STIF) : Passed
> 
> Test case(s) Added  : No
> 
> Memory leak check performed : Passed, No additional leaks introduced.
> 
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
> 
> Platforms and Profiles Functionality verified: armv5, winscw
> 
> Branch: 420Brizo
> 
> CVS Diff on 420Brizo: Attached


_______________________________________________
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]