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

List:       helix-protocol-cvs
Subject:    [Protocol-cvs] common/util sdptools.cpp,1.12,1.13
From:       vijendrakumara () helixcommunity ! org
Date:       2008-01-28 6:27:39
Message-ID: 200801280628.m0S6SLXJ006601 () mailer ! progressive-comp ! com
[Download RAW message or body]

Update of /cvsroot/protocol/common/util
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv23398

Modified Files:
	sdptools.cpp 
Log Message:
Reviewed By : Darrick Lew

Synopsis
=========

CR : Fix for PR 165066 : Poor MDP delivery of content with event streams

Branches: SERVER_CURRENT_RN

Suggested Reviewer: Darrick Lew, JZeng

Description

===========

When we played the event stream through MDP to realplayer 11, there is
some problem in buffer management manage by server.

Here is the details about it..

After playing the clips in realplayer 11, player sends the receiver
reports for every stream to server. The report contains the low_timestamp,
high timestamp etc.
With event stream the clip has three streams i.e 0(audio),1(video), 2(event)

Server uses the aggregate value of low_timestamp of all three streams. So
it takes the maximum value of low_timestamp between all three streams to
do the buffer management. So after getting low_timestamp, it removes all
packets from head of the buffer to till the low_timestamp value.

Assume clip contain event at 10sec and 1min.10sec.

The report received before the server send the 10sec data packet to player
is not having any problem. Till this period we get only two streams
low_timestamp in the report.

After server sends this 10sec event to player, in next receiver report
player sends the low_timestamp for all three streams. For event streams it
sends the low_timestamp value = 10000msec and for other two stream it
sends around 1200, 1250 msec respectively.
Here as we are using aggregate value in buffer management, low_timestamp
is get assigned 10000. So server thinks that player has played the packets
till 10000 msec. But actually player has played only 1200/1250 msec data.
But we remove from the buffer all the packets till 10000msec. So at this
point the buffer at server and at player is not in sync.

Fix
============

Add the code so that rdt_base is not sending signal for event stream to
change the low_timestamp of buffer management.

Files Affected
==============

