From gbajaj at real.com Tue Jan 2 06:21:24 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Tue Jan 2 07:13:55 2007
Subject: [Protocol-dev] CR:Failing on ASSERT while streaming over proxy with
HTTPCloaking is enabled.
In-Reply-To: <4594B986.9000705@real.com>
References: <458BEEA5.2030504@real.com>
<6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com>
<459263F6.5090702@real.com>
<6.2.1.2.2.20061228141924.07a05c18@mailone.real.com>
<4594B986.9000705@real.com>
Message-ID: <459A6A64.5020400@real.com>
Synopsis:
This change fixes the ASSERT issue which is occurring while streaming
over proxy with HTTPCloaking is enabled.
Overview:
In the current scenario, StartAuthenticationIfNeeded(pBuf) is being
called each time when GET channel has inbound data available for
reading, which at times contains binary data too. This causes binary
data to be parsed and end up with failing on an ASSERT in MSVCR71D.dll.
Ideally StartAuthenticationIfNeeded(pBuf) should be called only
when we have HTTP headers, containing ASCII data, coming from the get
channel.
This change fixes the ASSERT issue by calling
StartAuthenticationIfNeeded(pBuf) function only if binary data is not
coming from GET socket.
Files Added:
None
Files Modified:
protocol/common/util/HxCloakedSocket.cpp
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
Not a platform specific change
Distribution Libraries Affected:
no
Distribution library impact and planned action:
None
Platforms and Profiles Build Verified:
BIF branch -> HEAD_restricted
Target(s) ->splay
Profile ->helix-client-all-defines
SYSTEM_ID=win32-i386-vc7
Branch:
HEAD
Files Attached:
HttpCloakAssert.diff.txt
Thanks and Regards,
Gaurav Bajaj
Gaurav Bajaj wrote:
>
> Hi,
>
> ASSERT is occurring in "msvcr71d.dll" when
>
> "iscntrl(ch)" function is called from ---> (if(strchr(tspecials, ch)
> || iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
> with a negative value like "-58" passed in it (e.g. ch =-58)
>
> This character is read into "ch" from m_input.read(); which is being
> called
> inside this function call ----> MIMEToken nextTok = scanner.nextToken();
>
> Call stack when assert failed is as follows:
>
> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ---->
> "mimescan.cpp"
> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
> called from Line 352, ----> "httppars.cpp"
> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
> called from Line 455 ----> "httppars.cpp"
> rtspclnt.dll!HTTPParser::parseRequest() called from Line 588
> ------> "httppars.cpp"
> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48,
> unsigned long & nMsgLen=1500) called from Line 3206
> ------>"hxcloakedsocket.cpp"
> rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer
> * pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>
>
> Thanks & regards
> Gaurav Bajaj
>
>
>
>
> Milko Boic wrote:
>>
>> Which assert precisely is triggered?
>>
>> The change below does not seem right. It seems that int chRet would
>> never be negative after the change and the code compares chRet to -1.
>>
>> Milko
>>
>>
>>
>> At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>> Hi,
>>>
>>> Assert occurs when
>>>
>>> HTTPResponseMessage* pMessage =
>>> (HTTPResponseMessage*)Parser.parse( pBufferContents, nMsgLen );
>>> function is called from
>>>
>>> HXBOOL
>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>> function.
>>>
>>> to parse "pBufferContents" .
>>>
>>>
>>> Merging the below changes solves this problem
>>>
>>> Index: mimescan.cpp
>>> ===================================================================
>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>> retrieving revision 1.9
>>> diff -u -r1.9 mimescan.cpp
>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>> @@ -108,7 +108,7 @@
>>>
>>> if(m_nCurOffset < m_nBufSize)
>>> {
>>> - int chRet = m_pBuffer[m_nCurOffset];
>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>> //XXXkshoop treat a EOF in the string as an end of file.
>>> // never read beyond it. don't inc the offset.
>>>
>>>
>>> It seems that use of VC7 to build Atlas code is causing this
>>> problem.
>>> Should I check-in these changes..?
>>>
>>> Thanks & Regards
>>> Gaurav Bajaj
>>>
>>>
>>> Milko Boic wrote:
>>>> At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>> Detailed Status Report
>>>>>
>>>>> Completed Items
>>>>>
>>>>> Merged the changes related to "[Bug 172459] PROXY FAILURE: Real
>>>>> Player unable to play streams over
>>>>> proxy when cloaking is enabled ", in HEAD , tested the behavior,
>>>>> failing on assert.
>>>>
>>>> What assert is HEAD failing on? Are you looking into resolving this?
>>>>
>>>>
>>>>> Checking out the code and making build of latest "voldemort"
>>>>> branch to repro the bugs assigned.
>>>>>
>>>>> Thanks & Regards
>>>>> Gaurav Bajaj
>>>>
>>>>
>>
>>
>>
>
-------------- next part --------------
Index: hxcloakedsocket.cpp
===================================================================
RCS file: /cvsroot/protocol/common/util/hxcloakedsocket.cpp,v
retrieving revision 1.16
diff -u -r1.16 hxcloakedsocket.cpp
--- hxcloakedsocket.cpp 2 Jan 2007 12:36:53 -0000 1.16
+++ hxcloakedsocket.cpp 2 Jan 2007 12:23:32 -0000
@@ -1,5 +1,5 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Source last modified: $Id: hxcloakedsocket.cpp,v 1.16 2007/01/02 12:36:53 gbajaj Exp $
+ * Source last modified: $Id: hxcloakedsocket.cpp,v 1.15 2006/12/26 12:12:46 gbajaj Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
@@ -2109,7 +2109,7 @@
HX_ASSERT(pBuf);
// check for and possibly begin handling http authentication
- if( StartAuthenticationIfNeeded(pBuf) )
+ if( m_getState != gsReadData && StartAuthenticationIfNeeded(pBuf) )
{
// authentication process started
hr = HXR_OK;
From ehyche at real.com Tue Jan 2 07:33:07 2007
From: ehyche at real.com (Eric Hyche)
Date: Tue Jan 2 08:25:53 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To:
Message-ID: <008501c72e83$4f110f20$db68a8c0@EHYCHED620>
There appear to be three streams: one video, one audio,
and one other (can't tell, since SDP is not in the
log file). I would assume the three SET_PARAMETER calls
after the RTSP PLAY correspond to each stream. Usually
these can be distinguished by the URL in the RTSP SET_PARAMETER
(i.e. - rtsp://...../foo.3gp/audio, etc.) but for some reason,
all of the URLs look the same in this exchange.
Henry might be able to shed some more light on this...
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: client-dev-bounces@helixcommunity.org
> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> rajesh.rathinasamy@nokia.com
> Sent: Thursday, December 21, 2006 12:02 PM
> To: client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> Subject: [Client-dev] Redundant SET_PARAMTER during start of stream
>
> Hi,
> we noticed that after PLAY message sent to server, there
> are redundant SET_PARAMETER (PIPELINED) sent to server. I
> don't see any change in the bandwidth value reported. The
> message looks identical except for sequence number. In the
> attached log, there is one SET_PARAMETER before PLAY and
> three consecutive SET_PARAMETER PIPELINED before PLAY response.
>
> Can someone explain why this is sent multiple times ? Is it
> an error ?
>
>
>
> Thanks,
> Rajesh.
>
> <>
>
>
From rajesh.rathinasamy at nokia.com Tue Jan 2 08:38:45 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Jan 2 09:31:50 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To: <008501c72e83$4f110f20$db68a8c0@EHYCHED620>
Message-ID:
Hi Eric,
Thanks for your time.
Attaching a new log file. This has the complete RTSP chat. I could see
same set of RTSP chat for all clips. The session does not have three
streams, it has only one audio and one video and still multiple
SET_PARAM are sent. Apart from that the url sent in SET_PARAM is same
for all messages.
If the intention is send SET_PARAM for individual streams, why is that
required. I thought we are responding the client bandwidth and why
should it be sent for individual streams ?
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Tuesday, January 02, 2007 9:33 AM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of stream
>
>
>There appear to be three streams: one video, one audio, and
>one other (can't tell, since SDP is not in the log file). I
>would assume the three SET_PARAMETER calls after the RTSP PLAY
>correspond to each stream. Usually these can be distinguished
>by the URL in the RTSP SET_PARAMETER (i.e. -
>rtsp://...../foo.3gp/audio, etc.) but for some reason, all of
>the URLs look the same in this exchange.
>
>Henry might be able to shed some more light on this...
>
>Eric
>
>=============================================
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.
>
>> -----Original Message-----
>> From: client-dev-bounces@helixcommunity.org
>> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>> rajesh.rathinasamy@nokia.com
>> Sent: Thursday, December 21, 2006 12:02 PM
>> To: client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> Subject: [Client-dev] Redundant SET_PARAMTER during start of stream
>>
>> Hi,
>> we noticed that after PLAY message sent to server, there are
>> redundant SET_PARAMETER (PIPELINED) sent to server. I don't see any
>> change in the bandwidth value reported. The message looks identical
>> except for sequence number. In the attached log, there is one
>> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
>> PIPELINED before PLAY response.
>>
>> Can someone explain why this is sent multiple times ? Is it
>an error ?
>>
>>
>>
>> Thanks,
>> Rajesh.
>>
>> <>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Redundant_SetParam_1.zip
Type: application/x-zip-compressed
Size: 28602 bytes
Desc: Redundant_SetParam_1.zip
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070102/06e5cee8/Redundant_SetParam_1-0001.bin
From ping at real.com Tue Jan 2 10:33:42 2007
From: ping at real.com (Henry Ping)
Date: Tue Jan 2 11:26:36 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To:
Message-ID:
Rajesh,
The SetDeliveryBandwidth requests via SET_PARAMER is for the whole
presentation, not per individual stream. It does seems to be redundant to
send multiple SetDeliveryBandwidth in sequence with the same bandwidth
value.
I assume you're building with the mobile profile which uses different buffer
control model(HXFeedbackBufferControl) from the
rest(HXWatermarkBufferControl) when HELIX_FEATURE_FEEDBACK_BUFFER_CONTROL is
defined. I have a non-Mobile build and it doesn't exhibit the same problem
you saw, so I suspect the problem might reside in that particular buffer
control module.
I suggest to set breakpoint at RTSPClientProtocol::SetDeliveryBandwidth and
back trace to the source where the requests are generated.
-->Henry
> -----Original Message-----
> From: client-dev-bounces@helixcommunity.org
> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> rajesh.rathinasamy@nokia.com
> Sent: Tuesday, January 02, 2007 8:39 AM Ping
> To: ehyche@real.com; client-dev@helixcommunity.org;
> protocol-dev@helixcommunity.org
> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start
> of stream
>
> Hi Eric,
> Thanks for your time.
>
> Attaching a new log file. This has the complete RTSP chat.
> I could see same set of RTSP chat for all clips. The session
> does not have three streams, it has only one audio and one
> video and still multiple SET_PARAM are sent. Apart from that
> the url sent in SET_PARAM is same for all messages.
>
> If the intention is send SET_PARAM for individual streams,
> why is that required. I thought we are responding the client
> bandwidth and why should it be sent for individual streams ?
>
> Thanks,
> Rajesh.
>
>
> >-----Original Message-----
> >From: ext Eric Hyche [mailto:ehyche@real.com]
> >Sent: Tuesday, January 02, 2007 9:33 AM
> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
> start of stream
> >
> >
> >There appear to be three streams: one video, one audio, and
> one other
> >(can't tell, since SDP is not in the log file). I would assume the
> >three SET_PARAMETER calls after the RTSP PLAY correspond to each
> >stream. Usually these can be distinguished by the URL in the RTSP
> >SET_PARAMETER (i.e. - rtsp://...../foo.3gp/audio, etc.) but for some
> >reason, all of the URLs look the same in this exchange.
> >
> >Henry might be able to shed some more light on this...
> >
> >Eric
> >
> >=============================================
> >Eric Hyche (ehyche@real.com)
> >Technical Lead
> >RealNetworks, Inc.
> >
> >> -----Original Message-----
> >> From: client-dev-bounces@helixcommunity.org
> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> >> rajesh.rathinasamy@nokia.com
> >> Sent: Thursday, December 21, 2006 12:02 PM
> >> To: client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> >> Subject: [Client-dev] Redundant SET_PARAMTER during start of stream
> >>
> >> Hi,
> >> we noticed that after PLAY message sent to server, there are
> >> redundant SET_PARAMETER (PIPELINED) sent to server. I
> don't see any
> >> change in the bandwidth value reported. The message looks
> identical
> >> except for sequence number. In the attached log, there is one
> >> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
> >> PIPELINED before PLAY response.
> >>
> >> Can someone explain why this is sent multiple times ? Is it
> >an error ?
> >>
> >>
> >>
> >> Thanks,
> >> Rajesh.
> >>
> >> <>
> >>
> >>
> >
> >
>
From gwright at real.com Tue Jan 2 11:50:34 2007
From: gwright at real.com (Greg Wright)
Date: Tue Jan 2 12:43:14 2007
Subject: [Protocol-dev] CR:Failing on ASSERT while streaming over proxy
with HTTPCloaking is enabled.
In-Reply-To: <459A6A64.5020400@real.com>
References: <458BEEA5.2030504@real.com> <6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com> <459263F6.5090702@real.com> <6.2.1.2.2.20061228141924.07a05c18@mailone.real.com> <4594B986.9000705@real.com>
<459A6A64.5020400@real.com>
Message-ID: <459AB78A.8060307@real.com>
Looks good.
--greg.
Gaurav Bajaj wrote:
> Synopsis:
>
> This change fixes the ASSERT issue which is occurring while streaming
> over proxy with HTTPCloaking is enabled.
>
>
> Overview:
>
> In the current scenario, StartAuthenticationIfNeeded(pBuf) is being
> called each time when GET channel has inbound data available for
> reading, which at times contains binary data too. This causes binary
> data to be parsed and end up with failing on an ASSERT in MSVCR71D.dll.
> Ideally StartAuthenticationIfNeeded(pBuf) should be called only
> when we have HTTP headers, containing ASCII data, coming from the get
> channel.
> This change fixes the ASSERT issue by calling
> StartAuthenticationIfNeeded(pBuf) function only if binary data is not
> coming from GET socket.
>
> Files Added:
> None
>
> Files Modified:
> protocol/common/util/HxCloakedSocket.cpp
>
>
> Image Size and Heap Use impact (Client -Only):
> None.
>
> Platforms and Profiles Affected:
> Not a platform specific change
>
> Distribution Libraries Affected:
> no
>
> Distribution library impact and planned action:
> None
>
> Platforms and Profiles Build Verified:
>
> BIF branch -> HEAD_restricted
> Target(s) ->splay
> Profile ->helix-client-all-defines
> SYSTEM_ID=win32-i386-vc7
>
>
> Branch:
> HEAD
>
> Files Attached:
> HttpCloakAssert.diff.txt
>
>
> Thanks and Regards,
> Gaurav Bajaj
>
>
> Gaurav Bajaj wrote:
>>
>> Hi,
>>
>> ASSERT is occurring in "msvcr71d.dll" when
>>
>> "iscntrl(ch)" function is called from ---> (if(strchr(tspecials, ch)
>> || iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
>> with a negative value like "-58" passed in it (e.g. ch =-58)
>>
>> This character is read into "ch" from m_input.read(); which is being
>> called
>> inside this function call ----> MIMEToken nextTok = scanner.nextToken();
>>
>> Call stack when assert failed is as follows:
>>
>> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ---->
>> "mimescan.cpp"
>> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
>> called from Line 352, ----> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
>> called from Line 455 ----> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parseRequest() called from Line 588
>> ------> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48,
>> unsigned long & nMsgLen=1500) called from Line 3206
>> ------>"hxcloakedsocket.cpp"
>> rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer
>> * pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>>
>>
>> Thanks & regards
>> Gaurav Bajaj
>>
>>
>>
>>
>> Milko Boic wrote:
>>>
>>> Which assert precisely is triggered?
>>>
>>> The change below does not seem right. It seems that int chRet would
>>> never be negative after the change and the code compares chRet to -1.
>>>
>>> Milko
>>>
>>>
>>>
>>> At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>>> Hi,
>>>>
>>>> Assert occurs when
>>>>
>>>> HTTPResponseMessage* pMessage =
>>>> (HTTPResponseMessage*)Parser.parse( pBufferContents, nMsgLen );
>>>> function is called from
>>>>
>>>> HXBOOL
>>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>>> function.
>>>>
>>>> to parse "pBufferContents" .
>>>>
>>>>
>>>> Merging the below changes solves this problem
>>>>
>>>> Index: mimescan.cpp
>>>> ===================================================================
>>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>>> retrieving revision 1.9
>>>> diff -u -r1.9 mimescan.cpp
>>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>>> @@ -108,7 +108,7 @@
>>>>
>>>> if(m_nCurOffset < m_nBufSize)
>>>> {
>>>> - int chRet = m_pBuffer[m_nCurOffset];
>>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>>> //XXXkshoop treat a EOF in the string as an end of file.
>>>> // never read beyond it. don't inc the offset.
>>>>
>>>>
>>>> It seems that use of VC7 to build Atlas code is causing this
>>>> problem.
>>>> Should I check-in these changes..?
>>>>
>>>> Thanks & Regards
>>>> Gaurav Bajaj
>>>>
>>>>
>>>> Milko Boic wrote:
>>>>> At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>>> Detailed Status Report
>>>>>>
>>>>>> Completed Items
>>>>>>
>>>>>> Merged the changes related to "[Bug 172459] PROXY FAILURE: Real
>>>>>> Player unable to play streams over
>>>>>> proxy when cloaking is enabled ", in HEAD , tested the behavior,
>>>>>> failing on assert.
>>>>>
>>>>> What assert is HEAD failing on? Are you looking into resolving this?
>>>>>
>>>>>
>>>>>> Checking out the code and making build of latest "voldemort"
>>>>>> branch to repro the bugs assigned.
>>>>>>
>>>>>> Thanks & Regards
>>>>>> Gaurav Bajaj
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
From milko at real.com Tue Jan 2 12:37:54 2007
From: milko at real.com (Milko Boic)
Date: Tue Jan 2 13:30:44 2007
Subject: [Protocol-dev] Re: CR:Failing on ASSERT while streaming over proxy
with HTTPCloaking is enabled.
In-Reply-To: <459A6A64.5020400@real.com>
References: <458BEEA5.2030504@real.com>
<6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com>
<459263F6.5090702@real.com>
<6.2.1.2.2.20061228141924.07a05c18@mailone.real.com>
<4594B986.9000705@real.com> <459A6A64.5020400@real.com>
Message-ID: <6.2.1.2.2.20070102112610.04df67c0@mailone.real.com>
This seems to work around the robustness issues in the underlaying utility
function. We should fix the problem in the utility function as well.
MIMEInputStream::read()
{
if(m_bUndoValid)
{
int rc = m_nUndo;
m_bUndoValid = FALSE;
m_nUndo = -1;
return rc;
}
if(m_nCurOffset < m_nBufSize)
{
int chRet = m_pBuffer[m_nCurOffset];
//XXXkshoop treat a EOF in the string as an end of file.
// never read beyond it. don't inc the offset.
if(chRet != -1)
{
+ chRet = (int) (unsigned char) (m_pBuffer[m_nCurOffset]);
++m_nCurOffset;
return chRet;
}
}
return -1;
}
At 06:21 AM 1/2/2007, Gaurav Bajaj wrote:
>Synopsis:
>
>This change fixes the ASSERT issue which is occurring while streaming over
>proxy with HTTPCloaking is enabled.
>
>
>Overview:
>
>In the current scenario, StartAuthenticationIfNeeded(pBuf) is being called
>each time when GET channel has inbound data available for reading, which
>at times contains binary data too. This causes binary data to be parsed
>and end up with failing on an ASSERT in MSVCR71D.dll.
>Ideally StartAuthenticationIfNeeded(pBuf) should be called only
>when we have HTTP headers, containing ASCII data, coming from the get channel.
>This change fixes the ASSERT issue by calling
>StartAuthenticationIfNeeded(pBuf) function only if binary data is not
>coming from GET socket.
>
>Files Added:
>None
>
>Files Modified:
>protocol/common/util/HxCloakedSocket.cpp
>
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>Not a platform specific change
>
>Distribution Libraries Affected:
>no
>
>Distribution library impact and planned action:
>None
>
>Platforms and Profiles Build Verified:
>
>BIF branch -> HEAD_restricted
>Target(s) ->splay
>Profile ->helix-client-all-defines
>SYSTEM_ID=win32-i386-vc7
>
>
>Branch:
>HEAD
>
>Files Attached:
>HttpCloakAssert.diff.txt
>
>
>Thanks and Regards,
>Gaurav Bajaj
>
>
>Gaurav Bajaj wrote:
>>
>>Hi,
>>
>>ASSERT is occurring in "msvcr71d.dll" when
>>
>>"iscntrl(ch)" function is called from ---> (if(strchr(tspecials, ch) ||
>>iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
>>with a negative value like "-58" passed in it (e.g. ch =-58)
>>
>>This character is read into "ch" from m_input.read(); which is being called
>>inside this function call ----> MIMEToken nextTok = scanner.nextToken();
>>
>>Call stack when assert failed is as follows:
>>
>> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ----> "mimescan.cpp"
>> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
>>called from Line 352, ----> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
>>called from Line 455 ----> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parseRequest() called from Line 588
>> ------> "httppars.cpp"
>> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48, unsigned
>> long & nMsgLen=1500) called from Line 3206 ------>"hxcloakedsocket.cpp"
>> rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer *
>> pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>>
>>
>>Thanks & regards
>>Gaurav Bajaj
>>
>>
>>
>>
>>Milko Boic wrote:
>>>
>>>Which assert precisely is triggered?
>>>
>>>The change below does not seem right. It seems that int chRet would
>>>never be negative after the change and the code compares chRet to -1.
>>>
>>>Milko
>>>
>>>
>>>
>>>At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>>> Hi,
>>>>
>>>> Assert occurs when
>>>>
>>>> HTTPResponseMessage* pMessage = (HTTPResponseMessage*)Parser.parse(
>>>> pBufferContents, nMsgLen );
>>>> function is called from
>>>>
>>>> HXBOOL
>>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>>>function.
>>>>
>>>> to parse "pBufferContents" .
>>>>
>>>>
>>>> Merging the below changes solves this problem
>>>>
>>>> Index: mimescan.cpp
>>>> ===================================================================
>>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>>> retrieving revision 1.9
>>>> diff -u -r1.9 mimescan.cpp
>>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>>> @@ -108,7 +108,7 @@
>>>>
>>>> if(m_nCurOffset < m_nBufSize)
>>>> {
>>>> - int chRet = m_pBuffer[m_nCurOffset];
>>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>>> //XXXkshoop treat a EOF in the string as an end of file.
>>>> // never read beyond it. don't inc the offset.
>>>>
>>>>
>>>> It seems that use of VC7 to build Atlas code is causing this problem.
>>>> Should I check-in these changes..?
>>>>
>>>> Thanks & Regards
>>>> Gaurav Bajaj
>>>>
>>>>
>>>>Milko Boic wrote:
>>>>>At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>>> Detailed Status Report
>>>>>>
>>>>>>Completed Items
>>>>>>
>>>>>>Merged the changes related to "[Bug 172459] PROXY FAILURE: Real
>>>>>>Player unable to play streams over
>>>>>>proxy when cloaking is enabled ", in HEAD , tested the behavior,
>>>>>>failing on assert.
>>>>>
>>>>>What assert is HEAD failing on? Are you looking into resolving this?
>>>>>
>>>>>
>>>>>>Checking out the code and making build of latest "voldemort" branch
>>>>>>to repro the bugs assigned.
>>>>>>
>>>>>>Thanks & Regards
>>>>>>Gaurav Bajaj
>>>>>
>>>
>>>
>
>
>Index: hxcloakedsocket.cpp
>===================================================================
>RCS file: /cvsroot/protocol/common/util/hxcloakedsocket.cpp,v
>retrieving revision 1.16
>diff -u -r1.16 hxcloakedsocket.cpp
>--- hxcloakedsocket.cpp 2 Jan 2007 12:36:53 -0000 1.16
>+++ hxcloakedsocket.cpp 2 Jan 2007 12:23:32 -0000
>@@ -1,5 +1,5 @@
> /* ***** BEGIN LICENSE BLOCK *****
>- * Source last modified: $Id: hxcloakedsocket.cpp,v 1.16 2007/01/02
>12:36:53 gbajaj Exp $
>+ * Source last modified: $Id: hxcloakedsocket.cpp,v 1.15 2006/12/26
>12:12:46 gbajaj Exp $
> *
> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
> *
>@@ -2109,7 +2109,7 @@
> HX_ASSERT(pBuf);
>
> // check for and possibly begin handling http authentication
>- if( StartAuthenticationIfNeeded(pBuf) )
>+ if( m_getState != gsReadData && StartAuthenticationIfNeeded(pBuf) )
> {
> // authentication process started
> hr = HXR_OK;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070102/89cd6cea/attachment-0001.html
From rajesh.rathinasamy at nokia.com Tue Jan 2 12:41:16 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Jan 2 13:34:21 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To: <200701021832.l02IWe7E025137@mgw-mx05.nokia.com>
Message-ID:
Hi Henry,
Thanks for your response.
The profile we use is helix-client-s60-32-mmf-mdf-arm.pf. It uses
HXFeedbackBufferControl. Attaching the function call traces for all the
SET_PARAM during starting. (I could not take a txt version of call stack
trace, so I have the screen capture attached.)
SET_PARAM is sent during StartDownload, CheckSourceRegistration, Play
(Resume), OnBufferring.
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Henry Ping [mailto:ping@real.com]
>Sent: Tuesday, January 02, 2007 12:34 PM
>To: Rathinasamy Rajesh (Nokia-TP/Dallas); ehyche@real.com;
>client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of stream
>
>Rajesh,
>
>The SetDeliveryBandwidth requests via SET_PARAMER is for the
>whole presentation, not per individual stream. It does seems
>to be redundant to send multiple SetDeliveryBandwidth in
>sequence with the same bandwidth value.
>
>I assume you're building with the mobile profile which uses
>different buffer control model(HXFeedbackBufferControl) from the
>rest(HXWatermarkBufferControl) when
>HELIX_FEATURE_FEEDBACK_BUFFER_CONTROL is defined. I have a
>non-Mobile build and it doesn't exhibit the same problem you
>saw, so I suspect the problem might reside in that particular
>buffer control module.
>
>I suggest to set breakpoint at
>RTSPClientProtocol::SetDeliveryBandwidth and back trace to the
>source where the requests are generated.
>
>-->Henry
>
>> -----Original Message-----
>> From: client-dev-bounces@helixcommunity.org
>> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>> rajesh.rathinasamy@nokia.com
>> Sent: Tuesday, January 02, 2007 8:39 AM Ping
>> To: ehyche@real.com; client-dev@helixcommunity.org;
>> protocol-dev@helixcommunity.org
>> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
>> stream
>>
>> Hi Eric,
>> Thanks for your time.
>>
>> Attaching a new log file. This has the complete RTSP chat.
>> I could see same set of RTSP chat for all clips. The session
>does not
>> have three streams, it has only one audio and one video and still
>> multiple SET_PARAM are sent. Apart from that the url sent in
>SET_PARAM
>> is same for all messages.
>>
>> If the intention is send SET_PARAM for individual streams,
>why is that
>> required. I thought we are responding the client bandwidth and why
>> should it be sent for individual streams ?
>>
>> Thanks,
>> Rajesh.
>>
>>
>> >-----Original Message-----
>> >From: ext Eric Hyche [mailto:ehyche@real.com]
>> >Sent: Tuesday, January 02, 2007 9:33 AM
>> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
>> start of stream
>> >
>> >
>> >There appear to be three streams: one video, one audio, and
>> one other
>> >(can't tell, since SDP is not in the log file). I would assume the
>> >three SET_PARAMETER calls after the RTSP PLAY correspond to each
>> >stream. Usually these can be distinguished by the URL in the RTSP
>> >SET_PARAMETER (i.e. - rtsp://...../foo.3gp/audio, etc.) but
>for some
>> >reason, all of the URLs look the same in this exchange.
>> >
>> >Henry might be able to shed some more light on this...
>> >
>> >Eric
>> >
>> >=============================================
>> >Eric Hyche (ehyche@real.com)
>> >Technical Lead
>> >RealNetworks, Inc.
>> >
>> >> -----Original Message-----
>> >> From: client-dev-bounces@helixcommunity.org
>> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>> >> rajesh.rathinasamy@nokia.com
>> >> Sent: Thursday, December 21, 2006 12:02 PM
>> >> To: client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> >> Subject: [Client-dev] Redundant SET_PARAMTER during start
>of stream
>> >>
>> >> Hi,
>> >> we noticed that after PLAY message sent to server, there are
>> >> redundant SET_PARAMETER (PIPELINED) sent to server. I
>> don't see any
>> >> change in the bandwidth value reported. The message looks
>> identical
>> >> except for sequence number. In the attached log, there is one
>> >> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
>> >> PIPELINED before PLAY response.
>> >>
>> >> Can someone explain why this is sent multiple times ? Is it
>> >an error ?
>> >>
>> >>
>> >>
>> >> Thanks,
>> >> Rajesh.
>> >>
>> >> <>
>> >>
>> >>
>> >
>> >
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SetDeliveryBW.zip
Type: application/x-zip-compressed
Size: 236752 bytes
Desc: SetDeliveryBW.zip
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070102/dd8b4724/SetDeliveryBW-0001.bin
From rajesh.rathinasamy at nokia.com Tue Jan 2 12:49:20 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Jan 2 13:42:13 2007
Subject: [Protocol-dev] RE: [Client-dev] Crash on
RTSPTransportBuffer::GetCurrentBuffering & GetPacketFromQueue
In-Reply-To:
Message-ID:
Hi Greg,
I looked at the code and I don't see any other usage of m_bQueueIsEmpty
except for this little piece of comment. I think Henry already had some
concerns over Queue empty deterimation.
// XXX HP we have too many empty queue determination
// i.e. m_bQueueIsEmpty
// uEndIndex > MAX_DEQUEUE_SIZE
// m_pPacketDeque->empty() == TRUE
// m_pPacketDeque->size() == 0
I will try your suggestion of removing m_bQueueIsEmpty. I will keep you
posted.
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Gregory Wright [mailto:gwright@real.com]
>Sent: Wednesday, December 27, 2006 12:22 PM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>Cc: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>Subject: Re: [Client-dev] Crash on
>RTSPTransportBuffer::GetCurrentBuffering & GetPacketFromQueue
>
>On Dec 26, 2006, at 11:44 AM, rajesh.rathinasamy@nokia.com wrote:
>
>>
>> Hello All,
>> I'm working on 210CayS. Pause-Play after n (n is random)
>number of
>> times on Live stream is crashing on RTSPTransportBuffer.
>This sequence
>> is used when we do a full screen option on the player. The
>sequence of
>> operations are Pause, SetRotation, UpdateDisplaywindow &
>Play. I think
>> w.r.t this error what matters is the Pause-Play during a
>seek(Resume)
>> of live streaming.
>>
>> I enabled RTSP & TRAN log and those logs are of not much
>use. So I had
>> added some debug statements and collected the log for the crash
>> scenario. I'm not sure what exact steps will create a crash.
>>
>> But from what I had analysed, there is an inconsistency in the
>> PacketQueue size handling. There is a member variable
>m_bQueueIsEmpty
>> to track the emptiness of the packet queue. During
>> a Seek(Resume) case, the boolean variable m_bQueueIsEmpty
>> indicates that the Q has one or more packet, but the Q is empty.
>> The Boolean variable is false and the size of packetqueue is zero.
>> This results in accessing the front and rear packets in the
>Q which in
>> turn results in a crash.
>>
>> In first place why do we need to have a boolean variable
>> m_bQueueIsEmpty while PacketQueue->size() will give the same
>expected
>> result ?
>
>That is what I was thinking. If it is true that
>m_bQueueIsEmpty tracks the state of the list exactly, then I
>don't see any reason for it. Just make sure it isn't used in
>some strange fashion. Sometime variable are named in a way
>that doesn't make their use obvious.
>
>Can you try getting rid of m_bQueueIsEmpty and see what happens?
>
>--greg.
>
>> If m_bQueueIsEmpty is for some additional purpose, don't we have to
>> check the Q size and reset this flag everytime a packet is
>popped from
>> the queue ?
>>
>> Can someone help me with this crash ?
>>
>> I'm attaching the log file and diff of the src which was used to
>> generate the logs.
>> Snippet from logs:
>> ==============
>>
>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::Add Before Flush bQEmpty:0 QSize:23
>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::Add WARNING bQEmpty:0 QSize:1 13:07:35.860
>> sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:1
>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:90f998, rp:90f998
>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue Pop pkt from Q
>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue FirstSeq:2367
>LastSeq:2348
>>
>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue --> HXR_OK QSize:0
>>
>> <>.... At this point, the Q size is zero, but we are still
>> accessing the front and rear packets based on m_bQueueIsEmpty flag.
>>
>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:0
>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:922948, rp:90f998
>>
>>
>> Thanks,
>> Rajesh.
>>
>> <> <>
>>
>>
>>
>> _______________________________________________
>> Client-dev mailing list
>> Client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/client-dev
>
>
From rajesh.rathinasamy at nokia.com Tue Jan 2 12:50:58 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Jan 2 13:43:46 2007
Subject: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
In-Reply-To:
Message-ID:
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Tuesday, December 19, 2006 6:10 PM
To: rmathew@real.com; protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
Rishi,
<>>>>>>>
<>To pass the compatibility test for RTSP pipelining,
Should the Describe-Option pipeline feature be enabled ?
<> No.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Since Describe-Option pipeline is not required for (optional)
TCK compliane 31.1 RTSP pipelining ( 31 Reduced Startup Delay ), should
that test case be broken into two one for Describe-Option pipeline and
the other for the SETUP/SUBSCRIBE/PLAY ? (or the test criteria has to be
changed ?)
Please let me know if an error has to be raised for updating TCK
compliance doc (provided what I understand is correct)
Thanks,
Rajesh.
________________________________
From: ext Rishi Mathew [mailto:rmathew@real.com]
Sent: Monday, December 18, 2006 3:33 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA
TCK
Hi Rajesh,
Comments inline..
At 01:10 PM 12/18/2006, rajesh.rathinasamy@nokia.com
wrote:
Hi Rishi,
Thanks for your response. I have one more
question.
The RTSP pipelining is enabled by default. But
the code seems to disable the pipeline if the server is not Helix / Real
Server. So what does it mean to TCK compliance ? Just the capability to
RTSP pipeline with Helix / Real server fine for TCK Compliance ?
Yes. The ability to turn it on when possible. Be aware
this is an "optional" feature in the TCK.
Thanks,
Rishi.
Thanks,
Rajesh.
In rtsp\rtspclnt.cpp
==============
if( pViaHeader )
{
MIMEHeaderValue* pViaValue =
pViaHeader->getFirstHeaderValue();
while( pViaValue )
{
pViaValue->asString(it);
if( -1 == it.Find("RealProxy") )
{
//This is a non-Real proxy. Only
real proxies are known to work
//with RTSP piplining. If you
find another, add it here.
m_bPipelineRTSP = FALSE;
}
//Test for NetCache appliance.
if( -1 != it.Find("NetCache NetApp")
)
{
//Found at least one NetCache
Proxy.
m_bTrimTrailingSlashes = TRUE;
break;
}
pViaValue =
pViaHeader->getNextHeaderValue();
}
}
//We also turn off RTSP pipelining if this
is not a realserver(helix).
if( !IsRealServer() )
{
m_bPipelineRTSP = FALSE;
}
________________________________
From: ext Rishi Mathew [
mailto:rmathew@real.com ]
Sent: Monday, December 18, 2006 2:13 PM
To: Rathinasamy Rajesh
(Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org
Subject: Re: [Protocol-dev] RTSP
Pipelining & Helix DNA TCK
Hi Rajesh,
Comments inline..
At 02:45 PM 12/14/2006,
rajesh.rathinasamy@nokia.com wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C71FE1.A16090E5"
Hi,
I have a question regarding the RTSP
pipelining and helix DNA TCK v2.0.
According to Helix TCK , what is RTSP
pipeling ?
RTSP Pipelining is defined as "multiple
RTSP methods being sent by the client without needing to wait for
responses from the server".
By default with helix Server SETUP, PLAY
& SET_PARAMETER messages are pipelined. But I noticed a feature flag
HELIX_FEATURE_PIPELINED_DESCRIBE which pipelines Describe and Options
message.
To pass the compatibility test for RTSP
pipelining, Should the Describe-Option pipeline feature be enabled ?
No.
By the way is Describe-Option pipeline a
standard feature (Does other servers support it )?
No, this is a Helix Client-to-Helix
Server feature only. Helix Clients will not try this with other servers
or if appropriate preferences are set to disable it.
Thanks,
Rishi.
Thanks,
Rajesh.
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070102/395a557d/attachment.html
From rmathew at real.com Tue Jan 2 13:01:58 2007
From: rmathew at real.com (Rishi Mathew)
Date: Tue Jan 2 13:52:34 2007
Subject: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
In-Reply-To:
References:
Message-ID: <6.2.5.6.2.20070102130054.07f945b8@real.com>
Hi Rajesh,
We will update the TCK compliance doc with this information.
Thanks,
Rishi.
At 12:50 PM 1/2/2007, rajesh.rathinasamy@nokia.com wrote:
>
>
>
>----------
>From: protocol-dev-bounces@helixcommunity.org
>[mailto:protocol-dev-bounces@helixcommunity.org]
>Sent: Tuesday, December 19, 2006 6:10 PM
>To: rmathew@real.com; protocol-dev@helixcommunity.org
>Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>
>Rishi,
>
><>>>>>>>
><>To pass the compatibility test for RTSP pipelining, Should
>the Describe-Option pipeline feature be enabled ?
><> No.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> Since Describe-Option pipeline is not required for (optional)
> TCK compliane 31.1 RTSP pipelining ( 31 Reduced Startup Delay ),
> should that test case be broken into two one for Describe-Option
> pipeline and the other for the SETUP/SUBSCRIBE/PLAY ? (or the test
> criteria has to be changed ?)
>
>Please let me know if an error has to be raised for updating TCK
>compliance doc (provided what I understand is correct)
>
>
>Thanks,
>Rajesh.
>
>
>
>----------
>From: ext Rishi Mathew [mailto:rmathew@real.com]
>Sent: Monday, December 18, 2006 3:33 PM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org
>Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>
>Hi Rajesh,
>
>Comments inline..
>
>At 01:10 PM 12/18/2006, rajesh.rathinasamy@nokia.com wrote:
>>Hi Rishi,
>> Thanks for your response. I have one more question.
>>
>>The RTSP pipelining is enabled by default. But the code seems to
>>disable the pipeline if the server is not Helix / Real Server. So
>>what does it mean to TCK compliance ? Just the capability to RTSP
>>pipeline with Helix / Real server fine for TCK Compliance ?
>
>Yes. The ability to turn it on when possible. Be aware this is an
>"optional" feature in the TCK.
>
>Thanks,
>Rishi.
>
>>
>>Thanks,
>>Rajesh.
>>
>>In rtsp\rtspclnt.cpp
>>==============
>> if( pViaHeader )
>> {
>> MIMEHeaderValue* pViaValue = pViaHeader->getFirstHeaderValue();
>> while( pViaValue )
>> {
>> pViaValue->asString(it);
>> if( -1 == it.Find("RealProxy") )
>> {
>> //This is a non-Real proxy. Only real proxies are
>> known to work
>> //with RTSP piplining. If you find another, add it here.
>> m_bPipelineRTSP = FALSE;
>> }
>> //Test for NetCache appliance.
>> if( -1 != it.Find("NetCache NetApp") )
>> {
>> //Found at least one NetCache Proxy.
>> m_bTrimTrailingSlashes = TRUE;
>> break;
>> }
>> pViaValue = pViaHeader->getNextHeaderValue();
>> }
>> }
>> //We also turn off RTSP pipelining if this is not a realserver(helix).
>> if( !IsRealServer() )
>> {
>> m_bPipelineRTSP = FALSE;
>> }
>>
>>
>>
>>
>>----------
>>From: ext Rishi Mathew [ mailto:rmathew@real.com]
>>Sent: Monday, December 18, 2006 2:13 PM
>>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>>protocol-dev@helixcommunity.org
>>Subject: Re: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>>Hi Rajesh,
>>Comments inline..
>>At 02:45 PM 12/14/2006, rajesh.rathinasamy@nokia.com wrote:
>>>Content-class: urn:content-classes:message
>>>Content-Type: multipart/alternative;
>>> boundary="----_=_NextPart_001_01C71FE1.A16090E5"
>>>Hi,
>>> I have a question regarding the RTSP pipelining and helix DNA TCK v2.0.
>>>
>>> According to Helix TCK , what is RTSP pipeling ?
>>RTSP Pipelining is defined as "multiple RTSP methods being sent by
>>the client without needing to wait for responses from the server".
>>
>>>By default with helix Server SETUP, PLAY & SET_PARAMETER messages
>>>are pipelined. But I noticed a feature flag
>>>HELIX_FEATURE_PIPELINED_DESCRIBE which pipelines Describe and
>>>Options message.
>>>To pass the compatibility test for RTSP pipelining, Should the
>>>Describe-Option pipeline feature be enabled ?
>>No.
>>
>>
>>>By the way is Describe-Option pipeline a standard feature (Does
>>>other servers support it )?
>>No, this is a Helix Client-to-Helix Server feature only. Helix
>>Clients will not try this with other servers or if appropriate
>>preferences are set to disable it.
>>Thanks,
>>Rishi.
>>
>>
>>>Thanks,
>>>Rajesh.
>>>_______________________________________________
>>>Protocol-dev mailing list
>>>Protocol-dev@helixcommunity.org
>>>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
>>
>>
>>Rishi Mathew
>>Sr. Software Development Engineer
>>Helix Community
>>Real Networks, Inc.
>>rmathew@real.com
>>http://www.helixcommunity.org
>>http://www.realnetworks.com/products/support/devsupport.html
>
>
>Rishi Mathew
>Sr. Software Development Engineer
>Helix Community
>Real Networks, Inc.
>rmathew@real.com
>http://www.helixcommunity.org
>http://www.realnetworks.com/products/support/devsupport.html
Rishi Mathew
Sr. Software Development Engineer
Helix Community
RealNetworks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070102/7cc11fed/attachment-0001.html
From gbajaj at real.com Tue Jan 2 23:05:08 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Tue Jan 2 23:57:30 2007
Subject: [Protocol-dev] Re: CR:Failing on ASSERT while streaming over proxy
with HTTPCloaking is enabled.
In-Reply-To: <6.2.1.2.2.20070102112610.04df67c0@mailone.real.com>
References: <458BEEA5.2030504@real.com>
<6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com>
<459263F6.5090702@real.com>
<6.2.1.2.2.20061228141924.07a05c18@mailone.real.com>
<4594B986.9000705@real.com> <459A6A64.5020400@real.com>
<6.2.1.2.2.20070102112610.04df67c0@mailone.real.com>
Message-ID: <459B55A4.5010708@real.com>
This has been checked into HEAD.
Do we need to check this into Cayenne150 and Cayenne 210 too..?
Thanks & Regards
Gaurav Bajaj
Milko Boic wrote:
>
> This seems to work around the robustness issues in the underlaying
> utility function. We should fix the problem in the utility function
> as well.
>
> MIMEInputStream::read()
> {
> if (m_bUndoValid)
> {
> int rc = m_nUndo;
> m_bUndoValid = FALSE;
> m_nUndo = -1;
> return rc;
> }
>
> if (m_nCurOffset < m_nBufSize)
> {
> int chRet = m_pBuffer[m_nCurOffset];
>
> //XXXkshoop treat a EOF in the string as an end of file.
> // never read beyond it. don't inc the offset.
> if (chRet != -1)
> {
> + chRet = (int) (unsigned char) (m_pBuffer[m_nCurOffset]);
> ++m_nCurOffset;
> return chRet;
> }
> }
>
> return -1;
> }
>
> At 06:21 AM 1/2/2007, Gaurav Bajaj wrote:
>> Synopsis:
>>
>> This change fixes the ASSERT issue which is occurring while streaming
>> over proxy with HTTPCloaking is enabled.
>>
>>
>> Overview:
>>
>> In the current scenario, StartAuthenticationIfNeeded(pBuf) is being
>> called each time when GET channel has inbound data available for
>> reading, which at times contains binary data too. This causes binary
>> data to be parsed and end up with failing on an ASSERT in MSVCR71D.dll.
>> Ideally StartAuthenticationIfNeeded(pBuf) should be called only
>> when we have HTTP headers, containing ASCII data, coming from the get
>> channel.
>> This change fixes the ASSERT issue by calling
>> StartAuthenticationIfNeeded(pBuf) function only if binary data is not
>> coming from GET socket.
>>
>> Files Added:
>> None
>>
>> Files Modified:
>> protocol/common/util/HxCloakedSocket.cpp
>>
>>
>> Image Size and Heap Use impact (Client -Only):
>> None.
>>
>> Platforms and Profiles Affected:
>> Not a platform specific change
>>
>> Distribution Libraries Affected:
>> no
>>
>> Distribution library impact and planned action:
>> None
>>
>> Platforms and Profiles Build Verified:
>>
>> BIF branch -> HEAD_restricted
>> Target(s) ->splay
>> Profile ->helix-client-all-defines
>> SYSTEM_ID=win32-i386-vc7
>>
>>
>> Branch:
>> HEAD
>>
>> Files Attached:
>> HttpCloakAssert.diff.txt
>>
>>
>> Thanks and Regards,
>> Gaurav Bajaj
>>
>>
>> Gaurav Bajaj wrote:
>>>
>>> Hi,
>>>
>>> ASSERT is occurring in "msvcr71d.dll" when
>>>
>>> "iscntrl(ch)" function is called from ---> (if(strchr(tspecials, ch)
>>> || iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
>>> with a negative value like "-58" passed in it (e.g. ch =-58)
>>>
>>> This character is read into "ch" from m_input.read(); which is
>>> being called
>>> inside this function call ----> MIMEToken nextTok = scanner.nextToken();
>>>
>>> Call stack when assert failed is as follows:
>>>
>>> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ---->
>>> "mimescan.cpp"
>>> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
>>> called from Line 352, ----> "httppars.cpp"
>>> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
>>> called from Line 455 ----> "httppars.cpp"
>>> rtspclnt.dll!HTTPParser::parseRequest() called from Line
>>> 588 ------> "httppars.cpp"
>>> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48,
>>> unsigned long & nMsgLen=1500) called from Line 3206
>>> ------>"hxcloakedsocket.cpp"
>>>
>>> rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer
>>> * pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>>>
>>>
>>> Thanks & regards
>>> Gaurav Bajaj
>>>
>>>
>>>
>>>
>>> Milko Boic wrote:
>>>>
>>>> Which assert precisely is triggered?
>>>>
>>>> The change below does not seem right. It seems that int chRet
>>>> would never be negative after the change and the code compares
>>>> chRet to -1.
>>>>
>>>> Milko
>>>>
>>>>
>>>>
>>>> At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>>>> Hi,
>>>>>
>>>>> Assert occurs when
>>>>>
>>>>> HTTPResponseMessage* pMessage =
>>>>> (HTTPResponseMessage*)Parser.parse( pBufferContents, nMsgLen );
>>>>> function is called from
>>>>>
>>>>> HXBOOL
>>>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>>>> function.
>>>>>
>>>>> to parse "pBufferContents" .
>>>>>
>>>>>
>>>>> Merging the below changes solves this problem
>>>>>
>>>>> Index: mimescan.cpp
>>>>> ===================================================================
>>>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>>>> retrieving revision 1.9
>>>>> diff -u -r1.9 mimescan.cpp
>>>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>>>> @@ -108,7 +108,7 @@
>>>>>
>>>>> if(m_nCurOffset < m_nBufSize)
>>>>> {
>>>>> - int chRet = m_pBuffer[m_nCurOffset];
>>>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>>>> //XXXkshoop treat a EOF in the string as an end of file.
>>>>> // never read beyond it. don't inc the offset.
>>>>>
>>>>>
>>>>> It seems that use of VC7 to build Atlas code is causing this
>>>>> problem.
>>>>> Should I check-in these changes..?
>>>>>
>>>>> Thanks & Regards
>>>>> Gaurav Bajaj
>>>>>
>>>>>
>>>>> Milko Boic wrote:
>>>>>> At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>>>> Detailed Status Report
>>>>>>>
>>>>>>> Completed Items
>>>>>>>
>>>>>>> Merged the changes related to "[Bug 172459] PROXY FAILURE: Real
>>>>>>> Player unable to play streams over
>>>>>>> proxy when cloaking is enabled ", in HEAD , tested the behavior,
>>>>>>> failing on assert.
>>>>>>
>>>>>> What assert is HEAD failing on? Are you looking into resolving this?
>>>>>>
>>>>>>
>>>>>>> Checking out the code and making build of latest "voldemort"
>>>>>>> branch to repro the bugs assigned.
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> Gaurav Bajaj
>>>>>>
>>>>
>>>>
>>
>>
>> Index: hxcloakedsocket.cpp
>> ===================================================================
>> RCS file: /cvsroot/protocol/common/util/hxcloakedsocket.cpp,v
>> retrieving revision 1.16
>> diff -u -r1.16 hxcloakedsocket.cpp
>> --- hxcloakedsocket.cpp 2 Jan 2007 12:36:53 -0000 1.16
>> +++ hxcloakedsocket.cpp 2 Jan 2007 12:23:32 -0000
>> @@ -1,5 +1,5 @@
>> /* ***** BEGIN LICENSE BLOCK *****
>> - * Source last modified: $Id: hxcloakedsocket.cpp,v 1.16 2007/01/02
>> 12:36:53 gbajaj Exp $
>> + * Source last modified: $Id: hxcloakedsocket.cpp,v 1.15 2006/12/26
>> 12:12:46 gbajaj Exp $
>> *
>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights
>> Reserved.
>> *
>> @@ -2109,7 +2109,7 @@
>> HX_ASSERT(pBuf);
>>
>> // check for and possibly begin handling http authentication
>> - if( StartAuthenticationIfNeeded(pBuf) )
>> + if( m_getState != gsReadData && StartAuthenticationIfNeeded(pBuf) )
>> {
>> // authentication process started
>> hr = HXR_OK;
>
From milko at real.com Tue Jan 2 23:16:36 2007
From: milko at real.com (Milko Boic)
Date: Wed Jan 3 00:09:15 2007
Subject: [Protocol-dev] Re: CR:Failing on ASSERT while streaming over proxy
with HTTPCloaking is enabled.
In-Reply-To: <459B55A4.5010708@real.com>
References: <458BEEA5.2030504@real.com>
<6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com>
<459263F6.5090702@real.com>
<6.2.1.2.2.20061228141924.07a05c18@mailone.real.com>
<4594B986.9000705@real.com> <459A6A64.5020400@real.com>
<6.2.1.2.2.20070102112610.04df67c0@mailone.real.com>
<459B55A4.5010708@real.com>
Message-ID: <6.2.1.2.2.20070102231622.04cc0770@mailone.real.com>
At 11:05 PM 1/2/2007, Gaurav Bajaj wrote:
>This has been checked into HEAD.
>Do we need to check this into Cayenne150 and Cayenne 210 too..?
Yes.
Thanks,
Milko
>Thanks & Regards
>Gaurav Bajaj
>
>Milko Boic wrote:
>>
>>This seems to work around the robustness issues in the underlaying
>>utility function. We should fix the problem in the utility function as well.
>>
>>MIMEInputStream::read()
>>{
>> if (m_bUndoValid)
>> {
>> int rc = m_nUndo;
>> m_bUndoValid = FALSE;
>> m_nUndo = -1;
>> return rc;
>> }
>>
>> if (m_nCurOffset < m_nBufSize)
>> {
>> int chRet = m_pBuffer[m_nCurOffset];
>>
>> //XXXkshoop treat a EOF in the string as an end of file.
>> // never read beyond it. don't inc the offset.
>> if (chRet != -1)
>> {
>>+ chRet = (int) (unsigned char) (m_pBuffer[m_nCurOffset]);
>> ++m_nCurOffset;
>> return chRet;
>> }
>> }
>>
>> return -1;
>>}
>>
>>At 06:21 AM 1/2/2007, Gaurav Bajaj wrote:
>>>Synopsis:
>>>
>>>This change fixes the ASSERT issue which is occurring while streaming
>>>over proxy with HTTPCloaking is enabled.
>>>
>>>
>>>Overview:
>>>
>>>In the current scenario, StartAuthenticationIfNeeded(pBuf) is being
>>>called each time when GET channel has inbound data available for
>>>reading, which at times contains binary data too. This causes binary
>>>data to be parsed and end up with failing on an ASSERT in MSVCR71D.dll.
>>>Ideally StartAuthenticationIfNeeded(pBuf) should be called only
>>>when we have HTTP headers, containing ASCII data, coming from the get
>>>channel.
>>>This change fixes the ASSERT issue by calling
>>>StartAuthenticationIfNeeded(pBuf) function only if binary data is not
>>>coming from GET socket.
>>>
>>>Files Added:
>>>None
>>>
>>>Files Modified:
>>>protocol/common/util/HxCloakedSocket.cpp
>>>
>>>
>>>Image Size and Heap Use impact (Client -Only):
>>>None.
>>>
>>>Platforms and Profiles Affected:
>>>Not a platform specific change
>>>
>>>Distribution Libraries Affected:
>>>no
>>>
>>>Distribution library impact and planned action:
>>>None
>>>
>>>Platforms and Profiles Build Verified:
>>>
>>>BIF branch -> HEAD_restricted
>>>Target(s) ->splay
>>>Profile ->helix-client-all-defines
>>>SYSTEM_ID=win32-i386-vc7
>>>
>>>
>>>Branch:
>>>HEAD
>>>
>>>Files Attached:
>>>HttpCloakAssert.diff.txt
>>>
>>>
>>>Thanks and Regards,
>>>Gaurav Bajaj
>>>
>>>
>>>Gaurav Bajaj wrote:
>>>>
>>>>Hi,
>>>>
>>>>ASSERT is occurring in "msvcr71d.dll" when
>>>>
>>>>"iscntrl(ch)" function is called from ---> (if(strchr(tspecials, ch) ||
>>>>iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
>>>>with a negative value like "-58" passed in it (e.g. ch =-58)
>>>>
>>>>This character is read into "ch" from m_input.read(); which is being
>>>>called
>>>>inside this function call ----> MIMEToken nextTok = scanner.nextToken();
>>>>
>>>>Call stack when assert failed is as follows:
>>>>
>>>> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ---->
>>>> "mimescan.cpp"
>>>> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
>>>>called from Line 352, ----> "httppars.cpp"
>>>> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
>>>>called from Line 455 ----> "httppars.cpp"
>>>> rtspclnt.dll!HTTPParser::parseRequest() called from Line 588
>>>> ------> "httppars.cpp"
>>>> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48,
>>>> unsigned long & nMsgLen=1500) called from Line 3206
>>>> ------>"hxcloakedsocket.cpp"
>>>>
>>>>rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer *
>>>>pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>>>>
>>>>
>>>>Thanks & regards
>>>>Gaurav Bajaj
>>>>
>>>>
>>>>
>>>>
>>>>Milko Boic wrote:
>>>>>
>>>>>Which assert precisely is triggered?
>>>>>
>>>>>The change below does not seem right. It seems that int chRet would
>>>>>never be negative after the change and the code compares chRet to -1.
>>>>>
>>>>>Milko
>>>>>
>>>>>
>>>>>
>>>>>At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Assert occurs when
>>>>>>
>>>>>> HTTPResponseMessage* pMessage =
>>>>>> (HTTPResponseMessage*)Parser.parse( pBufferContents, nMsgLen );
>>>>>> function is called from
>>>>>>
>>>>>> HXBOOL
>>>>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>>>>>function.
>>>>>>
>>>>>> to parse "pBufferContents" .
>>>>>>
>>>>>>
>>>>>> Merging the below changes solves this problem
>>>>>>
>>>>>> Index: mimescan.cpp
>>>>>> ===================================================================
>>>>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>>>>> retrieving revision 1.9
>>>>>> diff -u -r1.9 mimescan.cpp
>>>>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>>>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>>>>> @@ -108,7 +108,7 @@
>>>>>>
>>>>>> if(m_nCurOffset < m_nBufSize)
>>>>>> {
>>>>>> - int chRet = m_pBuffer[m_nCurOffset];
>>>>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>>>>> //XXXkshoop treat a EOF in the string as an end of file.
>>>>>> // never read beyond it. don't inc the offset.
>>>>>>
>>>>>>
>>>>>> It seems that use of VC7 to build Atlas code is causing this problem.
>>>>>> Should I check-in these changes..?
>>>>>>
>>>>>> Thanks & Regards
>>>>>> Gaurav Bajaj
>>>>>>
>>>>>>
>>>>>>Milko Boic wrote:
>>>>>>>At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>>>>> Detailed Status Report
>>>>>>>>
>>>>>>>>Completed Items
>>>>>>>>
>>>>>>>>Merged the changes related to "[Bug 172459] PROXY FAILURE: Real
>>>>>>>>Player unable to play streams over
>>>>>>>>proxy when cloaking is enabled ", in HEAD , tested the behavior,
>>>>>>>>failing on assert.
>>>>>>>
>>>>>>>What assert is HEAD failing on? Are you looking into resolving this?
>>>>>>>
>>>>>>>
>>>>>>>>Checking out the code and making build of latest "voldemort" branch
>>>>>>>>to repro the bugs assigned.
>>>>>>>>
>>>>>>>>Thanks & Regards
>>>>>>>>Gaurav Bajaj
>>>>>
>>>
>>>
>>>Index: hxcloakedsocket.cpp
>>>===================================================================
>>>RCS file: /cvsroot/protocol/common/util/hxcloakedsocket.cpp,v
>>>retrieving revision 1.16
>>>diff -u -r1.16 hxcloakedsocket.cpp
>>>--- hxcloakedsocket.cpp 2 Jan 2007 12:36:53 -0000 1.16
>>>+++ hxcloakedsocket.cpp 2 Jan 2007 12:23:32 -0000
>>>@@ -1,5 +1,5 @@
>>> /* ***** BEGIN LICENSE BLOCK *****
>>>- * Source last modified: $Id: hxcloakedsocket.cpp,v 1.16 2007/01/02
>>>12:36:53 gbajaj Exp $
>>>+ * Source last modified: $Id: hxcloakedsocket.cpp,v 1.15 2006/12/26
>>>12:12:46 gbajaj Exp $
>>> *
>>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights
>>> Reserved.
>>> *
>>>@@ -2109,7 +2109,7 @@
>>> HX_ASSERT(pBuf);
>>>
>>> // check for and possibly begin handling http authentication
>>>- if( StartAuthenticationIfNeeded(pBuf) )
>>>+ if( m_getState != gsReadData && StartAuthenticationIfNeeded(pBuf) )
>>> {
>>> // authentication process started
>>> hr = HXR_OK;
From gbajaj at real.com Wed Jan 3 01:10:32 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Wed Jan 3 02:02:51 2007
Subject: [Protocol-dev] Re: CN:Failing on ASSERT while streaming over proxy
with HTTPCloaking is enabled.
In-Reply-To: <6.2.1.2.2.20070102231622.04cc0770@mailone.real.com>
References: <458BEEA5.2030504@real.com>
<6.2.1.2.2.20061222100339.065ea3d8@mailone.real.com>
<459263F6.5090702@real.com>
<6.2.1.2.2.20061228141924.07a05c18@mailone.real.com>
<4594B986.9000705@real.com> <459A6A64.5020400@real.com>
<6.2.1.2.2.20070102112610.04df67c0@mailone.real.com>
<459B55A4.5010708@real.com>
<6.2.1.2.2.20070102231622.04cc0770@mailone.real.com>
Message-ID: <459B7308.5010405@real.com>
This has been checked into Cayenne150 and Cayenne210.
- Gaurav
Milko Boic wrote:
> At 11:05 PM 1/2/2007, Gaurav Bajaj wrote:
>
>> This has been checked into HEAD.
>> Do we need to check this into Cayenne150 and Cayenne 210 too..?
>
>
> Yes.
>
> Thanks,
> Milko
>
>
>> Thanks & Regards
>> Gaurav Bajaj
>>
>> Milko Boic wrote:
>>>
>>> This seems to work around the robustness issues in the underlaying
>>> utility function. We should fix the problem in the utility function
>>> as well.
>>>
>>> MIMEInputStream::read()
>>> {
>>> if (m_bUndoValid)
>>> {
>>> int rc = m_nUndo;
>>> m_bUndoValid = FALSE;
>>> m_nUndo = -1;
>>> return rc;
>>> }
>>>
>>> if (m_nCurOffset < m_nBufSize)
>>> {
>>> int chRet = m_pBuffer[m_nCurOffset];
>>>
>>> //XXXkshoop treat a EOF in the string as an end of file.
>>> // never read beyond it. don't inc the offset.
>>> if (chRet != -1)
>>> {
>>> + chRet = (int) (unsigned char) (m_pBuffer[m_nCurOffset]);
>>> ++m_nCurOffset;
>>> return chRet;
>>> }
>>> }
>>>
>>> return -1;
>>> }
>>>
>>> At 06:21 AM 1/2/2007, Gaurav Bajaj wrote:
>>>> Synopsis:
>>>>
>>>> This change fixes the ASSERT issue which is occurring while
>>>> streaming over proxy with HTTPCloaking is enabled.
>>>>
>>>>
>>>> Overview:
>>>>
>>>> In the current scenario, StartAuthenticationIfNeeded(pBuf) is being
>>>> called each time when GET channel has inbound data available for
>>>> reading, which at times contains binary data too. This causes
>>>> binary data to be parsed and end up with failing on an ASSERT in
>>>> MSVCR71D.dll.
>>>> Ideally StartAuthenticationIfNeeded(pBuf) should be called only
>>>> when we have HTTP headers, containing ASCII data, coming from the
>>>> get channel.
>>>> This change fixes the ASSERT issue by calling
>>>> StartAuthenticationIfNeeded(pBuf) function only if binary data is
>>>> not coming from GET socket.
>>>>
>>>> Files Added:
>>>> None
>>>>
>>>> Files Modified:
>>>> protocol/common/util/HxCloakedSocket.cpp
>>>>
>>>>
>>>> Image Size and Heap Use impact (Client -Only):
>>>> None.
>>>>
>>>> Platforms and Profiles Affected:
>>>> Not a platform specific change
>>>>
>>>> Distribution Libraries Affected:
>>>> no
>>>>
>>>> Distribution library impact and planned action:
>>>> None
>>>>
>>>> Platforms and Profiles Build Verified:
>>>>
>>>> BIF branch -> HEAD_restricted
>>>> Target(s) ->splay
>>>> Profile ->helix-client-all-defines
>>>> SYSTEM_ID=win32-i386-vc7
>>>>
>>>>
>>>> Branch:
>>>> HEAD
>>>>
>>>> Files Attached:
>>>> HttpCloakAssert.diff.txt
>>>>
>>>>
>>>> Thanks and Regards,
>>>> Gaurav Bajaj
>>>>
>>>>
>>>> Gaurav Bajaj wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> ASSERT is occurring in "msvcr71d.dll" when
>>>>>
>>>>> "iscntrl(ch)" function is called from ---> (if(strchr(tspecials,
>>>>> ch) || iscntrl(ch)) ) line no.339 in file "mimescan.cpp"
>>>>> with a negative value like "-58" passed in it (e.g. ch =-58)
>>>>>
>>>>> This character is read into "ch" from m_input.read(); which is
>>>>> being called
>>>>> inside this function call ----> MIMEToken nextTok =
>>>>> scanner.nextToken();
>>>>>
>>>>> Call stack when assert failed is as follows:
>>>>>
>>>>> msvcr71d.dll!iscntrl(int c=-64) called from Line 339 ---->
>>>>> "mimescan.cpp"
>>>>> rtspclnt.dll!MIMEScanner::nextToken(char * upTo=0x00000000)
>>>>> called from Line 352, ----> "httppars.cpp"
>>>>> rtspclnt.dll!HTTPParser::parseRequestLine(CHXString & str={...})
>>>>> called from Line 455 ----> "httppars.cpp"
>>>>> rtspclnt.dll!HTTPParser::parseRequest() called from Line
>>>>> 588 ------> "httppars.cpp"
>>>>> rtspclnt.dll!HTTPParser::parse(const char * pMsg=0x01b69e48,
>>>>> unsigned long & nMsgLen=1500) called from Line 3206
>>>>> ------>"hxcloakedsocket.cpp"
>>>>>
>>>>> rtspclnt.dll!HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer
>>>>> * pBuf=0x00ba5768) called from Line 2112 -----> hxcloakedsocket.cpp
>>>>>
>>>>>
>>>>> Thanks & regards
>>>>> Gaurav Bajaj
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Milko Boic wrote:
>>>>>>
>>>>>> Which assert precisely is triggered?
>>>>>>
>>>>>> The change below does not seem right. It seems that int chRet
>>>>>> would never be negative after the change and the code compares
>>>>>> chRet to -1.
>>>>>>
>>>>>> Milko
>>>>>>
>>>>>>
>>>>>>
>>>>>> At 04:15 AM 12/27/2006, Gaurav Bajaj wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Assert occurs when
>>>>>>>
>>>>>>> HTTPResponseMessage* pMessage =
>>>>>>> (HTTPResponseMessage*)Parser.parse( pBufferContents, nMsgLen );
>>>>>>> function is called from
>>>>>>>
>>>>>>> HXBOOL
>>>>>>> HXCloakedSocket::StartAuthenticationIfNeeded(IHXBuffer* pBuf)
>>>>>>> function.
>>>>>>>
>>>>>>> to parse "pBufferContents" .
>>>>>>>
>>>>>>>
>>>>>>> Merging the below changes solves this problem
>>>>>>>
>>>>>>> Index: mimescan.cpp
>>>>>>>
>>>>>>> ===================================================================
>>>>>>> RCS file: /cvsroot/protocol/common/util/mimescan.cpp,v
>>>>>>> retrieving revision 1.9
>>>>>>> diff -u -r1.9 mimescan.cpp
>>>>>>> --- mimescan.cpp 2 Aug 2005 18:00:37 -0000 1.9
>>>>>>> +++ mimescan.cpp 27 Dec 2006 11:39:18 -0000
>>>>>>> @@ -108,7 +108,7 @@
>>>>>>>
>>>>>>> if(m_nCurOffset < m_nBufSize)
>>>>>>> {
>>>>>>> - int chRet = m_pBuffer[m_nCurOffset];
>>>>>>> + int chRet = (int)(unsigned char)m_pBuffer[m_nCurOffset];
>>>>>>> //XXXkshoop treat a EOF in the string as an end of file.
>>>>>>> // never read beyond it. don't inc the offset.
>>>>>>>
>>>>>>>
>>>>>>> It seems that use of VC7 to build Atlas code is causing this
>>>>>>> problem.
>>>>>>> Should I check-in these changes..?
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> Gaurav Bajaj
>>>>>>>
>>>>>>>
>>>>>>> Milko Boic wrote:
>>>>>>>> At 06:41 AM 12/22/2006, Gaurav Bajaj wrote:
>>>>>>>>> Detailed Status Report
>>>>>>>>>
>>>>>>>>> Completed Items
>>>>>>>>>
>>>>>>>>> Merged the changes related to "[Bug 172459] PROXY FAILURE:
>>>>>>>>> Real Player unable to play streams over
>>>>>>>>> proxy when cloaking is enabled ", in HEAD , tested the
>>>>>>>>> behavior, failing on assert.
>>>>>>>>
>>>>>>>> What assert is HEAD failing on? Are you looking into resolving
>>>>>>>> this?
>>>>>>>>
>>>>>>>>
>>>>>>>>> Checking out the code and making build of latest "voldemort"
>>>>>>>>> branch to repro the bugs assigned.
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> Gaurav Bajaj
>>>>>>
>>>>
>>>>
>>>> Index: hxcloakedsocket.cpp
>>>> ===================================================================
>>>> RCS file: /cvsroot/protocol/common/util/hxcloakedsocket.cpp,v
>>>> retrieving revision 1.16
>>>> diff -u -r1.16 hxcloakedsocket.cpp
>>>> --- hxcloakedsocket.cpp 2 Jan 2007 12:36:53 -0000 1.16
>>>> +++ hxcloakedsocket.cpp 2 Jan 2007 12:23:32 -0000
>>>> @@ -1,5 +1,5 @@
>>>> /* ***** BEGIN LICENSE BLOCK *****
>>>> - * Source last modified: $Id: hxcloakedsocket.cpp,v 1.16
>>>> 2007/01/02 12:36:53 gbajaj Exp $
>>>> + * Source last modified: $Id: hxcloakedsocket.cpp,v 1.15
>>>> 2006/12/26 12:12:46 gbajaj Exp $
>>>> *
>>>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights
>>>> Reserved.
>>>> *
>>>> @@ -2109,7 +2109,7 @@
>>>> HX_ASSERT(pBuf);
>>>>
>>>> // check for and possibly begin handling http authentication
>>>> - if( StartAuthenticationIfNeeded(pBuf) )
>>>> + if( m_getState != gsReadData &&
>>>> StartAuthenticationIfNeeded(pBuf) )
>>>> {
>>>> // authentication process started
>>>> hr = HXR_OK;
>
>
>
From rajesh.rathinasamy at nokia.com Wed Jan 3 06:32:39 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Jan 3 07:32:11 2007
Subject: [Protocol-dev] RE: [Client-dev] Crash on
RTSPTransportBuffer::GetCurrentBuffering &GetPacketFromQueue
In-Reply-To:
Message-ID:
Greg,
I tried replacing the m_bQueueIsEmpty with an inline function which
obtains the Q status from m_pPacketDeque. I did not see any problem.
Seems to work fine.
Can I CR that change or should we have to wait for some more comments ?
Thanks,
Rajesh.
>-----Original Message-----
>From: client-dev-bounces@helixcommunity.org
>[mailto:client-dev-bounces@helixcommunity.org]
>Sent: Tuesday, January 02, 2007 2:49 PM
>To: gwright@real.com; ping@real.com
>Cc: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>Subject: RE: [Client-dev] Crash on
>RTSPTransportBuffer::GetCurrentBuffering &GetPacketFromQueue
>
>Hi Greg,
>
>
>I looked at the code and I don't see any other usage of
>m_bQueueIsEmpty except for this little piece of comment. I
>think Henry already had some concerns over Queue empty deterimation.
>
>// XXX HP we have too many empty queue determination
> // i.e. m_bQueueIsEmpty
> // uEndIndex > MAX_DEQUEUE_SIZE
> // m_pPacketDeque->empty() == TRUE
> // m_pPacketDeque->size() == 0
>
>I will try your suggestion of removing m_bQueueIsEmpty. I will
>keep you posted.
>
>Thanks,
>Rajesh.
>
>
>
>>-----Original Message-----
>>From: ext Gregory Wright [mailto:gwright@real.com]
>>Sent: Wednesday, December 27, 2006 12:22 PM
>>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>>Cc: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>>Subject: Re: [Client-dev] Crash on
>>RTSPTransportBuffer::GetCurrentBuffering & GetPacketFromQueue
>>
>>On Dec 26, 2006, at 11:44 AM, rajesh.rathinasamy@nokia.com wrote:
>>
>>>
>>> Hello All,
>>> I'm working on 210CayS. Pause-Play after n (n is random)
>>number of
>>> times on Live stream is crashing on RTSPTransportBuffer.
>>This sequence
>>> is used when we do a full screen option on the player. The
>>sequence of
>>> operations are Pause, SetRotation, UpdateDisplaywindow &
>>Play. I think
>>> w.r.t this error what matters is the Pause-Play during a
>>seek(Resume)
>>> of live streaming.
>>>
>>> I enabled RTSP & TRAN log and those logs are of not much
>>use. So I had
>>> added some debug statements and collected the log for the crash
>>> scenario. I'm not sure what exact steps will create a crash.
>>>
>>> But from what I had analysed, there is an inconsistency in the
>>> PacketQueue size handling. There is a member variable
>>m_bQueueIsEmpty
>>> to track the emptiness of the packet queue. During
>>> a Seek(Resume) case, the boolean variable m_bQueueIsEmpty
>>> indicates that the Q has one or more packet, but the Q is empty.
>>> The Boolean variable is false and the size of packetqueue is zero.
>>> This results in accessing the front and rear packets in the
>>Q which in
>>> turn results in a crash.
>>>
>>> In first place why do we need to have a boolean variable
>>> m_bQueueIsEmpty while PacketQueue->size() will give the same
>>expected
>>> result ?
>>
>>That is what I was thinking. If it is true that
>m_bQueueIsEmpty tracks
>>the state of the list exactly, then I don't see any reason
>for it. Just
>>make sure it isn't used in some strange fashion. Sometime
>variable are
>>named in a way that doesn't make their use obvious.
>>
>>Can you try getting rid of m_bQueueIsEmpty and see what happens?
>>
>>--greg.
>>
>>> If m_bQueueIsEmpty is for some additional purpose, don't we have to
>>> check the Q size and reset this flag everytime a packet is
>>popped from
>>> the queue ?
>>>
>>> Can someone help me with this crash ?
>>>
>>> I'm attaching the log file and diff of the src which was used to
>>> generate the logs.
>>> Snippet from logs:
>>> ==============
>>>
>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::Add Before Flush bQEmpty:0 QSize:23
>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::Add WARNING bQEmpty:0 QSize:1 13:07:35.860
>>> sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:1
>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:90f998, rp:90f998
>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue Pop pkt from Q
>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue FirstSeq:2367
>>LastSeq:2348
>>>
>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue --> HXR_OK QSize:0
>>>
>>> <>.... At this point, the Q size is zero, but we are still
>>> accessing the front and rear packets based on m_bQueueIsEmpty flag.
>>>
>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:0
>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:922948, rp:90f998
>>>
>>>
>>> Thanks,
>>> Rajesh.
>>>
>>> <> <>
>>>
>>>
>>>
>>> _______________________________________________
>>> Client-dev mailing list
>>> Client-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/client-dev
>>
>>
>
>_______________________________________________
>Client-dev mailing list
>Client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/client-dev
>
From gwright at real.com Wed Jan 3 10:52:46 2007
From: gwright at real.com (Greg Wright)
Date: Wed Jan 3 11:45:13 2007
Subject: [Protocol-dev] Re: [Client-dev] Crash on
RTSPTransportBuffer::GetCurrentBuffering &GetPacketFromQueue
In-Reply-To:
References:
Message-ID: <459BFB7E.8090303@real.com>
rajesh.rathinasamy@nokia.com wrote:
> Greg,
> I tried replacing the m_bQueueIsEmpty with an inline function which
> obtains the Q status from m_pPacketDeque. I did not see any problem.
> Seems to work fine.
>
> Can I CR that change or should we have to wait for some more comments ?
Please send out a new CR for it.
--greg.
>
>
> Thanks,
> Rajesh.
>
>
>> -----Original Message-----
>> From: client-dev-bounces@helixcommunity.org
>> [mailto:client-dev-bounces@helixcommunity.org]
>> Sent: Tuesday, January 02, 2007 2:49 PM
>> To: gwright@real.com; ping@real.com
>> Cc: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>> Subject: RE: [Client-dev] Crash on
>> RTSPTransportBuffer::GetCurrentBuffering &GetPacketFromQueue
>>
>> Hi Greg,
>>
>>
>> I looked at the code and I don't see any other usage of
>> m_bQueueIsEmpty except for this little piece of comment. I
>> think Henry already had some concerns over Queue empty deterimation.
>>
>> // XXX HP we have too many empty queue determination
>> // i.e. m_bQueueIsEmpty
>> // uEndIndex > MAX_DEQUEUE_SIZE
>> // m_pPacketDeque->empty() == TRUE
>> // m_pPacketDeque->size() == 0
>>
>> I will try your suggestion of removing m_bQueueIsEmpty. I will
>> keep you posted.
>>
>> Thanks,
>> Rajesh.
>>
>>
>>
>>> -----Original Message-----
>>> From: ext Gregory Wright [mailto:gwright@real.com]
>>> Sent: Wednesday, December 27, 2006 12:22 PM
>>> To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>>> Cc: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>>> Subject: Re: [Client-dev] Crash on
>>> RTSPTransportBuffer::GetCurrentBuffering & GetPacketFromQueue
>>>
>>> On Dec 26, 2006, at 11:44 AM, rajesh.rathinasamy@nokia.com wrote:
>>>
>>>> Hello All,
>>>> I'm working on 210CayS. Pause-Play after n (n is random)
>>> number of
>>>> times on Live stream is crashing on RTSPTransportBuffer.
>>> This sequence
>>>> is used when we do a full screen option on the player. The
>>> sequence of
>>>> operations are Pause, SetRotation, UpdateDisplaywindow &
>>> Play. I think
>>>> w.r.t this error what matters is the Pause-Play during a
>>> seek(Resume)
>>>> of live streaming.
>>>>
>>>> I enabled RTSP & TRAN log and those logs are of not much
>>> use. So I had
>>>> added some debug statements and collected the log for the crash
>>>> scenario. I'm not sure what exact steps will create a crash.
>>>>
>>>> But from what I had analysed, there is an inconsistency in the
>>>> PacketQueue size handling. There is a member variable
>>> m_bQueueIsEmpty
>>>> to track the emptiness of the packet queue. During
>>>> a Seek(Resume) case, the boolean variable m_bQueueIsEmpty
>>>> indicates that the Q has one or more packet, but the Q is empty.
>>>> The Boolean variable is false and the size of packetqueue is zero.
>>>> This results in accessing the front and rear packets in the
>>> Q which in
>>>> turn results in a crash.
>>>>
>>>> In first place why do we need to have a boolean variable
>>>> m_bQueueIsEmpty while PacketQueue->size() will give the same
>>> expected
>>>> result ?
>>> That is what I was thinking. If it is true that
>> m_bQueueIsEmpty tracks
>>> the state of the list exactly, then I don't see any reason
>> for it. Just
>>> make sure it isn't used in some strange fashion. Sometime
>> variable are
>>> named in a way that doesn't make their use obvious.
>>>
>>> Can you try getting rid of m_bQueueIsEmpty and see what happens?
>>>
>>> --greg.
>>>
>>>> If m_bQueueIsEmpty is for some additional purpose, don't we have to
>>>> check the Q size and reset this flag everytime a packet is
>>> popped from
>>>> the queue ?
>>>>
>>>> Can someone help me with this crash ?
>>>>
>>>> I'm attaching the log file and diff of the src which was used to
>>>> generate the logs.
>>>> Snippet from logs:
>>>> ==============
>>>>
>>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::Add Before Flush bQEmpty:0 QSize:23
>>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::Add WARNING bQEmpty:0 QSize:1 13:07:35.860
>>>> sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:1
>>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:90f998, rp:90f998
>>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue Pop pkt from Q
>>>> 13:07:35.860 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue FirstSeq:2367
>>> LastSeq:2348
>>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue --> HXR_OK QSize:0
>>>>
>>>> <>.... At this point, the Q size is zero, but we are still
>>>> accessing the front and rear packets based on m_bQueueIsEmpty flag.
>>>>
>>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue Q:817758, QSize:0
>>>> 13:07:35.891 sti2:MCU_ASCII_PRINTF; channel:0xE0;
>>>> msg:RTSPTransportBuffer::GetPacketFromQueue fp:922948, rp:90f998
>>>>
>>>>
>>>> Thanks,
>>>> Rajesh.
>>>>
>>>> <> <>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Client-dev mailing list
>>>> Client-dev@helixcommunity.org
>>>> http://lists.helixcommunity.org/mailman/listinfo/client-dev
>>>
>> _______________________________________________
>> Client-dev mailing list
>> Client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/client-dev
>>
>
> _______________________________________________
> Client-dev mailing list
> Client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/client-dev
From ping at real.com Wed Jan 3 11:38:57 2007
From: ping at real.com (Henry Ping)
Date: Wed Jan 3 12:31:32 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To:
Message-ID:
Thanks for your callstack trace, it confirms the last 2 SetDeliveryBW
requests are issued by the HXFeedbackBufferControl and they are not issued
by the other buffering model(HXWatermarkBufferControl).
I am not familiar with the HXFeedbackBufferControl. It's critical code and
needs to be looked at carefully. Is this an urgent issue for you? Is the
content played successfully afterwards? I suggest to file a bug to Helix
database, so we can track it and assign dev resource to fix it.
Not sure if this is an option for you, you can also enable the server-side
rate adaptation, it reliefs the client-side rate adaptation and thus the
SetDeliveryBW requests.
-->Henry
> -----Original Message-----
> From: rajesh.rathinasamy@nokia.com
> [mailto:rajesh.rathinasamy@nokia.com]
> Sent: Tuesday, January 02, 2007 12:41 PM Ping
> To: ping@real.com; ehyche@real.com;
> client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start
> of stream
>
> Hi Henry,
> Thanks for your response.
>
> The profile we use is helix-client-s60-32-mmf-mdf-arm.pf. It
> uses HXFeedbackBufferControl. Attaching the function call
> traces for all the SET_PARAM during starting. (I could not
> take a txt version of call stack trace, so I have the screen
> capture attached.)
>
> SET_PARAM is sent during StartDownload,
> CheckSourceRegistration, Play (Resume), OnBufferring.
>
> Thanks,
> Rajesh.
>
>
>
>
>
> >-----Original Message-----
> >From: ext Henry Ping [mailto:ping@real.com]
> >Sent: Tuesday, January 02, 2007 12:34 PM
> >To: Rathinasamy Rajesh (Nokia-TP/Dallas); ehyche@real.com;
> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
> start of stream
> >
> >Rajesh,
> >
> >The SetDeliveryBandwidth requests via SET_PARAMER is for the whole
> >presentation, not per individual stream. It does seems to be
> redundant
> >to send multiple SetDeliveryBandwidth in sequence with the same
> >bandwidth value.
> >
> >I assume you're building with the mobile profile which uses
> different
> >buffer control model(HXFeedbackBufferControl) from the
> >rest(HXWatermarkBufferControl) when
> >HELIX_FEATURE_FEEDBACK_BUFFER_CONTROL is defined. I have a
> non-Mobile
> >build and it doesn't exhibit the same problem you saw, so I
> suspect the
> >problem might reside in that particular buffer control module.
> >
> >I suggest to set breakpoint at
> >RTSPClientProtocol::SetDeliveryBandwidth and back trace to
> the source
> >where the requests are generated.
> >
> >-->Henry
> >
> >> -----Original Message-----
> >> From: client-dev-bounces@helixcommunity.org
> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> >> rajesh.rathinasamy@nokia.com
> >> Sent: Tuesday, January 02, 2007 8:39 AM Ping
> >> To: ehyche@real.com; client-dev@helixcommunity.org;
> >> protocol-dev@helixcommunity.org
> >> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
> >> stream
> >>
> >> Hi Eric,
> >> Thanks for your time.
> >>
> >> Attaching a new log file. This has the complete RTSP chat.
> >> I could see same set of RTSP chat for all clips. The session
> >does not
> >> have three streams, it has only one audio and one video and still
> >> multiple SET_PARAM are sent. Apart from that the url sent in
> >SET_PARAM
> >> is same for all messages.
> >>
> >> If the intention is send SET_PARAM for individual streams,
> >why is that
> >> required. I thought we are responding the client bandwidth and why
> >> should it be sent for individual streams ?
> >>
> >> Thanks,
> >> Rajesh.
> >>
> >>
> >> >-----Original Message-----
> >> >From: ext Eric Hyche [mailto:ehyche@real.com]
> >> >Sent: Tuesday, January 02, 2007 9:33 AM
> >> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
> >> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
> >> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
> >> start of stream
> >> >
> >> >
> >> >There appear to be three streams: one video, one audio, and
> >> one other
> >> >(can't tell, since SDP is not in the log file). I would
> assume the
> >> >three SET_PARAMETER calls after the RTSP PLAY correspond to each
> >> >stream. Usually these can be distinguished by the URL in the RTSP
> >> >SET_PARAMETER (i.e. - rtsp://...../foo.3gp/audio, etc.) but
> >for some
> >> >reason, all of the URLs look the same in this exchange.
> >> >
> >> >Henry might be able to shed some more light on this...
> >> >
> >> >Eric
> >> >
> >> >=============================================
> >> >Eric Hyche (ehyche@real.com)
> >> >Technical Lead
> >> >RealNetworks, Inc.
> >> >
> >> >> -----Original Message-----
> >> >> From: client-dev-bounces@helixcommunity.org
> >> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
> >> >> rajesh.rathinasamy@nokia.com
> >> >> Sent: Thursday, December 21, 2006 12:02 PM
> >> >> To: client-dev@helixcommunity.org;
> protocol-dev@helixcommunity.org
> >> >> Subject: [Client-dev] Redundant SET_PARAMTER during start
> >of stream
> >> >>
> >> >> Hi,
> >> >> we noticed that after PLAY message sent to server, there are
> >> >> redundant SET_PARAMETER (PIPELINED) sent to server. I
> >> don't see any
> >> >> change in the bandwidth value reported. The message looks
> >> identical
> >> >> except for sequence number. In the attached log, there is one
> >> >> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
> >> >> PIPELINED before PLAY response.
> >> >>
> >> >> Can someone explain why this is sent multiple times ? Is it
> >> >an error ?
> >> >>
> >> >>
> >> >>
> >> >> Thanks,
> >> >> Rajesh.
> >> >>
> >> >> <>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> >
>
From rajesh.rathinasamy at nokia.com Wed Jan 3 15:29:20 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Jan 3 16:22:36 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during start
of stream
In-Reply-To: <200701031938.l03JcIiW002163@mgw-mx06.nokia.com>
Message-ID:
Hi Henry,
Thank you very much for your time.
This error is not a blocker. I can open a bug on Bugzilla. The content
plays through fine. It was an obervation from the test team.
Thanks,
Rajesh,
>-----Original Message-----
>From: ext Henry Ping [mailto:ping@real.com]
>Sent: Wednesday, January 03, 2007 1:39 PM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); ehyche@real.com;
>client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of stream
>
>Thanks for your callstack trace, it confirms the last 2
>SetDeliveryBW requests are issued by the
>HXFeedbackBufferControl and they are not issued by the other
>buffering model(HXWatermarkBufferControl).
>
>I am not familiar with the HXFeedbackBufferControl. It's
>critical code and needs to be looked at carefully. Is this an
>urgent issue for you? Is the content played successfully
>afterwards? I suggest to file a bug to Helix database, so we
>can track it and assign dev resource to fix it.
>
>Not sure if this is an option for you, you can also enable the
>server-side rate adaptation, it reliefs the client-side rate
>adaptation and thus the SetDeliveryBW requests.
>
>-->Henry
>
>> -----Original Message-----
>> From: rajesh.rathinasamy@nokia.com
>> [mailto:rajesh.rathinasamy@nokia.com]
>> Sent: Tuesday, January 02, 2007 12:41 PM Ping
>> To: ping@real.com; ehyche@real.com;
>> client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
>> stream
>>
>> Hi Henry,
>> Thanks for your response.
>>
>> The profile we use is helix-client-s60-32-mmf-mdf-arm.pf. It uses
>> HXFeedbackBufferControl. Attaching the function call traces for all
>> the SET_PARAM during starting. (I could not take a txt
>version of call
>> stack trace, so I have the screen capture attached.)
>>
>> SET_PARAM is sent during StartDownload,
>CheckSourceRegistration, Play
>> (Resume), OnBufferring.
>>
>> Thanks,
>> Rajesh.
>>
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: ext Henry Ping [mailto:ping@real.com]
>> >Sent: Tuesday, January 02, 2007 12:34 PM
>> >To: Rathinasamy Rajesh (Nokia-TP/Dallas); ehyche@real.com;
>> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
>> start of stream
>> >
>> >Rajesh,
>> >
>> >The SetDeliveryBandwidth requests via SET_PARAMER is for the whole
>> >presentation, not per individual stream. It does seems to be
>> redundant
>> >to send multiple SetDeliveryBandwidth in sequence with the same
>> >bandwidth value.
>> >
>> >I assume you're building with the mobile profile which uses
>> different
>> >buffer control model(HXFeedbackBufferControl) from the
>> >rest(HXWatermarkBufferControl) when
>> >HELIX_FEATURE_FEEDBACK_BUFFER_CONTROL is defined. I have a
>> non-Mobile
>> >build and it doesn't exhibit the same problem you saw, so I
>> suspect the
>> >problem might reside in that particular buffer control module.
>> >
>> >I suggest to set breakpoint at
>> >RTSPClientProtocol::SetDeliveryBandwidth and back trace to
>> the source
>> >where the requests are generated.
>> >
>> >-->Henry
>> >
>> >> -----Original Message-----
>> >> From: client-dev-bounces@helixcommunity.org
>> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>> >> rajesh.rathinasamy@nokia.com
>> >> Sent: Tuesday, January 02, 2007 8:39 AM Ping
>> >> To: ehyche@real.com; client-dev@helixcommunity.org;
>> >> protocol-dev@helixcommunity.org
>> >> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
>> >> stream
>> >>
>> >> Hi Eric,
>> >> Thanks for your time.
>> >>
>> >> Attaching a new log file. This has the complete RTSP chat.
>> >> I could see same set of RTSP chat for all clips. The session
>> >does not
>> >> have three streams, it has only one audio and one video and still
>> >> multiple SET_PARAM are sent. Apart from that the url sent in
>> >SET_PARAM
>> >> is same for all messages.
>> >>
>> >> If the intention is send SET_PARAM for individual streams,
>> >why is that
>> >> required. I thought we are responding the client
>bandwidth and why
>> >> should it be sent for individual streams ?
>> >>
>> >> Thanks,
>> >> Rajesh.
>> >>
>> >>
>> >> >-----Original Message-----
>> >> >From: ext Eric Hyche [mailto:ehyche@real.com]
>> >> >Sent: Tuesday, January 02, 2007 9:33 AM
>> >> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>> >> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>> >> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
>> >> start of stream
>> >> >
>> >> >
>> >> >There appear to be three streams: one video, one audio, and
>> >> one other
>> >> >(can't tell, since SDP is not in the log file). I would
>> assume the
>> >> >three SET_PARAMETER calls after the RTSP PLAY correspond to each
>> >> >stream. Usually these can be distinguished by the URL in
>the RTSP
>> >> >SET_PARAMETER (i.e. - rtsp://...../foo.3gp/audio, etc.) but
>> >for some
>> >> >reason, all of the URLs look the same in this exchange.
>> >> >
>> >> >Henry might be able to shed some more light on this...
>> >> >
>> >> >Eric
>> >> >
>> >> >=============================================
>> >> >Eric Hyche (ehyche@real.com)
>> >> >Technical Lead
>> >> >RealNetworks, Inc.
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: client-dev-bounces@helixcommunity.org
>> >> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>> >> >> rajesh.rathinasamy@nokia.com
>> >> >> Sent: Thursday, December 21, 2006 12:02 PM
>> >> >> To: client-dev@helixcommunity.org;
>> protocol-dev@helixcommunity.org
>> >> >> Subject: [Client-dev] Redundant SET_PARAMTER during start
>> >of stream
>> >> >>
>> >> >> Hi,
>> >> >> we noticed that after PLAY message sent to server,
>there are
>> >> >> redundant SET_PARAMETER (PIPELINED) sent to server. I
>> >> don't see any
>> >> >> change in the bandwidth value reported. The message looks
>> >> identical
>> >> >> except for sequence number. In the attached log, there is one
>> >> >> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
>> >> >> PIPELINED before PLAY response.
>> >> >>
>> >> >> Can someone explain why this is sent multiple times ? Is it
>> >> >an error ?
>> >> >>
>> >> >>
>> >> >>
>> >> >> Thanks,
>> >> >> Rajesh.
>> >> >>
>> >> >> <>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
From rajesh.rathinasamy at nokia.com Thu Jan 4 16:11:36 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Thu Jan 4 17:05:37 2007
Subject: [Protocol-dev] CR: Fix for inconsistency in packet queue emptiness
handling in RTSPTransportBuffer
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? Copy of transbuf.cpp
? Makefile
? Umakefil.upp
? armv5-rel32
? cvs_diff.txt
? pub/Copy of transbuf.h
Index: transbuf.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/transbuf.cpp,v
retrieving revision 1.27.2.3
diff -w -u -b -r1.27.2.3 transbuf.cpp
--- transbuf.cpp 21 Dec 2006 16:57:40 -0000 1.27.2.3
+++ transbuf.cpp 4 Jan 2007 22:55:08 -0000
@@ -129,7 +129,6 @@
m_bWaitingForLiveSeekFlush(FALSE),
m_bFlushHolding(FALSE),
m_bIsEnded(FALSE),
- m_bQueueIsEmpty(TRUE),
m_bStreamBegin(FALSE),
m_bStreamDone(FALSE),
m_bSourceStopped(FALSE),
@@ -456,7 +455,6 @@
m_bWaitingForLiveSeekFlush = FALSE;
m_bFlushHolding = FALSE;
m_bIsEnded = FALSE;
- m_bQueueIsEmpty = TRUE;
m_bCacheIsEmpty = TRUE;
m_bStreamBegin = FALSE;
m_bStreamDone = FALSE;
@@ -549,7 +547,7 @@
// Queue should not be empty at this point, since seek index
// was contained within the queue prior to flush
- HX_ASSERT(!m_bQueueIsEmpty);
+ HX_ASSERT(!IsQueueEmpty());
}
else
{
@@ -579,10 +577,9 @@
{
ClientPacket* tempPacket = NULL;
- if (m_bQueueIsEmpty)
+ if (IsQueueEmpty())
{
SanitizePacketQueue();
- m_bQueueIsEmpty = FALSE;
}
UINT32 uTailIndex = GetPacketIndex(m_uLastSequenceNumber);
@@ -1013,7 +1010,7 @@
rc = GetPacketFromQueue(pPacket);
}
- if( m_bQueueIsEmpty && m_bCacheIsEmpty )
+ if( IsQueueEmpty() && m_bCacheIsEmpty )
{
if (m_bIsEnded)
{
@@ -1179,7 +1176,7 @@
}
else if (iPacketIndex == 0)
{
- if (!m_bQueueIsEmpty)
+ if (!IsQueueEmpty())
{
pPacket = (ClientPacket*)(*m_pPacketDeque)[0];
@@ -1247,7 +1244,7 @@
iPacketIndex = 0;
}
- ASSERT(m_bQueueIsEmpty ? bAllACK : TRUE);
+ ASSERT(IsQueueEmpty() ? bAllACK : TRUE);
UINT32 uLastNAKSequenceNumber = 0;
HXBOOL bNAKFound = FALSE;
@@ -1446,7 +1443,7 @@
UINT32 uEndIndex = GetPacketIndex(m_uEndSequenceNumber);
// XXX HP we have too many empty queue determination
- // i.e. m_bQueueIsEmpty
+ // i.e. IsQueueEmpty()
// uEndIndex > MAX_DEQUEUE_SIZE
// m_pPacketDeque->empty() == TRUE
// m_pPacketDeque->size() == 0
@@ -1821,7 +1818,6 @@
* InitializeTime(&m_PacketTime);
*/
- m_bQueueIsEmpty = TRUE;
m_ulCurrentQueueByteCount = 0;
/*
@@ -1855,12 +1851,12 @@
if (m_pPacketDeque && m_uSeekCount == 0 && !m_bWaitingForSeekFlush)
{
- if (!m_bCacheIsEmpty && m_bQueueIsEmpty)
+ if (!m_bCacheIsEmpty && IsQueueEmpty())
{
ulFrontTimeStamp = m_ulFrontTimeStampCached;
ulRearTimeStamp = m_ulRearTimeStampCached;
}
- else if (m_bCacheIsEmpty && !m_bQueueIsEmpty)
+ else if (m_bCacheIsEmpty && !IsQueueEmpty())
{
ClientPacket* frontPacket = (ClientPacket*)m_pPacketDeque->front();
ClientPacket* rearPacket = (ClientPacket*)m_pPacketDeque->back();
@@ -1868,7 +1864,7 @@
ulFrontTimeStamp = frontPacket->GetTime();
ulRearTimeStamp = rearPacket->GetTime();
}
- else if (!m_bCacheIsEmpty && !m_bQueueIsEmpty)
+ else if (!m_bCacheIsEmpty && !IsQueueEmpty())
{
ClientPacket* rearPacket = (ClientPacket*)m_pPacketDeque->back();
@@ -1961,7 +1957,7 @@
* If we're empty, there's nothing to flush
*/
- if (m_bQueueIsEmpty)
+ if (IsQueueEmpty())
{
return;
}
@@ -2153,7 +2149,7 @@
pPacket = NULL;
- if (m_bQueueIsEmpty)
+ if (IsQueueEmpty())
{
return HXR_NO_DATA;
}
@@ -2269,15 +2265,6 @@
}
m_pPendingLock->Unlock();
- /*
- * The player has all the packets for the stream when first == end
- * sequence number
- */
- if (m_uFirstSequenceNumber == m_uLastSequenceNumber)
- {
- m_bQueueIsEmpty = TRUE;
- }
-
UpdateStatsFromPacket(pPacket);
m_LastPacketTime = m_PacketTime;
Index: pub/transbuf.h
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/pub/transbuf.h,v
retrieving revision 1.12.2.1
diff -w -u -b -r1.12.2.1 transbuf.h
--- pub/transbuf.h 20 Dec 2006 10:32:15 -0000 1.12.2.1
+++ pub/transbuf.h 4 Jan 2007 22:55:08 -0000
@@ -57,8 +57,8 @@
#include "cachobj.h"
#include "hxthread.h"
+#include "hxdeque.h"
-class HX_deque;
class ClientPacket;
class RTSPTransport;
@@ -193,6 +193,9 @@
void Func();
private:
+
+ inline HXBOOL IsQueueEmpty();
+
class RTSPTransportBufferCallback : public IHXCallback
{
public:
@@ -240,7 +243,6 @@
HXBOOL m_bWaitingForLiveSeekFlush;
HXBOOL m_bFlushHolding;
HXBOOL m_bIsEnded;
- HXBOOL m_bQueueIsEmpty;
HXBOOL m_bStreamBegin;
HXBOOL m_bStreamDone;
HXBOOL m_bSourceStopped;
@@ -339,4 +341,15 @@
return m_ulByteLimit;
}
+inline HXBOOL
+RTSPTransportBuffer::IsQueueEmpty()
+{
+ HXBOOL bRet = TRUE;
+ if(m_pPacketDeque != NULL)
+ {
+ bRet = m_pPacketDeque->empty();
+ }
+ return bRet;
+}
+
#endif /* _TRANSPORT_BUFFER_H_ */
From rajesh.rathinasamy at nokia.com Mon Jan 8 07:27:18 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Jan 8 08:18:56 2007
Subject: RESEND: [Protocol-dev] CR: Fix for inconsistency in packet queue
emptinesshandling in RTSPTransportBuffer
In-Reply-To:
Message-ID:
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Thursday, January 04, 2007 6:12 PM
To: protocol-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for inconsistency in packet
queue emptinesshandling in RTSPTransportBuffer
"Nokia submits this code under the terms of a commercial
contribution agreement with RealNetworks, and I am authorized to
contribute this code under said agreement."
Modified by: rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 04-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6U82QD
Synopsis: CR: Fix for inconsistency in packet queue
emptiness handling in RTSPTransportBuffer
There is an inconsistency in the PacketQueue size
handling in RTSPTransportBuffer. There is a member variable
m_bQueueIsEmpty to track the emptiness of the packet queue. During a
Seek(Resume) case, the boolean variable m_bQueueIsEmpty indicates that
the Q has one or more packet, but the Q is empty. The Boolean variable
is false and the size of packetqueue is zero. This results in accessing
the front and rear packets in the Q which in turn results in a crash.
Solution is to remove the boolean variable and use the
packetqueue to obtain the emptiness.
Root Cause of the problem: Implementation phase
Files Modified:
protocol/transport/common/system/transbuf.cpp
protocol/transport/common/system/pub/transbuf.h
Image Size and Heap Use impact: no major impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction of problem does
not have a determined procedure. Very hard to reproduce.
Memory leak check performed : Yes. No new leaks
introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5,
winscw
Branch: Head & 210CayS
<>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070108/522da99c/attachment.html
From ehyche at real.com Mon Jan 8 08:11:18 2007
From: ehyche at real.com (Eric Hyche)
Date: Mon Jan 8 09:02:34 2007
Subject: RESEND: [Protocol-dev] CR: Fix for inconsistency in packet
queueemptinesshandling in RTSPTransportBuffer
In-Reply-To:
Message-ID: <007701c7333f$a22f3ef0$db68a8c0@EHYCHED620>
Rajesh,
This change looks good. Sorry for the delay
in reviewing it.
Eric
=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
> rajesh.rathinasamy@nokia.com
> Sent: Monday, January 08, 2007 10:27 AM
> To: protocol-dev-bounces@helixcommunity.org;
> protocol-dev@helixcommunity.org
> Subject: RESEND: [Protocol-dev] CR: Fix for inconsistency in
> packet queueemptinesshandling in RTSPTransportBuffer
>
>
>
>
> ________________________________
>
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org]
> Sent: Thursday, January 04, 2007 6:12 PM
> To: protocol-dev@helixcommunity.org
> Subject: [Protocol-dev] CR: Fix for inconsistency in
> packet queue emptinesshandling in RTSPTransportBuffer
>
>
>
> "Nokia submits this code under the terms of a
> commercial contribution agreement with RealNetworks, and I am
> authorized to contribute this code under said agreement."
>
> Modified by: rajesh.rathinasamy@nokia.com
>
> Reviewed by:
>
> Date: 04-Jan-2007
>
> Project: SymbianMmf
>
> ErrorId: EOVL-6U82QD
>
> Synopsis: CR: Fix for inconsistency in packet
> queue emptiness handling in RTSPTransportBuffer
>
> There is an inconsistency in the
> PacketQueue size handling in RTSPTransportBuffer. There is a
> member variable m_bQueueIsEmpty to track the emptiness of the
> packet queue. During a Seek(Resume) case, the boolean
> variable m_bQueueIsEmpty indicates that the Q has one or more
> packet, but the Q is empty. The Boolean variable is false and
> the size of packetqueue is zero. This results in accessing
> the front and rear packets in the Q which in turn results in a crash.
>
> Solution is to remove the boolean variable and
> use the packetqueue to obtain the emptiness.
>
> Root Cause of the problem: Implementation phase
>
> Files Modified:
> protocol/transport/common/system/transbuf.cpp
> protocol/transport/common/system/pub/transbuf.h
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Pass
>
> Test case(s) Added : No. Reproduction of
> problem does not have a determined procedure. Very hard to reproduce.
>
> Memory leak check performed : Yes. No new
> leaks introduced.
>
> Platforms and Profiles Build Verified:
> helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified:
> armv5, winscw
>
> Branch: Head & 210CayS
>
> <>
>
>
From rajesh.rathinasamy at nokia.com Mon Jan 8 09:37:39 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Jan 8 10:29:49 2007
Subject: [Protocol-dev] CN: Fix for inconsistency in packet queue
emptinesshandling in RTSPTransportBuffer
In-Reply-To: <007701c7333f$a22f3ef0$db68a8c0@EHYCHED620>
Message-ID:
Hi Eric,
Thanks for reviewing.
The changes have been committed into Head and 210CayS.
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Monday, January 08, 2007 10:11 AM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>protocol-dev-bounces@helixcommunity.org;
>protocol-dev@helixcommunity.org
>Subject: RE: RESEND: [Protocol-dev] CR: Fix for inconsistency
>in packet queueemptinesshandling in RTSPTransportBuffer
>
>
>Rajesh,
>
>This change looks good. Sorry for the delay in reviewing it.
>
>Eric
>
>=============================================
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.
>
>> -----Original Message-----
>> From: protocol-dev-bounces@helixcommunity.org
>> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
>> rajesh.rathinasamy@nokia.com
>> Sent: Monday, January 08, 2007 10:27 AM
>> To: protocol-dev-bounces@helixcommunity.org;
>> protocol-dev@helixcommunity.org
>> Subject: RESEND: [Protocol-dev] CR: Fix for inconsistency in packet
>> queueemptinesshandling in RTSPTransportBuffer
>>
>>
>>
>>
>> ________________________________
>>
>> From: protocol-dev-bounces@helixcommunity.org
>> [mailto:protocol-dev-bounces@helixcommunity.org]
>> Sent: Thursday, January 04, 2007 6:12 PM
>> To: protocol-dev@helixcommunity.org
>> Subject: [Protocol-dev] CR: Fix for inconsistency in
>packet queue
>> emptinesshandling in RTSPTransportBuffer
>>
>>
>>
>> "Nokia submits this code under the terms of a
>commercial contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: rajesh.rathinasamy@nokia.com
>>
>> Reviewed by:
>>
>> Date: 04-Jan-2007
>>
>> Project: SymbianMmf
>>
>> ErrorId: EOVL-6U82QD
>>
>> Synopsis: CR: Fix for inconsistency in packet
>queue emptiness
>> handling in RTSPTransportBuffer
>>
>> There is an inconsistency in the
>PacketQueue size handling in
>> RTSPTransportBuffer. There is a member variable m_bQueueIsEmpty to
>> track the emptiness of the packet queue. During a Seek(Resume) case,
>> the boolean variable m_bQueueIsEmpty indicates that the Q has one or
>> more packet, but the Q is empty. The Boolean variable is
>false and the
>> size of packetqueue is zero. This results in accessing the
>front and
>> rear packets in the Q which in turn results in a crash.
>>
>> Solution is to remove the boolean variable and
>use the packetqueue
>> to obtain the emptiness.
>>
>> Root Cause of the problem: Implementation phase
>>
>> Files Modified:
>> protocol/transport/common/system/transbuf.cpp
>> protocol/transport/common/system/pub/transbuf.h
>>
>> Image Size and Heap Use impact: no major impact
>>
>> Module Release testing (STIF) : Pass
>>
>> Test case(s) Added : No. Reproduction of
>problem does not have a
>> determined procedure. Very hard to reproduce.
>>
>> Memory leak check performed : Yes. No new
>leaks introduced.
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-32-mmf-mdf-arm
>>
>> Platforms and Profiles Functionality verified:
>> armv5, winscw
>>
>> Branch: Head & 210CayS
>>
>> <>
>>
>>
>
>
From gwright at real.com Mon Jan 8 12:20:58 2007
From: gwright at real.com (Greg Wright)
Date: Mon Jan 8 13:12:09 2007
Subject: [Protocol-dev] CR: Fix for inconsistency in packet queue emptiness
handling in RTSPTransportBuffer
In-Reply-To:
References:
Message-ID: <45A2A7AA.60308@real.com>
I think this looks good.
--greg.
rajesh.rathinasamy@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement."
>
> Modified by: rajesh.rathinasamy@nokia.com
>
> Reviewed by:
>
> Date: 04-Jan-2007
>
> Project: SymbianMmf
>
> ErrorId: EOVL-6U82QD
>
> Synopsis: CR: Fix for inconsistency in packet queue emptiness
> handling in RTSPTransportBuffer
>
> There is an inconsistency in the PacketQueue size handling
> in RTSPTransportBuffer. There is a member variable m_bQueueIsEmpty to
> track the emptiness of the packet queue. During a Seek(Resume) case, the
> boolean variable m_bQueueIsEmpty indicates that the Q has one or more
> packet, but the Q is empty. The Boolean variable is false and the size
> of packetqueue is zero. This results in accessing the front and rear
> packets in the Q which in turn results in a crash.
>
> Solution is to remove the boolean variable and use the
> packetqueue to obtain the emptiness.
>
> Root Cause of the problem: Implementation phase
>
> Files Modified:
> protocol/transport/common/system/transbuf.cpp
> protocol/transport/common/system/pub/transbuf.h
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Pass
>
> Test case(s) Added : No. Reproduction of problem does not
> have a determined procedure. Very hard to reproduce.
>
> Memory leak check performed : Yes. No new leaks introduced.
>
> Platforms and Profiles Build Verified:
> helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Head & 210CayS
>
> <>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
From rmathew at real.com Mon Jan 8 13:12:51 2007
From: rmathew at real.com (Rishi Mathew)
Date: Mon Jan 8 14:01:35 2007
Subject: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
In-Reply-To: <6.2.5.6.2.20070102130054.07f945b8@real.com>
References:
<6.2.5.6.2.20070102130054.07f945b8@real.com>
Message-ID: <6.2.5.6.2.20070108131116.0601bba8@real.com>
Rajesh,
We have released and uploaded the v 2.2 of the TCK with your suggested change.
Please see Docs section of:
https://helixcommunity.org/projects/client-tck/
Thanks,
Rishi.
At 01:01 PM 1/2/2007, Rishi Mathew wrote:
>Hi Rajesh,
>
>We will update the TCK compliance doc with this information.
>
>Thanks,
>Rishi.
>
>At 12:50 PM 1/2/2007, rajesh.rathinasamy@nokia.com wrote:
>>
>>
>>
>>----------
>>From: protocol-dev-bounces@helixcommunity.org [
>>mailto:protocol-dev-bounces@helixcommunity.org]
>>Sent: Tuesday, December 19, 2006 6:10 PM
>>To: rmathew@real.com; protocol-dev@helixcommunity.org
>>Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>>Rishi,
>>
>><>>>>>>>
>><>To pass the compatibility test for RTSP pipelining,
>>Should the Describe-Option pipeline feature be enabled ?
>><> No.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>> Since Describe-Option pipeline is not required for (optional)
>> TCK compliane 31.1 RTSP pipelining ( 31 Reduced Startup Delay ),
>> should that test case be broken into two one for Describe-Option
>> pipeline and the other for the SETUP/SUBSCRIBE/PLAY ? (or the test
>> criteria has to be changed ?)
>>
>>Please let me know if an error has to be raised for updating TCK
>>compliance doc (provided what I understand is correct)
>>
>>
>>Thanks,
>>Rajesh.
>>
>>
>>
>>----------
>>From: ext Rishi Mathew [ mailto:rmathew@real.com]
>>Sent: Monday, December 18, 2006 3:33 PM
>>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>>protocol-dev@helixcommunity.org
>>Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>>Hi Rajesh,
>>Comments inline..
>>At 01:10 PM 12/18/2006, rajesh.rathinasamy@nokia.com wrote:
>>>Hi Rishi,
>>> Thanks for your response. I have one more question.
>>>
>>>The RTSP pipelining is enabled by default. But the code seems to
>>>disable the pipeline if the server is not Helix / Real Server. So
>>>what does it mean to TCK compliance ? Just the capability to RTSP
>>>pipeline with Helix / Real server fine for TCK Compliance ?
>>Yes. The ability to turn it on when possible. Be aware this is an
>>"optional" feature in the TCK.
>>Thanks,
>>Rishi.
>>
>>>Thanks,
>>>Rajesh.
>>>
>>>In rtsp\rtspclnt.cpp
>>>==============
>>> if( pViaHeader )
>>> {
>>> MIMEHeaderValue* pViaValue = pViaHeader->getFirstHeaderValue();
>>> while( pViaValue )
>>> {
>>> pViaValue->asString(it);
>>> if( -1 == it.Find("RealProxy") )
>>> {
>>> //This is a non-Real proxy. Only real proxies are
>>> known to work
>>> //with RTSP piplining. If you find another, add it here.
>>> m_bPipelineRTSP = FALSE;
>>> }
>>> //Test for NetCache appliance.
>>> if( -1 != it.Find("NetCache NetApp") )
>>> {
>>> //Found at least one NetCache Proxy.
>>> m_bTrimTrailingSlashes = TRUE;
>>> break;
>>> }
>>> pViaValue = pViaHeader->getNextHeaderValue();
>>> }
>>> }
>>> //We also turn off RTSP pipelining if this is not a realserver(helix).
>>> if( !IsRealServer() )
>>> {
>>> m_bPipelineRTSP = FALSE;
>>> }
>>>
>>>
>>>
>>>
>>>----------
>>>From: ext Rishi Mathew [ mailto:rmathew@real.com]
>>>Sent: Monday, December 18, 2006 2:13 PM
>>>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>>>protocol-dev@helixcommunity.org
>>>Subject: Re: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
>>>Hi Rajesh,
>>>Comments inline..
>>>At 02:45 PM 12/14/2006, rajesh.rathinasamy@nokia.com wrote:
>>>>Content-class: urn:content-classes:message
>>>>Content-Type: multipart/alternative;
>>>> boundary="----_=_NextPart_001_01C71FE1.A16090E5"
>>>>Hi,
>>>> I have a question regarding the RTSP pipelining and helix DNA
>>>> TCK v2.0.
>>>> According to Helix TCK , what is RTSP pipeling ?
>>>RTSP Pipelining is defined as "multiple RTSP methods being sent by
>>>the client without needing to wait for responses from the server".
>>>
>>>>By default with helix Server SETUP, PLAY &
>>>>SET_PARAMETER messages are pipelined. But I noticed a feature
>>>>flag HELIX_FEATURE_PIPELINED_DESCRIBE which pipelines Describe
>>>>and Options message.
>>>>To pass the compatibility test for RTSP pipelining, Should the
>>>>Describe-Option pipeline feature be enabled ?
>>>No.
>>>
>>>
>>>>By the way is Describe-Option pipeline a standard feature (Does
>>>>other servers support it )?
>>>No, this is a Helix Client-to-Helix Server feature only. Helix
>>>Clients will not try this with other servers or if appropriate
>>>preferences are set to disable it.
>>>Thanks,
>>>Rishi.
>>>
>>>
>>>>Thanks,
>>>>Rajesh.
>>>>_______________________________________________
>>>>Protocol-dev mailing list
>>>>Protocol-dev@helixcommunity.org
>>>>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
>>>
>>>
>>>Rishi Mathew
>>>Sr. Software Development Engineer
>>>Helix Community
>>>Real Networks, Inc.
>>>rmathew@real.com
>>>http://www.helixcommunity.org
>>>http://www.realnetworks.com/products/support/devsupport.html
>>
>>
>>Rishi Mathew
>>Sr. Software Development Engineer
>>Helix Community
>>Real Networks, Inc.
>>rmathew@real.com
>>http://www.helixcommunity.org
>>http://www.realnetworks.com/products/support/devsupport.html
>
>Rishi Mathew
>Sr. Software Development Engineer
>Helix Community
>Real Networks, Inc.
>rmathew@real.com
>http://www.helixcommunity.org
>http://www.realnetworks.com/products/support/devsupport.html
>_______________________________________________
>Protocol-dev mailing list
>Protocol-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Sr. Software Development Engineer
Helix Community
RealNetworks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070108/357d3329/attachment-0001.html
From rajesh.rathinasamy at nokia.com Mon Jan 8 13:16:25 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Jan 8 14:08:12 2007
Subject: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
In-Reply-To: <6.2.5.6.2.20070108131116.0601bba8@real.com>
Message-ID:
Hi Rishi,
Thanks for the follow up and update.
Thanks,
Rajesh.
________________________________
From: ext Rishi Mathew [mailto:rmathew@real.com]
Sent: Monday, January 08, 2007 3:13 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] RTSP Pipelining & Helix DNA TCK
Rajesh,
We have released and uploaded the v 2.2 of the TCK with your
suggested change.
Please see Docs section of:
https://helixcommunity.org/projects/client-tck/
Thanks,
Rishi.
At 01:01 PM 1/2/2007, Rishi Mathew wrote:
Hi Rajesh,
We will update the TCK compliance doc with this
information.
Thanks,
Rishi.
At 12:50 PM 1/2/2007, rajesh.rathinasamy@nokia.com
wrote:
________________________________
From:
protocol-dev-bounces@helixcommunity.org [
mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Tuesday, December 19, 2006 6:10 PM
To: rmathew@real.com;
protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] RTSP
Pipelining & Helix DNA TCK
Rishi,
<>>>>>>>
<>To pass the compatibility test
for RTSP pipelining, Should the Describe-Option pipeline feature be
enabled ?
<> No.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Since Describe-Option pipeline is not
required for (optional) TCK compliane 31.1 RTSP pipelining ( 31 Reduced
Startup Delay ), should that test case be broken into two one for
Describe-Option pipeline and the other for the SETUP/SUBSCRIBE/PLAY ?
(or the test criteria has to be changed ?)
Please let me know if an error has to be
raised for updating TCK compliance doc (provided what I understand is
correct)
Thanks,
Rajesh.
________________________________
From: ext Rishi Mathew [
mailto:rmathew@real.com]
Sent: Monday, December 18, 2006 3:33 PM
To: Rathinasamy Rajesh
(Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] RTSP
Pipelining & Helix DNA TCK
Hi Rajesh,
Comments inline..
At 01:10 PM 12/18/2006,
rajesh.rathinasamy@nokia.com wrote:
Hi Rishi,
Thanks for your response. I have one
more question.
The RTSP pipelining is enabled by
default. But the code seems to disable the pipeline if the server is not
Helix / Real Server. So what does it mean to TCK compliance ? Just the
capability to RTSP pipeline with Helix / Real server fine for TCK
Compliance ?
Yes. The ability to turn it on when
possible. Be aware this is an "optional" feature in the TCK.
Thanks,
Rishi.
Thanks,
Rajesh.
In rtsp\rtspclnt.cpp
==============
if( pViaHeader )
{
MIMEHeaderValue* pViaValue =
pViaHeader->getFirstHeaderValue();
while( pViaValue )
{
pViaValue->asString(it);
if( -1 ==
it.Find("RealProxy") )
{
//This is a non-Real
proxy. Only real proxies are known to work
//with RTSP piplining.
If you find another, add it here.
m_bPipelineRTSP = FALSE;
}
//Test for NetCache
appliance.
if( -1 != it.Find("NetCache
NetApp") )
{
//Found at least one
NetCache Proxy.
m_bTrimTrailingSlashes =
TRUE;
break;
}
pViaValue =
pViaHeader->getNextHeaderValue();
}
}
//We also turn off RTSP pipelining
if this is not a realserver(helix).
if( !IsRealServer() )
{
m_bPipelineRTSP = FALSE;
}
________________________________
From: ext Rishi Mathew [
mailto:rmathew@real.com]
Sent: Monday, December 18, 2006 2:13 PM
To: Rathinasamy Rajesh
(Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org
Subject: Re: [Protocol-dev] RTSP
Pipelining & Helix DNA TCK
Hi Rajesh,
Comments inline..
At 02:45 PM 12/14/2006,
rajesh.rathinasamy@nokia.com wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C71FE1.A16090E5"
Hi,
I have a question regarding the RTSP
pipelining and helix DNA TCK v2.0.
According to Helix TCK , what is RTSP
pipeling ?
RTSP Pipelining is defined as "multiple
RTSP methods being sent by the client without needing to wait for
responses from the server".
By default with helix Server SETUP, PLAY
& SET_PARAMETER messages are pipelined. But I noticed a feature flag
HELIX_FEATURE_PIPELINED_DESCRIBE which pipelines Describe and Options
message.
To pass the compatibility test for RTSP
pipelining, Should the Describe-Option pipeline feature be enabled ?
No.
By the way is Describe-Option pipeline a
standard feature (Does other servers support it )?
No, this is a Helix Client-to-Helix
Server feature only. Helix Clients will not try this with other servers
or if appropriate preferences are set to disable it.
Thanks,
Rishi.
Thanks,
Rajesh.
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Sr. Software Development Engineer
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070108/d550a785/attachment.html
From rajesh.rathinasamy at nokia.com Wed Jan 10 15:46:37 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Jan 10 16:37:37 2007
Subject: [Protocol-dev] Transport switchover failure in case of port blocking
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: splay_webserver.cap
Type: application/octet-stream
Size: 16454 bytes
Desc: splay_webserver.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070110/2b39ec5d/splay_webserver-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PC_webserver_1.cap
Type: application/octet-stream
Size: 6768 bytes
Desc: PC_webserver_1.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070110/2b39ec5d/PC_webserver_1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S60_webserver.cap
Type: application/octet-stream
Size: 47517 bytes
Desc: S60_webserver.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070110/2b39ec5d/S60_webserver-0001.obj
From rajesh.rathinasamy at nokia.com Thu Jan 11 06:29:09 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Thu Jan 11 07:19:48 2007
Subject: [Protocol-dev] CR: Fix for failure to switch to tcp transport when
udp ports are blocked
Message-ID:
"Nokia submits this code under the terms of a commercial contribution
agreement with RealNetworks, and I am authorized to contribute this code
under said agreement."
Modified by: rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch to tcp transport when
udp ports are blocked.
Problem: All udp ports are blocked on the router or on server
(used iptables on linux OS). When we try to stream a clip, the client
first tries to establish RTSP connection and waits for UDP data. Since
UDP ports were blocked there was UDP timeout should occur and the client
should switch to next transport. Instead of transport switch, we say
server timeout. The transport switch happens properly if the UDP timeout
value is smaller than ServerTimeout value.
The current transport mode on rtspclnt.cpp is intialized to
TCPMode. From what I understand, the current transport mode indicates
the media transport protocol. Changes are based on this assumption.
If the current transport is TCP or HTTPCloak,
RTSPClientProtocol::handleMessage (during 200 OK for OPTIONS) sets the
lastPackettimestamp on RTSPProtocol. Setting this variable makes the
server timeout handling active on RTSPProtocol::process. The current
tarnsport changes to UDP mode after describe response and session setup.
This change in mode will avoid any more update to the last packet
received time on RTSPProtocol. And since there are no incoming UDP data
because of port blocking, the server timeout fires on the RTSPProtocol.
As a change I have initialized the current transport mode on
RTSPClientProtocol to unknownMode instead of TCPMode.
Root Cause of the problem: Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction of problem includes
blocking of port on router
Memory leak check performed : Yes. No new leaks introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006 09:39:00 -0000 1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007 22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070111/e689b086/attachment.html
From ping at real.com Thu Jan 11 09:08:23 2007
From: ping at real.com (Henry Ping)
Date: Thu Jan 11 09:58:57 2007
Subject: [Protocol-dev] CR: Fix for failure to switch to tcp transport
whenudp ports are blocked
In-Reply-To:
Message-ID:
Looks good, your description below is accurate.
-->Henry
_____
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Thursday, January 11, 2007 6:29 AM Ping
To: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for failure to switch to tcp transport
whenudp ports are blocked
"Nokia submits this code under the terms of a commercial contribution
agreement with RealNetworks, and I am authorized to contribute this code
under said agreement."
Modified by: rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch to tcp transport when udp
ports are blocked.
Problem: All udp ports are blocked on the router or on server (used
iptables on linux OS). When we try to stream a clip, the client first tries
to establish RTSP connection and waits for UDP data. Since UDP ports were
blocked there was UDP timeout should occur and the client should switch to
next transport. Instead of transport switch, we say server timeout. The
transport switch happens properly if the UDP timeout value is smaller than
ServerTimeout value.
The current transport mode on rtspclnt.cpp is intialized to TCPMode.
>From what I understand, the current transport mode indicates the media
transport protocol. Changes are based on this assumption.
If the current transport is TCP or HTTPCloak,
RTSPClientProtocol::handleMessage (during 200 OK for OPTIONS) sets the
lastPackettimestamp on RTSPProtocol. Setting this variable makes the server
timeout handling active on RTSPProtocol::process. The current tarnsport
changes to UDP mode after describe response and session setup. This change
in mode will avoid any more update to the last packet received time on
RTSPProtocol. And since there are no incoming UDP data because of port
blocking, the server timeout fires on the RTSPProtocol.
As a change I have initialized the current transport mode on
RTSPClientProtocol to unknownMode instead of TCPMode.
Root Cause of the problem: Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction of problem includes
blocking of port on router
Memory leak check performed : Yes. No new leaks introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006 09:39:00 -0000 1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007 22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070111/54162012/attachment.html
From rajesh.rathinasamy at nokia.com Thu Jan 11 12:05:55 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Thu Jan 11 12:57:44 2007
Subject: [Protocol-dev] CR: Fix for failure to switch to tcp transport
whenudp ports are blocked
In-Reply-To: <200701111707.l0BH7Wl9014252@mgw-mx06.nokia.com>
Message-ID:
Thanks Henry !
The changes have been committed to Head and 210CayS
- Rajesh.
________________________________
From: ext Henry Ping [mailto:ping@real.com]
Sent: Thursday, January 11, 2007 11:08 AM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: RE: [Protocol-dev] CR: Fix for failure to switch to tcp
transport whenudp ports are blocked
Looks good, your description below is accurate.
-->Henry
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Thursday, January 11, 2007 6:29 AM Ping
To: protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for failure to switch to
tcp transport whenudp ports are blocked
"Nokia submits this code under the terms of a commercial
contribution agreement with RealNetworks, and I am authorized to
contribute this code under said agreement."
Modified by: rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch to tcp
transport when udp ports are blocked.
Problem: All udp ports are blocked on the router
or on server (used iptables on linux OS). When we try to stream a clip,
the client first tries to establish RTSP connection and waits for UDP
data. Since UDP ports were blocked there was UDP timeout should occur
and the client should switch to next transport. Instead of transport
switch, we say server timeout. The transport switch happens properly if
the UDP timeout value is smaller than ServerTimeout value.
The current transport mode on rtspclnt.cpp is
intialized to TCPMode. From what I understand, the current transport
mode indicates the media transport protocol. Changes are based on this
assumption.
If the current transport is TCP or HTTPCloak,
RTSPClientProtocol::handleMessage (during 200 OK for OPTIONS) sets the
lastPackettimestamp on RTSPProtocol. Setting this variable makes the
server timeout handling active on RTSPProtocol::process. The current
tarnsport changes to UDP mode after describe response and session setup.
This change in mode will avoid any more update to the last packet
received time on RTSPProtocol. And since there are no incoming UDP data
because of port blocking, the server timeout fires on the RTSPProtocol.
As a change I have initialized the current
transport mode on RTSPClientProtocol to unknownMode instead of TCPMode.
Root Cause of the problem: Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction of
problem includes blocking of port on router
Memory leak check performed : Yes. No new leaks
introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified:
armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006 09:39:00 -0000
1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007 22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070111/0073d18a/attachment-0001.html
From milko at real.com Thu Jan 11 12:24:49 2007
From: milko at real.com (Milko Boic)
Date: Thu Jan 11 13:15:23 2007
Subject: [Client-dev] RE: [Protocol-dev] CR: Fix for failure to
switch to tcp transport whenudp ports are blocked
In-Reply-To:
References: <200701111707.l0BH7Wl9014252@mgw-mx06.nokia.com>
Message-ID: <6.2.1.2.2.20070111122429.04f57108@mailone.real.com>
Please commit to hxclient_1_5_0_cayenne as well.
Thanks,
Milko
At 12:05 PM 1/11/2007, rajesh.rathinasamy@nokia.com wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01C735BB.E76DD096"
>
>Thanks Henry !
>
>The changes have been committed to Head and 210CayS
>
>
>- Rajesh.
>
>
>
>----------
>From: ext Henry Ping [mailto:ping@real.com]
>Sent: Thursday, January 11, 2007 11:08 AM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>Subject: RE: [Protocol-dev] CR: Fix for failure to switch to tcp transport
>whenudp ports are blocked
>
>Looks good, your description below is accurate.
>
>-->Henry
>
>
>----------
>From: protocol-dev-bounces@helixcommunity.org
>[mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
>rajesh.rathinasamy@nokia.com
>Sent: Thursday, January 11, 2007 6:29 AM Ping
>To: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
>Subject: [Protocol-dev] CR: Fix for failure to switch to tcp transport
>whenudp ports are blocked
>
>"Nokia submits this code under the terms of a commercial contribution
>agreement with RealNetworks, and I am authorized to contribute this code
>under said agreement."
>Modified by: rajesh.rathinasamy@nokia.com
>
>Reviewed by:
>Date: 10-Jan-2007
>
>Project: SymbianMmf
>
>ErrorId: EOVL-6XBTKL
>
>Synopsis: CR: Fix for failure to switch to tcp transport when udp ports
>are blocked.
>
>Problem: All udp ports are blocked on the router or on server (used
>iptables on linux OS). When we try to stream a clip, the client first
>tries to establish RTSP connection and waits for UDP data. Since UDP ports
>were blocked there was UDP timeout should occur and the client should
>switch to next transport. Instead of transport switch, we say server
>timeout. The transport switch happens properly if the UDP timeout value is
>smaller than ServerTimeout value.
>The current transport mode on rtspclnt.cpp is intialized to TCPMode. From
>what I understand, the current transport mode indicates the media
>transport protocol. Changes are based on this assumption.
>If the current transport is TCP or
>HTTPCloak, RTSPClientProtocol::handleMessage (during 200 OK for OPTIONS)
>sets the lastPackettimestamp on RTSPProtocol. Setting this variable makes
>the server timeout handling active on RTSPProtocol::process. The current
>tarnsport changes to UDP mode after describe response and session setup.
>This change in mode will avoid any more update to the last packet received
>time on RTSPProtocol. And since there are no incoming UDP data because of
>port blocking, the server timeout fires on the RTSPProtocol.
>As a change I have initialized the current transport mode on
>RTSPClientProtocol to unknownMode instead of TCPMode.
>Root Cause of the problem: Implementation phase
>
>Files Modified:
>protocol/rtsp/rtspclnt.cpp
>
>Image Size and Heap Use impact: no major impact
>
>Module Release testing (STIF) : Pass
>Test case(s) Added : No. Reproduction of problem includes blocking of
>port on router
>
>Memory leak check performed : Yes. No new leaks introduced.
>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
>Platforms and Profiles Functionality verified: armv5, winscw
> Branch: Head & 210CayS
>
>Index: rtspclnt.cpp
>===================================================================
>RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>retrieving revision 1.182.2.17
>diff -w -u -b -r1.182.2.17 rtspclnt.cpp
>--- rtspclnt.cpp 21 Dec 2006 09:39:00 -0000 1.182.2.17
>+++ rtspclnt.cpp 10 Jan 2007 22:10:53 -0000
>@@ -2397,7 +2397,7 @@
> m_cloakPort(0),
> m_pMutex(NULL),
> m_uProtocolType(0),
>- m_currentTransport(TCPMode),
>+ m_currentTransport(UnknownMode),
> m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
> m_bSplitterConsumer(FALSE),
> m_pPacketFilter(NULL),
>
>_______________________________________________
>Client-dev mailing list
>Client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070111/5b4a69a6/attachment.html
From rajesh.rathinasamy at nokia.com Thu Jan 11 14:36:50 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Thu Jan 11 15:27:38 2007
Subject: [Client-dev] RE: [Protocol-dev] CR: Fix for failure to switch to
tcp transport whenudp ports are blocked
In-Reply-To: <6.2.1.2.2.20070111122429.04f57108@mailone.real.com>
Message-ID:
The changes have been committed to 150Cay as well.
Thanks,
Rajesh.
________________________________
From: ext Milko Boic [mailto:milko@real.com]
Sent: Thursday, January 11, 2007 2:25 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); ping@real.com;
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: Re: [Client-dev] RE: [Protocol-dev] CR: Fix for failure
to switch to tcp transport whenudp ports are blocked
Please commit to hxclient_1_5_0_cayenne as well.
Thanks,
Milko
At 12:05 PM 1/11/2007, rajesh.rathinasamy@nokia.com wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C735BB.E76DD096"
Thanks Henry !
The changes have been committed to Head and 210CayS
- Rajesh.
________________________________
From: ext Henry Ping [mailto:ping@real.com ]
Sent: Thursday, January 11, 2007 11:08 AM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: RE: [Protocol-dev] CR: Fix for failure
to switch to tcp transport whenudp ports are blocked
Looks good, your description below is accurate.
-->Henry
________________________________
From:
protocol-dev-bounces@helixcommunity.org [
mailto:protocol-dev-bounces@helixcommunity.org
] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Thursday, January 11, 2007 6:29 AM
Ping
To: protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
"Nokia submits this code under the terms
of a commercial contribution agreement with RealNetworks, and I am
authorized to contribute this code under said agreement."
Modified by:
rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch
to tcp transport when udp ports are blocked.
Problem: All udp ports are blocked on
the router or on server (used iptables on linux OS). When we try to
stream a clip, the client first tries to establish RTSP connection and
waits for UDP data. Since UDP ports were blocked there was UDP timeout
should occur and the client should switch to next transport. Instead of
transport switch, we say server timeout. The transport switch happens
properly if the UDP timeout value is smaller than ServerTimeout value.
The current transport mode on
rtspclnt.cpp is intialized to TCPMode. From what I understand, the
current transport mode indicates the media transport protocol. Changes
are based on this assumption.
If the current transport is TCP or
HTTPCloak, RTSPClientProtocol::handleMessage (during 200 OK for
OPTIONS) sets the lastPackettimestamp on RTSPProtocol. Setting this
variable makes the server timeout handling active on
RTSPProtocol::process. The current tarnsport changes to UDP mode after
describe response and session setup. This change in mode will avoid any
more update to the last packet received time on RTSPProtocol. And since
there are no incoming UDP data because of port blocking, the server
timeout fires on the RTSPProtocol.
As a change I have initialized the
current transport mode on RTSPClientProtocol to unknownMode instead of
TCPMode.
Root Cause of the problem:
Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major
impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction
of problem includes blocking of port on router
Memory leak check performed : Yes. No
new leaks introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality
verified: armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file:
/cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006
09:39:00 -0000 1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007
22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070111/e90d46f1/attachment-0001.html
From rajesh.rathinasamy at nokia.com Fri Jan 12 08:47:23 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Fri Jan 12 09:38:31 2007
Subject: [Protocol-dev] FW:Transport switchover failure in case of port
blocking
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: splay_webserver.cap
Type: application/octet-stream
Size: 16454 bytes
Desc: splay_webserver.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070112/f17b12ac/splay_webserver-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PC_webserver_1.cap
Type: application/octet-stream
Size: 6768 bytes
Desc: PC_webserver_1.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070112/f17b12ac/PC_webserver_1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S60_webserver.cap
Type: application/octet-stream
Size: 47517 bytes
Desc: S60_webserver.cap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070112/f17b12ac/S60_webserver-0001.obj
-------------- next part --------------
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
From ping at real.com Fri Jan 12 10:24:03 2007
From: ping at real.com (Henry Ping)
Date: Fri Jan 12 11:14:23 2007
Subject: [Protocol-dev] FW:Transport switchover failure in case of
portblocking
In-Reply-To:
Message-ID:
Rajesh,
I assume you're referring to HTTPCloaking. The client does the port scanning
for HTTPCloaking, instead of doing it sequentially, it scans 4 ports(80,
8080, 554, 7070) at the same time by attempting to establish 4 separate HTTP
connections. The client picks the first one responses success and cancels
the rest.
The Ethereal traces you provided are not conclusive. From the symptom you
described below, it seems as if we didn't handle the 404 response properly
and considered it as a "successful" connection for HTTPCloaking.
Can you try the following steps to narrow down the problem:
1. Appending "?cloakport="80"" to the URL, this tells the client to only
attempt HTTPCloaking via port 80. You can verify this by setting breakpoint
at RTSPClientProtocol::GetAddrInfoDone where it initiates the cloakport
scanning.
2. Set breakpoint at RTSPClientProtocol::SessionSucceeded, if this is called
and the m_cloakPort is 80, then this can be the problem.
It's also helpful to know which version of cloaking implementation is used
when this occurs, you can find it out by looking at the
RTSPClientSession::StartCloakingSession.
I don't think SmartER Networking will have any effect on detecting the
successful cloaking port. It will only cache the previous successful
cloaking port for subsequent playback to reduce connecting time by not
scanning the cloaking ports.
-->Henry
_____
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Friday, January 12, 2007 8:47 AM Ping
To: protocol-dev@helixcommunity.org
Subject: [Protocol-dev] FW:Transport switchover failure in case of
portblocking
_____
From: client-dev-bounces@helixcommunity.org
[mailto:client-dev-bounces@helixcommunity.org]
Sent: Wednesday, January 10, 2007 5:47 PM
To: protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: [Client-dev] Transport switchover failure in case of port blocking
Hello All,
We were testing transport switch over for various cases. Switch over to
HTTP streaming fails when a webserver is running on port 80 and Helix
WebService on port 8080. For this use case, the port 554 is blocked (or
server can run on different port). Expected behaviour for the client would
be to try 554(RTSP), 80 (HTTP), 8080 (HTTP) and try streaming on port 8080.
But what we see is "unable to connect" eventhough the ethereal shows that
Helix server responded with 200 OK on port 8080.
Is that an expected behaviour for the client to fail if a different
webserver is running on 80 ? The same problem is not seen when there is no
server listening on port 80. In that case it streams properly from 8080.
I'm assuming that the 404 from webserver is causing the client to give up.
But the client tries to all set of ports twice and it does not bail out for
earlier 404 error from webserver.
The problem is seen on splay (off 210CayS branch) and on SymbianMmf targets.
I tried the same thing on PC RealPlayer. Realplayer on PC seem to work. But
it did not work staright away. First time it also failed. Closing the player
and starting it again, it started working. I'm not sure whether the failure
port informations are stored in temp files or in registry. I don't have a
specified set of operations to make the PC player to fail, but it does fail
once in a while. ( I disabled the
Tools->Preferences->Connection->Internet/Privacy cookies option. I noticed
that the cookies file had some ip address)
Attaching the ethereal traces for SymbiamMmf, splay and PC player (Failure
case).
Can someone shed more information on what is expected behaviour ?
Note: HELIX_FEATURE_SMARTERNETWORK is not enabled on SymbianMmf build.
Thanks,
Rajesh.
<> <> <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070112/41fcdd88/attachment.html
From rajesh.rathinasamy at nokia.com Fri Jan 12 14:10:52 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Fri Jan 12 15:01:24 2007
Subject: [Protocol-dev] FW:Transport switchover failure in case of
portblocking
In-Reply-To: <200701121822.l0CIMDvi008359@mgw-mx03.nokia.com>
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxlog.zip
Type: application/x-zip-compressed
Size: 14326 bytes
Desc: hxlog.zip
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070112/539e195d/hxlog-0001.bin
From bodimiki at gmail.com Thu Jan 18 10:17:00 2007
From: bodimiki at gmail.com (Bodi Miklos)
Date: Thu Jan 18 11:06:01 2007
Subject: [Protocol-dev] Producer Transport protocol
Message-ID: <32e9b37d0701181017m3a19f56bs9c73b781f6f0f051@mail.gmail.com>
Hi Everyone,
I'm trying to write a Symbian OS application, which sends streaming
content to Helix? Server Version 11.1 running on Windows. The
application would send H.263 or MPEG4 coded media to the server.
Could you write to me what is the transport protokoll of the messages
between the producer and the Helix Server?
I did not find documentation about this issue.
Could you send me a link where can I find a good documentation about
the used protocolls by the producer?
I tried out the Real Producer Basic 11 and the Real Producer Plus 8.5
(windows version) and catched the messages with ethereal, but it can
not decode them.
Best Regards,
Miki
--
B?di Mikl?s
From gwright at real.com Thu Jan 18 11:02:20 2007
From: gwright at real.com (Greg Wright)
Date: Thu Jan 18 11:51:02 2007
Subject: [Protocol-dev] Producer Transport protocol
In-Reply-To: <32e9b37d0701181017m3a19f56bs9c73b781f6f0f051@mail.gmail.com>
References: <32e9b37d0701181017m3a19f56bs9c73b781f6f0f051@mail.gmail.com>
Message-ID: <45AFC43C.6090704@real.com>
I think you would have better luck asking on the server-dev mailing
lists. A bunch of the server devs are on this list but I think they
monitor the server-dev one the most.
Also, the source code of the producer is available as well. You
could take a look there and see if that helps.
https://helix-producer.helixcommunity.org/
--greg.
Bodi Miklos wrote:
> Hi Everyone,
>
> I'm trying to write a Symbian OS application, which sends streaming
> content to Helix? Server Version 11.1 running on Windows. The
> application would send H.263 or MPEG4 coded media to the server.
>
> Could you write to me what is the transport protokoll of the messages
> between the producer and the Helix Server?
>
> I did not find documentation about this issue.
> Could you send me a link where can I find a good documentation about
> the used protocolls by the producer?
>
> I tried out the Real Producer Basic 11 and the Real Producer Plus 8.5
> (windows version) and catched the messages with ethereal, but it can
> not decode them.
>
> Best Regards,
> Miki
>
From bodimiki at gmail.com Thu Jan 18 12:05:42 2007
From: bodimiki at gmail.com (Bodi Miklos)
Date: Thu Jan 18 12:54:33 2007
Subject: [Protocol-dev] Producer Transport protocol
In-Reply-To: <45AFC43C.6090704@real.com>
References: <32e9b37d0701181017m3a19f56bs9c73b781f6f0f051@mail.gmail.com>
<45AFC43C.6090704@real.com>
Message-ID: <32e9b37d0701181205y33fafb6fqea561e4483d7bae4@mail.gmail.com>
Hi Greg,
Thanks for the quick answer.
I have alerady checked the helixcommunity site and checked out the
producer source, but I can not find the protokol realization in the
source.
There is no documentation in the source and I am not an expert coder
to understand it easily. Can you help where can I approximately find
it?
Maybe the check out from the cvs was not successful, because I only
have a container directory and I have some directories called
"symbian" and as far as I know only the player is ported to symbian
platform.
Thanks,
Miki
2007/1/18, Greg Wright :
> I think you would have better luck asking on the server-dev mailing
> lists. A bunch of the server devs are on this list but I think they
> monitor the server-dev one the most.
>
> Also, the source code of the producer is available as well. You
> could take a look there and see if that helps.
>
> https://helix-producer.helixcommunity.org/
>
> --greg.
>
>
>
> Bodi Miklos wrote:
> > Hi Everyone,
> >
> > I'm trying to write a Symbian OS application, which sends streaming
> > content to Helix? Server Version 11.1 running on Windows. The
> > application would send H.263 or MPEG4 coded media to the server.
> >
> > Could you write to me what is the transport protokoll of the messages
> > between the producer and the Helix Server?
> >
> > I did not find documentation about this issue.
> > Could you send me a link where can I find a good documentation about
> > the used protocolls by the producer?
> >
> > I tried out the Real Producer Basic 11 and the Real Producer Plus 8.5
> > (windows version) and catched the messages with ethereal, but it can
> > not decode them.
> >
> > Best Regards,
> > Miki
> >
>
>
--
B?di Mikl?s
From gbajaj at real.com Fri Jan 19 02:10:30 2007
From: gbajaj at real.com (Gaurav Bajaj)
Date: Fri Jan 19 02:59:36 2007
Subject: [Protocol-dev] Re: [Helix-client-dev] RTCP Goodbye
In-Reply-To: <45ADE482.6070107@real.com>
References: <200701120648.l0C6mFo6008463@maytag02.real.com>
<45ADE482.6070107@real.com>
Message-ID: <45B09916.4000409@real.com>
Hi,
The bug is not getting reprod after conducting several tests so far.
Test conducted so far are as follows:-
* live sesion disconnect between encoder/server
o Tried to repro this bug by not adding any code from my side
I just simply played a live session from server and at the
client end started playing the clip. After some time I terminated the
live session and the
server sent a RTCP BYE message to the client.
Once the client receive this message, it plays the clip for
few secs and then stops.
When I analyzed the logs, I observed
1. Client do get one or two packets in Transport Buffer's
Add/Insert() function that Server might have sent before the RTCP_BYE
message(expected)
2. Client plays the packets that are stored in the queue for
the renderer (expected)
3.There is no call of OnBuffering() as client does not
expect any more packet from the server
4. Then StreamDone is called and consequently TEAR_DOWN
message is sent to the server and finally
5. Player is stopped, and hence the presentation is closed
* Sent fake BYE packet but continue to receive data packets - client
contiunes to play as it should
o Done some modification in the code to repro the bug by
simulating the behavior of receiving RTCP_BYE by calling
"m_pDataTransport->getTransportBuffer(m_pDataTransport->m_streamNumber);"
from function RTCPBaseTransport::handlePacket()
o Client keeps on receiving and playing the packets until and
unless the client sends a RTSP_TEARDOWN message when the user exits the
App using 'q'.
* Sent fake bye packet and ignore any more incoming data packets -
client correctly stops and issues TEARDOWN as it should. This was
the recent test conducted, please find the RTSP conversation
attached along with Diff (modified code) and packet Logs
Thanks & Regards
Gaurav Bajaj
Gaurav Bajaj wrote:
> Hi Loretta,
>
> I have tried to repro this behavior, but could not get through
> Here are my steps:-
> I just simply played a live session from server and at the client end
> started playing the clip. After some time I terminated the live
> session and the server sent a RTCP BYE message to the client.
> Once the client receive this message, it plays the clip for few secs
> and then stops.
> When I analyzed the logs, I observed
> 1. Client do get one or two packets in Transport Buffer's Add/Insert()
> function that Server might have sent before the RTCP_BYE
> message(expected)
> 2. Client plays the packets that are stored in the queue for the
> renderer (expected)
> 3.There is no call of OnBuffering() as client does not expect any more
> packet from the server
> 4. Then StreamDone is called and consequently TEARDOWN message is sent
> to the server and finally
> 5. Player is stopped, and hence the presentation is closed.
> Please find the RTSP server-client conversation as well as the packet
> logs.
>
> Please provide me the contents with which you reprod the "*case 2*"* ,
> *so that I can work on this issue.
>
> Thanks & Regards
> Gaurav Bajaj
>
> Loretta Lamieri wrote:
>>
>> Hi thanks for the answer,
>>
>> But I need more information about the handling of RTCP BYE packet.
>>
>> We have identified two different cases:
>>
>> 1. *Stream of a media content with a finite duration (trace file
>> Stream1.cap)*
>>
>> * *In this case the TEARDOWN method is correctly sent by the client
>> after the reception of the RTCP BYE packet on both audio and video
>> stream
>>
>> 2. *Streaming of 1 minute of a mobile pay-TV channel* *(trace file
>> Stream2.cap)*
>>
>> * *In this case the RTCP packet is received after 1 minute of
>> streaming, but the client doesn?t send the TEARDOWN method even if
>> there is no RTP traffic. So the RTSP session remains erroneously
>> (from our point of view) active.
>>
>> We need to know the reasons why in the second case the TEARDOWN
>> method is not sent by the client after the reception of the RTCP BYE
>> packet.
>>
>> Thanks again
>>
>> Loretta Lamieri
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Jeff Ayars [mailto:jeffa@real.com]
>> *Sent:* Friday, January 05, 2007 7:42 AM
>> *To:* Loretta Lamieri; helix-client-dev@helixcommunity.org
>> *Subject:* Re: [Helix-client-dev] RTCP Goodbye
>>
>> At 10:21 PM 1/4/2007, Loretta Lamieri wrote:
>>
>> Hi again,
>> Im using your Helix DNA Client (Branch "hxclient_1_4_2_neptunex", to
>> test a streaming platform on a mobile phone environment.
>> I m trying to stream a media content that have a finite duration
>> (i.e. 1 minute) and at the end of the RTP stream I receive a RTCP BYE
>> packet from the streaming server instead of RTSP TEARDOWN.
>>
>> So, It seems that this packet is used to close the RTSP session.
>>
>>
>> No. It's used to signal the end of the RTP stream.
>>
>> Is it compliant to the RTSP rfc?
>>
>>
>> Yes. The client sends the TEARDOWN when it doesn't need the session
>> anymore. If it is in a state where it might re-play the stream, it is
>> a valid optimization to not send the TEARDOWN.
>>
>> If yes, how the client has to behave when it receives this kind of
>> packet?
>>
>>
>> It allows the client to know it has all of the packets for the
>> session. It can stop sending RTCP messages. It can know that the
>> network resources are free to setup another stream. It can do nothing.
>>
>> Does it must send a RTSP TEARDOWN to the streaming server?
>>
>>
>> No, only if the client knows it doesn't need the session with the
>> server anymore does it need to send the TEARDOWN
>>
>> JEff
>>
>>
>> Thanks
>> Loretta Lamieri
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
> ------------------------------------------------------------------------
>
> Simpleplayer is looking for the client core at .\clntcore.dll
> Starting play #1...
> Starting player 0...
> OnPosLength(0,0)
> OnPosLength(0,0)
> OnBegin(0)
> Player 0 beginning playback...
> OnPosLength(0,0)
> OnPresentationOpened()
> ----------------clip info--------------------
>
> 41157078 00912800 RTSPTransportBuffer::GetPacket
> 41157078 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 0)
>
> 41157093 00912800 RTSPTransportBuffer::GetPacket
> 41157093 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 0)
>
> 41157093 00912800 RTSPTransportBuffer::GetPacket
> 41157093 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 0)
>
> 41157125 00912800 RTSPTransportBuffer::GetPacket
> 41157125 009133E0 RTSPTransportBuffer::GetPacket
> 41157125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41157125 009133E0 RTSPTransportBuffer::Add pPacket=00921DB0
> 41157125 9415792 SPProtocol::HandlePacket pPacket=00000000OnBuffering(0, 0)
> ========Source 0========
> ====File Header====
> DefaultLicenseValue 0
> Height 144
> LatencyMode 0
> LiveStream 1
> StreamCount 2
> Width 176
> ====Stream 0====
> AvgBitRate 33901
> AvgPacketSize 418
> Duration 0
> FMTPprofile-level-id 8
> HasOutOfOrderTS 1
> Height 144
> LiveStream 1
> PostDecodeDelay 400
> Preroll 1000
> RtcpRRRate 1271
> RtcpRSRate 423
> RTPPayloadType 96
> SamplesPerSecond 90000
> StreamNumber 0
> Width 176
> ====Stream 1====
> AvgBitRate 12840
> AvgPacketSize 320
> Duration 0
> FMTPoctet-align 1
> HasOutOfOrderTS 1
> LiveStream 1
> PostDecodeDelay 1000
> Preroll 100
> RtcpRRRate 481
> RtcpRSRate 160
> RTPPayloadType 97
> SamplesPerSecond 8000
> StreamNumber 1
> ---------------------------------------------
>
> 41157125 00912800 RTSPTransportBuffer::GetPacket
> 41157125 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 0)
>
> 41157125 00912800 RTSPTransportBuffer::GetPacket
> 41157125 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 0)
>
> 41157156 00912800 RTSPTransportBuffer::GetPacket
> 41157156 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157156 00912800 RTSPTransportBuffer::GetPacket
> 41157156 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157187 00912800 RTSPTransportBuffer::GetPacket
> 41157187 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157203 00912800 RTSPTransportBuffer::GetPacket
> 41157203 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157218 00912800 RTSPTransportBuffer::GetPacket
> 41157218 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157234 00912800 RTSPTransportBuffer::GetPacket
> 41157234 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157250 00912800 RTSPTransportBuffer::GetPacket
> 41157250 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157265 00912800 RTSPTransportBuffer::GetPacket
> 41157265 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157281 00912800 RTSPTransportBuffer::GetPacket
> 41157281 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157281 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41157281 009133E0 RTSPTransportBuffer::Add pPacket=00922B50
> 41157296 00912800 RTSPTransportBuffer::GetPacket
> 41157296 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157296 00912800 RTSPTransportBuffer::GetPacket
> 41157296 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 9)
>
> 41157312 00912800 RTSPTransportBuffer::GetPacket
> 41157312 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 18)
>
> 41157328 00912800 RTSPTransportBuffer::GetPacket
> 41157328 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 18)
>
> 41157343 00912800 RTSPTransportBuffer::GetPacket
> 41157343 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 25)
>
> 41157359 00912800 RTSPTransportBuffer::GetPacket
> 41157359 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 26)
>
> 41157375 00912800 RTSPTransportBuffer::GetPacket
> 41157375 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 26)
>
> 41157390 00912800 RTSPTransportBuffer::GetPacket
> 41157390 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 27)
>
> 41157406 00912800 RTSPTransportBuffer::GetPacket
> 41157406 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 27)
>
> 41157421 00912800 RTSPTransportBuffer::GetPacket
> 41157421 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 28)
>
> 41157437 00912800 RTSPTransportBuffer::GetPacket
> 41157437 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 28)
>
> 41157453 00912800 RTSPTransportBuffer::GetPacket
> 41157453 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 29)
>
> 41157468 00912800 RTSPTransportBuffer::GetPacket
> 41157468 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 29)
>
> 41157468 00912800 RTSPTransportBuffer::GetPacket
> 41157468 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 30)
>
> 41157500 00912800 RTSPTransportBuffer::GetPacket
> 41157500 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 31)
>
> 41157500 00912800 RTSPTransportBuffer::GetPacket
> 41157500 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 31)
>
> 41157531 00912800 RTSPTransportBuffer::GetPacket
> 41157531 009133E0 RTSPTransportBuffer::GetPacket
> 41157531 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41157531 009133E0 RTSPTransportBuffer::Add pPacket=00924BF0OnBuffering(0, 32)
>
> 41157531 00912800 RTSPTransportBuffer::GetPacket
> 41157531 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 32)
>
> 41157531 00912800 RTSPTransportBuffer::GetPacket
> 41157531 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 32)
>
> 41157562 00912800 RTSPTransportBuffer::GetPacket
> 41157562 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 42)
>
> 41157562 00912800 RTSPTransportBuffer::GetPacket
> 41157562 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 42)
>
> 41157593 00912800 RTSPTransportBuffer::GetPacket
> 41157593 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 43)
>
> 41157593 00912800 RTSPTransportBuffer::GetPacket
> 41157593 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 43)
>
> 41157625 00912800 RTSPTransportBuffer::GetPacket
> 41157625 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 44)
>
> 41157625 00912800 RTSPTransportBuffer::GetPacket
> 41157625 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 44)
>
> 41157656 00912800 RTSPTransportBuffer::GetPacket
> 41157656 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 45)
>
> 41157656 00912800 RTSPTransportBuffer::GetPacket
> 41157656 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 45)
>
> 41157687 00912800 RTSPTransportBuffer::GetPacket
> 41157687 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 46)
>
> 41157687 00912800 RTSPTransportBuffer::GetPacket
> 41157687 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 46)
>
> 41157718 00912800 RTSPTransportBuffer::GetPacket
> 41157718 009133E0 RTSPTransportBuffer::GetPacket
> 41157718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41157718 009133E0 RTSPTransportBuffer::Add pPacket=00925480OnBuffering(0, 47)
>
> 41157718 00912800 RTSPTransportBuffer::GetPacket
> 41157718 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 47)
>
> 41157718 00912800 RTSPTransportBuffer::GetPacket
> 41157718 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 47)
>
> 41157750 00912800 RTSPTransportBuffer::GetPacket
> 41157750 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 58)
> OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 12170
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 12170
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 1243329
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 4
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 4
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 12170
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 12170
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 1243329
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 4
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 4
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 1242045
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 8806904
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 1
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 0
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 0
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 0
> Statistics.Player0.Source0.Stream0.Total30 : 0
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12170
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12170
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 1284
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 0
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 4
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 4
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 4
> Statistics.Player0.Source0.Stream1.Total30 : 4
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 4
> Statistics.Player0.Source0.Total30 : 4
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 4
> Statistics.Player0.Total30 : 4
> Statistics.StreamSwitchOccured : 0
>
> 41157750 00912800 RTSPTransportBuffer::GetPacket
> 41157750 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 58)
>
> 41157781 00912800 RTSPTransportBuffer::GetPacket
> 41157781 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 59)
>
> 41157781 00912800 RTSPTransportBuffer::GetPacket
> 41157781 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 59)
>
> 41157812 00912800 RTSPTransportBuffer::GetPacket
> 41157812 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 60)
>
> 41157812 00912800 RTSPTransportBuffer::GetPacket
> 41157812 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 60)
>
> 41157843 00912800 RTSPTransportBuffer::GetPacket
> 41157843 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 61)
>
> 41157843 00912800 RTSPTransportBuffer::GetPacket
> 41157843 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 61)
>
> 41157875 00912800 RTSPTransportBuffer::GetPacket
> 41157875 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 62)
>
> 41157875 00912800 RTSPTransportBuffer::GetPacket
> 41157875 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 62)
>
> 41157906 00912800 RTSPTransportBuffer::GetPacket
> 41157906 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 63)
>
> 41157906 00912800 RTSPTransportBuffer::GetPacket
> 41157906 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 63)
>
> 41157937 00912800 RTSPTransportBuffer::GetPacket
> 41157937 009133E0 RTSPTransportBuffer::GetPacket
> 41157937 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41157937 009133E0 RTSPTransportBuffer::Add pPacket=00928C70OnBuffering(0, 65)
>
> 41157937 00912800 RTSPTransportBuffer::GetPacket
> 41157937 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 65)
>
> 41157937 00912800 RTSPTransportBuffer::GetPacket
> 41157937 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 65)
>
> 41157968 00912800 RTSPTransportBuffer::GetPacket
> 41157968 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 74)
>
> 41157968 00912800 RTSPTransportBuffer::GetPacket
> 41157968 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 74)
>
> 41158000 00912800 RTSPTransportBuffer::GetPacket
> 41158000 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 76)
>
> 41158000 00912800 RTSPTransportBuffer::GetPacket
> 41158000 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 76)
>
> 41158031 00912800 RTSPTransportBuffer::GetPacket
> 41158031 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 77)
>
> 41158031 00912800 RTSPTransportBuffer::GetPacket
> 41158031 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 77)
>
> 41158062 00912800 RTSPTransportBuffer::GetPacket
> 41158062 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 78)
>
> 41158062 00912800 RTSPTransportBuffer::GetPacket
> 41158062 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 78)
>
> 41158093 00912800 RTSPTransportBuffer::GetPacket
> 41158093 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 79)
>
> 41158093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41158093 009133E0 RTSPTransportBuffer::Add pPacket=00928DA0
> 41158093 00912800 RTSPTransportBuffer::GetPacket
> 41158093 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 79)
>
> 41158093 00912800 RTSPTransportBuffer::GetPacket
> 41158093 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 79)
>
> 41158125 00912800 RTSPTransportBuffer::GetPacket
> 41158125 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 85)
>
> 41158125 00912800 RTSPTransportBuffer::GetPacket
> 41158125 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 85)
>
> 41158156 00912800 RTSPTransportBuffer::GetPacket
> 41158156 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 86)
>
> 41158156 00912800 RTSPTransportBuffer::GetPacket
> 41158156 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 86)
>
> 41158187 00912800 RTSPTransportBuffer::GetPacket
> 41158187 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 87)
>
> 41158187 00912800 RTSPTransportBuffer::GetPacket
> 41158187 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 87)
>
> 41158218 00912800 RTSPTransportBuffer::GetPacket
> 41158218 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 88)
>
> 41158218 00912800 RTSPTransportBuffer::GetPacket
> 41158218 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 88)
>
> 41158250 00912800 RTSPTransportBuffer::GetPacket
> 41158250 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 89)
>
> 41158250 00912800 RTSPTransportBuffer::GetPacket
> 41158250 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 90)
>
> 41158281 00912800 RTSPTransportBuffer::GetPacket
> 41158281 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 90)
>
> 41158281 00912800 RTSPTransportBuffer::GetPacket
> 41158281 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 91)
>
> 41158312 00912800 RTSPTransportBuffer::GetPacket
> 41158312 009133E0 RTSPTransportBuffer::GetPacket
> 41158312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41158312 009133E0 RTSPTransportBuffer::Add pPacket=0092A6F0OnBuffering(0, 92)
>
> 41158312 00912800 RTSPTransportBuffer::GetPacket
> 41158312 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 92)
>
> 41158312 00912800 RTSPTransportBuffer::GetPacket
> 41158312 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 92)
>
> 41158343 00912800 RTSPTransportBuffer::GetPacket
> 41158343 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 93)
>
> 41158343 00912800 RTSPTransportBuffer::GetPacket
> 41158343 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 93)
>
> 41158375 00912800 RTSPTransportBuffer::GetPacket
> 41158375 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 94)
>
> 41158375 00912800 RTSPTransportBuffer::GetPacket
> 41158375 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 94)
>
> 41158406 00912800 RTSPTransportBuffer::GetPacket
> 41158406 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 95)
>
> 41158406 00912800 RTSPTransportBuffer::GetPacket
> 41158406 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 95)
>
> 41158437 00912800 RTSPTransportBuffer::GetPacket
> 41158437 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 96)
>
> 41158437 00912800 RTSPTransportBuffer::GetPacket
> 41158437 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 96)
>
> 41158468 00912800 RTSPTransportBuffer::GetPacket
> 41158468 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 97)
>
> 41158468 00912800 RTSPTransportBuffer::GetPacket
> 41158468 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 97)
>
> 41158500 00912800 RTSPTransportBuffer::GetPacket
> 41158500 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 98)
>
> 41158500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41158500 009133E0 RTSPTransportBuffer::Add pPacket=0092CFB0
> 41158500 00912800 RTSPTransportBuffer::GetPacket
> 41158500 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 99)
>
> 41158500 00912800 RTSPTransportBuffer::GetPacket
> 41158500 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 99)
>
> 41158531 00912800 RTSPTransportBuffer::GetPacket
> 41158531 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 99)
>
> 41158531 00912800 RTSPTransportBuffer::GetPacket
> 41158531 009133E0 RTSPTransportBuffer::GetPacket OnBuffering(0, 99)
>
> 41158562 00912800 RTSPTransportBuffer::GetPacket OnBuffering(0, 100)
> OnPosLength(0,0)
>
> 41158562 00912800 RTSPTransportBuffer::GetPacket
> 41158593 00912800 RTSPTransportBuffer::GetPacket
> 41158593 00912800 RTSPTransportBuffer::GetPacket
> 41158625 00912800 RTSPTransportBuffer::GetPacket
> 41158625 00912800 RTSPTransportBuffer::GetPacket
> 41158656 00912800 RTSPTransportBuffer::GetPacket
> 41158656 00912800 RTSPTransportBuffer::GetPacket
> 41158687 00912800 RTSPTransportBuffer::GetPacket
> 41158687 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41158687 009133E0 RTSPTransportBuffer::Add pPacket=009283D0
> 41158687 00912800 RTSPTransportBuffer::GetPacket
> 41158718 00912800 RTSPTransportBuffer::GetPacket
> 41158718 00912800 RTSPTransportBuffer::GetPacket
> 41158750 00912800 RTSPTransportBuffer::GetPacket
> 41158750 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 12533
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 12840
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 9515336
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 9
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 9
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 12533
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 9515336
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 9
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 9
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 9512768
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 9383092
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 0
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 0
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 0
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 0
> Statistics.Player0.Source0.Stream0.Total30 : 0
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12533
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 1600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 9
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 9
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 9
> Statistics.Player0.Source0.Stream1.Total30 : 9
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 9
> Statistics.Player0.Source0.Total30 : 9
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 9
> Statistics.Player0.Total30 : 9
> Statistics.StreamSwitchOccured : 0
>
> 41158781 00912800 RTSPTransportBuffer::GetPacket
> 41158781 00912800 RTSPTransportBuffer::GetPacket
> 41158812 00912800 RTSPTransportBuffer::GetPacket
> 41158812 00912800 RTSPTransportBuffer::GetPacket
> 41158843 00912800 RTSPTransportBuffer::GetPacket
> 41158843 009133E0 RTSPTransportBuffer::GetPacket
> 41158843 00912800 RTSPTransportBuffer::GetPacket
> 41158843 00912800 RTSPTransportBuffer::GetPacket
> 41158875 00912800 RTSPTransportBuffer::GetPacket
> 41158875 00912800 RTSPTransportBuffer::GetPacket
> 41158906 00912800 RTSPTransportBuffer::GetPacket
> 41158906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41158906 009133E0 RTSPTransportBuffer::Add pPacket=0091E840
> 41158906 00912800 RTSPTransportBuffer::GetPacket
> 41158937 00912800 RTSPTransportBuffer::GetPacket
> 41158937 00912800 RTSPTransportBuffer::GetPacket
> 41158968 00912800 RTSPTransportBuffer::GetPacket
> 41158968 00912800 RTSPTransportBuffer::GetPacket
> 41159000 00912800 RTSPTransportBuffer::GetPacket
> 41159000 00912800 RTSPTransportBuffer::GetPacket
> 41159031 00912800 RTSPTransportBuffer::GetPacket
> 41159031 00912800 RTSPTransportBuffer::GetPacket
> 41159062 00912800 RTSPTransportBuffer::GetPacket
> 41159062 009133E0 RTSPTransportBuffer::GetPacket
> 41159062 00912800 RTSPTransportBuffer::GetPacket
> 41159062 00912800 RTSPTransportBuffer::GetPacket
> 41159093 00912800 RTSPTransportBuffer::GetPacket
> 41159093 00912800 RTSPTransportBuffer::GetPacket
> 41159125 00912800 RTSPTransportBuffer::GetPacket
> 41159125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41159125 009133E0 RTSPTransportBuffer::Add pPacket=0091FA60
> 41159125 00912800 RTSPTransportBuffer::GetPacket
> 41159156 00912800 RTSPTransportBuffer::GetPacket
> 41159156 00912800 RTSPTransportBuffer::GetPacket
> 41159187 00912800 RTSPTransportBuffer::GetPacket
> 41159187 00912800 RTSPTransportBuffer::GetPacket
> 41159218 00912800 RTSPTransportBuffer::GetPacket
> 41159218 00912800 RTSPTransportBuffer::GetPacket
> 41159250 00912800 RTSPTransportBuffer::GetPacket
> 41159250 009133E0 RTSPTransportBuffer::GetPacket
> 41159250 00912800 RTSPTransportBuffer::GetPacket
> 41159250 00912800 RTSPTransportBuffer::GetPacket
> 41159281 00912800 RTSPTransportBuffer::GetPacket
> 41159281 00912800 RTSPTransportBuffer::GetPacket
> 41159312 00912800 RTSPTransportBuffer::GetPacket
> 41159312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41159312 009133E0 RTSPTransportBuffer::Add pPacket=008F0120
> 41159312 00912800 RTSPTransportBuffer::GetPacket
> 41159343 00912800 RTSPTransportBuffer::GetPacket
> 41159343 00912800 RTSPTransportBuffer::GetPacket
> 41159375 00912800 RTSPTransportBuffer::GetPacket
> 41159375 00912800 RTSPTransportBuffer::GetPacket
> 41159406 00912800 RTSPTransportBuffer::GetPacket
> 41159406 00912800 RTSPTransportBuffer::GetPacket
> 41159437 00912800 RTSPTransportBuffer::GetPacket
> 41159437 00912800 RTSPTransportBuffer::GetPacket
> 41159468 00912800 RTSPTransportBuffer::GetPacket
> 41159468 009133E0 RTSPTransportBuffer::GetPacket
> 41159468 00912800 RTSPTransportBuffer::GetPacket
> 41159468 00912800 RTSPTransportBuffer::GetPacket
> 41159500 00912800 RTSPTransportBuffer::GetPacket
> 41159500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41159500 009133E0 RTSPTransportBuffer::Add pPacket=00927B10
> 41159500 00912800 RTSPTransportBuffer::GetPacket
> 41159531 00912800 RTSPTransportBuffer::GetPacket
> 41159531 00912800 RTSPTransportBuffer::GetPacket
> 41159562 00912800 RTSPTransportBuffer::GetPacket
> 41159562 00912800 RTSPTransportBuffer::GetPacket
> 41159593 00912800 RTSPTransportBuffer::GetPacket
> 41159593 00912800 RTSPTransportBuffer::GetPacket
> 41159625 00912800 RTSPTransportBuffer::GetPacket
> 41159625 00912800 RTSPTransportBuffer::GetPacket
> 41159656 00912800 RTSPTransportBuffer::GetPacket
> 41159656 009133E0 RTSPTransportBuffer::GetPacket
> 41159656 00912800 RTSPTransportBuffer::GetPacket
> 41159656 00912800 RTSPTransportBuffer::GetPacket
> 41159687 00912800 RTSPTransportBuffer::GetPacket
> 41159687 00912800 RTSPTransportBuffer::GetPacket
> 41159718 00912800 RTSPTransportBuffer::GetPacket
> 41159718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41159718 009133E0 RTSPTransportBuffer::Add pPacket=00926F70
> 41159718 00912800 RTSPTransportBuffer::GetPacket
> 41159750 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 12641
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 12840
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 9515336
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 14
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 14
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 12641
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 9515336
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 14
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 14
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 9512768
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 9383092
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 0
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 0
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 0
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 0
> Statistics.Player0.Source0.Stream0.Total30 : 0
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12641
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 1200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 2600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 14
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 14
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 14
> Statistics.Player0.Source0.Stream1.Total30 : 14
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 14
> Statistics.Player0.Source0.Total30 : 14
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 14
> Statistics.Player0.Total30 : 14
> Statistics.StreamSwitchOccured : 0
>
> 41159750 00912800 RTSPTransportBuffer::GetPacket
> 41159781 00912800 RTSPTransportBuffer::GetPacket
> 41159781 00912800 RTSPTransportBuffer::GetPacket
> 41159812 00912800 RTSPTransportBuffer::GetPacket
> 41159812 00912800 RTSPTransportBuffer::GetPacket
> 41159843 00912800 RTSPTransportBuffer::GetPacket
> 41159843 009133E0 RTSPTransportBuffer::GetPacket
> 41159843 00912800 RTSPTransportBuffer::GetPacket
> 41159843 00912800 RTSPTransportBuffer::GetPacket
> 41159875 00912800 RTSPTransportBuffer::GetPacket
> 41159875 00912800 RTSPTransportBuffer::GetPacket
> 41159906 00912800 RTSPTransportBuffer::GetPacket
> 41159906 00912800 RTSPTransportBuffer::GetPacket
> 41159937 00912800 RTSPTransportBuffer::GetPacket
> 41159937 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41159937 009133E0 RTSPTransportBuffer::Add pPacket=00928F20
> 41159937 00912800 RTSPTransportBuffer::GetPacket
> 41159968 00912800 RTSPTransportBuffer::GetPacket
> 41159968 00912800 RTSPTransportBuffer::GetPacket
> 41160000 00912800 RTSPTransportBuffer::GetPacket
> 41160000 00912800 RTSPTransportBuffer::GetPacket
> 41160031 00912800 RTSPTransportBuffer::GetPacket
> 41160031 00912800 RTSPTransportBuffer::GetPacket
> 41160062 00912800 RTSPTransportBuffer::GetPacket
> 41160062 009133E0 RTSPTransportBuffer::GetPacket
> 41160062 00912800 RTSPTransportBuffer::GetPacket
> 41160062 00912800 RTSPTransportBuffer::GetPacket
> 41160093 00912800 RTSPTransportBuffer::GetPacket
> 41160093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41160093 009133E0 RTSPTransportBuffer::Add pPacket=00923B20
> 41160093 00912800 RTSPTransportBuffer::GetPacket
> 41160125 00912800 RTSPTransportBuffer::GetPacket
> 41160125 00912800 RTSPTransportBuffer::GetPacket
> 41160156 00912800 RTSPTransportBuffer::GetPacket
> 41160156 00912800 RTSPTransportBuffer::GetPacket
> 41160187 00912800 RTSPTransportBuffer::GetPacket
> 41160187 00912800 RTSPTransportBuffer::GetPacket
> 41160218 00912800 RTSPTransportBuffer::GetPacket
> 41160218 00912800 RTSPTransportBuffer::GetPacket
> 41160250 00912800 RTSPTransportBuffer::GetPacket
> 41160250 009133E0 RTSPTransportBuffer::GetPacket
> 41160250 00912800 RTSPTransportBuffer::GetPacket
> 41160250 00912800 RTSPTransportBuffer::GetPacket
> 41160281 00912800 RTSPTransportBuffer::GetPacket
> 41160281 00912800 RTSPTransportBuffer::GetPacket
> 41160312 00912800 RTSPTransportBuffer::GetPacket
> 41160312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41160312 009133E0 RTSPTransportBuffer::Add pPacket=0092F6B0
> 41160312 00912800 RTSPTransportBuffer::GetPacket
> 41160343 00912800 RTSPTransportBuffer::GetPacket
> 41160343 00912800 RTSPTransportBuffer::GetPacket
> 41160375 00912800 RTSPTransportBuffer::GetPacket
> 41160375 00912800 RTSPTransportBuffer::GetPacket
> 41160406 00912800 RTSPTransportBuffer::GetPacket
> 41160406 00912800 RTSPTransportBuffer::GetPacket
> 41160437 00912800 RTSPTransportBuffer::GetPacket
> 41160437 00912800 RTSPTransportBuffer::GetPacket
> 41160468 00912800 RTSPTransportBuffer::GetPacket
> 41160468 009133E0 RTSPTransportBuffer::GetPacket
> 41160468 00912800 RTSPTransportBuffer::GetPacket
> 41160468 00912800 RTSPTransportBuffer::GetPacket
> 41160500 00912800 RTSPTransportBuffer::GetPacket
> 41160500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41160500 009133E0 RTSPTransportBuffer::Add pPacket=00931CF0
> 41160500 00912800 RTSPTransportBuffer::GetPacket
> 41160531 00912800 RTSPTransportBuffer::GetPacket
> 41160531 00912800 RTSPTransportBuffer::GetPacket
> 41160562 00912800 RTSPTransportBuffer::GetPacket
> 41160562 00912800 RTSPTransportBuffer::GetPacket
> 41160593 00912800 RTSPTransportBuffer::GetPacket
> 41160593 00912800 RTSPTransportBuffer::GetPacket
> 41160625 00912800 RTSPTransportBuffer::GetPacket
> 41160625 00912800 RTSPTransportBuffer::GetPacket
> 41160656 00912800 RTSPTransportBuffer::GetPacket
> 41160656 009133E0 RTSPTransportBuffer::GetPacket
> 41160656 00912800 RTSPTransportBuffer::GetPacket
> 41160656 00912800 RTSPTransportBuffer::GetPacket
> 41160687 00912800 RTSPTransportBuffer::GetPacket
> 41160687 00912800 RTSPTransportBuffer::GetPacket
> 41160718 00912800 RTSPTransportBuffer::GetPacket
> 41160718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41160718 009133E0 RTSPTransportBuffer::Add pPacket=00931100
> 41160718 00912800 RTSPTransportBuffer::GetPacket
> 41160750 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 12693
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 12840
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 9515336
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 19
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 19
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 12693
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 9515336
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 19
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 19
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 9512768
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 9383092
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 0
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 0
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 0
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 0
> Statistics.Player0.Source0.Stream0.Total30 : 0
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12693
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 2200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 3600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 19
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 19
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 19
> Statistics.Player0.Source0.Stream1.Total30 : 19
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 19
> Statistics.Player0.Source0.Total30 : 19
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 19
> Statistics.Player0.Total30 : 19
> Statistics.StreamSwitchOccured : 0
>
> 41160750 00912800 RTSPTransportBuffer::GetPacket
> 41160781 00912800 RTSPTransportBuffer::GetPacket
> 41160781 00912800 RTSPTransportBuffer::GetPacket
> 41160812 00912800 RTSPTransportBuffer::GetPacket
> 41160812 00912800 RTSPTransportBuffer::GetPacket
> 41160843 00912800 RTSPTransportBuffer::GetPacket
> 41160843 009133E0 RTSPTransportBuffer::GetPacket
> 41160843 00912800 RTSPTransportBuffer::GetPacket
> 41160843 00912800 RTSPTransportBuffer::GetPacket
> 41160875 00912800 RTSPTransportBuffer::GetPacket
> 41160875 00912800 RTSPTransportBuffer::GetPacket
> 41160906 00912800 RTSPTransportBuffer::GetPacket
> 41160906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41160906 009133E0 RTSPTransportBuffer::Add pPacket=00933480
> 41160906 00912800 RTSPTransportBuffer::GetPacket
> 41160937 00912800 RTSPTransportBuffer::GetPacket
> 41160937 00912800 RTSPTransportBuffer::GetPacket
> 41160968 00912800 RTSPTransportBuffer::GetPacket
> 41160968 00912800 RTSPTransportBuffer::GetPacket
> 41161000 00912800 RTSPTransportBuffer::GetPacket
> 41161000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161000 00912800 RTSPTransportBuffer::Add pPacket=00935E10
> 41161000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161000 00912800 RTSPTransportBuffer::GetPacket
> 41161062 00912800 RTSPTransportBuffer::GetPacket
> 41161062 009133E0 RTSPTransportBuffer::GetPacket
> 41161062 00912800 RTSPTransportBuffer::GetPacket
> 41161062 00912800 RTSPTransportBuffer::GetPacket
> 41161093 00912800 RTSPTransportBuffer::GetPacket
> 41161093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161093 00912800 RTSPTransportBuffer::Add pPacket=00937AB0
> 41161093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161093 009133E0 RTSPTransportBuffer::Add pPacket=009379F0
> 41161093 00912800 RTSPTransportBuffer::GetPacket
> 41161093 00912800 RTSPTransportBuffer::GetPacket
> 41161312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161312 00912800 RTSPTransportBuffer::Add pPacket=00939B60
> 41161312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161312 009133E0 RTSPTransportBuffer::Add pPacket=00939A60
> 41161312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161312 00912800 RTSPTransportBuffer::Add pPacket=009396E0
> 41161312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161312 00912800 RTSPTransportBuffer::Add pPacket=009395E0
> 41161312 00912800 RTSPTransportBuffer::GetPacket
> 41161312 009133E0 RTSPTransportBuffer::GetPacket
> 41161312 00912800 RTSPTransportBuffer::GetPacket
> 41161312 00912800 RTSPTransportBuffer::GetPacket
> 41161343 00912800 RTSPTransportBuffer::GetPacket
> 41161343 00912800 RTSPTransportBuffer::GetPacket
> 41161375 00912800 RTSPTransportBuffer::GetPacket
> 41161375 00912800 RTSPTransportBuffer::GetPacket
> 41161406 00912800 RTSPTransportBuffer::GetPacket
> 41161406 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161406 00912800 RTSPTransportBuffer::Add pPacket=0093A300
> 41161406 00912800 RTSPTransportBuffer::GetPacket
> 41161468 00912800 RTSPTransportBuffer::GetPacket
> 41161468 009133E0 RTSPTransportBuffer::GetPacket
> 41161468 00912800 RTSPTransportBuffer::GetPacket
> 41161468 00912800 RTSPTransportBuffer::GetPacket
> 41161500 00912800 RTSPTransportBuffer::GetPacket
> 41161500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161500 00912800 RTSPTransportBuffer::Add pPacket=0093CB60
> 41161500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161500 009133E0 RTSPTransportBuffer::Add pPacket=0093CE40
> 41161500 00912800 RTSPTransportBuffer::GetPacket
> 41161562 00912800 RTSPTransportBuffer::GetPacket
> 41161562 00912800 RTSPTransportBuffer::GetPacket
> 41161593 00912800 RTSPTransportBuffer::GetPacket
> 41161593 00912800 RTSPTransportBuffer::GetPacket
> 41161609 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161609 00912800 RTSPTransportBuffer::Add pPacket=0093D430
> 41161625 00912800 RTSPTransportBuffer::GetPacket
> 41161656 009133E0 RTSPTransportBuffer::GetPacket
> 41161656 00912800 RTSPTransportBuffer::GetPacket
> 41161656 00912800 RTSPTransportBuffer::GetPacket
> 41161656 00912800 RTSPTransportBuffer::GetPacket
> 41161687 00912800 RTSPTransportBuffer::GetPacket
> 41161687 00912800 RTSPTransportBuffer::GetPacket
> 41161718 00912800 RTSPTransportBuffer::GetPacket
> 41161718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161718 00912800 RTSPTransportBuffer::Add pPacket=0093E890
> 41161718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161718 009133E0 RTSPTransportBuffer::Add pPacket=0093EE40
> 41161718 00912800 RTSPTransportBuffer::GetPacket
> 41161750 00912800 RTSPTransportBuffer::GetPacket
> 41161750 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 19454
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 45656
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 6670
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 33
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 33
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 19454
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 45656
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 6670
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 33
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 33
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 6731
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 32816
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 4102
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 3900
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 4600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 9
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 9
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 9
> Statistics.Player0.Source0.Stream0.Total30 : 9
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12723
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 3200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 4600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 24
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 24
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 24
> Statistics.Player0.Source0.Stream1.Total30 : 24
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 33
> Statistics.Player0.Source0.Total30 : 33
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 33
> Statistics.Player0.Total30 : 33
> Statistics.StreamSwitchOccured : 0
>
> 41161781 00912800 RTSPTransportBuffer::GetPacket
> 41161781 00912800 RTSPTransportBuffer::GetPacket
> 41161781 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161781 00912800 RTSPTransportBuffer::Add pPacket=00940CA0
> 41161812 00912800 RTSPTransportBuffer::GetPacket
> 41161843 009133E0 RTSPTransportBuffer::GetPacket
> 41161843 00912800 RTSPTransportBuffer::GetPacket
> 41161843 00912800 RTSPTransportBuffer::GetPacket
> 41161843 00912800 RTSPTransportBuffer::GetPacket
> 41161875 00912800 RTSPTransportBuffer::GetPacket
> 41161875 00912800 RTSPTransportBuffer::GetPacket
> 41161906 00912800 RTSPTransportBuffer::GetPacket
> 41161906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161906 00912800 RTSPTransportBuffer::Add pPacket=00940DB0
> 41161906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41161906 009133E0 RTSPTransportBuffer::Add pPacket=00940D40
> 41161906 00912800 RTSPTransportBuffer::GetPacket
> 41161968 00912800 RTSPTransportBuffer::GetPacket
> 41161968 00912800 RTSPTransportBuffer::GetPacket
> 41162000 00912800 RTSPTransportBuffer::GetPacket
> 41162000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162000 00912800 RTSPTransportBuffer::Add pPacket=00941EF0
> 41162000 00912800 RTSPTransportBuffer::GetPacket
> 41162062 00912800 RTSPTransportBuffer::GetPacket
> 41162062 009133E0 RTSPTransportBuffer::GetPacket
> 41162062 00912800 RTSPTransportBuffer::GetPacket
> 41162062 00912800 RTSPTransportBuffer::GetPacket
> 41162093 00912800 RTSPTransportBuffer::GetPacket
> 41162093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162093 00912800 RTSPTransportBuffer::Add pPacket=00943040
> 41162093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162093 009133E0 RTSPTransportBuffer::Add pPacket=00944BE0
> 41162093 00912800 RTSPTransportBuffer::GetPacket
> 41162156 00912800 RTSPTransportBuffer::GetPacket
> 41162171 00912800 RTSPTransportBuffer::GetPacket
> 41162187 00912800 RTSPTransportBuffer::GetPacket
> 41162203 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162203 00912800 RTSPTransportBuffer::Add pPacket=009448F0
> 41162203 00912800 RTSPTransportBuffer::GetPacket
> 41162250 00912800 RTSPTransportBuffer::GetPacket
> 41162250 009133E0 RTSPTransportBuffer::GetPacket
> 41162250 00912800 RTSPTransportBuffer::GetPacket
> 41162265 00912800 RTSPTransportBuffer::GetPacket
> 41162281 00912800 RTSPTransportBuffer::GetPacket
> 41162296 00912800 RTSPTransportBuffer::GetPacket
> 41162312 00912800 RTSPTransportBuffer::GetPacket
> 41162328 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162328 00912800 RTSPTransportBuffer::Add pPacket=00946D00
> 41162328 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162328 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162328 009133E0 RTSPTransportBuffer::Add pPacket=00945F70
> 41162328 00912800 RTSPTransportBuffer::GetPacket
> 41162343 00912800 RTSPTransportBuffer::GetPacket
> 41162359 00912800 RTSPTransportBuffer::GetPacket
> 41162375 00912800 RTSPTransportBuffer::GetPacket
> 41162390 00912800 RTSPTransportBuffer::GetPacket
> 41162406 00912800 RTSPTransportBuffer::GetPacket
> 41162421 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162421 00912800 RTSPTransportBuffer::Add pPacket=00946D90
> 41162421 00912800 RTSPTransportBuffer::GetPacket
> 41162453 009133E0 RTSPTransportBuffer::GetPacket
> 41162453 00912800 RTSPTransportBuffer::GetPacket
> 41162453 00912800 RTSPTransportBuffer::GetPacket
> 41162468 00912800 RTSPTransportBuffer::GetPacket
> 41162484 00912800 RTSPTransportBuffer::GetPacket
> 41162500 00912800 RTSPTransportBuffer::GetPacket
> 41162515 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162515 00912800 RTSPTransportBuffer::Add pPacket=00936BF0
> 41162515 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162515 009133E0 RTSPTransportBuffer::Add pPacket=00932FB0
> 41162515 00912800 RTSPTransportBuffer::GetPacket
> 41162546 00912800 RTSPTransportBuffer::GetPacket
> 41162562 00912800 RTSPTransportBuffer::GetPacket
> 41162578 00912800 RTSPTransportBuffer::GetPacket
> 41162593 00912800 RTSPTransportBuffer::GetPacket
> 41162609 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162609 00912800 RTSPTransportBuffer::Add pPacket=00937470
> 41162609 00912800 RTSPTransportBuffer::GetPacket
> 41162656 00912800 RTSPTransportBuffer::GetPacket
> 41162656 009133E0 RTSPTransportBuffer::GetPacket
> 41162656 00912800 RTSPTransportBuffer::GetPacket
> 41162671 00912800 RTSPTransportBuffer::GetPacket
> 41162687 00912800 RTSPTransportBuffer::GetPacket
> 41162703 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162703 00912800 RTSPTransportBuffer::Add pPacket=00948360
> 41162703 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162703 009133E0 RTSPTransportBuffer::Add pPacket=009482F0
> 41162703 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 25049
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 52763
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 9346
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 48
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 48
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 25049
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 52763
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 9346
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 48
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 48
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 12271
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 39715
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 6778
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 4200
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 5600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 19
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 19
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 19
> Statistics.Player0.Source0.Stream0.Total30 : 19
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12778
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 13048
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 4200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 5600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 29
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 29
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 29
> Statistics.Player0.Source0.Stream1.Total30 : 29
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 48
> Statistics.Player0.Source0.Total30 : 48
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 48
> Statistics.Player0.Total30 : 48
> Statistics.StreamSwitchOccured : 0
>
> 41162750 00912800 RTSPTransportBuffer::GetPacket
> 41162765 00912800 RTSPTransportBuffer::GetPacket
> 41162781 00912800 RTSPTransportBuffer::GetPacket
> 41162796 00912800 RTSPTransportBuffer::GetPacket
> 41162812 00912800 RTSPTransportBuffer::GetPacket
> 41162828 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162828 00912800 RTSPTransportBuffer::Add pPacket=009487B0
> 41162828 00912800 RTSPTransportBuffer::GetPacket
> 41162843 00912800 RTSPTransportBuffer::GetPacket
> 41162843 009133E0 RTSPTransportBuffer::GetPacket
> 41162843 00912800 RTSPTransportBuffer::GetPacket
> 41162859 00912800 RTSPTransportBuffer::GetPacket
> 41162875 00912800 RTSPTransportBuffer::GetPacket
> 41162890 00912800 RTSPTransportBuffer::GetPacket
> 41162906 00912800 RTSPTransportBuffer::GetPacket
> 41162921 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162921 00912800 RTSPTransportBuffer::Add pPacket=0094B940
> 41162921 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41162921 009133E0 RTSPTransportBuffer::Add pPacket=00949610
> 41162921 00912800 RTSPTransportBuffer::GetPacket
> 41162953 00912800 RTSPTransportBuffer::GetPacket
> 41162968 00912800 RTSPTransportBuffer::GetPacket
> 41162984 00912800 RTSPTransportBuffer::GetPacket
> 41163000 00912800 RTSPTransportBuffer::GetPacket
> 41163015 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163015 00912800 RTSPTransportBuffer::Add pPacket=00949BA0
> 41163015 00912800 RTSPTransportBuffer::GetPacket
> 41163046 009133E0 RTSPTransportBuffer::GetPacket
> 41163046 00912800 RTSPTransportBuffer::GetPacket
> 41163046 00912800 RTSPTransportBuffer::GetPacket
> 41163062 00912800 RTSPTransportBuffer::GetPacket
> 41163078 00912800 RTSPTransportBuffer::GetPacket
> 41163093 00912800 RTSPTransportBuffer::GetPacket
> 41163109 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163109 00912800 RTSPTransportBuffer::Add pPacket=0094CD80
> 41163109 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163109 009133E0 RTSPTransportBuffer::Add pPacket=0094B1C0
> 41163109 00912800 RTSPTransportBuffer::GetPacket
> 41163156 00912800 RTSPTransportBuffer::GetPacket
> 41163171 00912800 RTSPTransportBuffer::GetPacket
> 41163187 00912800 RTSPTransportBuffer::GetPacket
> 41163203 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163203 00912800 RTSPTransportBuffer::Add pPacket=0094D110
> 41163203 00912800 RTSPTransportBuffer::GetPacket
> 41163250 00912800 RTSPTransportBuffer::GetPacket
> 41163250 009133E0 RTSPTransportBuffer::GetPacket
> 41163250 00912800 RTSPTransportBuffer::GetPacket
> 41163265 00912800 RTSPTransportBuffer::GetPacket
> 41163281 00912800 RTSPTransportBuffer::GetPacket
> 41163296 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163296 00912800 RTSPTransportBuffer::Add pPacket=0094EE70
> 41163296 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163296 009133E0 RTSPTransportBuffer::Add pPacket=0094EE00
> 41163296 00912800 RTSPTransportBuffer::GetPacket
> 41163343 00912800 RTSPTransportBuffer::GetPacket
> 41163359 00912800 RTSPTransportBuffer::GetPacket
> 41163375 00912800 RTSPTransportBuffer::GetPacket
> 41163375 00912800 RTSPTransportBuffer::GetPacket
> 41163406 00912800 RTSPTransportBuffer::GetPacket
> 41163406 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163406 00912800 RTSPTransportBuffer::Add pPacket=0094F500
> 41163406 00912800 RTSPTransportBuffer::GetPacket
> 41163468 00912800 RTSPTransportBuffer::GetPacket
> 41163468 009133E0 RTSPTransportBuffer::GetPacket
> 41163468 00912800 RTSPTransportBuffer::GetPacket
> 41163468 00912800 RTSPTransportBuffer::GetPacket
> 41163500 00912800 RTSPTransportBuffer::GetPacket
> 41163500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163500 00912800 RTSPTransportBuffer::Add pPacket=00951830
> 41163500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163500 009133E0 RTSPTransportBuffer::Add pPacket=009517C0
> 41163500 00912800 RTSPTransportBuffer::GetPacket
> 41163562 00912800 RTSPTransportBuffer::GetPacket
> 41163562 00912800 RTSPTransportBuffer::GetPacket
> 41163593 00912800 RTSPTransportBuffer::GetPacket
> 41163593 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163593 00912800 RTSPTransportBuffer::Add pPacket=00951C00
> 41163593 00912800 RTSPTransportBuffer::GetPacket
> 41163656 00912800 RTSPTransportBuffer::GetPacket
> 41163656 009133E0 RTSPTransportBuffer::GetPacket
> 41163656 00912800 RTSPTransportBuffer::GetPacket
> 41163656 00912800 RTSPTransportBuffer::GetPacket
> 41163687 00912800 RTSPTransportBuffer::GetPacket
> 41163687 00912800 RTSPTransportBuffer::GetPacket
> 41163718 00912800 RTSPTransportBuffer::GetPacket
> 41163718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163718 00912800 RTSPTransportBuffer::Add pPacket=00952AC0
> 41163718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163718 009133E0 RTSPTransportBuffer::Add pPacket=00952A50
> 41163718 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 28744
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 50747
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 10381
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 63
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 63
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 28744
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 50747
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 10381
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 63
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 63
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 15927
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 37699
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 7813
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 5100
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 6600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 29
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 29
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 29
> Statistics.Player0.Source0.Stream0.Total30 : 29
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12817
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 13048
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 5200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 6600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 34
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 34
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 34
> Statistics.Player0.Source0.Stream1.Total30 : 34
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 63
> Statistics.Player0.Source0.Total30 : 63
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 63
> Statistics.Player0.Total30 : 63
> Statistics.StreamSwitchOccured : 0
>
> 41163750 00912800 RTSPTransportBuffer::GetPacket
> 41163750 00912800 RTSPTransportBuffer::GetPacket
> 41163781 00912800 RTSPTransportBuffer::GetPacket
> 41163781 00912800 RTSPTransportBuffer::GetPacket
> 41163812 00912800 RTSPTransportBuffer::GetPacket
> 41163812 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163812 00912800 RTSPTransportBuffer::Add pPacket=00954D60
> 41163812 00912800 RTSPTransportBuffer::GetPacket
> 41163843 00912800 RTSPTransportBuffer::GetPacket
> 41163843 009133E0 RTSPTransportBuffer::GetPacket
> 41163843 00912800 RTSPTransportBuffer::GetPacket
> 41163843 00912800 RTSPTransportBuffer::GetPacket
> 41163875 00912800 RTSPTransportBuffer::GetPacket
> 41163875 00912800 RTSPTransportBuffer::GetPacket
> 41163906 00912800 RTSPTransportBuffer::GetPacket
> 41163906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163906 00912800 RTSPTransportBuffer::Add pPacket=00955EC0
> 41163906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41163906 009133E0 RTSPTransportBuffer::Add pPacket=009542E0
> 41163906 00912800 RTSPTransportBuffer::GetPacket
> 41163968 00912800 RTSPTransportBuffer::GetPacket
> 41163968 00912800 RTSPTransportBuffer::GetPacket
> 41164000 00912800 RTSPTransportBuffer::GetPacket
> 41164000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164000 00912800 RTSPTransportBuffer::Add pPacket=00956FB0
> 41164000 00912800 RTSPTransportBuffer::GetPacket
> 41164062 00912800 RTSPTransportBuffer::GetPacket
> 41164062 009133E0 RTSPTransportBuffer::GetPacket
> 41164062 00912800 RTSPTransportBuffer::GetPacket
> 41164062 00912800 RTSPTransportBuffer::GetPacket
> 41164093 00912800 RTSPTransportBuffer::GetPacket
> 41164093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164093 00912800 RTSPTransportBuffer::Add pPacket=00928680
> 41164093 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164093 009133E0 RTSPTransportBuffer::Add pPacket=0091DCD0
> 41164093 00912800 RTSPTransportBuffer::GetPacket
> 41164156 00912800 RTSPTransportBuffer::GetPacket
> 41164156 00912800 RTSPTransportBuffer::GetPacket
> 41164187 00912800 RTSPTransportBuffer::GetPacket
> 41164187 00912800 RTSPTransportBuffer::GetPacket
> 41164218 00912800 RTSPTransportBuffer::GetPacket
> 41164218 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164218 00912800 RTSPTransportBuffer::Add pPacket=00934160
> 41164218 00912800 RTSPTransportBuffer::GetPacket
> 41164250 00912800 RTSPTransportBuffer::GetPacket
> 41164250 009133E0 RTSPTransportBuffer::GetPacket
> 41164250 00912800 RTSPTransportBuffer::GetPacket
> 41164250 00912800 RTSPTransportBuffer::GetPacket
> 41164281 00912800 RTSPTransportBuffer::GetPacket
> 41164281 00912800 RTSPTransportBuffer::GetPacket
> 41164312 00912800 RTSPTransportBuffer::GetPacket
> 41164312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164312 00912800 RTSPTransportBuffer::Add pPacket=009594A0
> 41164312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164312 009133E0 RTSPTransportBuffer::Add pPacket=00959430
> 41164312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164312 00912800 RTSPTransportBuffer::GetPacket
> 41164343 00912800 RTSPTransportBuffer::GetPacket
> 41164343 00912800 RTSPTransportBuffer::GetPacket
> 41164375 00912800 RTSPTransportBuffer::GetPacket
> 41164375 00912800 RTSPTransportBuffer::GetPacket
> 41164406 00912800 RTSPTransportBuffer::GetPacket
> 41164406 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164406 00912800 RTSPTransportBuffer::Add pPacket=00959060
> 41164406 00912800 RTSPTransportBuffer::GetPacket
> 41164484 00912800 RTSPTransportBuffer::GetPacket
> 41164484 009133E0 RTSPTransportBuffer::GetPacket
> 41164484 00912800 RTSPTransportBuffer::GetPacket
> 41164500 00912800 RTSPTransportBuffer::GetPacket
> 41164515 00912800 RTSPTransportBuffer::GetPacket
> 41164515 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164515 00912800 RTSPTransportBuffer::Add pPacket=0095A6C0
> 41164515 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164515 009133E0 RTSPTransportBuffer::Add pPacket=0095A440
> 41164531 00912800 RTSPTransportBuffer::GetPacket
> 41164546 00912800 RTSPTransportBuffer::GetPacket
> 41164562 00912800 RTSPTransportBuffer::GetPacket
> 41164578 00912800 RTSPTransportBuffer::GetPacket
> 41164593 00912800 RTSPTransportBuffer::GetPacket
> 41164609 00912800 RTSPTransportBuffer::GetPacket
> 41164609 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164609 00912800 RTSPTransportBuffer::Add pPacket=0095B2E0
> 41164625 00912800 RTSPTransportBuffer::GetPacket
> 41164656 009133E0 RTSPTransportBuffer::GetPacket
> 41164656 00912800 RTSPTransportBuffer::GetPacket
> 41164656 00912800 RTSPTransportBuffer::GetPacket
> 41164671 00912800 RTSPTransportBuffer::GetPacket
> 41164687 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164687 00912800 RTSPTransportBuffer::Add pPacket=0095C520
> 41164687 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164687 009133E0 RTSPTransportBuffer::Add pPacket=0095DEC0
> 41164687 00912800 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 31312
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 48888
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 9533
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 78
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 78
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 31312
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 48888
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 9533
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 78
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 78
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 18492
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 36048
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 6965
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 6200
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 7600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 39
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 39
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 39
> Statistics.Player0.Source0.Stream0.Total30 : 39
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12820
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 6200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 7600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 39
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 39
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 39
> Statistics.Player0.Source0.Stream1.Total30 : 39
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 78
> Statistics.Player0.Source0.Total30 : 78
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 78
> Statistics.Player0.Total30 : 78
> Statistics.StreamSwitchOccured : 0
>
> 41164750 00912800 RTSPTransportBuffer::GetPacket
> 41164765 00912800 RTSPTransportBuffer::GetPacket
> 41164781 00912800 RTSPTransportBuffer::GetPacket
> 41164796 00912800 RTSPTransportBuffer::GetPacket
> 41164812 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164812 00912800 RTSPTransportBuffer::Add pPacket=00960A40
> 41164812 00912800 RTSPTransportBuffer::GetPacket
> 41164843 009133E0 RTSPTransportBuffer::GetPacket
> 41164843 00912800 RTSPTransportBuffer::GetPacket
> 41164843 00912800 RTSPTransportBuffer::GetPacket
> 41164859 00912800 RTSPTransportBuffer::GetPacket
> 41164875 00912800 RTSPTransportBuffer::GetPacket
> 41164890 00912800 RTSPTransportBuffer::GetPacket
> 41164906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164906 00912800 RTSPTransportBuffer::Add pPacket=009610F0
> 41164906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41164906 009133E0 RTSPTransportBuffer::Add pPacket=00961080
> 41164906 00912800 RTSPTransportBuffer::GetPacket
> 41164953 00912800 RTSPTransportBuffer::GetPacket
> 41164968 00912800 RTSPTransportBuffer::GetPacket
> 41164984 00912800 RTSPTransportBuffer::GetPacket
> 41165000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165000 00912800 RTSPTransportBuffer::Add pPacket=00962B60
> 41165000 00912800 RTSPTransportBuffer::GetPacket
> 41165046 00912800 RTSPTransportBuffer::GetPacket
> 41165046 009133E0 RTSPTransportBuffer::GetPacket
> 41165046 00912800 RTSPTransportBuffer::GetPacket
> 41165062 00912800 RTSPTransportBuffer::GetPacket
> 41165078 00912800 RTSPTransportBuffer::GetPacket
> 41165093 00912800 RTSPTransportBuffer::GetPacket
> 41165109 00912800 RTSPTransportBuffer::GetPacket
> 41165109 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165109 00912800 RTSPTransportBuffer::Add pPacket=00963EC0
> 41165109 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165109 009133E0 RTSPTransportBuffer::Add pPacket=00964700
> 41165125 00912800 RTSPTransportBuffer::GetPacket
> 41165156 00912800 RTSPTransportBuffer::GetPacket
> 41165171 00912800 RTSPTransportBuffer::GetPacket
> 41165187 00912800 RTSPTransportBuffer::GetPacket
> 41165203 00912800 RTSPTransportBuffer::GetPacket
> 41165218 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165218 00912800 RTSPTransportBuffer::Add pPacket=009643C0
> 41165218 00912800 RTSPTransportBuffer::GetPacket
> 41165250 009133E0 RTSPTransportBuffer::GetPacket
> 41165250 00912800 RTSPTransportBuffer::GetPacket
> 41165250 00912800 RTSPTransportBuffer::GetPacket
> 41165265 00912800 RTSPTransportBuffer::GetPacket
> 41165531 00912800 RTSPTransportBuffer::GetPacket
> 41165531 009133E0 RTSPTransportBuffer::GetPacket
> 41165531 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165531 00912800 RTSPTransportBuffer::Add pPacket=009679A0
> 41165531 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165531 009133E0 RTSPTransportBuffer::Add pPacket=009678F0
> 41165531 00912800 RTSPTransportBuffer::GetPacket
> 41165531 009133E0 RTSPTransportBuffer::GetPacket
> 41165546 00912800 RTSPTransportBuffer::GetPacket
> 41165546 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165546 00912800 RTSPTransportBuffer::Add pPacket=0095C490
> 41165546 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165546 009133E0 RTSPTransportBuffer::Add pPacket=0095EAD0
> 41165546 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165546 00912800 RTSPTransportBuffer::Add pPacket=0095E9D0
> 41165562 00912800 RTSPTransportBuffer::GetPacket
> 41165562 00912800 RTSPTransportBuffer::GetPacket
> 41165562 00912800 RTSPTransportBuffer::GetPacket
> 41165562 00912800 RTSPTransportBuffer::GetPacket
> 41165593 00912800 RTSPTransportBuffer::GetPacket
> 41165593 00912800 RTSPTransportBuffer::GetPacket
> 41165625 00912800 RTSPTransportBuffer::GetPacket
> 41165625 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165625 00912800 RTSPTransportBuffer::Add pPacket=0095E0E0
> 41165625 00912800 RTSPTransportBuffer::GetPacket
> 41165656 00912800 RTSPTransportBuffer::GetPacket
> 41165656 009133E0 RTSPTransportBuffer::GetPacket
> 41165656 00912800 RTSPTransportBuffer::GetPacket
> 41165656 00912800 RTSPTransportBuffer::GetPacket
> 41165687 00912800 RTSPTransportBuffer::GetPacket
> 41165687 00912800 RTSPTransportBuffer::GetPacket
> 41165718 00912800 RTSPTransportBuffer::GetPacket
> 41165718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165718 00912800 RTSPTransportBuffer::Add pPacket=0095F750
> 41165718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165718 009133E0 RTSPTransportBuffer::Add pPacket=0095F6E0OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 30439
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 23592
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 6766
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 93
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 93
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 30439
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 23592
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 6766
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 93
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 93
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 17617
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 10752
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 4198
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 7100
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 8600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 49
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 49
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 49
> Statistics.Player0.Source0.Stream0.Total30 : 49
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12822
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 7200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 8600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 44
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 44
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 44
> Statistics.Player0.Source0.Stream1.Total30 : 44
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 93
> Statistics.Player0.Source0.Total30 : 93
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 93
> Statistics.Player0.Total30 : 93
> Statistics.StreamSwitchOccured : 0
>
> 41165718 00912800 RTSPTransportBuffer::GetPacket
> 41165750 00912800 RTSPTransportBuffer::GetPacket
> 41165750 00912800 RTSPTransportBuffer::GetPacket
> 41165781 00912800 RTSPTransportBuffer::GetPacket
> 41165781 00912800 RTSPTransportBuffer::GetPacket
> 41165812 00912800 RTSPTransportBuffer::GetPacket
> 41165812 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165812 00912800 RTSPTransportBuffer::Add pPacket=00968A00
> 41165812 00912800 RTSPTransportBuffer::GetPacket
> 41165843 00912800 RTSPTransportBuffer::GetPacket
> 41165843 009133E0 RTSPTransportBuffer::GetPacket
> 41165843 00912800 RTSPTransportBuffer::GetPacket
> 41165843 00912800 RTSPTransportBuffer::GetPacket
> 41165875 00912800 RTSPTransportBuffer::GetPacket
> 41165875 00912800 RTSPTransportBuffer::GetPacket
> 41165906 00912800 RTSPTransportBuffer::GetPacket
> 41165906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165906 00912800 RTSPTransportBuffer::Add pPacket=0096AAC0
> 41165906 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41165906 009133E0 RTSPTransportBuffer::Add pPacket=0096AA50
> 41165906 00912800 RTSPTransportBuffer::GetPacket
> 41165968 00912800 RTSPTransportBuffer::GetPacket
> 41165968 00912800 RTSPTransportBuffer::GetPacket
> 41166000 00912800 RTSPTransportBuffer::GetPacket
> 41166000 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166000 00912800 RTSPTransportBuffer::Add pPacket=00969AD0
> 41166000 00912800 RTSPTransportBuffer::GetPacket
> 41166062 00912800 RTSPTransportBuffer::GetPacket
> 41166062 009133E0 RTSPTransportBuffer::GetPacket
> 41166062 00912800 RTSPTransportBuffer::GetPacket
> 41166062 00912800 RTSPTransportBuffer::GetPacket
> 41166093 00912800 RTSPTransportBuffer::GetPacket
> 41166093 00912800 RTSPTransportBuffer::GetPacket
> 41166125 00912800 RTSPTransportBuffer::GetPacket
> 41166125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166125 00912800 RTSPTransportBuffer::Add pPacket=0096C940
> 41166125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166125 009133E0 RTSPTransportBuffer::Add pPacket=0096C8D0
> 41166125 00912800 RTSPTransportBuffer::GetPacket
> 41166125 00912800 RTSPTransportBuffer::GetPacket
> 41166125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166125 00912800 RTSPTransportBuffer::Add pPacket=0096C790
> 41166125 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166125 00912800 RTSPTransportBuffer::Add pPacket=0096C720
> 41166156 00912800 RTSPTransportBuffer::GetPacket
> 41166156 00912800 RTSPTransportBuffer::GetPacket
> 41166156 00912800 RTSPTransportBuffer::GetPacket
> 41166156 00912800 RTSPTransportBuffer::GetPacket
> 41166187 00912800 RTSPTransportBuffer::GetPacket
> 41166187 00912800 RTSPTransportBuffer::GetPacket
> 41166218 00912800 RTSPTransportBuffer::GetPacket
> 41166218 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166218 00912800 RTSPTransportBuffer::Add pPacket=0096C390
> 41166218 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166218 00912800 RTSPTransportBuffer::GetPacket
> 41166250 00912800 RTSPTransportBuffer::GetPacket
> 41166250 009133E0 RTSPTransportBuffer::GetPacket
> 41166250 00912800 RTSPTransportBuffer::GetPacket
> 41166250 00912800 RTSPTransportBuffer::GetPacket
> 41166281 00912800 RTSPTransportBuffer::GetPacket
> 41166281 00912800 RTSPTransportBuffer::GetPacket
> 41166312 00912800 RTSPTransportBuffer::GetPacket
> 41166312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166312 00912800 RTSPTransportBuffer::Add pPacket=0096DDD0
> 41166312 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166312 009133E0 RTSPTransportBuffer::Add pPacket=0096DD60
> 41166312 00912800 RTSPTransportBuffer::GetPacket
> 41166343 00912800 RTSPTransportBuffer::GetPacket
> 41166343 00912800 RTSPTransportBuffer::GetPacket
> 41166375 00912800 RTSPTransportBuffer::GetPacket
> 41166375 00912800 RTSPTransportBuffer::GetPacket
> 41166406 00912800 RTSPTransportBuffer::GetPacket
> 41166406 00912800 RTSPTransportBuffer::GetPacket
> 41166437 00912800 RTSPTransportBuffer::GetPacket
> 41166437 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166437 00912800 RTSPTransportBuffer::Add pPacket=0096E430
> 41166437 00912800 RTSPTransportBuffer::GetPacket
> 41166468 00912800 RTSPTransportBuffer::GetPacket
> 41166468 009133E0 RTSPTransportBuffer::GetPacket
> 41166468 00912800 RTSPTransportBuffer::GetPacket
> 41166468 00912800 RTSPTransportBuffer::GetPacket
> 41166500 00912800 RTSPTransportBuffer::GetPacket
> 41166500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166500 00912800 RTSPTransportBuffer::Add pPacket=00961D30
> 41166500 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166500 009133E0 RTSPTransportBuffer::Add pPacket=0091DD20
> 41166500 00912800 RTSPTransportBuffer::GetPacket
> 41166562 00912800 RTSPTransportBuffer::GetPacket
> 41166562 00912800 RTSPTransportBuffer::GetPacket
> 41166593 00912800 RTSPTransportBuffer::GetPacket
> 41166593 00912800 RTSPTransportBuffer::GetPacket
> 41166625 00912800 RTSPTransportBuffer::GetPacket
> 41166625 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166625 00912800 RTSPTransportBuffer::Add pPacket=00922B80
> 41166625 00912800 RTSPTransportBuffer::GetPacket
> 41166656 00912800 RTSPTransportBuffer::GetPacket
> 41166656 009133E0 RTSPTransportBuffer::GetPacket
> 41166656 00912800 RTSPTransportBuffer::GetPacket
> 41166656 00912800 RTSPTransportBuffer::GetPacket
> 41166687 00912800 RTSPTransportBuffer::GetPacket
> 41166687 00912800 RTSPTransportBuffer::GetPacket
> 41166718 00912800 RTSPTransportBuffer::GetPacket
> 41166718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166718 00912800 RTSPTransportBuffer::Add pPacket=02471BA0
> 41166718 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166718 009133E0 RTSPTransportBuffer::Add pPacket=02471670
> 41166718 9415792 SPProtocol::HandlePacket pPacket=00000000OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 32205
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 47824
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 7277
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 110
> Statistics.Player0.OutOfOrder : 0
> Statistics.Player0.Received : 110
> Statistics.Player0.Recovered : 0
> Statistics.Player0.ResendReceived : 0
> Statistics.Player0.ResendRequested : 0
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 32205
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 47824
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 7277
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 110
> Statistics.Player0.Source0.OutOfOrder : 0
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 110
> Statistics.Player0.Source0.Recovered : 0
> Statistics.Player0.Source0.ResendReceived : 0
> Statistics.Player0.Source0.ResendRequested : 0
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 19381
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 34984
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 4709
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 8100
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 9600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 61
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 61
> Statistics.Player0.Source0.Stream0.Recovered : 0
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 0
> Statistics.Player0.Source0.Stream0.ResendRequested : 0
> Statistics.Player0.Source0.Stream0.Total : 61
> Statistics.Player0.Source0.Stream0.Total30 : 61
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 12824
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 12840
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 8200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 9600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 49
> Statistics.Player0.Source0.Stream1.OutOfOrder : 0
> Statistics.Player0.Source0.Stream1.Received : 49
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 49
> Statistics.Player0.Source0.Stream1.Total30 : 49
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 110
> Statistics.Player0.Source0.Total30 : 110
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 110
> Statistics.Player0.Total30 : 110
> Statistics.StreamSwitchOccured : 0
>
> 41166718 00912800 RTSPTransportBuffer::GetPacket
> 41166750 00912800 RTSPTransportBuffer::GetPacket
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=02470170
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=02470100
> 41166750 00912800 RTSPTransportBuffer::GetPacket
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=02474900
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=02474890
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00911210 RTCPBaseTransport::handlePacket 1243256
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=024741B0
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=0 uStreamNumber=0
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00917820 RTCPBaseTransport::handlePacket 1243256
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=024738B0
> 41166750 00917B40 RTSPTransport::CheckForSourceDone m_bSourceDone=0 uStreamNumber=1
> 41166750 00917B40 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=1
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=024731B0
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=024744F0
> 41166750 00917B40 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=1
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00911210 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00917820 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=02474660
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=02474FB0
> 41166750 00917B40 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=1
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00911210 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00917820 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=02472040
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 009133E0 RTSPTransportBuffer::Add pPacket=02473290
> 41166750 00917B40 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=1
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00911210 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00917820 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=024745F0
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00911210 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> RTCP_BYE_RECEIVED
> 41166750 00917820 RTCPBaseTransport::handlePacket 1243256
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166750 00912800 RTSPTransportBuffer::Add pPacket=02474820
> 41166750 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166750 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166765 00912800 RTSPTransportBuffer::Add pPacket=024747B0
> 41166765 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166765 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166765 00912800 RTSPTransportBuffer::Add pPacket=02474740
> 41166765 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166765 9415792 SPProtocol::HandlePacket pPacket=00000000
> 41166765 00912800 RTSPTransportBuffer::Add pPacket=024746D0
> 41166765 00911530 RTSPTransport::CheckForSourceDone m_bSourceDone=1 uStreamNumber=0
> 41166843 00912800 RTSPTransportBuffer::GetPacket
> 41166843 009133E0 RTSPTransportBuffer::GetPacket
> 41166968 00912800 RTSPTransportBuffer::GetPacket
> 41167062 00912800 RTSPTransportBuffer::GetPacket
> 41167062 009133E0 RTSPTransportBuffer::GetPacket
> 41167156 00912800 RTSPTransportBuffer::GetPacket
> 41167250 00912800 RTSPTransportBuffer::GetPacket
> 41167250 009133E0 RTSPTransportBuffer::GetPacket
> 41167343 00912800 RTSPTransportBuffer::GetPacket
> 41167468 00912800 RTSPTransportBuffer::GetPacket
> 41167468 009133E0 RTSPTransportBuffer::GetPacket
> 41167562 00912800 RTSPTransportBuffer::GetPacket
> 41167656 00912800 RTSPTransportBuffer::GetPacket
> 41167656 009133E0 RTSPTransportBuffer::GetPacket OnStatisticsChanged():
> Statistics.EstimatedBandwidth : 10485800
> Statistics.Player0.Abstract : ""
> Statistics.Player0.Author : ""
> Statistics.Player0.AverageBandwidth : 0
> Statistics.Player0.AverageLatency : 0
> Statistics.Player0.BufferingMode : 0
> Statistics.Player0.ClipBandwidth : 46741
> Statistics.Player0.Copyright : ""
> Statistics.Player0.CurrentBandwidth : 0
> Statistics.Player0.Description : ""
> Statistics.Player0.Duplicate : 0
> Statistics.Player0.FilledBufferSize : 5293
> Statistics.Player0.FirstTimestamp : 0
> Statistics.Player0.HighLatency : 0
> Statistics.Player0.Keywords : ""
> Statistics.Player0.LastTimestamp : 0
> Statistics.Player0.Late : 0
> Statistics.Player0.Lost : 0
> Statistics.Player0.Lost30 : 0
> Statistics.Player0.LowLatency : 0
> Statistics.Player0.Normal : 120
> Statistics.Player0.OutOfOrder : 2
> Statistics.Player0.Received : 127
> Statistics.Player0.Recovered : 7
> Statistics.Player0.ResendReceived : 7
> Statistics.Player0.ResendRequested : 7
> Statistics.Player0.Source0.Abstract : ""
> Statistics.Player0.Source0.Author : ""
> Statistics.Player0.Source0.AverageBandwidth : 0
> Statistics.Player0.Source0.AverageLatency : 0
> Statistics.Player0.Source0.BufferingMode : 0
> Statistics.Player0.Source0.ClipBandwidth : 46741
> Statistics.Player0.Source0.Copyright : ""
> Statistics.Player0.Source0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Description : ""
> Statistics.Player0.Source0.Duplicate : 0
> Statistics.Player0.Source0.FilledBufferSize : 5293
> Statistics.Player0.Source0.FirstTimestamp : 0
> Statistics.Player0.Source0.HighLatency : 0
> Statistics.Player0.Source0.Keywords : ""
> Statistics.Player0.Source0.LastTimestamp : 0
> Statistics.Player0.Source0.Late : 0
> Statistics.Player0.Source0.Lost : 0
> Statistics.Player0.Source0.Lost30 : 0
> Statistics.Player0.Source0.LowLatency : 0
> Statistics.Player0.Source0.Normal : 120
> Statistics.Player0.Source0.OutOfOrder : 2
> Statistics.Player0.Source0.PerfectPlayAllowed : 1
> Statistics.Player0.Source0.Protocol : "RTSP"
> Statistics.Player0.Source0.ProtocolVersion : 0
> Statistics.Player0.Source0.Received : 127
> Statistics.Player0.Source0.Recovered : 7
> Statistics.Player0.Source0.ResendReceived : 7
> Statistics.Player0.Source0.ResendRequested : 7
> Statistics.Player0.Source0.ServerInfo : "Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)"
> Statistics.Player0.Source0.SourceName : "rtsp://192.168.1.249/broadcast/live.3gp"
> Statistics.Player0.Source0.Stream0.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream0.AverageLatency : 0
> Statistics.Player0.Source0.Stream0.ClipBandwidth : 33901
> Statistics.Player0.Source0.Stream0.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream0.Duplicate : 0
> Statistics.Player0.Source0.Stream0.FilledBufferSize : 2725
> Statistics.Player0.Source0.Stream0.FirstTimestamp : 9100
> Statistics.Player0.Source0.Stream0.HighLatency : 0
> Statistics.Player0.Source0.Stream0.LastTimestamp : 10600
> Statistics.Player0.Source0.Stream0.Late : 0
> Statistics.Player0.Source0.Stream0.Lost : 0
> Statistics.Player0.Source0.Stream0.Lost30 : 0
> Statistics.Player0.Source0.Stream0.LowLatency : 0
> Statistics.Player0.Source0.Stream0.MimeType : "video/MP4V-ES"
> Statistics.Player0.Source0.Stream0.Normal : 65
> Statistics.Player0.Source0.Stream0.OutOfOrder : 0
> Statistics.Player0.Source0.Stream0.Received : 72
> Statistics.Player0.Source0.Stream0.Recovered : 7
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.CodecFrameWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.CodecName : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.CurrentFrameRate : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.FailedBlts : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesDisplayed : "100.0"
> Statistics.Player0.Source0.Stream0.Renderer.FramesDropped : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesLost : 0
> Statistics.Player0.Source0.Stream0.Renderer.FramesUpsampled : "0.0"
> Statistics.Player0.Source0.Stream0.Renderer.ImageHeight : 144
> Statistics.Player0.Source0.Stream0.Renderer.ImageWidth : 176
> Statistics.Player0.Source0.Stream0.Renderer.Name : "MPEG-4 Video"
> Statistics.Player0.Source0.Stream0.Renderer.SureStream : "FALSE"
> Statistics.Player0.Source0.Stream0.Renderer.VideoSurfaceMode : 1
> Statistics.Player0.Source0.Stream0.ResendReceived : 7
> Statistics.Player0.Source0.Stream0.ResendRequested : 7
> Statistics.Player0.Source0.Stream0.Total : 72
> Statistics.Player0.Source0.Stream0.Total30 : 61
> Statistics.Player0.Source0.Stream1.AverageBandwidth : 0
> Statistics.Player0.Source0.Stream1.AverageLatency : 0
> Statistics.Player0.Source0.Stream1.ClipBandwidth : 12840
> Statistics.Player0.Source0.Stream1.CurrentBandwidth : 0
> Statistics.Player0.Source0.Stream1.Duplicate : 0
> Statistics.Player0.Source0.Stream1.FilledBufferSize : 2568
> Statistics.Player0.Source0.Stream1.FirstTimestamp : 9200
> Statistics.Player0.Source0.Stream1.HighLatency : 0
> Statistics.Player0.Source0.Stream1.LastTimestamp : 10600
> Statistics.Player0.Source0.Stream1.Late : 0
> Statistics.Player0.Source0.Stream1.Lost : 0
> Statistics.Player0.Source0.Stream1.Lost30 : 0
> Statistics.Player0.Source0.Stream1.LowLatency : 0
> Statistics.Player0.Source0.Stream1.MimeType : "audio/AMR"
> Statistics.Player0.Source0.Stream1.Normal : 55
> Statistics.Player0.Source0.Stream1.OutOfOrder : 2
> Statistics.Player0.Source0.Stream1.Received : 55
> Statistics.Player0.Source0.Stream1.Recovered : 0
> Statistics.Player0.Source0.Stream1.Renderer.BitsPerSample : 16
> Statistics.Player0.Source0.Stream1.Renderer.Channels : 1
> Statistics.Player0.Source0.Stream1.Renderer.CodecFourCC : "amrn"
> Statistics.Player0.Source0.Stream1.Renderer.CodecName : "AMR Narrow-band Audio"
> Statistics.Player0.Source0.Stream1.Renderer.Name : "MPEG-4 Audio"
> Statistics.Player0.Source0.Stream1.Renderer.SamplesPerSec : 8000
> Statistics.Player0.Source0.Stream1.ResendReceived : 0
> Statistics.Player0.Source0.Stream1.ResendRequested : 0
> Statistics.Player0.Source0.Stream1.Total : 55
> Statistics.Player0.Source0.Stream1.Total30 : 49
> Statistics.Player0.Source0.Title : ""
> Statistics.Player0.Source0.Total : 127
> Statistics.Player0.Source0.Total30 : 110
> Statistics.Player0.Source0.TransportMode : "UDP"
> Statistics.Player0.Title : ""
> Statistics.Player0.Total : 127
> Statistics.Player0.Total30 : 110
> Statistics.StreamSwitchOccured : 0
>
> 41167750 00912800 RTSPTransportBuffer::GetPacket
> 41167750 00911210 RTCPUDPTransport::streamDone streamNumber=0 m_bSendBye=1
> 41167906 008FA310 RTSPClientProtocol::SendTeardownRequest TEAR_DOWN Message SentOnStop()
> Player 0 stopped.
> Statistics.Player0.Normal = 120
> Statistics.Player0.Recovered = 7
> Statistics.Player0.Received = 127
> Statistics.Player0.Lost = 0
> Statistics.Player0.Late = 0
> Statistics.Player0.ClipBandwidth = 46741
> Statistics.Player0.AverageBandwidth = 0
> Statistics.Player0.CurrentBandwidth = 0
> OnPresentationClosed()
>
> 41167921 008EA910 HXPlayer::StopPlayer
>
> Playback complete. Stopping all players...
>
> 41167937 008EA910 HXPlayer::StopPlayer
>
> 41167937 008EA910 HXPlayer::StopPlayer
>
> 41167968 008EA910 HXPlayer::StopPlayer
>
> Done.
>
> ------------------------------------------------------------------------
>
> RTSPClientProtocol[008FA340]
> OUT:
> OPTIONS rtsp://192.168.1.249:554 RTSP/1.0
>
> CSeq: 1
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> Supported: ABD-1.0
>
> ClientChallenge: 51a911e73bc2662f7b55c51c29798b49
>
> ClientID: WinNT_5.1_10.0.0.9790_play32_RN01_EN_UNK
>
> CompanyID: U8LCakcYJu88yDh1pRvjcA==
>
> GUID: 00000000-0000-0000-0000-000000000000
>
> PlayerStarttime: [10/01/2007:21:19:53 05:00]
>
> Pragma: initiate-session
>
> RegionData: 0
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 1
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Supported: ABD-1.0
>
> Session: 10128-1;timeout=80
>
> Server: Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)
>
> Public: OPTIONS,DESCRIBE,ANNOUNCE,PLAY,PAUSE,SETUP,GET_PARAMETER,SET_PARAMETER,TEARDOWN
>
> TurboPlay: 1
>
> RealChallenge1: 20dfbda35067878eeb4cf0012c5128ad
>
> StatsMask: 8
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> DESCRIBE rtsp://192.168.1.249:554/broadcast/live.3gp RTSP/1.0
>
> CSeq: 2
>
> Accept: application/sdp
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> Session: 10128-1;timeout=80
>
> Bandwidth: 10485800
>
> ClientID: WinNT_5.1_10.0.0.9790_play32_RN01_EN_UNK
>
> GUID: 00000000-0000-0000-0000-000000000000
>
> Language: en-US
>
> RegionData: 0
>
> Require: com.real.retain-entity-for-setup
>
> SupportsMaximumASMBandwidth: 1
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 2
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
> Set-Cookie: cbid=gfcgdhjlmjgkcldmeorrpprtlrjrktlufkgjkidljjckelplosoropktrrmsktqpfkhjhhgi;path=/;expires=Thu,31-Dec-2037 23:59:59 GMT
>
> vsrc: http://192.168.1.249:80/viewsource/template.html?nuyhtgAirdz6b0z94eBxmjtgm0g6bfi058i7000000000000000000000000000000000000000000000000tBw4e4
>
> Content-base: rtsp://192.168.1.249:554/broadcast/live.3gp/
>
> ETag: 10128-1
>
> Session: 10128-1;timeout=80
>
> Vary: User-Agent,ClientID
>
> Content-type: application/sdp
>
> x-real-usestrackid: 1
>
> Content-length: 1981
>
>
>
> v=0
>
> o=- 281000 281000 IN IP4 192.168.1.249
>
> s=live.3gp
>
> i=
>
> c=IN IP4 0.0.0.0
>
> t=0 0
>
> a=SdpplinVersion:1610641560
>
> a=StreamCount:integer;2
>
> a=control:*
>
> a=DefaultLicenseValue:integer;0
>
> a=Height:integer;144
>
> a=LatencyMode:integer;0
>
> a=LiveStream:integer;1
>
> a=Width:integer;176
>
> a=FileType:string;"MPEG4"
>
> a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"
>
> a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIrAE////4I/wOBNgABQJhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVlFCS0FVZkF5UUF5UUFFRFNBUkFCSjFBQUNUcUFBQWs2Z0dFQUJFQUFGZmtBQUJYNUFnQUFBQUFBTUJLQUtmQXlRQVpRQUVEY2NWQUFBQUFBQUFBQUFBQUFBR0VBQkVBQUFmUUFBQlg1QWdBQUFBQUFNPQQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2kAAkBGZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTZ1RBcUJXMG1FRUg4QUFBQi9BQUFCRUtDS0NuNAQSAg0AACAAAAAAAAAAAAUDAABABgkBAAAAAAAAAAA="
>
> m=video 0 RTP/AVP 96
>
> b=AS:40
>
> b=RR:1271
>
> b=RS:423
>
> a=control:streamid=65335
>
> a=range:npt=0-
>
> a=length:npt=0
>
> a=rtpmap:96 MP4V-ES/90000
>
> a=fmtp:96 profile-level-id=8; config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F
>
> a=mimetype:string;"video/MP4V-ES"
>
> a=AvgBitRate:integer;33901
>
> a=AvgPacketSize:integer;418
>
> a=HasOutOfOrderTS:integer;1
>
> a=Height:integer;144
>
> a=LiveStream:integer;1
>
> a=Preroll:integer;1000
>
> a=Width:integer;176
>
> a=ASMRuleBook:string;"Marker=0,AverageBandwidth=33901,TimeStampDelivery=TRUE;Marker=1,AverageBandwidth=0,TimeStampDelivery=TRUE;"
>
> a=cliprect:0,0,144,176
>
> a=mpeg4-esid:201
>
> a=x-envivio-verid:00035A30
>
> m=audio 0 RTP/AVP 97
>
> b=AS:16
>
> b=RR:481
>
> b=RS:160
>
> a=control:streamid=65435
>
> a=range:npt=0-
>
> a=length:npt=0
>
> a=rtpmap:97 AMR/8000
>
> a=fmtp:97 octet-align=1
>
> a=mimetype:string;"audio/AMR"
>
> a=AvgBitRate:integer;12840
>
> a=AvgPacketSize:integer;320
>
> a=HasOutOfOrderTS:integer;1
>
> a=LiveStream:integer;1
>
> a=ASMRuleBook:string;"Marker=0,AverageBandwidth=12840,TimeStampDelivery=TRUE;Marker=1,AverageBandwidth=0,TimeStampDelivery=TRUE;"
>
> a=mpeg4-esid:101
>
> a=x-envivio-verid:00035A30
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> SETUP rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65335 RTSP/1.0
>
> CSeq: 3
>
> RealChallenge2: 7ac916d0c2104e9138959e9bd184cfe101d0a8e3, sd=71c439dc
>
> Transport: RTP/AVP;unicast;client_port=6970-6971;mode=play,RTP/AVP/TCP;unicast;mode=play
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> If-Match: 10128-1
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 3
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
> Reconnect: true
>
> RDTFeatureLevel: 0
>
> StatsMask: 8
>
> RealChallenge3: 9967f41b32d5c340923d30bce71a942a4f213d09,sdr=9f3c93e9
>
> Transport: RTP/AVP;unicast;client_port=6970-6971;server_port=27680-27681
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> SETUP rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65435 RTSP/1.0
>
> CSeq: 4
>
> Transport: RTP/AVP;unicast;client_port=6972-6973;mode=play
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> Session: 10128-1
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 4
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
> RDTFeatureLevel: 0
>
> StatsMask: 8
>
> Transport: RTP/AVP;unicast;client_port=6972-6973;server_port=18094-18095
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
>
> CSeq: 5
>
> Subscribe: stream=0;rule=0,stream=0;rule=1,stream=1;rule=0,stream=1;rule=1
>
> Session: 10128-1
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
>
> CSeq: 6
>
> SetDeliveryBandwidth: Bandwidth=186964;BackOff=0
>
> Session: 10128-1
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> PLAY rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
>
> CSeq: 7
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> Session: 10128-1
>
> Range: npt=0-
>
> Bandwidth: 10485800
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 5
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 6
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
>
>
>
> RTSPClientProtocol[008FA340]
> IN:
> RTSP/1.0 200 OK
>
> CSeq: 7
>
> Date: Wed,10 Jan 2007 15:49:53 GMT
>
> Session: 10128-1;timeout=80
>
> RTP-Info: url=rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65335;seq=0;rtptime=756000,url=rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65435;seq=0;rtptime=67200
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
>
> CSeq: 8
>
> Session: 10128-1
>
> PlayerStats: [Stat4:2 video/MP4V-ES|N/A|72|0|7|0|0|;audio/AMR|N/A|55|0|0|0|0| 1 1|186964|1437| 0 1 1797 9281 0 1506|0|2412]
>
>
>
>
> RTSPClientProtocol[008FA340]
> OUT:
> TEARDOWN rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
>
> CSeq: 9
>
> User-Agent: RealMedia Player HelixDNAClient/10.0.0.9790 (win32)
>
> Session: 10128-1
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>
-------------- next part --------------
Index: rtptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/rtptran.cpp,v
retrieving revision 1.88.2.10
diff -u -r1.88.2.10 rtptran.cpp
--- rtptran.cpp 19 Dec 2006 15:52:44 -0000 1.88.2.10
+++ rtptran.cpp 18 Jan 2007 12:29:04 -0000
@@ -2656,6 +2656,10 @@
m_pReportCallback(0),
m_bCallbackPending(FALSE),
m_reportTimeoutID(0),
+#ifdef _FAKE_BYE_PACKET
+ m_bByePacketFaked(FALSE),
+ m_ultimeup(HX_GET_TICKCOUNT()),
+#endif
m_bSchedulerStarted(FALSE),
m_bSendRTCP(TRUE),
m_bSSRCDetermined(FALSE),
@@ -3063,6 +3067,25 @@
// we need to deal with a compund packet
RTCPUnPacker unpacker;
+#ifdef _FAKE_BYE_PACKET
+ if(m_bByePacketFaked)
+ {
+ return HXR_OK;
+ }
+ if(!m_bByePacketFaked)
+ {
+ if( HX_GET_TICKCOUNT() > (m_ultimeup + 9000))
+ {
+ m_bByePacketFaked = TRUE;
+ printf("\n%lu\t%u\tTIME_UP\n\t\tInformSourceStopped Called Here", HX_GET_TICKCOUNT(), this);
+ RTSPTransportBuffer* pTransportBuffer =
+ m_pDataTransport->getTransportBuffer(m_pDataTransport->m_streamNumber);
+
+ pTransportBuffer->InformSourceStopped();
+ }
+
+ }
+#endif
if (HXR_OK != unpacker.UnPack(pBuffer))
{
// failed...don't do anything more...still ok to return HXR_OK;
@@ -3272,6 +3295,7 @@
{
DPRINTF(D_INFO, ("RTCP: BYE received\n"));
m_pReportHandler->OnRTCPReceive(pPkt, ulNow);
+ printf("\nRTCP_BYE_RECEIVED\n%lu\t%p\tRTCPBaseTransport::handlePacket\t%lu", HX_GET_TICKCOUNT(), this);
bBye = TRUE;
}
@@ -4092,7 +4116,7 @@
HX_ASSERT(streamNumber == m_streamNumber);
HX_ASSERT(streamNumber == m_pDataTransport->m_streamNumber);
-
+ printf("\n%lu\t%p\tRTCPUDPTransport::streamDone\tstreamNumber=%lu\tm_bSendBye=%lu\n", HX_GET_TICKCOUNT(), this, streamNumber, m_bSendBye);
// this will be called from RTPUDPTransport::streamDone();
if (m_bSendBye)
{
@@ -4341,6 +4365,7 @@
HX_ASSERT(streamNumber == m_pDataTransport->m_streamNumber);
// this will be called from RTPUDPTransport::streamDone();
+ printf("\n%lu\t%p\tRTCPTCPTransport::streamDone\tstreamNumber=%lu\tm_bSendBye=%lu\n", HX_GET_TICKCOUNT(), this, streamNumber, m_bSendBye);
if (m_bSendBye)
{
sendBye();
Index: pub/rtptran.h
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/pub/rtptran.h,v
retrieving revision 1.44.2.1
diff -u -r1.44.2.1 rtptran.h
--- pub/rtptran.h 15 Dec 2006 07:20:52 -0000 1.44.2.1
+++ pub/rtptran.h 18 Jan 2007 12:29:54 -0000
@@ -61,6 +61,8 @@
#include "tconverter.h"
#include "chxkeepalive.h"
#include "ihx3gpp.h"
+#define __TAKE_LOGS_
+#define _FAKE_BYE_PACKET
// GCC won't let me forward declare CHXMapLongToObj::Iterator,
// so I have to include this. -JR
@@ -576,7 +578,10 @@
CallbackHandle m_reportTimeoutID;
BOOL m_bSchedulerStarted;
BOOL m_bSendRTCP;
-
+#ifdef _FAKE_BYE_PACKET
+ UINT32 m_ultimeup;
+ BOOL m_bByePacketFaked;
+#endif
BOOL m_bSSRCDetermined;
UINT32 m_ulSSRCDetermined;
Index: rtsptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/rtsptran.cpp,v
retrieving revision 1.36.4.8
diff -u -r1.36.4.8 rtsptran.cpp
--- rtsptran.cpp 15 Dec 2006 07:00:49 -0000 1.36.4.8
+++ rtsptran.cpp 10 Jan 2007 14:18:58 -0000
@@ -1406,6 +1406,7 @@
void
RTSPTransport::CheckForSourceDone(UINT16 uStreamNumber)
{
+ printf("\n%lu\t%p\tRTSPTransport::CheckForSourceDone\tm_bSourceDone=%lu\tuStreamNumber=%lu", HX_GET_TICKCOUNT(), this, m_bSourceDone, uStreamNumber);
if (m_bSourceDone)
{
return;
Index: transbuf.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/transbuf.cpp,v
retrieving revision 1.20.6.8
diff -u -r1.20.6.8 transbuf.cpp
--- transbuf.cpp 21 Dec 2006 16:41:25 -0000 1.20.6.8
+++ transbuf.cpp 19 Jan 2007 07:12:52 -0000
@@ -132,7 +132,10 @@
m_bQueueIsEmpty(TRUE),
m_bStreamBegin(FALSE),
m_bStreamDone(FALSE),
+#ifdef _FAKE_BYE_PACKET
m_bSourceStopped(FALSE),
+#endif _FAKE_BYE_PACKET
+ m_bByeFakedInTransBuff(FALSE),
m_bACKDone(FALSE),
m_bStreamDoneSent(FALSE),
m_bPaused(FALSE),
@@ -376,6 +379,14 @@
HX_RESULT
RTSPTransportBuffer::Add(ClientPacket* pPacket)
{
+#ifdef _FAKE_BYE_PACKET
+ if(m_bSourceStopped)
+ {
+ printf("\n%lu\t%p\tRTSPTransportBuffer::Add\tReturned from ADD\n", HX_GET_TICKCOUNT(), this);
+ return HXR_OK;
+ }
+#endif
+ printf("\n%lu\t%p\tRTSPTransportBuffer::Add\tpPacket=%p", HX_GET_TICKCOUNT(), this, pPacket);
if (pPacket && !m_bFirstPacketAdd)
{
m_bFirstPacketAdd = TRUE;
@@ -578,6 +589,13 @@
RTSPTransportBuffer::Insert(ClientPacket* pPacket)
{
ClientPacket* tempPacket = NULL;
+#ifdef _FAKE_BYE_PACKET
+ if(m_bSourceStopped)
+ {
+ printf("\n%lu\t%p\tRTSPTransportBuffer::Add\tReturned from INSERT\N", HX_GET_TICKCOUNT(), this);
+ return HXR_OK;
+ }
+#endif
if (m_bQueueIsEmpty)
{
@@ -980,7 +998,7 @@
HX_RESULT rc = HXR_OK;
pPacket = NULL;
-
+ printf("\n%lu\t%p\tRTSPTransportBuffer::GetPacket\t\n", HX_GET_TICKCOUNT(), this);
if( m_bStreamDone )
{
HXLOGL4(HXLOG_TRAN, "RTSPTransportBuffer::GetPacket() StreamDone");
@@ -1496,6 +1514,9 @@
)
{
m_bSourceStopped = TRUE;
+#ifdef _FAKE_BYE_PACKET
+ m_bByeFakedInTransBuff = TRUE;
+#endif
}
void
Index: pub/transbuf.h
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/pub/transbuf.h,v
retrieving revision 1.9.6.3
diff -u -r1.9.6.3 transbuf.h
--- pub/transbuf.h 15 Dec 2006 07:10:05 -0000 1.9.6.3
+++ pub/transbuf.h 19 Jan 2007 07:17:22 -0000
@@ -57,7 +57,9 @@
#include "cachobj.h"
#include "hxthread.h"
-
+#ifndef _FAKE_BYE_PACKET
+#define _FAKE_BYE_PACKET
+#endif
class HX_deque;
class ClientPacket;
class RTSPTransport;
@@ -244,6 +246,9 @@
BOOL m_bStreamBegin;
BOOL m_bStreamDone;
BOOL m_bSourceStopped;
+#ifdef _FAKE_BYE_PACKET
+ BOOL m_bByeFakedInTransBuff;
+#endif
BOOL m_bACKDone;
BOOL m_bStreamDoneSent;
BOOL m_bPaused;
-------------- next part --------------
Simpleplayer is looking for the client core at .\clntcore.dll
----------------clip info--------------------
18827781 00912D10 RTSPTransportBuffer::GetPacket
18827781 0092CD50 RTSPTransportBuffer::GetPacket
18827796 00912D10 RTSPTransportBuffer::GetPacket
18827796 0092CD50 RTSPTransportBuffer::GetPacket
18827796 00912D10 RTSPTransportBuffer::GetPacket
18827796 0092CD50 RTSPTransportBuffer::GetPacket
18827828 00912D10 RTSPTransportBuffer::GetPacket
18827828 0092CD50 RTSPTransportBuffer::GetPacket
========Source 0========
====File Header====
DefaultLicenseValue 0
Height 144
LatencyMode 0
LiveStream 1
StreamCount 2
Width 176
====Stream 0====
AvgBitRate 33901
AvgPacketSize 418
Duration 0
FMTPprofile-level-id 8
HasOutOfOrderTS 1
Height 144
LiveStream 1
PostDecodeDelay 400
Preroll 1000
RtcpRRRate 1271
RtcpRSRate 423
RTPPayloadType 96
SamplesPerSecond 90000
StreamNumber 0
Width 176
====Stream 1====
AvgBitRate 12840
AvgPacketSize 320
Duration 0
FMTPoctet-align 1
HasOutOfOrderTS 1
LiveStream 1
PostDecodeDelay 1000
Preroll 100
RtcpRRRate 481
RtcpRSRate 160
RTPPayloadType 97
SamplesPerSecond 8000
StreamNumber 1
---------------------------------------------
18827828 00912D10 RTSPTransportBuffer::GetPacket
18827828 0092CD50 RTSPTransportBuffer::GetPacket
18827859 00912D10 RTSPTransportBuffer::GetPacket
18827859 0092CD50 RTSPTransportBuffer::GetPacket
18827890 00912D10 RTSPTransportBuffer::GetPacket
18827890 0092CD50 RTSPTransportBuffer::GetPacket
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 00912D10 RTSPTransportBuffer::Add pPacket=00907540
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 0092CD50 RTSPTransportBuffer::Add pPacket=00911B00
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 00912D10 RTSPTransportBuffer::GetPacket
18827906 0092CD50 RTSPTransportBuffer::GetPacket
18827906 0092CD50 RTSPTransportBuffer::GetPacket
18827906 00912D10 RTSPTransportBuffer::GetPacket
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 0092CD50 RTSPTransportBuffer::Add pPacket=00929310
18827906 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827906 0092CD50 RTSPTransportBuffer::Add pPacket=0092DB40
18827921 0092CD50 RTSPTransportBuffer::GetPacket
18827921 00912D10 RTSPTransportBuffer::GetPacket
18827921 00912D10 RTSPTransportBuffer::GetPacket
18827921 0092CD50 RTSPTransportBuffer::GetPacket
18827921 00912D10 RTSPTransportBuffer::GetPacket
18827921 0092CD50 RTSPTransportBuffer::GetPacket
18827921 00912D10 RTSPTransportBuffer::GetPacket
18827921 0092CD50 RTSPTransportBuffer::GetPacket
18827953 00912D10 RTSPTransportBuffer::GetPacket
18827953 0092CD50 RTSPTransportBuffer::GetPacket
18827953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827953 0092CD50 RTSPTransportBuffer::Add pPacket=00931B10
18827953 00912D10 RTSPTransportBuffer::GetPacket
18827953 0092CD50 RTSPTransportBuffer::GetPacket
18827953 00912D10 RTSPTransportBuffer::GetPacket
18827953 0092CD50 RTSPTransportBuffer::GetPacket
18827953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18827953 0092CD50 RTSPTransportBuffer::Add pPacket=00931AA0
18827984 00912D10 RTSPTransportBuffer::GetPacket
18827984 0092CD50 RTSPTransportBuffer::GetPacket
18827984 00912D10 RTSPTransportBuffer::GetPacket
18827984 0092CD50 RTSPTransportBuffer::GetPacket
18827984 00912D10 RTSPTransportBuffer::GetPacket
18827984 0092CD50 RTSPTransportBuffer::GetPacket
18828015 00912D10 RTSPTransportBuffer::GetPacket
18828015 0092CD50 RTSPTransportBuffer::GetPacket
18828015 00912D10 RTSPTransportBuffer::GetPacket
18828015 0092CD50 RTSPTransportBuffer::GetPacket
18828046 00912D10 RTSPTransportBuffer::GetPacket
18828046 0092CD50 RTSPTransportBuffer::GetPacket
18828046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828046 0092CD50 RTSPTransportBuffer::Add pPacket=00934080
18828046 00912D10 RTSPTransportBuffer::GetPacket
18828046 0092CD50 RTSPTransportBuffer::GetPacket
18828046 00912D10 RTSPTransportBuffer::GetPacket
18828046 0092CD50 RTSPTransportBuffer::GetPacket
18828046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828046 0092CD50 RTSPTransportBuffer::Add pPacket=00935470
18828046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828046 0092CD50 RTSPTransportBuffer::Add pPacket=00933170
18828078 00912D10 RTSPTransportBuffer::GetPacket
18828078 0092CD50 RTSPTransportBuffer::GetPacket
18828078 00912D10 RTSPTransportBuffer::GetPacket
18828078 0092CD50 RTSPTransportBuffer::GetPacket
18828078 00912D10 RTSPTransportBuffer::GetPacket
18828078 0092CD50 RTSPTransportBuffer::GetPacket
18828078 00912D10 RTSPTransportBuffer::GetPacket
18828078 0092CD50 RTSPTransportBuffer::GetPacket
18828109 00912D10 RTSPTransportBuffer::GetPacket
18828109 0092CD50 RTSPTransportBuffer::GetPacket
18828109 00912D10 RTSPTransportBuffer::GetPacket
18828109 0092CD50 RTSPTransportBuffer::GetPacket
18828140 00912D10 RTSPTransportBuffer::GetPacket
18828140 0092CD50 RTSPTransportBuffer::GetPacket
18828140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828140 0092CD50 RTSPTransportBuffer::Add pPacket=00938790
18828140 00912D10 RTSPTransportBuffer::GetPacket
18828140 0092CD50 RTSPTransportBuffer::GetPacket
18828140 00912D10 RTSPTransportBuffer::GetPacket
18828140 0092CD50 RTSPTransportBuffer::GetPacket
18828140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828140 0092CD50 RTSPTransportBuffer::Add pPacket=0093AFB0
18828171 00912D10 RTSPTransportBuffer::GetPacket
18828171 0092CD50 RTSPTransportBuffer::GetPacket
18828171 00912D10 RTSPTransportBuffer::GetPacket
18828171 0092CD50 RTSPTransportBuffer::GetPacket
18828171 00912D10 RTSPTransportBuffer::GetPacket
18828171 0092CD50 RTSPTransportBuffer::GetPacket
18828203 00912D10 RTSPTransportBuffer::GetPacket
18828203 0092CD50 RTSPTransportBuffer::GetPacket
18828203 00912D10 RTSPTransportBuffer::GetPacket
18828203 0092CD50 RTSPTransportBuffer::GetPacket
18828234 00912D10 RTSPTransportBuffer::GetPacket
18828234 0092CD50 RTSPTransportBuffer::GetPacket
18828234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828234 0092CD50 RTSPTransportBuffer::Add pPacket=009384B0
18828234 00912D10 RTSPTransportBuffer::GetPacket
18828234 0092CD50 RTSPTransportBuffer::GetPacket
18828234 00912D10 RTSPTransportBuffer::GetPacket
18828234 0092CD50 RTSPTransportBuffer::GetPacket
18828234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828234 0092CD50 RTSPTransportBuffer::Add pPacket=0093A040
18828234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828234 0092CD50 RTSPTransportBuffer::Add pPacket=0093BFB0
18828265 00912D10 RTSPTransportBuffer::GetPacket
18828265 0092CD50 RTSPTransportBuffer::GetPacket
18828265 00912D10 RTSPTransportBuffer::GetPacket
18828265 0092CD50 RTSPTransportBuffer::GetPacket
18828265 00912D10 RTSPTransportBuffer::GetPacket
18828265 0092CD50 RTSPTransportBuffer::GetPacket
18828265 00912D10 RTSPTransportBuffer::GetPacket
18828265 0092CD50 RTSPTransportBuffer::GetPacket
18828296 00912D10 RTSPTransportBuffer::GetPacket
18828296 0092CD50 RTSPTransportBuffer::GetPacket
18828296 00912D10 RTSPTransportBuffer::GetPacket
18828296 0092CD50 RTSPTransportBuffer::GetPacket
18828328 00912D10 RTSPTransportBuffer::GetPacket
18828328 0092CD50 RTSPTransportBuffer::GetPacket
18828328 00912D10 RTSPTransportBuffer::GetPacket
18828328 0092CD50 RTSPTransportBuffer::GetPacket
18828359 00912D10 RTSPTransportBuffer::GetPacket
18828359 0092CD50 RTSPTransportBuffer::GetPacket
18828359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828359 0092CD50 RTSPTransportBuffer::Add pPacket=00940130
18828359 00912D10 RTSPTransportBuffer::GetPacket
18828359 0092CD50 RTSPTransportBuffer::GetPacket
18828359 00912D10 RTSPTransportBuffer::GetPacket
18828359 0092CD50 RTSPTransportBuffer::GetPacket
18828359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828359 0092CD50 RTSPTransportBuffer::Add pPacket=00942AF0
18828390 00912D10 RTSPTransportBuffer::GetPacket
18828390 0092CD50 RTSPTransportBuffer::GetPacket
18828390 00912D10 RTSPTransportBuffer::GetPacket
18828390 0092CD50 RTSPTransportBuffer::GetPacket
18828390 00912D10 RTSPTransportBuffer::GetPacket
18828390 0092CD50 RTSPTransportBuffer::GetPacket
18828421 00912D10 RTSPTransportBuffer::GetPacket
18828421 0092CD50 RTSPTransportBuffer::GetPacket
18828421 00912D10 RTSPTransportBuffer::GetPacket
18828421 0092CD50 RTSPTransportBuffer::GetPacket
18828453 00912D10 RTSPTransportBuffer::GetPacket
18828453 0092CD50 RTSPTransportBuffer::GetPacket
18828453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828453 0092CD50 RTSPTransportBuffer::Add pPacket=00943500
18828453 00912D10 RTSPTransportBuffer::GetPacket
18828453 0092CD50 RTSPTransportBuffer::GetPacket
18828453 00912D10 RTSPTransportBuffer::GetPacket
18828453 0092CD50 RTSPTransportBuffer::GetPacket
18828484 00912D10 RTSPTransportBuffer::GetPacket
18828484 0092CD50 RTSPTransportBuffer::GetPacket
18828484 00912D10 RTSPTransportBuffer::GetPacket
18828484 0092CD50 RTSPTransportBuffer::GetPacket
18828515 00912D10 RTSPTransportBuffer::GetPacket
18828515 0092CD50 RTSPTransportBuffer::GetPacket
18828515 00912D10 RTSPTransportBuffer::GetPacket
18828515 0092CD50 RTSPTransportBuffer::GetPacket
18828546 00912D10 RTSPTransportBuffer::GetPacket
18828546 0092CD50 RTSPTransportBuffer::GetPacket
18828546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828546 0092CD50 RTSPTransportBuffer::Add pPacket=00945DD0
18828546 00912D10 RTSPTransportBuffer::GetPacket
18828546 0092CD50 RTSPTransportBuffer::GetPacket
18828546 00912D10 RTSPTransportBuffer::GetPacket
18828546 0092CD50 RTSPTransportBuffer::GetPacket
18828578 00912D10 RTSPTransportBuffer::GetPacket
18828578 0092CD50 RTSPTransportBuffer::GetPacket
18828578 00912D10 RTSPTransportBuffer::GetPacket
18828578 0092CD50 RTSPTransportBuffer::GetPacket
18828609 00912D10 RTSPTransportBuffer::GetPacket
18828609 0092CD50 RTSPTransportBuffer::GetPacket
18828609 00912D10 RTSPTransportBuffer::GetPacket
18828609 0092CD50 RTSPTransportBuffer::GetPacket
18828640 00912D10 RTSPTransportBuffer::GetPacket
18828640 0092CD50 RTSPTransportBuffer::GetPacket
18828640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828640 0092CD50 RTSPTransportBuffer::Add pPacket=00946510
18828640 00912D10 RTSPTransportBuffer::GetPacket
18828640 0092CD50 RTSPTransportBuffer::GetPacket
18828640 00912D10 RTSPTransportBuffer::GetPacket
18828640 0092CD50 RTSPTransportBuffer::GetPacket
18828671 00912D10 RTSPTransportBuffer::GetPacket
18828671 0092CD50 RTSPTransportBuffer::GetPacket
18828671 00912D10 RTSPTransportBuffer::GetPacket
18828671 0092CD50 RTSPTransportBuffer::GetPacket
18828703 00912D10 RTSPTransportBuffer::GetPacket
18828703 0092CD50 RTSPTransportBuffer::GetPacket
18828703 00912D10 RTSPTransportBuffer::GetPacket
18828703 0092CD50 RTSPTransportBuffer::GetPacket
18828734 00912D10 RTSPTransportBuffer::GetPacket
18828734 0092CD50 RTSPTransportBuffer::GetPacket
18828734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828734 0092CD50 RTSPTransportBuffer::Add pPacket=00948130
18828734 00912D10 RTSPTransportBuffer::GetPacket
18828734 0092CD50 RTSPTransportBuffer::GetPacket
18828734 00912D10 RTSPTransportBuffer::GetPacket
18828734 0092CD50 RTSPTransportBuffer::GetPacket
18828765 00912D10 RTSPTransportBuffer::GetPacket
18828765 0092CD50 RTSPTransportBuffer::GetPacket
18828765 00912D10 RTSPTransportBuffer::GetPacket
18828765 0092CD50 RTSPTransportBuffer::GetPacket
18828796 00912D10 RTSPTransportBuffer::GetPacket
18828796 0092CD50 RTSPTransportBuffer::GetPacket
18828796 00912D10 RTSPTransportBuffer::GetPacket
18828796 0092CD50 RTSPTransportBuffer::GetPacket
18828828 00912D10 RTSPTransportBuffer::GetPacket
18828828 0092CD50 RTSPTransportBuffer::GetPacket
18828828 00912D10 RTSPTransportBuffer::GetPacket
18828828 0092CD50 RTSPTransportBuffer::GetPacket
18828859 00912D10 RTSPTransportBuffer::GetPacket
18828859 0092CD50 RTSPTransportBuffer::GetPacket
18828859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828859 0092CD50 RTSPTransportBuffer::Add pPacket=00949440
18828859 00912D10 RTSPTransportBuffer::GetPacket
18828859 0092CD50 RTSPTransportBuffer::GetPacket
18828859 00912D10 RTSPTransportBuffer::GetPacket
18828859 0092CD50 RTSPTransportBuffer::GetPacket
18828890 00912D10 RTSPTransportBuffer::GetPacket
18828890 0092CD50 RTSPTransportBuffer::GetPacket
18828890 00912D10 RTSPTransportBuffer::GetPacket
18828890 0092CD50 RTSPTransportBuffer::GetPacket
18828921 00912D10 RTSPTransportBuffer::GetPacket
18828921 0092CD50 RTSPTransportBuffer::GetPacket
18828921 00912D10 RTSPTransportBuffer::GetPacket
18828921 0092CD50 RTSPTransportBuffer::GetPacket
18828953 00912D10 RTSPTransportBuffer::GetPacket
18828953 0092CD50 RTSPTransportBuffer::GetPacket
18828953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18828953 0092CD50 RTSPTransportBuffer::Add pPacket=0094BCF0
18828953 00912D10 RTSPTransportBuffer::GetPacket
18828953 0092CD50 RTSPTransportBuffer::GetPacket
18828953 00912D10 RTSPTransportBuffer::GetPacket
18828953 0092CD50 RTSPTransportBuffer::GetPacket
18828984 00912D10 RTSPTransportBuffer::GetPacket
18828984 0092CD50 RTSPTransportBuffer::GetPacket
18828984 00912D10 RTSPTransportBuffer::GetPacket
18828984 0092CD50 RTSPTransportBuffer::GetPacket
18829015 00912D10 RTSPTransportBuffer::GetPacket
18829015 0092CD50 RTSPTransportBuffer::GetPacket
18829015 00912D10 RTSPTransportBuffer::GetPacket
18829015 0092CD50 RTSPTransportBuffer::GetPacket
18829046 00912D10 RTSPTransportBuffer::GetPacket
18829046 0092CD50 RTSPTransportBuffer::GetPacket
18829046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829046 0092CD50 RTSPTransportBuffer::Add pPacket=0094C2F0
18829046 00912D10 RTSPTransportBuffer::GetPacket
18829046 0092CD50 RTSPTransportBuffer::GetPacket
18829046 00912D10 RTSPTransportBuffer::GetPacket
18829046 0092CD50 RTSPTransportBuffer::GetPacket
18829078 00912D10 RTSPTransportBuffer::GetPacket
18829078 0092CD50 RTSPTransportBuffer::GetPacket
18829078 00912D10 RTSPTransportBuffer::GetPacket
18829078 0092CD50 RTSPTransportBuffer::GetPacket
18829109 00912D10 RTSPTransportBuffer::GetPacket
18829109 0092CD50 RTSPTransportBuffer::GetPacket
18829109 00912D10 RTSPTransportBuffer::GetPacket
18829109 0092CD50 RTSPTransportBuffer::GetPacket
18829140 00912D10 RTSPTransportBuffer::GetPacket
18829140 0092CD50 RTSPTransportBuffer::GetPacket
18829140 00912D10 RTSPTransportBuffer::GetPacket
18829140 0092CD50 RTSPTransportBuffer::GetPacket
18829171 00912D10 RTSPTransportBuffer::GetPacket
18829171 0092CD50 RTSPTransportBuffer::GetPacket
18829171 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829171 0092CD50 RTSPTransportBuffer::Add pPacket=0094EA20
18829171 00912D10 RTSPTransportBuffer::GetPacket
18829171 0092CD50 RTSPTransportBuffer::GetPacket
18829171 00912D10 RTSPTransportBuffer::GetPacket
18829171 0092CD50 RTSPTransportBuffer::GetPacket
18829203 00912D10 RTSPTransportBuffer::GetPacket
18829203 0092CD50 RTSPTransportBuffer::GetPacket
18829203 00912D10 RTSPTransportBuffer::GetPacket
18829203 0092CD50 RTSPTransportBuffer::GetPacket
18829234 00912D10 RTSPTransportBuffer::GetPacket
18829234 0092CD50 RTSPTransportBuffer::GetPacket
18829234 00912D10 RTSPTransportBuffer::GetPacket
18829234 0092CD50 RTSPTransportBuffer::GetPacket
18829265 00912D10 RTSPTransportBuffer::GetPacket
18829265 0092CD50 RTSPTransportBuffer::GetPacket
18829265 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829265 0092CD50 RTSPTransportBuffer::Add pPacket=009517D0
18829265 00912D10 RTSPTransportBuffer::GetPacket
18829265 0092CD50 RTSPTransportBuffer::GetPacket
18829265 00912D10 RTSPTransportBuffer::GetPacket
18829265 0092CD50 RTSPTransportBuffer::GetPacket
18829296 00912D10 RTSPTransportBuffer::GetPacket
18829296 0092CD50 RTSPTransportBuffer::GetPacket
18829296 00912D10 RTSPTransportBuffer::GetPacket
18829296 0092CD50 RTSPTransportBuffer::GetPacket
18829328 00912D10 RTSPTransportBuffer::GetPacket
18829328 00912D10 RTSPTransportBuffer::GetPacket
18829359 00912D10 RTSPTransportBuffer::GetPacket
18829359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829359 0092CD50 RTSPTransportBuffer::Add pPacket=00951900
18829359 00912D10 RTSPTransportBuffer::GetPacket
18829390 00912D10 RTSPTransportBuffer::GetPacket
18829390 00912D10 RTSPTransportBuffer::GetPacket
18829421 00912D10 RTSPTransportBuffer::GetPacket
18829421 00912D10 RTSPTransportBuffer::GetPacket
18829437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829437 00912D10 RTSPTransportBuffer::Add pPacket=009531B0
18829437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829437 0092CD50 RTSPTransportBuffer::Add pPacket=00953B60
18829437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829437 00912D10 RTSPTransportBuffer::Add pPacket=00953AF0
18829437 00912D10 RTSPTransportBuffer::GetPacket
18829437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829437 00912D10 RTSPTransportBuffer::Add pPacket=00954FB0
18829562 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829562 00912D10 RTSPTransportBuffer::Add pPacket=00954AC0
18829562 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829562 0092CD50 RTSPTransportBuffer::Add pPacket=00954A50
18829640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829640 00912D10 RTSPTransportBuffer::Add pPacket=00954280
18829640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829640 0092CD50 RTSPTransportBuffer::Add pPacket=00954210
18829640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829640 00912D10 RTSPTransportBuffer::Add pPacket=009541A0
18829640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829640 00912D10 RTSPTransportBuffer::Add pPacket=00954130
18829734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829734 00912D10 RTSPTransportBuffer::Add pPacket=00955DE0
18829734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829734 00912D10 RTSPTransportBuffer::Add pPacket=00955D70
18829859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829859 0092CD50 RTSPTransportBuffer::Add pPacket=00955310
18829859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829859 00912D10 RTSPTransportBuffer::Add pPacket=009552A0
18829859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829859 0092CD50 RTSPTransportBuffer::Add pPacket=00955230
18829859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829859 00912D10 RTSPTransportBuffer::Add pPacket=009551C0
18829953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829953 00912D10 RTSPTransportBuffer::Add pPacket=009569B0
18829953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18829953 00912D10 RTSPTransportBuffer::Add pPacket=00956940
18830046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830046 0092CD50 RTSPTransportBuffer::Add pPacket=00956150
18830046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830046 00912D10 RTSPTransportBuffer::Add pPacket=009560E0
18830046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830046 0092CD50 RTSPTransportBuffer::Add pPacket=00956070
18830046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830046 00912D10 RTSPTransportBuffer::Add pPacket=00957FB0
18830140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830140 00912D10 RTSPTransportBuffer::Add pPacket=009578B0
18830140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830140 00912D10 RTSPTransportBuffer::Add pPacket=00957840
18830218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830218 0092CD50 RTSPTransportBuffer::Add pPacket=00957320
18830218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830218 00912D10 RTSPTransportBuffer::Add pPacket=009572B0
18830234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830234 00912D10 RTSPTransportBuffer::Add pPacket=00911B00
18830234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830234 0092CD50 RTSPTransportBuffer::Add pPacket=00914220
18830437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830437 00912D10 RTSPTransportBuffer::Add pPacket=0092C600
18830437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830437 0092CD50 RTSPTransportBuffer::Add pPacket=0092E2A0
18830437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830437 00912D10 RTSPTransportBuffer::Add pPacket=0092A050
18830437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830437 00912D10 RTSPTransportBuffer::Add pPacket=0092D0C0
18830546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830546 00912D10 RTSPTransportBuffer::Add pPacket=0092E660
18830546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830546 0092CD50 RTSPTransportBuffer::Add pPacket=0092E5F0
18830640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830640 00912D10 RTSPTransportBuffer::Add pPacket=0092D560
18830640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830640 0092CD50 RTSPTransportBuffer::Add pPacket=00929230
18830640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830640 00912D10 RTSPTransportBuffer::Add pPacket=009291C0
18830640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830640 00912D10 RTSPTransportBuffer::Add pPacket=00929150
18830750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830750 00912D10 RTSPTransportBuffer::Add pPacket=0091C2E0
18830750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830750 0092CD50 RTSPTransportBuffer::Add pPacket=0091F660
18830859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18830859 00912D10 RTSPTransportBuffer::Add pPacket=0092F600
18831046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831046 00912D10 RTSPTransportBuffer::Add pPacket=00932AC0
18831046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831046 0092CD50 RTSPTransportBuffer::Add pPacket=00936260
18831156 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831156 00912D10 RTSPTransportBuffer::Add pPacket=00932FB0
18831156 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831156 00912D10 RTSPTransportBuffer::Add pPacket=00932F40
18831234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831234 0092CD50 RTSPTransportBuffer::Add pPacket=00936430
18831234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831234 00912D10 RTSPTransportBuffer::Add pPacket=009363C0
18831234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831234 0092CD50 RTSPTransportBuffer::Add pPacket=00931610
18831234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831234 00912D10 RTSPTransportBuffer::Add pPacket=009315A0
18831343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831343 00912D10 RTSPTransportBuffer::Add pPacket=00931DB0
18831343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831343 00912D10 RTSPTransportBuffer::Add pPacket=00931D40
18831437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831437 0092CD50 RTSPTransportBuffer::Add pPacket=00934A70
18831437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831437 00912D10 RTSPTransportBuffer::Add pPacket=00934490
18831437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831437 00912D10 RTSPTransportBuffer::Add pPacket=00934420
18831750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831750 0092CD50 RTSPTransportBuffer::Add pPacket=00934550
18831750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831750 00912D10 RTSPTransportBuffer::Add pPacket=009320F0
18831859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831859 00912D10 RTSPTransportBuffer::Add pPacket=00933C20
18831859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831859 0092CD50 RTSPTransportBuffer::Add pPacket=00933BB0
18831859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831859 00912D10 RTSPTransportBuffer::Add pPacket=00933B40
18831859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831859 00912D10 RTSPTransportBuffer::Add pPacket=00933AD0
18831953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831953 0092CD50 RTSPTransportBuffer::Add pPacket=00930CC0
18831953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18831953 00912D10 RTSPTransportBuffer::Add pPacket=00930C50
18832078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832078 00912D10 RTSPTransportBuffer::Add pPacket=00930190
18832078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832078 0092CD50 RTSPTransportBuffer::Add pPacket=00930120
18832078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832078 00912D10 RTSPTransportBuffer::Add pPacket=009300B0
18832078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832078 00912D10 RTSPTransportBuffer::Add pPacket=0092E1A0
18832140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832140 0092CD50 RTSPTransportBuffer::Add pPacket=0094D0E0
18832140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832140 00912D10 RTSPTransportBuffer::Add pPacket=0094E9E0
18832453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832453 00912D10 RTSPTransportBuffer::Add pPacket=0091F340
18832453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832453 0092CD50 RTSPTransportBuffer::Add pPacket=00927260
18832453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832453 00912D10 RTSPTransportBuffer::Add pPacket=00926B50
18832453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832453 00912D10 RTSPTransportBuffer::Add pPacket=00921E90
18832546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832546 0092CD50 RTSPTransportBuffer::Add pPacket=00958B80
18832546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832546 00912D10 RTSPTransportBuffer::Add pPacket=00958AD0
18832656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832656 00912D10 RTSPTransportBuffer::Add pPacket=00959F20
18832656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832656 0092CD50 RTSPTransportBuffer::Add pPacket=00959EB0
18832656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832656 00912D10 RTSPTransportBuffer::Add pPacket=009582C0
18832656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832656 00912D10 RTSPTransportBuffer::Add pPacket=00958250
18832750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832750 0092CD50 RTSPTransportBuffer::Add pPacket=00959CA0
18832750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832750 00912D10 RTSPTransportBuffer::Add pPacket=00959C30
18832828 0092CD50 RTSPTransportBuffer::GetPacket
18832843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18832843 00912D10 RTSPTransportBuffer::Add pPacket=009597B0
18832921 00912D10 RTSPTransportBuffer::GetPacket
18832921 00912D10 RTSPTransportBuffer::GetPacket
18833109 0092CD50 RTSPTransportBuffer::GetPacket
18833109 00912D10 RTSPTransportBuffer::GetPacket
18833109 00912D10 RTSPTransportBuffer::GetPacket
18833140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833140 0092CD50 RTSPTransportBuffer::Add pPacket=0095E400
18833140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833140 00912D10 RTSPTransportBuffer::Add pPacket=0095E390
18833140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833140 0092CD50 RTSPTransportBuffer::Add pPacket=0095E320
18833140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833140 00912D10 RTSPTransportBuffer::Add pPacket=0095E2B0
18833234 0092CD50 RTSPTransportBuffer::GetPacket
18833234 00912D10 RTSPTransportBuffer::GetPacket
18833234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833234 00912D10 RTSPTransportBuffer::Add pPacket=0092DEA0
18833234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833234 0092CD50 RTSPTransportBuffer::Add pPacket=0092DDA0
18833234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833234 00912D10 RTSPTransportBuffer::Add pPacket=0095F6F0
18833234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833234 00912D10 RTSPTransportBuffer::Add pPacket=0095F680
18833312 00912D10 RTSPTransportBuffer::GetPacket
18833312 00912D10 RTSPTransportBuffer::GetPacket
18833343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833343 00912D10 RTSPTransportBuffer::Add pPacket=00960900
18833343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833343 0092CD50 RTSPTransportBuffer::Add pPacket=00960280
18833421 0092CD50 RTSPTransportBuffer::GetPacket
18833421 00912D10 RTSPTransportBuffer::GetPacket
18833437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833437 00912D10 RTSPTransportBuffer::Add pPacket=00962DF0
18833437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833437 0092CD50 RTSPTransportBuffer::Add pPacket=00962D80
18833437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833437 00912D10 RTSPTransportBuffer::Add pPacket=00961C60
18833515 00912D10 RTSPTransportBuffer::GetPacket
18833531 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833531 00912D10 RTSPTransportBuffer::Add pPacket=00963B50
18833609 0092CD50 RTSPTransportBuffer::GetPacket
18833609 00912D10 RTSPTransportBuffer::GetPacket
18833625 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833625 00912D10 RTSPTransportBuffer::Add pPacket=009646C0
18833625 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833625 0092CD50 RTSPTransportBuffer::Add pPacket=00964650
18833718 00912D10 RTSPTransportBuffer::GetPacket
18833734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833734 00912D10 RTSPTransportBuffer::Add pPacket=00965880
18833812 00912D10 RTSPTransportBuffer::GetPacket
18833812 0092CD50 RTSPTransportBuffer::GetPacket
18833859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833859 00912D10 RTSPTransportBuffer::Add pPacket=00927F20
18833859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833859 0092CD50 RTSPTransportBuffer::Add pPacket=0092DFB0
18833921 00912D10 RTSPTransportBuffer::GetPacket
18833968 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18833968 00912D10 RTSPTransportBuffer::Add pPacket=00952C40
18834015 0092CD50 RTSPTransportBuffer::GetPacket
18834015 00912D10 RTSPTransportBuffer::GetPacket
18834109 00912D10 RTSPTransportBuffer::GetPacket
18834140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834140 00912D10 RTSPTransportBuffer::Add pPacket=00960BD0
18834140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834140 0092CD50 RTSPTransportBuffer::Add pPacket=00966400
18834140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834140 00912D10 RTSPTransportBuffer::Add pPacket=009650D0
18834234 0092CD50 RTSPTransportBuffer::GetPacket
18834234 00912D10 RTSPTransportBuffer::GetPacket
18834250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834250 00912D10 RTSPTransportBuffer::Add pPacket=009692E0
18834250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834250 0092CD50 RTSPTransportBuffer::Add pPacket=00969270
18834328 00912D10 RTSPTransportBuffer::GetPacket
18834328 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834328 00912D10 RTSPTransportBuffer::Add pPacket=0096ADD0
18834421 0092CD50 RTSPTransportBuffer::GetPacket
18834421 00912D10 RTSPTransportBuffer::GetPacket
18834437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834437 00912D10 RTSPTransportBuffer::Add pPacket=0096B4D0
18834437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834437 0092CD50 RTSPTransportBuffer::Add pPacket=0096CF70
18834515 00912D10 RTSPTransportBuffer::GetPacket
18834531 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834531 00912D10 RTSPTransportBuffer::Add pPacket=0096C210
18834609 00912D10 RTSPTransportBuffer::GetPacket
18834609 0092CD50 RTSPTransportBuffer::GetPacket
18834640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834640 00912D10 RTSPTransportBuffer::Add pPacket=009696E0
18834640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834640 0092CD50 RTSPTransportBuffer::Add pPacket=00969670
18834734 00912D10 RTSPTransportBuffer::GetPacket
18834734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834734 00912D10 RTSPTransportBuffer::Add pPacket=0096BCA0
18834828 00912D10 RTSPTransportBuffer::GetPacket
18834828 0092CD50 RTSPTransportBuffer::GetPacket
18834859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834859 00912D10 RTSPTransportBuffer::Add pPacket=0096BBF0
18834859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834859 0092CD50 RTSPTransportBuffer::Add pPacket=0096F070
18834921 00912D10 RTSPTransportBuffer::GetPacket
18834937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18834937 00912D10 RTSPTransportBuffer::Add pPacket=0096D6B0
18834937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835015 00912D10 RTSPTransportBuffer::GetPacket
18835015 0092CD50 RTSPTransportBuffer::GetPacket
18835046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835046 00912D10 RTSPTransportBuffer::Add pPacket=024B1130
18835046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835046 0092CD50 RTSPTransportBuffer::Add pPacket=024B10C0
18835109 00912D10 RTSPTransportBuffer::GetPacket
18835156 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835156 00912D10 RTSPTransportBuffer::Add pPacket=024B20B0
18835218 00912D10 RTSPTransportBuffer::GetPacket
18835218 0092CD50 RTSPTransportBuffer::GetPacket
18835250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835250 00912D10 RTSPTransportBuffer::Add pPacket=024B21C0
18835250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835250 0092CD50 RTSPTransportBuffer::Add pPacket=024B4120
18835312 00912D10 RTSPTransportBuffer::GetPacket
18835343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835343 00912D10 RTSPTransportBuffer::Add pPacket=024B2DE0
18835421 0092CD50 RTSPTransportBuffer::GetPacket
18835421 00912D10 RTSPTransportBuffer::GetPacket
18835453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835453 00912D10 RTSPTransportBuffer::Add pPacket=024B5270
18835453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835453 0092CD50 RTSPTransportBuffer::Add pPacket=024B5200
18835515 00912D10 RTSPTransportBuffer::GetPacket
18835546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835546 00912D10 RTSPTransportBuffer::Add pPacket=024B3A20
18835609 00912D10 RTSPTransportBuffer::GetPacket
18835609 0092CD50 RTSPTransportBuffer::GetPacket
18835656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835656 00912D10 RTSPTransportBuffer::Add pPacket=0091F150
18835656 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835656 0092CD50 RTSPTransportBuffer::Add pPacket=0091C2E0
18835718 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835718 00912D10 RTSPTransportBuffer::Add pPacket=0096FA40
18835734 00912D10 RTSPTransportBuffer::GetPacket
18835828 00912D10 RTSPTransportBuffer::GetPacket
18835828 0092CD50 RTSPTransportBuffer::GetPacket
18835859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835859 00912D10 RTSPTransportBuffer::Add pPacket=00929310
18835859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835859 0092CD50 RTSPTransportBuffer::Add pPacket=0092A360
18835921 00912D10 RTSPTransportBuffer::GetPacket
18835937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18835937 00912D10 RTSPTransportBuffer::Add pPacket=024B8B20
18836015 00912D10 RTSPTransportBuffer::GetPacket
18836015 0092CD50 RTSPTransportBuffer::GetPacket
18836078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836078 00912D10 RTSPTransportBuffer::Add pPacket=024B9050
18836078 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836078 0092CD50 RTSPTransportBuffer::Add pPacket=024B8580
18836109 00912D10 RTSPTransportBuffer::GetPacket
18836140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836140 00912D10 RTSPTransportBuffer::Add pPacket=024B8FB0
18836234 00912D10 RTSPTransportBuffer::GetPacket
18836234 0092CD50 RTSPTransportBuffer::GetPacket
18836234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836234 00912D10 RTSPTransportBuffer::Add pPacket=024BDF50
18836234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836234 0092CD50 RTSPTransportBuffer::Add pPacket=024BD9E0
18836328 00912D10 RTSPTransportBuffer::GetPacket
18836359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836359 00912D10 RTSPTransportBuffer::Add pPacket=024BD970
18836421 00912D10 RTSPTransportBuffer::GetPacket
18836421 0092CD50 RTSPTransportBuffer::GetPacket
18836421 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836421 00912D10 RTSPTransportBuffer::Add pPacket=024BE1B0
18836421 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836421 0092CD50 RTSPTransportBuffer::Add pPacket=024BE140
18836515 00912D10 RTSPTransportBuffer::GetPacket
18836578 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836578 00912D10 RTSPTransportBuffer::Add pPacket=024BB800
18836609 00912D10 RTSPTransportBuffer::GetPacket
18836609 0092CD50 RTSPTransportBuffer::GetPacket
18836640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836640 00912D10 RTSPTransportBuffer::Add pPacket=009317A0
18836640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836640 0092CD50 RTSPTransportBuffer::Add pPacket=00931730
18836718 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836718 00912D10 RTSPTransportBuffer::Add pPacket=00931BD0
18836734 00912D10 RTSPTransportBuffer::GetPacket
18836812 0092CD50 RTSPTransportBuffer::GetPacket
18836812 00912D10 RTSPTransportBuffer::GetPacket
18836843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836843 00912D10 RTSPTransportBuffer::Add pPacket=024C0200
18836843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836843 0092CD50 RTSPTransportBuffer::Add pPacket=024C0190
18836921 00912D10 RTSPTransportBuffer::GetPacket
18836937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18836937 00912D10 RTSPTransportBuffer::Add pPacket=024C1770
18837015 00912D10 RTSPTransportBuffer::GetPacket
18837015 0092CD50 RTSPTransportBuffer::GetPacket
18837062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837062 00912D10 RTSPTransportBuffer::Add pPacket=024C2DD0
18837062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837062 0092CD50 RTSPTransportBuffer::Add pPacket=024C3420
18837109 00912D10 RTSPTransportBuffer::GetPacket
18837140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837140 00912D10 RTSPTransportBuffer::Add pPacket=024C1D60
18837218 0092CD50 RTSPTransportBuffer::GetPacket
18837218 00912D10 RTSPTransportBuffer::GetPacket
18837250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837250 00912D10 RTSPTransportBuffer::Add pPacket=024C50C0
18837250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837250 0092CD50 RTSPTransportBuffer::Add pPacket=024C5050
18837312 00912D10 RTSPTransportBuffer::GetPacket
18837359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837359 00912D10 RTSPTransportBuffer::Add pPacket=024C3290
18837421 0092CD50 RTSPTransportBuffer::GetPacket
18837421 00912D10 RTSPTransportBuffer::GetPacket
18837437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837437 00912D10 RTSPTransportBuffer::Add pPacket=00936260
18837437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837437 0092CD50 RTSPTransportBuffer::Add pPacket=00931B60
18837437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837437 00912D10 RTSPTransportBuffer::Add pPacket=0094F710
18837515 00912D10 RTSPTransportBuffer::GetPacket
18837531 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837531 00912D10 RTSPTransportBuffer::Add pPacket=00911B00
18837609 0092CD50 RTSPTransportBuffer::GetPacket
18837609 00912D10 RTSPTransportBuffer::GetPacket
18837640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837640 00912D10 RTSPTransportBuffer::Add pPacket=024C6040
18837640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837640 0092CD50 RTSPTransportBuffer::Add pPacket=024C7450
18837718 00912D10 RTSPTransportBuffer::GetPacket
18837750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837750 00912D10 RTSPTransportBuffer::Add pPacket=024B6900
18837812 00912D10 RTSPTransportBuffer::GetPacket
18837812 0092CD50 RTSPTransportBuffer::GetPacket
18837843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837843 00912D10 RTSPTransportBuffer::Add pPacket=024C98F0
18837843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837843 0092CD50 RTSPTransportBuffer::Add pPacket=024C9880
18837921 00912D10 RTSPTransportBuffer::GetPacket
18837937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18837937 00912D10 RTSPTransportBuffer::Add pPacket=024C9110
18838015 00912D10 RTSPTransportBuffer::GetPacket
18838015 0092CD50 RTSPTransportBuffer::GetPacket
18838062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838062 00912D10 RTSPTransportBuffer::Add pPacket=024CB050
18838062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838062 0092CD50 RTSPTransportBuffer::Add pPacket=024CCE30
18838109 00912D10 RTSPTransportBuffer::GetPacket
18838140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838140 00912D10 RTSPTransportBuffer::Add pPacket=024C94F0
18838218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838218 00912D10 RTSPTransportBuffer::Add pPacket=024CC2C0
18838218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838218 0092CD50 RTSPTransportBuffer::Add pPacket=024CC250
18838218 0092CD50 RTSPTransportBuffer::GetPacket
18838218 00912D10 RTSPTransportBuffer::GetPacket
18838312 00912D10 RTSPTransportBuffer::GetPacket
18838343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838343 00912D10 RTSPTransportBuffer::Add pPacket=024CCA70
18838421 00912D10 RTSPTransportBuffer::GetPacket
18838421 0092CD50 RTSPTransportBuffer::GetPacket
18838437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838437 00912D10 RTSPTransportBuffer::Add pPacket=024C1B50
18838437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838437 0092CD50 RTSPTransportBuffer::Add pPacket=024C7790
18838515 00912D10 RTSPTransportBuffer::GetPacket
18838531 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838531 00912D10 RTSPTransportBuffer::Add pPacket=0095C470
18838609 00912D10 RTSPTransportBuffer::GetPacket
18838609 0092CD50 RTSPTransportBuffer::GetPacket
18838640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838640 00912D10 RTSPTransportBuffer::Add pPacket=009581E0
18838640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838640 0092CD50 RTSPTransportBuffer::Add pPacket=00958170
18838734 00912D10 RTSPTransportBuffer::GetPacket
18838734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838734 00912D10 RTSPTransportBuffer::Add pPacket=024D1970
18838828 00912D10 RTSPTransportBuffer::GetPacket
18838828 0092CD50 RTSPTransportBuffer::GetPacket
18838828 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838828 00912D10 RTSPTransportBuffer::Add pPacket=024D3F20
18838828 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838828 0092CD50 RTSPTransportBuffer::Add pPacket=024D39F0
18838828 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838828 9516144 TIME_UP
InformSourceStopped Called Here
18838921 00912D10 RTSPTransportBuffer::GetPacket
18838937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18838937 00912D10 RTSPTransportBuffer::Add pPacket=024D2420
18839015 00912D10 RTSPTransportBuffer::GetPacket
18839015 0092CD50 RTSPTransportBuffer::GetPacket
18839046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839046 00912D10 RTSPTransportBuffer::Add pPacket=024D4D00
18839046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839046 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18839109 00912D10 RTSPTransportBuffer::GetPacket
18839156 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839156 00912D10 RTSPTransportBuffer::Add pPacket=024D2E80
18839218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839218 00912D10 RTSPTransportBuffer::Add pPacket=024D6950
18839218 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839218 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18839218 00912D10 RTSPTransportBuffer::GetPacket
18839218 0092CD50 RTSPTransportBuffer::GetPacket
18839312 00912D10 RTSPTransportBuffer::GetPacket
18839343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839343 00912D10 RTSPTransportBuffer::Add pPacket=00929B50
18839421 0092CD50 RTSPTransportBuffer::GetPacket
18839421 00912D10 RTSPTransportBuffer::GetPacket
18839437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839437 00912D10 RTSPTransportBuffer::Add pPacket=009634E0
18839437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839437 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18839515 00912D10 RTSPTransportBuffer::GetPacket
18839531 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839531 00912D10 RTSPTransportBuffer::Add pPacket=009565E0
18839609 0092CD50 RTSPTransportBuffer::GetPacket
18839609 00912D10 RTSPTransportBuffer::GetPacket
18839640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839640 00912D10 RTSPTransportBuffer::Add pPacket=00963870
18839640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839640 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18839718 00912D10 RTSPTransportBuffer::GetPacket
18839734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839734 00912D10 RTSPTransportBuffer::Add pPacket=00961180
18839812 0092CD50 RTSPTransportBuffer::GetPacket
18839812 00912D10 RTSPTransportBuffer::GetPacket
18839843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839843 00912D10 RTSPTransportBuffer::Add pPacket=024D8320
18839843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839843 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18839921 00912D10 RTSPTransportBuffer::GetPacket
18839937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18839937 00912D10 RTSPTransportBuffer::Add pPacket=024D98C0
18840015 00912D10 RTSPTransportBuffer::GetPacket
18840015 0092CD50 RTSPTransportBuffer::GetPacket
18840046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840046 00912D10 RTSPTransportBuffer::Add pPacket=024D90B0
18840046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840046 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18840109 00912D10 RTSPTransportBuffer::GetPacket
18840140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840140 00912D10 RTSPTransportBuffer::Add pPacket=024D9EB0
18840234 00912D10 RTSPTransportBuffer::GetPacket
18840234 0092CD50 RTSPTransportBuffer::GetPacket
18840250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840250 00912D10 RTSPTransportBuffer::Add pPacket=024DECE0
18840250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840250 9557872 TIME_UP
InformSourceStopped Called Here
18840250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840250 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18840328 00912D10 RTSPTransportBuffer::GetPacket
18840359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840359 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840421 00912D10 RTSPTransportBuffer::GetPacket
18840421 0092CD50 RTSPTransportBuffer::GetPacket
18840437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840437 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840437 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840437 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18840515 00912D10 RTSPTransportBuffer::GetPacket
18840578 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840578 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840609 00912D10 RTSPTransportBuffer::GetPacket
18840609 0092CD50 RTSPTransportBuffer::GetPacket
18840640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840640 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840640 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18840734 00912D10 RTSPTransportBuffer::GetPacket
18840750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840750 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840812 0092CD50 RTSPTransportBuffer::GetPacket
18840812 00912D10 RTSPTransportBuffer::GetPacket
18840843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840843 00912D10 RTSPTransportBuffer::Add Returned from ADD
18840843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840843 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18840921 00912D10 RTSPTransportBuffer::GetPacket
18840953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18840953 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841015 00912D10 RTSPTransportBuffer::GetPacket
18841015 0092CD50 RTSPTransportBuffer::GetPacket
18841062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841062 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841062 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18841109 00912D10 RTSPTransportBuffer::GetPacket
18841140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841140 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841218 0092CD50 RTSPTransportBuffer::GetPacket
18841218 00912D10 RTSPTransportBuffer::GetPacket
18841250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841250 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841250 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18841312 00912D10 RTSPTransportBuffer::GetPacket
18841359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841359 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841421 0092CD50 RTSPTransportBuffer::GetPacket
18841421 00912D10 RTSPTransportBuffer::GetPacket
18841453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841453 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841453 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18841515 00912D10 RTSPTransportBuffer::GetPacket
18841562 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841562 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841609 0092CD50 RTSPTransportBuffer::GetPacket
18841609 00912D10 RTSPTransportBuffer::GetPacket
18841640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841640 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841640 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841640 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18841718 00912D10 RTSPTransportBuffer::GetPacket
18841750 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841750 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841812 00912D10 RTSPTransportBuffer::GetPacket
18841812 0092CD50 RTSPTransportBuffer::GetPacket
18841843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841843 00912D10 RTSPTransportBuffer::Add Returned from ADD
18841843 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841843 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18841921 00912D10 RTSPTransportBuffer::GetPacket
18841953 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18841953 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842015 00912D10 RTSPTransportBuffer::GetPacket
18842015 0092CD50 RTSPTransportBuffer::GetPacket
18842062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842062 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842062 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842062 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18842109 00912D10 RTSPTransportBuffer::GetPacket
18842156 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842156 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842218 0092CD50 RTSPTransportBuffer::GetPacket
18842218 00912D10 RTSPTransportBuffer::GetPacket
18842234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842234 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842234 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842234 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18842312 00912D10 RTSPTransportBuffer::GetPacket
18842343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842343 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842421 00912D10 RTSPTransportBuffer::GetPacket
18842421 0092CD50 RTSPTransportBuffer::GetPacket
18842453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842453 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842453 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18842453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842453 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842515 00912D10 RTSPTransportBuffer::GetPacket
18842546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842546 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842609 00912D10 RTSPTransportBuffer::GetPacket
18842609 0092CD50 RTSPTransportBuffer::GetPacket
18842671 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842671 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842671 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842671 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18842718 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842718 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842734 00912D10 RTSPTransportBuffer::GetPacket
18842828 00912D10 RTSPTransportBuffer::GetPacket
18842828 0092CD50 RTSPTransportBuffer::GetPacket
18842828 00912D10 RTSPTransportBuffer::GetPacket
18842859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842859 00912D10 RTSPTransportBuffer::Add Returned from ADD
18842859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842859 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18842921 00912D10 RTSPTransportBuffer::GetPacket
18842937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18842937 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843015 00912D10 RTSPTransportBuffer::GetPacket
18843015 0092CD50 RTSPTransportBuffer::GetPacket
18843031 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843031 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843031 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843031 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18843109 00912D10 RTSPTransportBuffer::GetPacket
18843125 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843125 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843218 0092CD50 RTSPTransportBuffer::GetPacket
18843218 00912D10 RTSPTransportBuffer::GetPacket
18843250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843250 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843250 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18843312 00912D10 RTSPTransportBuffer::GetPacket
18843343 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843343 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843421 00912D10 RTSPTransportBuffer::GetPacket
18843421 0092CD50 RTSPTransportBuffer::GetPacket
18843453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843453 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843453 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843453 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18843515 00912D10 RTSPTransportBuffer::GetPacket
18843546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843546 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843609 00912D10 RTSPTransportBuffer::GetPacket
18843609 0092CD50 RTSPTransportBuffer::GetPacket
18843671 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843671 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843671 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843671 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18843734 00912D10 RTSPTransportBuffer::GetPacket
18843734 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843734 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843828 0092CD50 RTSPTransportBuffer::GetPacket
18843828 00912D10 RTSPTransportBuffer::GetPacket
18843859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843859 00912D10 RTSPTransportBuffer::Add Returned from ADD
18843859 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843859 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18843921 00912D10 RTSPTransportBuffer::GetPacket
18843937 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18843937 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844015 0092CD50 RTSPTransportBuffer::GetPacket
18844015 00912D10 RTSPTransportBuffer::GetPacket
18844046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844046 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844046 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844046 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18844109 00912D10 RTSPTransportBuffer::GetPacket
18844140 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844140 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844234 00912D10 RTSPTransportBuffer::GetPacket
18844234 0092CD50 RTSPTransportBuffer::GetPacket
18844250 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844250 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844265 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844265 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18844328 00912D10 RTSPTransportBuffer::GetPacket
18844359 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844359 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844421 0092CD50 RTSPTransportBuffer::GetPacket
18844421 00913470 RTCPUDPTransport::streamDone streamNumber=1 m_bSendBye=1
18844421 00912D10 RTSPTransportBuffer::GetPacket
18844468 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844468 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844468 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844468 0092CD50 RTSPTransportBuffer::Add Returned from ADD
18844515 00912D10 RTSPTransportBuffer::GetPacket
18844546 9458160 RTSPProtocol::HandlePacket pPacket=00000000
18844546 00912D10 RTSPTransportBuffer::Add Returned from ADD
18844609 0092CD50 RTSPTransportBuffer::GetPacket
18844609 00912D10 RTSPTransportBuffer::GetPacket
18844625 00906870 RTSPClientProtocol::SendTeardownRequest TEAR_DOWN Message Sent
18844640 008F6CA0 HXPlayer::StopPlayer
18844640 008F6CA0 HXPlayer::StopPlayer
18844640 008F6CA0 HXPlayer::StopPlayer
-------------- next part --------------
RTSPClientProtocol[009068A0]
OUT:
OPTIONS rtsp://192.168.1.249:554 RTSP/1.0
CSeq: 1
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Supported: ABD-1.0
ClientChallenge: 719ff3d9a0896ea8b7abf98d7a3794a2
ClientID: WinNT_5.1_10.0.0.10188_play32_RN01_EN_UNK
CompanyID: 7IyZ2qDGcafDdEZyyTtX3A==
GUID: 00000000-0000-0000-0000-000000000000
PlayerStarttime: [19/01/2007:15:10:40 05:00]
Pragma: initiate-session
RegionData: 0
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 1
Date: Fri,19 Jan 2007 09:40:40 GMT
Supported: ABD-1.0
Session: 27253-1;timeout=80
Server: Helix Server Version 11.1.1.1099 (win32) (RealServer compatible)
Public: OPTIONS,DESCRIBE,ANNOUNCE,PLAY,PAUSE,SETUP,GET_PARAMETER,SET_PARAMETER,TEARDOWN
TurboPlay: 1
RealChallenge1: fe0c005f5dfbaf8f3fafec6afc86416d
StatsMask: 8
RTSPClientProtocol[009068A0]
OUT:
DESCRIBE rtsp://192.168.1.249:554/broadcast/live.3gp RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Session: 27253-1;timeout=80
Bandwidth: 10485800
ClientID: WinNT_5.1_10.0.0.10188_play32_RN01_EN_UNK
GUID: 00000000-0000-0000-0000-000000000000
Language: en-US
RegionData: 0
Require: com.real.retain-entity-for-setup
SupportsMaximumASMBandwidth: 1
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 2
Date: Fri,19 Jan 2007 09:40:40 GMT
Session: 27253-1;timeout=80
Set-Cookie: cbid=hfigihhlnjfklldmeorrmpptmrjrktlufkgjkidldgifhlplosrorpqtfrksqtppifjjdhpi;path=/;expires=Thu,31-Dec-2037 23:59:59 GMT
vsrc: http://192.168.1.249:80/viewsource/template.html?nuyhtgAirdz6b0z94eBxmjtgm0g6bfi058i7000000000000000000000000000000000000000000000000tBw4e4
Content-base: rtsp://192.168.1.249:554/broadcast/live.3gp/
ETag: 27253-1
Session: 27253-1;timeout=80
Vary: User-Agent,ClientID
Content-type: application/sdp
x-real-usestrackid: 1
Content-length: 1971
v=0
o=- 0 0 IN IP4 192.168.1.249
s=live.3gp
i=
c=IN IP4 0.0.0.0
t=0 0
a=SdpplinVersion:1610641560
a=StreamCount:integer;2
a=control:*
a=DefaultLicenseValue:integer;0
a=Height:integer;144
a=LatencyMode:integer;0
a=LiveStream:integer;1
a=Width:integer;176
a=FileType:string;"MPEG4"
a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"
a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIrAE////4I/wOBNgABQJhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVlFCS0FVZkF5UUF5UUFFRFNBUkFCSjFBQUNUcUFBQWs2Z0dFQUJFQUFGZmtBQUJYNUFnQUFBQUFBTUJLQUtmQXlRQVpRQUVEY2NWQUFBQUFBQUFBQUFBQUFBR0VBQkVBQUFmUUFBQlg1QWdBQUFBQUFNPQQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2kAAkBGZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTZ1RBcUJXMG1FRUg4QUFBQi9BQUFCRUtDS0NuNAQSAg0AACAAAAAAAAAAAAUDAABABgkBAAAAAAAAAAA="
m=video 0 RTP/AVP 96
b=AS:40
b=RR:1271
b=RS:423
a=control:streamid=65335
a=range:npt=0-
a=length:npt=0
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=8; config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F
a=mimetype:string;"video/MP4V-ES"
a=AvgBitRate:integer;33901
a=AvgPacketSize:integer;418
a=HasOutOfOrderTS:integer;1
a=Height:integer;144
a=LiveStream:integer;1
a=Preroll:integer;1000
a=Width:integer;176
a=ASMRuleBook:string;"Marker=0,AverageBandwidth=33901,TimeStampDelivery=TRUE;Marker=1,AverageBandwidth=0,TimeStampDelivery=TRUE;"
a=cliprect:0,0,144,176
a=mpeg4-esid:201
a=x-envivio-verid:00035A30
m=audio 0 RTP/AVP 97
b=AS:16
b=RR:481
b=RS:160
a=control:streamid=65435
a=range:npt=0-
a=length:npt=0
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align=1
a=mimetype:string;"audio/AMR"
a=AvgBitRate:integer;12840
a=AvgPacketSize:integer;320
a=HasOutOfOrderTS:integer;1
a=LiveStream:integer;1
a=ASMRuleBook:string;"Marker=0,AverageBandwidth=12840,TimeStampDelivery=TRUE;Marker=1,AverageBandwidth=0,TimeStampDelivery=TRUE;"
a=mpeg4-esid:101
a=x-envivio-verid:00035A30
RTSPClientProtocol[009068A0]
OUT:
SETUP rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65335 RTSP/1.0
CSeq: 3
RealChallenge2: d2780b91d8a6e3de619c956d9fb7a9f901d0a8e3, sd=d0de699a
Transport: RTP/AVP;unicast;client_port=6970-6971;mode=play,RTP/AVP/TCP;unicast;mode=play
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
If-Match: 27253-1
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 3
Date: Fri,19 Jan 2007 09:40:41 GMT
Session: 27253-1;timeout=80
Reconnect: true
RDTFeatureLevel: 0
StatsMask: 8
RealChallenge3: 65555c3f16b2cdb24dadad7e8c4f1b3d4f213d09,sdr=651c4a81
Transport: RTP/AVP;unicast;client_port=6970-6971;server_port=10058-10059
RTSPClientProtocol[009068A0]
OUT:
SETUP rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65435 RTSP/1.0
CSeq: 4
Transport: RTP/AVP;unicast;client_port=6972-6973;mode=play
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Session: 27253-1
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 4
Date: Fri,19 Jan 2007 09:40:41 GMT
Session: 27253-1;timeout=80
RDTFeatureLevel: 0
StatsMask: 8
Transport: RTP/AVP;unicast;client_port=6972-6973;server_port=30920-30921
RTSPClientProtocol[009068A0]
OUT:
SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 5
Subscribe: stream=0;rule=0,stream=0;rule=1,stream=1;rule=0,stream=1;rule=1
Session: 27253-1
RTSPClientProtocol[009068A0]
OUT:
SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 6
SetDeliveryBandwidth: Bandwidth=186964;BackOff=0
Session: 27253-1
RTSPClientProtocol[009068A0]
OUT:
PLAY rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 7
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Session: 27253-1
Range: npt=0-
Bandwidth: 10485800
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 5
Date: Fri,19 Jan 2007 09:40:41 GMT
Session: 27253-1;timeout=80
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 6
Date: Fri,19 Jan 2007 09:40:41 GMT
Session: 27253-1;timeout=80
RTSPClientProtocol[009068A0]
IN:
RTSP/1.0 200 OK
CSeq: 7
Date: Fri,19 Jan 2007 09:40:41 GMT
Session: 27253-1;timeout=80
RTP-Info: url=rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65335;seq=0;rtptime=659592000,url=rtsp://192.168.1.249:554/broadcast/live.3gp/streamid=65435;seq=0;rtptime=58630400
RTSPClientProtocol[009068A0]
OUT:
PAUSE rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 8
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Session: 27253-1
RTSPClientProtocol[009068A0]
OUT:
SET_PARAMETER rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 9
Session: 27253-1
PlayerStats: [Stat4:2 video/MP4V-ES|N/A|133|0|0|23522|0|;audio/AMR|N/A|83|0|0|12844|0| 1 1|186964|1422| 0 1 1813 15281 0 6182|0|6957]
RTSPClientProtocol[009068A0]
OUT:
TEARDOWN rtsp://192.168.1.249:554/broadcast/live.3gp/ RTSP/1.0
CSeq: 10
User-Agent: RealMedia Player HelixDNAClient/10.0.0.10188 (win32)
Session: 27253-1
From rajesh.rathinasamy at nokia.com Mon Jan 29 11:10:32 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Jan 29 11:57:08 2007
Subject: [Client-dev] RE: [Protocol-dev] CR: Fix for failure to switch
totcp transport whenudp ports are blocked
In-Reply-To:
References: <6.2.1.2.2.20070111122429.04f57108@mailone.real.com>
Message-ID:
Hi Henry & All,
The problem of protocol switch over is still seen sometimes. Use
case is block (or drop) all UDP packets on the server terminal. Before
netsource detects data timeout and switches transport, the
RTSPProtocol's server timeout fires and reports error instead of switch
over.
I was able to track down what is causing the problem. client\core
RTSPProtocol::resume api, sets the m_ulLastPacketReceivedTime value
which later times out resulting in Server timeout. What is the exact
purpose of the member variable m_ulLastPacketReceivedTime ?
Is it to track the Inactivity TCP media data ? If so, setting that value
in resume call will trigger the timer handling for UDP data too.
Thanks,
Rajesh.
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Thursday, January 11, 2007 4:37 PM
To: milko@real.com; ping@real.com;
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: RE: [Client-dev] RE: [Protocol-dev] CR: Fix for failure
to switch totcp transport whenudp ports are blocked
The changes have been committed to 150Cay as well.
Thanks,
Rajesh.
________________________________
From: ext Milko Boic [mailto:milko@real.com]
Sent: Thursday, January 11, 2007 2:25 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
ping@real.com; protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: Re: [Client-dev] RE: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
Please commit to hxclient_1_5_0_cayenne as well.
Thanks,
Milko
At 12:05 PM 1/11/2007, rajesh.rathinasamy@nokia.com
wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C735BB.E76DD096"
Thanks Henry !
The changes have been committed to Head and
210CayS
- Rajesh.
________________________________
From: ext Henry Ping
[mailto:ping@real.com ]
Sent: Thursday, January 11, 2007 11:08
AM
To: Rathinasamy Rajesh
(Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: RE: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
Looks good, your description below is
accurate.
-->Henry
________________________________
From:
protocol-dev-bounces@helixcommunity.org [
mailto:protocol-dev-bounces@helixcommunity.org
] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Thursday, January 11, 2007 6:29 AM
Ping
To: protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
"Nokia submits this code under the terms
of a commercial contribution agreement with RealNetworks, and I am
authorized to contribute this code under said agreement."
Modified by:
rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch
to tcp transport when udp ports are blocked.
Problem: All udp ports are blocked on
the router or on server (used iptables on linux OS). When we try to
stream a clip, the client first tries to establish RTSP connection and
waits for UDP data. Since UDP ports were blocked there was UDP timeout
should occur and the client should switch to next transport. Instead of
transport switch, we say server timeout. The transport switch happens
properly if the UDP timeout value is smaller than ServerTimeout value.
The current transport mode on
rtspclnt.cpp is intialized to TCPMode. From what I understand, the
current transport mode indicates the media transport protocol. Changes
are based on this assumption.
If the current transport is TCP or
HTTPCloak, RTSPClientProtocol::handleMessage (during 200 OK for
OPTIONS) sets the lastPackettimestamp on RTSPProtocol. Setting this
variable makes the server timeout handling active on
RTSPProtocol::process. The current tarnsport changes to UDP mode after
describe response and session setup. This change in mode will avoid any
more update to the last packet received time on RTSPProtocol. And since
there are no incoming UDP data because of port blocking, the server
timeout fires on the RTSPProtocol.
As a change I have initialized the
current transport mode on RTSPClientProtocol to unknownMode instead of
TCPMode.
Root Cause of the problem:
Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major
impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction
of problem includes blocking of port on router
Memory leak check performed : Yes. No
new leaks introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality
verified: armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file:
/cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006
09:39:00 -0000 1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007
22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070129/55674aaa/attachment.html
From Junhong.Liu at nokia.com Mon Jan 29 12:20:51 2007
From: Junhong.Liu at nokia.com (Junhong.Liu@nokia.com)
Date: Mon Jan 29 13:07:22 2007
Subject: [Protocol-dev] RE: [Client-dev] Redundant SET_PARAMTER during
startof stream
In-Reply-To:
References: <200701031938.l03JcIiW002163@mgw-mx06.nokia.com>
Message-ID:
Hi,
I did some study on this issue and found out the possible reason for the
last 2 SetDeliveryBW requests. See the attached diagram.
Symbian client first calls Prepare() to MMF controller. Because of the
pre-fetch feature, HXPlayer will start to send RTSP messages including
PLAY to the server. Before the download is done, HXFeedBackBufferCtrl is
in Buffering state. However, when PlayL() issued from the Sybmian
client, HXPlayer will call HXFeedBackBufferCtrl's OnResume(). Since the
download is not done, HXFeedbackBufferCtrl will transit to Buffering
state again very soon. In HXFeedBackBufferCtrl, OnBuffering() and
OnResume() will call RTSP SetDeliveryBandwidth().
The root cause seems the mismatch between the MMF state machine and the
helix core in some short period because of the pre-fetch. We don't want
to make changes in this part, so I am thinking to try other
alternatives.
1) Add check in HXFeedBackBufferCtrl. If the new bandwidth is same as
the old one, don't send it again.
Or
2) Remove the SetDeliveryBandwidth() in OnBuffer() and onResume(), and
totally rely on the periodic timer to send the updated parameters.
Any idea or suggestion on these?
Thanks,
Junhong
>-----Original Message-----
>From: protocol-dev-bounces@helixcommunity.org
>[mailto:protocol-dev-bounces@helixcommunity.org]
>Sent: Wednesday, January 03, 2007 5:29 PM
>To: ping@real.com; ehyche@real.com;
>client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>Subject: [Protocol-dev] RE: [Client-dev] Redundant
>SET_PARAMTER during startof stream
>
>Hi Henry,
> Thank you very much for your time.
>
>This error is not a blocker. I can open a bug on Bugzilla. The
>content plays through fine. It was an obervation from the test team.
>
>Thanks,
>Rajesh,
>
>
>>-----Original Message-----
>>From: ext Henry Ping [mailto:ping@real.com]
>>Sent: Wednesday, January 03, 2007 1:39 PM
>>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); ehyche@real.com;
>>client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>>Subject: RE: [Client-dev] Redundant SET_PARAMTER during start
>of stream
>>
>>Thanks for your callstack trace, it confirms the last 2 SetDeliveryBW
>>requests are issued by the HXFeedbackBufferControl and they are not
>>issued by the other buffering model(HXWatermarkBufferControl).
>>
>>I am not familiar with the HXFeedbackBufferControl. It's
>critical code
>>and needs to be looked at carefully. Is this an urgent issue for you?
>>Is the content played successfully afterwards? I suggest to
>file a bug
>>to Helix database, so we can track it and assign dev resource to fix
>>it.
>>
>>Not sure if this is an option for you, you can also enable the
>>server-side rate adaptation, it reliefs the client-side rate
>adaptation
>>and thus the SetDeliveryBW requests.
>>
>>-->Henry
>>
>>> -----Original Message-----
>>> From: rajesh.rathinasamy@nokia.com
>>> [mailto:rajesh.rathinasamy@nokia.com]
>>> Sent: Tuesday, January 02, 2007 12:41 PM Ping
>>> To: ping@real.com; ehyche@real.com;
>>> client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>>> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
>>> stream
>>>
>>> Hi Henry,
>>> Thanks for your response.
>>>
>>> The profile we use is helix-client-s60-32-mmf-mdf-arm.pf. It uses
>>> HXFeedbackBufferControl. Attaching the function call traces for all
>>> the SET_PARAM during starting. (I could not take a txt
>>version of call
>>> stack trace, so I have the screen capture attached.)
>>>
>>> SET_PARAM is sent during StartDownload,
>>CheckSourceRegistration, Play
>>> (Resume), OnBufferring.
>>>
>>> Thanks,
>>> Rajesh.
>>>
>>>
>>>
>>>
>>>
>>> >-----Original Message-----
>>> >From: ext Henry Ping [mailto:ping@real.com]
>>> >Sent: Tuesday, January 02, 2007 12:34 PM
>>> >To: Rathinasamy Rajesh (Nokia-TP/Dallas); ehyche@real.com;
>>> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>>> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
>>> start of stream
>>> >
>>> >Rajesh,
>>> >
>>> >The SetDeliveryBandwidth requests via SET_PARAMER is for the whole
>>> >presentation, not per individual stream. It does seems to be
>>> redundant
>>> >to send multiple SetDeliveryBandwidth in sequence with the same
>>> >bandwidth value.
>>> >
>>> >I assume you're building with the mobile profile which uses
>>> different
>>> >buffer control model(HXFeedbackBufferControl) from the
>>> >rest(HXWatermarkBufferControl) when
>>> >HELIX_FEATURE_FEEDBACK_BUFFER_CONTROL is defined. I have a
>>> non-Mobile
>>> >build and it doesn't exhibit the same problem you saw, so I
>>> suspect the
>>> >problem might reside in that particular buffer control module.
>>> >
>>> >I suggest to set breakpoint at
>>> >RTSPClientProtocol::SetDeliveryBandwidth and back trace to
>>> the source
>>> >where the requests are generated.
>>> >
>>> >-->Henry
>>> >
>>> >> -----Original Message-----
>>> >> From: client-dev-bounces@helixcommunity.org
>>> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>>> >> rajesh.rathinasamy@nokia.com
>>> >> Sent: Tuesday, January 02, 2007 8:39 AM Ping
>>> >> To: ehyche@real.com; client-dev@helixcommunity.org;
>>> >> protocol-dev@helixcommunity.org
>>> >> Subject: RE: [Client-dev] Redundant SET_PARAMTER during start of
>>> >> stream
>>> >>
>>> >> Hi Eric,
>>> >> Thanks for your time.
>>> >>
>>> >> Attaching a new log file. This has the complete RTSP chat.
>>> >> I could see same set of RTSP chat for all clips. The session
>>> >does not
>>> >> have three streams, it has only one audio and one video
>and still
>>> >> multiple SET_PARAM are sent. Apart from that the url sent in
>>> >SET_PARAM
>>> >> is same for all messages.
>>> >>
>>> >> If the intention is send SET_PARAM for individual streams,
>>> >why is that
>>> >> required. I thought we are responding the client
>>bandwidth and why
>>> >> should it be sent for individual streams ?
>>> >>
>>> >> Thanks,
>>> >> Rajesh.
>>> >>
>>> >>
>>> >> >-----Original Message-----
>>> >> >From: ext Eric Hyche [mailto:ehyche@real.com]
>>> >> >Sent: Tuesday, January 02, 2007 9:33 AM
>>> >> >To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
>>> >> >client-dev@helixcommunity.org; protocol-dev@helixcommunity.org
>>> >> >Subject: RE: [Client-dev] Redundant SET_PARAMTER during
>>> >> start of stream
>>> >> >
>>> >> >
>>> >> >There appear to be three streams: one video, one audio, and
>>> >> one other
>>> >> >(can't tell, since SDP is not in the log file). I would
>>> assume the
>>> >> >three SET_PARAMETER calls after the RTSP PLAY
>correspond to each
>>> >> >stream. Usually these can be distinguished by the URL in
>>the RTSP
>>> >> >SET_PARAMETER (i.e. - rtsp://...../foo.3gp/audio, etc.) but
>>> >for some
>>> >> >reason, all of the URLs look the same in this exchange.
>>> >> >
>>> >> >Henry might be able to shed some more light on this...
>>> >> >
>>> >> >Eric
>>> >> >
>>> >> >=============================================
>>> >> >Eric Hyche (ehyche@real.com)
>>> >> >Technical Lead
>>> >> >RealNetworks, Inc.
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: client-dev-bounces@helixcommunity.org
>>> >> >> [mailto:client-dev-bounces@helixcommunity.org] On Behalf Of
>>> >> >> rajesh.rathinasamy@nokia.com
>>> >> >> Sent: Thursday, December 21, 2006 12:02 PM
>>> >> >> To: client-dev@helixcommunity.org;
>>> protocol-dev@helixcommunity.org
>>> >> >> Subject: [Client-dev] Redundant SET_PARAMTER during start
>>> >of stream
>>> >> >>
>>> >> >> Hi,
>>> >> >> we noticed that after PLAY message sent to server,
>>there are
>>> >> >> redundant SET_PARAMETER (PIPELINED) sent to server. I
>>> >> don't see any
>>> >> >> change in the bandwidth value reported. The message looks
>>> >> identical
>>> >> >> except for sequence number. In the attached log,
>there is one
>>> >> >> SET_PARAMETER before PLAY and three consecutive SET_PARAMETER
>>> >> >> PIPELINED before PLAY response.
>>> >> >>
>>> >> >> Can someone explain why this is sent multiple times ? Is it
>>> >> >an error ?
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Rajesh.
>>> >> >>
>>> >> >> <>
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>
>_______________________________________________
>Protocol-dev mailing list
>Protocol-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.pdf
Type: application/octet-stream
Size: 25308 bytes
Desc: 1.pdf
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070129/a1c5f57b/1-0001.obj
From rajesh.rathinasamy at nokia.com Tue Jan 30 18:05:30 2007
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Jan 30 18:51:49 2007
Subject: [Client-dev] RE: [Protocol-dev] CR: Fix for failure to
switchtotcp transport whenudp ports are blocked
In-Reply-To:
References: <6.2.1.2.2.20070111122429.04f57108@mailone.real.com>
Message-ID:
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Monday, January 29, 2007 1:11 PM
To: protocol-dev-bounces@helixcommunity.org; ping@real.com;
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: RE: [Client-dev] RE: [Protocol-dev] CR: Fix for failure
to switchtotcp transport whenudp ports are blocked
Hi Henry & All,
The problem of protocol switch over is still seen
sometimes. Use case is block (or drop) all UDP packets on the server
terminal. Before netsource detects data timeout and switches transport,
the RTSPProtocol's server timeout fires and reports error instead of
switch over.
I was able to track down what is causing the problem.
client\core RTSPProtocol::resume api, sets the
m_ulLastPacketReceivedTime value which later times out resulting in
Server timeout. What is the exact purpose of the member variable
m_ulLastPacketReceivedTime ?
Is it to track the Inactivity TCP media data ? If so, setting
that value in resume call will trigger the timer handling for UDP data
too.
Thanks,
Rajesh.
________________________________
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org]
Sent: Thursday, January 11, 2007 4:37 PM
To: milko@real.com; ping@real.com;
protocol-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: RE: [Client-dev] RE: [Protocol-dev] CR: Fix for
failure to switch totcp transport whenudp ports are blocked
The changes have been committed to 150Cay as well.
Thanks,
Rajesh.
________________________________
From: ext Milko Boic [mailto:milko@real.com]
Sent: Thursday, January 11, 2007 2:25 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas);
ping@real.com; protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: Re: [Client-dev] RE: [Protocol-dev] CR:
Fix for failure to switch to tcp transport whenudp ports are blocked
Please commit to hxclient_1_5_0_cayenne as well.
Thanks,
Milko
At 12:05 PM 1/11/2007,
rajesh.rathinasamy@nokia.com wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C735BB.E76DD096"
Thanks Henry !
The changes have been committed to Head
and 210CayS
- Rajesh.
________________________________
From: ext Henry Ping
[mailto:ping@real.com ]
Sent: Thursday, January 11, 2007 11:08
AM
To: Rathinasamy Rajesh
(Nokia-TP-MSW/Dallas); protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: RE: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
Looks good, your description below is
accurate.
-->Henry
________________________________
From:
protocol-dev-bounces@helixcommunity.org [
mailto:protocol-dev-bounces@helixcommunity.org
] On Behalf Of
rajesh.rathinasamy@nokia.com
Sent: Thursday, January 11, 2007 6:29 AM
Ping
To: protocol-dev@helixcommunity.org;
client-dev@helixcommunity.org
Subject: [Protocol-dev] CR: Fix for
failure to switch to tcp transport whenudp ports are blocked
"Nokia submits this code under the terms
of a commercial contribution agreement with RealNetworks, and I am
authorized to contribute this code under said agreement."
Modified by:
rajesh.rathinasamy@nokia.com
Reviewed by:
Date: 10-Jan-2007
Project: SymbianMmf
ErrorId: EOVL-6XBTKL
Synopsis: CR: Fix for failure to switch
to tcp transport when udp ports are blocked.
Problem: All udp ports are blocked on
the router or on server (used iptables on linux OS). When we try to
stream a clip, the client first tries to establish RTSP connection and
waits for UDP data. Since UDP ports were blocked there was UDP timeout
should occur and the client should switch to next transport. Instead of
transport switch, we say server timeout. The transport switch happens
properly if the UDP timeout value is smaller than ServerTimeout value.
The current transport mode on
rtspclnt.cpp is intialized to TCPMode. From what I understand, the
current transport mode indicates the media transport protocol. Changes
are based on this assumption.
If the current transport is TCP or
HTTPCloak, RTSPClientProtocol::handleMessage (during 200 OK for
OPTIONS) sets the lastPackettimestamp on RTSPProtocol. Setting this
variable makes the server timeout handling active on
RTSPProtocol::process. The current tarnsport changes to UDP mode after
describe response and session setup. This change in mode will avoid any
more update to the last packet received time on RTSPProtocol. And since
there are no incoming UDP data because of port blocking, the server
timeout fires on the RTSPProtocol.
As a change I have initialized the
current transport mode on RTSPClientProtocol to unknownMode instead of
TCPMode.
Root Cause of the problem:
Implementation phase
Files Modified:
protocol/rtsp/rtspclnt.cpp
Image Size and Heap Use impact: no major
impact
Module Release testing (STIF) : Pass
Test case(s) Added : No. Reproduction
of problem includes blocking of port on router
Memory leak check performed : Yes. No
new leaks introduced.
Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality
verified: armv5, winscw
Branch: Head & 210CayS
Index: rtspclnt.cpp
===================================================================
RCS file:
/cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.182.2.17
diff -w -u -b -r1.182.2.17 rtspclnt.cpp
--- rtspclnt.cpp 21 Dec 2006
09:39:00 -0000 1.182.2.17
+++ rtspclnt.cpp 10 Jan 2007
22:10:53 -0000
@@ -2397,7 +2397,7 @@
m_cloakPort(0),
m_pMutex(NULL),
m_uProtocolType(0),
- m_currentTransport(TCPMode),
+ m_currentTransport(UnknownMode),
m_ulBufferDepth(BUFFER_DEPTH_UNDEFINED),
m_bSplitterConsumer(FALSE),
m_pPacketFilter(NULL),
_______________________________________________
Client-dev mailing list
Client-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/client-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20070130/65624219/attachment.html
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.