server\protocol\transport\rdt\ rdt_base.cpp
protocol\common\util\sdptools.cpp
protocol\transp[ort\common\system\pub\rtspif.h
server\protocol\rtsp\ crtspbase.cpp

Testing Performed

=================

Functional Tests:
-----------------

- Verified by playing event stream through realplayer 11 and check the
logs and verify that rdt_base is not sending signal to buffer management.
Also verify in rate_manager logs that eviction of packet from buffer is
having properly.

Integration Tests:

n/a

Leak Tests:

n/a

Performance Tests:

n/a

Platforms Tested: win32-i386-vc7

Build verified:
win32-i386-vc7
linux-rhel4-i686
sunos-5.10-sparc-server

QA Hints
========

None

Thanks and Regards
Vijendra


Index: sdptools.cpp
===================================================================
RCS file: /cvsroot/protocol/common/util/sdptools.cpp,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- sdptools.cpp	6 Jul 2007 20:51:32 -0000	1.12
+++ sdptools.cpp	28 Jan 2008 06:27:37 -0000	1.13
@@ -50,12 +50,14 @@
 /****************************************************************************
  *  Defines
  */
-#define AUDIO_MIMETYPE_PREFIX	    "audio/"
+#define AUDIO_MIMETYPE_PREFIX       "audio/"
 #define AUDIO_MIMETYPE_PREFIX_SIZE  (sizeof(AUDIO_MIMETYPE_PREFIX) - 1)
-#define VIDEO_MIMETYPE_PREFIX	    "video/"
+#define VIDEO_MIMETYPE_PREFIX       "video/"
 #define VIDEO_MIMETYPE_PREFIX_SIZE  (sizeof(VIDEO_MIMETYPE_PREFIX) - 1)
-#define APP_MIMETYPE_PREFIX	    "application/"
+#define APP_MIMETYPE_PREFIX     "application/"
 #define APP_MIMETYPE_PREFIX_SIZE    (sizeof(APP_MIMETYPE_PREFIX) - 1)
+#define REALEVENT_MIME_TYPE         "application/x-pn-realevent"
+
 
 
 /****************************************************************************
@@ -90,10 +92,10 @@
 
     while (SUCCEEDED(retVal) && ((*pString) != '\0'))
     {
-	retVal = _HexCharPairToByte(pOutBuffer, pString);
+    retVal = _HexCharPairToByte(pOutBuffer, pString);
 
-	pOutBuffer++;
-	pString += 2;
+    pOutBuffer++;
+    pString += 2;
     }
 
     return retVal;
@@ -114,29 +116,29 @@
 
     do
     {
-	uIdx--;
+    uIdx--;
 
-	cBits = *pCharPair;
+    cBits = *pCharPair;
 
-	if ((cBits >= '0') && (cBits <= '9'))
-	{
-	    uAddVal = (UINT8)(cBits - '0');
-	}
-	else if ((cBits >= 'a') && (cBits <= 'f'))
-	{
-	    uAddVal = (UINT8)(cBits - 'a' + 10);
-	}
-	else if ((cBits >= 'A') && (cBits <= 'F'))
-	{
-	    uAddVal = (UINT8)(cBits - 'A' + 10);
-	}
-	else
-	{
-	    return HXR_FAIL;
-	}
+    if ((cBits >= '0') && (cBits <= '9'))
+    {
+        uAddVal = (UINT8)(cBits - '0');
+    }
+    else if ((cBits >= 'a') && (cBits <= 'f'))
+    {
+        uAddVal = (UINT8)(cBits - 'a' + 10);
+    }
+    else if ((cBits >= 'A') && (cBits <= 'F'))
+    {
+        uAddVal = (UINT8)(cBits - 'A' + 10);
+    }
+    else
+    {
+        return HXR_FAIL;
+    }
 
-	uByte += (UINT8)(uAddVal << (4 * uIdx));
-	pCharPair++;
+    uByte += (UINT8)(uAddVal << (4 * uIdx));
+    pCharPair++;
     } while ((uIdx != 0) && (*pCharPair != '\0'));
 
     *pByte = uByte;
@@ -151,7 +153,7 @@
 
     for(UINT32 i = 0; i < ulSize; i++)
     {
-	_ByteToHexCharPair(pBuffer[i], &pString[i*2]);
+    _ByteToHexCharPair(pBuffer[i], &pString[i*2]);
     }
 
     pString[ulSize*2] = '\0';
@@ -178,24 +180,29 @@
 
     if (pMimeType)
     {
-	if (strncasecmp(AUDIO_MIMETYPE_PREFIX, 
-			pMimeType, 
-			AUDIO_MIMETYPE_PREFIX_SIZE) == 0)
-	{
-	    eMediaType = RTSPMEDIA_TYPE_AUDIO;
-	}
-	else if (strncasecmp(VIDEO_MIMETYPE_PREFIX, 
-			pMimeType, 
-			VIDEO_MIMETYPE_PREFIX_SIZE) == 0)
-	{
-	    eMediaType = RTSPMEDIA_TYPE_VIDEO;
-	}
-	else if (strncasecmp(APP_MIMETYPE_PREFIX, 
-			pMimeType, 
-			APP_MIMETYPE_PREFIX_SIZE) == 0)
-	{
-	    eMediaType = RTSPMEDIA_TYPE_APP;
-	}
+    if (strncasecmp(AUDIO_MIMETYPE_PREFIX, 
+            pMimeType, 
+            AUDIO_MIMETYPE_PREFIX_SIZE) == 0)
+    {
+        eMediaType = RTSPMEDIA_TYPE_AUDIO;
+    }
+    else if (strncasecmp(VIDEO_MIMETYPE_PREFIX, 
+            pMimeType, 
+            VIDEO_MIMETYPE_PREFIX_SIZE) == 0)
+    {
+        eMediaType = RTSPMEDIA_TYPE_VIDEO;
+    }
+    else if (strcasecmp(REALEVENT_MIME_TYPE,
+        pMimeType) == 0)
+    {
+        eMediaType = RTSPMEDIA_TYPE_EVENT;
+    }
+    else if (strncasecmp(APP_MIMETYPE_PREFIX, 
+            pMimeType, 
+            APP_MIMETYPE_PREFIX_SIZE) == 0)
+    {
+        eMediaType = RTSPMEDIA_TYPE_APP;
+    }
     }
 
     return eMediaType;


_______________________________________________
Protocol-cvs mailing list
Protocol-cvs@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-cvs
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic