From mgupta at real.com Wed Dec 1 05:09:56 2004
From: mgupta at real.com (mgupta@real.com)
Date: Wed Dec 1 05:10:00 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
Message-ID: <52308.66.119.34.39.1101906596.squirrel@flawless.real.com>
Modified by: mgupta@real.com
Reviewed by: milko@real.com
Date: 12:01:04
Project: AVI File Format Support
Synopsis:
1) Riff.cpp was not keeping the exact offset of the file pointer. Fixed
the problem.
2) Changed the licence headers to tri-licensed in the AVI code.
Fix: Offset was being incremented by one when the offset was not short
aligned. This is not being done now.
Files Modified:
/datatype/avi/fileformat/avistrm.cpp
/datatype/avi/fileformat/aviffpln.cpp
/datatype/avi/fileformat/aviindx.cpp
/datatype/common/util/riff.cpp
/datatype/avi/fileformat/pub/avistrm.h
/datatype/avi/fileformat/pub/aviffpln.h
/datatype/avi/fileformat/pub/aviindx.h
/datatype/common/util/pub/riff.h
Files Added: None
Image Size and Heap Use impact: None
Platforms and Profiles Build Verified: Win32
Platforms and Profiles Functionality verified: Win32
Branch: head
Copyright assignment:
I agree to assign to RealNetworks full copyright ownership of the code
represented by the attached patch. I warrant that I am legally entitled to
grant the copyright assignment and that my contribution does not violate
any law or breach any contract. I understand that RealNetworks may license
this code under RPSL, RCSL, and/or any other license at RealNetworks' sole
discretion.
QA Instructions:
None
-------------- next part --------------
Index: aviffpln.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/aviffpln.cpp,v
retrieving revision 1.3
diff -u -w -r1.3 aviffpln.cpp
--- aviffpln.cpp 10 Nov 2004 11:01:08 -0000 1.3
+++ aviffpln.cpp 1 Dec 2004 12:45:02 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
-------------- next part --------------
Index: aviffpln.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
retrieving revision 1.2
diff -u -w -r1.2 aviffpln.h
--- aviffpln.h 17 Oct 2004 06:31:14 -0000 1.2
+++ aviffpln.h 1 Dec 2004 12:48:21 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
-------------- next part --------------
Index: aviindx.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/aviindx.cpp,v
retrieving revision 1.3
diff -u -w -r1.3 aviindx.cpp
--- aviindx.cpp 10 Nov 2004 11:01:59 -0000 1.3
+++ aviindx.cpp 1 Dec 2004 12:47:23 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
-------------- next part --------------
Index: aviindx.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/aviindx.h,v
retrieving revision 1.3
diff -u -w -r1.3 aviindx.h
--- aviindx.h 10 Nov 2004 11:04:34 -0000 1.3
+++ aviindx.h 1 Dec 2004 12:49:06 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
-------------- next part --------------
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.3
diff -u -w -r1.3 avistrm.cpp
--- avistrm.cpp 10 Nov 2004 11:00:19 -0000 1.3
+++ avistrm.cpp 1 Dec 2004 12:58:33 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
@@ -34,10 +48,12 @@
* ***** END LICENSE BLOCK ***** */
//#ifndef USE_SIMPLE_SEGMENT_PAYLOAD
-//#define USE_SIMPLE_SEGMENT_PAYLOAD 0 // SimpleSegmentPayload is used in case it
+//#define USE_SIMPLE_SEGMENT_PAYLOAD // SimpleSegmentPayload is used in case it
//#endif // is required that dwSuggestedBufferSize
// for each of the streams is used.
+#define HELIX_FEATURE_AVIFF_NATIVE_H263_MACRO 0
+
#include "aviffpln.h"
#include "aviindx.h"
#include "avistrm.h"
@@ -293,6 +309,8 @@
m_chunkPrefetchArray[i].pBuffer = NULL;
}
#endif
+
+// m_bLocalPlayback = FALSE;
}
@@ -554,6 +572,10 @@
case AVI_VIDS_TYPE:
{
BitmapInfo* bi = (BitmapInfo*) m_pFormat;
+
+ pHeader->SetPropertyULONG32("Width", bi->ulWidth);
+ pHeader->SetPropertyULONG32("Height", bi->ulHeight);
+
if (bi->ulCompression == BI_RGB)
{
QT_VIDEO_HEADER vhead;
@@ -606,8 +628,28 @@
else
#endif // 0
{
+#if HELIX_FEATURE_AVIFF_NATIVE_H263_MACRO
+ if (m_header.ulHandler == 0x48323633)
+ {
+ IHXBuffer *pASMRuleBook = NULL;
+
+ if (HXR_OK == m_pCommonClassFactory->CreateInstance(CLSID_IHXBuffer,
+ (void**)&pASMRuleBook))
+ {
+ pASMRuleBook->Set((const BYTE*)"Marker=0;Marker=1;", 18+1);
+ pHeader->SetPropertyCString("ASMRuleBook", pASMRuleBook);
+ }
+
+ strcpy(szStreamName, "Video Track");
+ strcpy (szMimeType, "video/X-RN-3GPP-H263");
+ }
+ else
+#endif
+ {
+ strcpy(szStreamName, "An AVI stream");
strcpy(szMimeType, "video/x-pn-icm-plugin");
}
+ }
HeaderInfo hi;
hi.frameRect.left = 0;
@@ -655,6 +697,8 @@
pHeader->SetPropertyULONG32("PacketsSegmented", 0);
}
+ pHeader->SetPropertyULONG32("SamplesPerSecond", (UINT32) m_fSamplesPerSecond);
+
break;
}
case AVI_AUDS_TYPE:
@@ -1335,7 +1379,7 @@
//
UINT32 CAVIStream::PeekPacketTime()
{
- HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
+ //HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
if (m_pNextPacket)
{
return m_pNextPacket->GetTime();
@@ -1567,11 +1611,12 @@
{
// Find the time of the next packet.
UINT32 ulNextPacketTime;
+ UINT32 ulChunkSize = m_pReader->GetChunkRawSize ();
if (IsAudio ())
{
WaveInfo* pWaveInfo = (WaveInfo*) m_pFormat;
- ulNextPacketTime = (UINT32) (((double)(m_ulTotalBytesRead + len) / pWaveInfo->ulAvgBytesPerSec) * 1000);
+ ulNextPacketTime = (UINT32) (((double)(m_ulTotalBytesRead + ulChunkSize) / pWaveInfo->ulAvgBytesPerSec) * 1000);
}
else
{
@@ -1583,8 +1628,8 @@
// Discard the packet.
m_ulChunkReadTarget++;
m_ulMaxReadChunk = m_ulMinReadChunk = m_ulChunkReadTarget;
- m_ulTotalBytesPacketised += len;
- m_ulTotalBytesRead += len;
+ m_ulTotalBytesPacketised += ulChunkSize;
+ m_ulTotalBytesRead += ulChunkSize;
m_state = eChunkSeek;
m_pReader->FileSeek(m_pReader->GetOffset () + len);
return HXR_OK;
@@ -1651,6 +1696,7 @@
return HXR_OK;
}
+ pBuffer->SetSize (m_pReader->GetChunkRawSize ());
UINT32 bufferSize = pBuffer->GetSize();
if (!m_pNextPacket)
-------------- next part --------------
Index: avistrm.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
retrieving revision 1.3
diff -u -w -r1.3 avistrm.h
--- avistrm.h 10 Nov 2004 11:05:22 -0000 1.3
+++ avistrm.h 1 Dec 2004 12:48:46 -0000
@@ -1,30 +1,44 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Version: RCSL 1.0/RPSL 1.0
+ * Source last modified: $Id:$
*
- * Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
+ * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
- * The contents of this file, and the files included with this file, are
- * subject to the current version of the RealNetworks Public Source License
- * Version 1.0 (the "RPSL") available at
+ * The contents of this file, and the files included with this file,
+ * are subject to the current version of the RealNetworks Public
+ * Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
- * the file under the RealNetworks Community Source License Version 1.0
- * (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
- * in which case the RCSL will apply. You may also obtain the license terms
- * directly from RealNetworks. You may not use this file except in
- * compliance with the RPSL or, if you have a valid RCSL with RealNetworks
- * applicable to this file, the RCSL. Please see the applicable RPSL or
- * RCSL for the rights, obligations and limitations governing use of the
+ * the file under the current version of the RealNetworks Community
+ * Source License (the "RCSL") available at
+ * http://www.helixcommunity.org/content/rcsl, in which case the RCSL
+ * will apply. You may also obtain the license terms directly from
+ * RealNetworks. You may not use this file except in compliance with
+ * the RPSL or, if you have a valid RCSL with RealNetworks applicable
+ * to this file, the RCSL. Please see the applicable RPSL or RCSL for
+ * the rights, obligations and limitations governing use of the
* contents of the file.
*
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL") in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your version of
+ * this file only under the terms of the GPL, and not to allow others
+ * to use your version of this file under the terms of either the RPSL
+ * or RCSL, indicate your decision by deleting the provisions above
+ * and replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient may
+ * use your version of this file under the terms of any one of the
+ * RPSL, the RCSL or the GPL.
+ *
* This file is part of the Helix DNA Technology. RealNetworks is the
- * developer of the Original Code and owns the copyrights in the portions
- * it created.
+ * developer of the Original Code and owns the copyrights in the
+ * portions it created.
*
- * This file, and the files included with this file, is distributed and made
- * available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
- * EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
- * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
- * FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
+ * This file, and the files included with this file, is distributed
+ * and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
+ * KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
+ * ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
+ * ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
-------------- next part --------------
Index: riff.cpp
===================================================================
RCS file: /cvsroot/datatype/common/util/riff.cpp,v
retrieving revision 1.9
diff -u -w -r1.9 riff.cpp
--- riff.cpp 10 Nov 2004 11:09:06 -0000 1.9
+++ riff.cpp 1 Dec 2004 12:51:40 -0000
@@ -299,17 +299,6 @@
}
}
- if ( m_ulFileType == RIFF_FILE_MAGIC_NUMBER ||
- m_ulFileType == IFF_FILE_MAGIC_NUMBER )
- {
- // Make sure the offset is aligned(2 bytes)
- uRem = (UINT16)(m_ulCurOffset % 2);
- if ( uRem != 0 )
- {
- m_ulCurOffset += 1;
- }
- }
-
switch ( m_state )
{
case RS_GetFileTypePending:
@@ -384,6 +373,8 @@
// Found the chunk we were asked for
m_state = RS_Ready;
m_ulChunkBodyLen = GetLong(&buf[4]);
+ m_ulChunkSize = m_ulChunkBodyLen;
+
// Make sure the body length is aligned(2 bytes)
if ( m_ulFileType == RIFF_FILE_MAGIC_NUMBER )
{
@@ -475,6 +466,7 @@
m_ulGetChunkType = (UINT32)getlong(buf);
m_state = RS_ReadChunkBodyPending;
LONG32 baseLen = GetLong(&buf[4]);
+ m_ulChunkSize = baseLen;
if ( (m_ulFileType == RIFF_FILE_MAGIC_NUMBER) &&
(m_ulGetChunkType == (UINT32)0) )
@@ -563,6 +555,14 @@
m_ulChunkType = (UINT32)getlong(buf);
m_state = RS_ReadChunkBodyPending;
LONG32 baseLen = GetLong(&buf[4]);
+ m_ulChunkSize = baseLen;
+
+ if ((m_ulFileType == RIFF_FILE_MAGIC_NUMBER ||
+ m_ulFileType == IFF_FILE_MAGIC_NUMBER) &&
+ (baseLen % 2 == 1))
+ {
+ baseLen++;
+ }
if ( (m_ulFileType == RIFF_FILE_MAGIC_NUMBER) &&
(m_ulGetChunkType == (UINT32)0) )
@@ -742,6 +742,16 @@
m_ulLevel++;
m_levelInfo[m_ulLevel].m_startOffset = m_ulCurOffset;
+
+ if (m_ulFileType == RIFF_FILE_MAGIC_NUMBER ||
+ m_ulFileType == IFF_FILE_MAGIC_NUMBER)
+ {
+ if (m_ulCurOffset % 2 == 1)
+ {
+ m_levelInfo[m_ulLevel].m_startOffset++;
+ }
+ }
+
m_levelInfo[m_ulLevel].started = FALSE;
return m_pResponse->RIFFDescendDone(HXR_OK);
@@ -837,4 +847,10 @@
CRIFFReader::GetChunkType()
{
return m_ulChunkType;
+}
+
+UINT32
+CRIFFReader::GetChunkRawSize(void)
+{
+ return m_ulChunkSize;
}
-------------- next part --------------
Index: riff.h
===================================================================
RCS file: /cvsroot/datatype/common/util/pub/riff.h,v
retrieving revision 1.4
diff -u -w -r1.4 riff.h
--- riff.h 10 Nov 2004 11:09:58 -0000 1.4
+++ riff.h 1 Dec 2004 12:52:55 -0000
@@ -175,6 +175,7 @@
UINT32 GetListType();
UINT32 GetOffset();
UINT32 GetChunkType();
+ UINT32 GetChunkRawSize(void);
private:
struct LevelInfo
From ehyche at real.com Wed Dec 1 06:33:52 2004
From: ehyche at real.com (Eric Hyche)
Date: Wed Dec 1 06:33:58 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
In-Reply-To: <52308.66.119.34.39.1101906596.squirrel@flawless.real.com>
Message-ID: <5.1.0.14.2.20041201092140.0213edd8@mailone.real.com>
Some comments:
>@@ -34,10 +48,12 @@
> * ***** END LICENSE BLOCK ***** */
>
> //#ifndef USE_SIMPLE_SEGMENT_PAYLOAD
>-//#define USE_SIMPLE_SEGMENT_PAYLOAD 0 //
SimpleSegmentPayload is used in case it
>+//#define USE_SIMPLE_SEGMENT_PAYLOAD // SimpleSegmentPayload is
used in case it
>
//#endif
//
>
Why it this still here if it's commented out?
>@@ -293,6 +309,8 @@
> m_chunkPrefetchArray[i].pBuffer = NULL;
> }
> #endif
>+
>+// m_bLocalPlayback = FALSE;
> }
Same comment - do we need this if it's commented out?
>+#if HELIX_FEATURE_AVIFF_NATIVE_H263_MACRO
>+ if (m_header.ulHandler == 0x48323633)
>+ {
>+ IHXBuffer *pASMRuleBook = NULL;
>+
>+ if (HXR_OK ==
m_pCommonClassFactory->CreateInstance(CLSID_IHXBuffer,
>+
(void**)&pASMRuleBook))
>+ {
>+ pASMRuleBook->Set((const
BYTE*)"Marker=0;Marker=1;", 18+1);
>+
pHeader->SetPropertyCString("ASMRuleBook", pASMRuleBook);
>+ }
>+
Please use SetCStringPropertyCCF() (in common/util/pub/pckunpck.h)
to do this. It would look like:
if (m_header.ulHandler == 0x48323633)
{
SetCStringPropertyCCF(pHeader, "ASMRuleBook, "Marker=0;Marker=1;",
m_pContext);
}
>@@ -1335,7 +1379,7 @@
> //
> UINT32 CAVIStream::PeekPacketTime()
> {
>- HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
>+ //HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
>
Why was this commented out?
The rest looks good.
Eric
At 05:09 AM 12/1/2004 -0800, mgupta@real.com wrote:
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Modified by: mgupta@real.com
>Reviewed by: milko@real.com
>Date: 12:01:04
>Project: AVI File Format Support
>
>Synopsis:
>1) Riff.cpp was not keeping the exact offset of the file pointer. Fixed
>the problem.
>2) Changed the licence headers to tri-licensed in the AVI code.
>
>Fix: Offset was being incremented by one when the offset was not short
>aligned. This is not being done now.
>
>Files Modified:
>
>/datatype/avi/fileformat/avistrm.cpp
>/datatype/avi/fileformat/aviffpln.cpp
>/datatype/avi/fileformat/aviindx.cpp
>/datatype/common/util/riff.cpp
>/datatype/avi/fileformat/pub/avistrm.h
>/datatype/avi/fileformat/pub/aviffpln.h
>/datatype/avi/fileformat/pub/aviindx.h
>/datatype/common/util/pub/riff.h
>
>
>Files Added: None
>
>Image Size and Heap Use impact: None
>Platforms and Profiles Build Verified: Win32
>Platforms and Profiles Functionality verified: Win32
>
>Branch: head
>
>Copyright assignment:
>I agree to assign to RealNetworks full copyright ownership of the code
>represented by the attached patch. I warrant that I am legally entitled to
>grant the copyright assignment and that my contribution does not violate
>any law or breach any contract. I understand that RealNetworks may license
>this code under RPSL, RCSL, and/or any other license at RealNetworks' sole
>discretion.
>
>QA Instructions:
>None
>
>Content-Type: text/plain; name="aviffpln_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviffpln_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviffpln_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviffpln_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviindx_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviindx_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviindx_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviindx_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="avistrm_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="avistrm_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="avistrm_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="avistrm_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="riff_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="riff_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="riff_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="riff_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From milko at real.com Wed Dec 1 11:47:23 2004
From: milko at real.com (milko)
Date: Wed Dec 1 11:47:35 2004
Subject: [datatype-dev] Re: CN-Client: AVI File Format support
In-Reply-To: <52308.66.119.34.39.1101906596.squirrel@flawless.real.com>
Message-ID: <5.1.0.14.2.20041201114711.03880b80@mailone.real.com>
Looks good.
At 05:09 AM 12/1/2004, mgupta@real.com wrote:
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Modified by: mgupta@real.com
>Reviewed by: milko@real.com
>Date: 12:01:04
>Project: AVI File Format Support
>
>Synopsis:
>1) Riff.cpp was not keeping the exact offset of the file pointer. Fixed
>the problem.
>2) Changed the licence headers to tri-licensed in the AVI code.
>
>Fix: Offset was being incremented by one when the offset was not short
>aligned. This is not being done now.
>
>Files Modified:
>
>/datatype/avi/fileformat/avistrm.cpp
>/datatype/avi/fileformat/aviffpln.cpp
>/datatype/avi/fileformat/aviindx.cpp
>/datatype/common/util/riff.cpp
>/datatype/avi/fileformat/pub/avistrm.h
>/datatype/avi/fileformat/pub/aviffpln.h
>/datatype/avi/fileformat/pub/aviindx.h
>/datatype/common/util/pub/riff.h
>
>
>Files Added: None
>
>Image Size and Heap Use impact: None
>Platforms and Profiles Build Verified: Win32
>Platforms and Profiles Functionality verified: Win32
>
>Branch: head
>
>Copyright assignment:
>I agree to assign to RealNetworks full copyright ownership of the code
>represented by the attached patch. I warrant that I am legally entitled to
>grant the copyright assignment and that my contribution does not violate
>any law or breach any contract. I understand that RealNetworks may license
>this code under RPSL, RCSL, and/or any other license at RealNetworks' sole
>discretion.
>
>QA Instructions:
>None
>
>Content-Type: text/plain; name="aviffpln_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviffpln_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviffpln_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviffpln_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviindx_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviindx_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="aviindx_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="aviindx_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="avistrm_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="avistrm_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="avistrm_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="avistrm_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="riff_cpp.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="riff_cpp.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>Content-Type: text/plain; name="riff_h.txt"; charset=iso-8859-1
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="riff_h.txt"
>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
From sgavali at pace.stpp.soft.net Thu Dec 2 01:03:53 2004
From: sgavali at pace.stpp.soft.net (Santosh)
Date: Thu Dec 2 01:04:04 2004
Subject: [datatype-dev] Initial train like noise in playback
In-Reply-To: <5.1.0.14.2.20041124092054.01c5dbf8@mailone.real.com>
Message-ID:
Hi,
I have kept IDEAL_MINIMAL_INITIAL_PUSHDOWN 500 & MINIMUM_INITIAL_PUSHDOWN
2000, with these values I'm getting train like noise for RA files.
With the values of 160 & 100 respectively there is no noise ! What may be
the reason ?
Regards,
Santosh
From mgupta at real.com Thu Dec 2 08:11:07 2004
From: mgupta at real.com (mgupta@real.com)
Date: Thu Dec 2 08:11:11 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
In-Reply-To: <5.1.0.14.2.20041201092140.0213edd8@mailone.real.com>
References: <52308.66.119.34.39.1101906596.squirrel@flawless.real.com>
<5.1.0.14.2.20041201092140.0213edd8@mailone.real.com>
Message-ID: <1260.192.168.129.189.1102003867.squirrel@goodfellas.real.com>
Hi Eric,
Please see the answers below.
Regards,
Mukesh
>
> Some comments:
>
> >@@ -34,10 +48,12 @@
> > * ***** END LICENSE BLOCK ***** */
> >
> > //#ifndef USE_SIMPLE_SEGMENT_PAYLOAD
> >-//#define USE_SIMPLE_SEGMENT_PAYLOAD 0 //
> SimpleSegmentPayload is used in case it
> >+//#define USE_SIMPLE_SEGMENT_PAYLOAD // SimpleSegmentPayload is
> used in case it
> >
> //#endif
> //
> >
> Why it this still here if it's commented out?
>>There was some problem coming up after using SimplePayload class which
is >>being used for packetization support. If any further changes needs
to be >>done, then this need to be un-commented. Thats why I have left
it.
>
> >@@ -293,6 +309,8 @@
> > m_chunkPrefetchArray[i].pBuffer = NULL;
> > }
> > #endif
> >+
> >+// m_bLocalPlayback = FALSE;
> > }
>
> Same comment - do we need this if it's commented out?
>
>> This I added for testing purposes, but can be removed.
> >+#if HELIX_FEATURE_AVIFF_NATIVE_H263_MACRO
> >+ if (m_header.ulHandler == 0x48323633)
> >+ {
> >+ IHXBuffer *pASMRuleBook = NULL;
> >+
> >+ if (HXR_OK ==
> m_pCommonClassFactory->CreateInstance(CLSID_IHXBuffer,
> >+
> (void**)&pASMRuleBook))
> >+ {
> >+ pASMRuleBook->Set((const
> BYTE*)"Marker=0;Marker=1;", 18+1);
> >+
> pHeader->SetPropertyCString("ASMRuleBook", pASMRuleBook);
> >+ }
> >+
>
> Please use SetCStringPropertyCCF() (in common/util/pub/pckunpck.h)
> to do this. It would look like:
>
> if (m_header.ulHandler == 0x48323633)
> {
> SetCStringPropertyCCF(pHeader, "ASMRuleBook, "Marker=0;Marker=1;",
> m_pContext);
> }
>> I will do the suggested change.
>
> >@@ -1335,7 +1379,7 @@
> > //
> > UINT32 CAVIStream::PeekPacketTime()
> > {
> >- HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
> >+ //HX_TRACE("CAVIFileFormat::CAVIStream::GetNextPacketTime()\n");
> >
> Why was this commented out?
>> At all the places in the code, HX_TRACE statements are commented out.
>>This was not commented initially. So, I commented this one also.
>
> The rest looks good.
>
> Eric
>
> At 05:09 AM 12/1/2004 -0800, mgupta@real.com wrote:
>>Content-Type: text/plain; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Modified by: mgupta@real.com
>>Reviewed by: milko@real.com
>>Date: 12:01:04
>>Project: AVI File Format Support
>>
>>Synopsis:
>>1) Riff.cpp was not keeping the exact offset of the file pointer. Fixed
>>the problem.
>>2) Changed the licence headers to tri-licensed in the AVI code.
>>
>>Fix: Offset was being incremented by one when the offset was not short
>>aligned. This is not being done now.
>>
>>Files Modified:
>>
>>/datatype/avi/fileformat/avistrm.cpp
>>/datatype/avi/fileformat/aviffpln.cpp
>>/datatype/avi/fileformat/aviindx.cpp
>>/datatype/common/util/riff.cpp
>>/datatype/avi/fileformat/pub/avistrm.h
>>/datatype/avi/fileformat/pub/aviffpln.h
>>/datatype/avi/fileformat/pub/aviindx.h
>>/datatype/common/util/pub/riff.h
>>
>>
>>Files Added: None
>>
>>Image Size and Heap Use impact: None
>>Platforms and Profiles Build Verified: Win32
>>Platforms and Profiles Functionality verified: Win32
>>
>>Branch: head
>>
>>Copyright assignment:
>>I agree to assign to RealNetworks full copyright ownership of the code
>>represented by the attached patch. I warrant that I am legally entitled
>> to
>>grant the copyright assignment and that my contribution does not violate
>>any law or breach any contract. I understand that RealNetworks may
>> license
>>this code under RPSL, RCSL, and/or any other license at RealNetworks'
>> sole
>>discretion.
>>
>>QA Instructions:
>>None
>>
>>Content-Type: text/plain; name="aviffpln_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviffpln_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviffpln_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviffpln_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviindx_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviindx_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviindx_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviindx_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="avistrm_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="avistrm_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="avistrm_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="avistrm_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="riff_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="riff_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="riff_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="riff_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
>
>
From kross at real.com Thu Dec 2 09:35:29 2004
From: kross at real.com (Kevin Ross)
Date: Thu Dec 2 09:35:33 2004
Subject: [datatype-dev] CR-Client: Fix looping audio at end of clip,
also fixes crossfade hiccups
Message-ID: <6.1.2.0.2.20041202091812.043c8460@mailone.real.com>
Synopsis:
Fixes looping audio at the end of a clip. Also fixes the audio hiccups
heard during crossfade in RealPlayer.
Overview:
The bug comes from the fact that audio services can't tell the difference
between network congestion or end of stream when it runs dry. It was
assuming congestion, and that a rebuffer would be required, and would stop
writing data to the audio device, waiting for the OnDryNotifications to
signal a rebuffer is needed. This doesn't work in two scenarios. One is
end of stream. When audio services stops writing to the audio device, but
allows the audio device to keep playing, then the audio device runs dry and
starts looping. The second case is when the audio renderer doesn't care
that audio services has run dry. The renderer might want audio services to
just continue anyway, inserting silence instead of rebuffering.
The fix is to have a different return value from the OnDryNotification that
the audio services can act upon. If it returns HXR_OK, then that means the
audio renderer has no more data to give, and audio services should continue
normally, inserting silence if needed. HXR_WOULD_BLOCK means the audio
renderer has run dry and a rebuffer will occur. In this case, audio
services will stop writing data to the audio device, waiting for a
rebuffer, just like before.
Files Modified:
client/audiosvc/hxaudstr_new.cpp - changed the
CHXAudioStream::MixIntoBuffer to handle different return codes from
OnDryNotification
datatype/common/audrend/audrend.cpp - changed OnDryNotification to return
HXR_WOULD_BLOCK when rebuffering
datatype/mp3/renderer/mp3rend.cpp
datatype/rm/audio/renderer/rarender.cpp
datatype/wav/renderer/pcm/pcmrendr.cpp
Image Size and Heap Use impact:
none
Platforms and Profiles Affected:
all
Distribution Libraries affected:
none
Distribution library impact and planned action:
none
-----------------------------------------------------------
Platforms and Profiles Build Verified:
win32-i386-vc7, helix-client-all-defines
Platforms and Profiles Functionality verified:
win32-i386-vc7, helix-client-all-defines
Branch:
HEAD
QA Instructions:
Index: client/audiosvc/hxaudstr_new.cpp
===================================================================
RCS file: /cvsroot/client/audiosvc/hxaudstr_new.cpp,v
retrieving revision 1.27
diff -u -w -b -r1.27 hxaudstr_new.cpp
--- client/audiosvc/hxaudstr_new.cpp 19 Oct 2004 21:30:10 -0000 1.27
+++ client/audiosvc/hxaudstr_new.cpp 29 Nov 2004 22:47:38 -0000
@@ -1616,6 +1616,7 @@
// to the source which sets m_rebufferStatus = REBUFFER_WARNING
if (m_DryNotificationMap->GetCount() > 0)
{
+ BOOL bWouldBlock = FALSE;
IHXDryNotification* pDryNotification = 0;
CHXMapPtrToPtr::Iterator lIter = m_DryNotificationMap->Begin();
for (; lIter != m_DryNotificationMap->End(); ++lIter)
@@ -1629,9 +1630,13 @@
{
return theErr;
}
+ else if (theErr == HXR_WOULD_BLOCK)
+ {
+ bWouldBlock = TRUE;
+ }
}
- if (!bIsMixBufferDirty)
+ if (bWouldBlock)
{
return HXR_WOULD_BLOCK;
}
Index: datatype/common/audrend/audrend.cpp
===================================================================
RCS file: /cvsroot/datatype/common/audrend/audrend.cpp,v
retrieving revision 1.34
diff -u -w -b -r1.34 audrend.cpp
--- datatype/common/audrend/audrend.cpp 3 Sep 2004 01:24:26 -0000 1.34
+++ datatype/common/audrend/audrend.cpp 1 Dec 2004 21:24:01 -0000
@@ -911,6 +911,8 @@
STDMETHODIMP CAudioRenderer::OnDryNotification(UINT32 /*IN*/
ulCurrentStreamTime,
UINT32 /*IN*/
ulMinimumDurationRequired)
{
+ HX_RESULT hr = HXR_OK;
+
MLOG_MISC(m_pErrorMessages, "ODN (%lu,%lu)\n",
ulCurrentStreamTime, ulMinimumDurationRequired);
/* If the renderer is delayed, do not report rebuffer status until the
@@ -954,13 +956,14 @@
IsTimeLess(m_ulLastWriteTime, ulAudioWantedTime))
{
StartRebuffer(ulAudioWantedTime);
+ hr = HXR_WOULD_BLOCK;
}
}
exit:
m_pMutex->Unlock();
- return HXR_OK;
+ return hr;
}
Index: datatype/mp3/renderer/mp3rend.cpp
===================================================================
RCS file: /cvsroot/datatype/mp3/renderer/mp3rend.cpp,v
retrieving revision 1.22
diff -u -w -b -r1.22 mp3rend.cpp
--- datatype/mp3/renderer/mp3rend.cpp 2 Nov 2004 22:53:05 -0000 1.22
+++ datatype/mp3/renderer/mp3rend.cpp 1 Dec 2004 21:24:01 -0000
@@ -845,6 +845,8 @@
CRnMp3Ren::OnDryNotification(UINT32 /*IN*/ ulCurrentStreamTime,
UINT32 /*IN*/ ulMinimumDurationRequired)
{
+ HX_RESULT hr = HXR_OK;
+
// We do not set our rebuffer flag at the end of a stream
if (m_bEndOfPackets || !m_pStream)
return HXR_OK;
@@ -878,10 +880,11 @@
m_pPacketParser->GetTimePerPkt() + 1);
}
m_pStream->ReportRebufferStatus(m_nPacketsNeeded, 0);
+ hr = HXR_WOULD_BLOCK;
}
#endif
- return HXR_OK;
+ return hr;
}
STDMETHODIMP
Index: datatype/rm/audio/renderer/rarender.cpp
===================================================================
RCS file: /cvsroot/datatype/rm/audio/renderer/rarender.cpp,v
retrieving revision 1.44
diff -u -w -b -r1.44 rarender.cpp
--- datatype/rm/audio/renderer/rarender.cpp 2 Nov 2004 22:53:05
-0000 1.44
+++ datatype/rm/audio/renderer/rarender.cpp 1 Dec 2004 21:24:01 -0000
@@ -2260,6 +2260,8 @@
STDMETHODIMP CRealAudioRenderer::OnDryNotification(UINT32 /*IN*/
ulCurrentStreamTime,
UINT32 /*IN*/
ulMinimumDurationRequired)
{
+ HX_RESULT hr = HXR_OK;
+
// If we are playing at non-1x playback, then don't
// take any action on a OnDryNotification
if (m_lPlaybackVelocity != HX_PLAYBACK_VELOCITY_NORMAL)
@@ -2453,6 +2455,8 @@
m_pStream->ReportRebufferStatus(1,0);
}
+ hr = HXR_WOULD_BLOCK;
+
DEBUG_OUTF(SWITCH_FILE,
(s, "Entering Buffering\t%u\n",
m_usCurrentDryNotificationStream));
DEBUG_OUT(m_pErrorMessages, DOL_REALAUDIO,
@@ -2477,7 +2481,7 @@
exit:
m_pMutex->Unlock();
- return HXR_OK;
+ return hr;
}
#ifdef _MACINTOSH
Index: datatype/wav/renderer/pcm/pcmrendr.cpp
===================================================================
RCS file: /cvsroot/datatype/wav/renderer/pcm/pcmrendr.cpp,v
retrieving revision 1.2
diff -u -w -b -r1.2 pcmrendr.cpp
--- datatype/wav/renderer/pcm/pcmrendr.cpp 24 Oct 2003 17:07:17
-0000 1.2
+++ datatype/wav/renderer/pcm/pcmrendr.cpp 1 Dec 2004 21:24:02 -0000
@@ -904,6 +904,8 @@
STDMETHODIMP CPCMRenderer::OnDryNotification(UINT32 /*IN*/
ulCurrentStreamTime,
UINT32 /*IN*/
ulMinimumDurationRequired)
{
+ HX_RESULT hr = HXR_OK;
+
if ((!m_bPacketsDone) && m_pStream)
{
// {FILE* f1 = ::fopen("c:\\aurend.txt", "a+"); ::fprintf(f1,
"DryNotification tickCount: %11lu\n", HX_GET_BETTERTICKCOUNT());::fclose(f1);}
@@ -911,9 +913,10 @@
m_pStream->ReportRebufferStatus(DRY_BUFFER_COUNT, 0);
m_bStreamDry = TRUE;
m_chBufferingCount = 0;
+ hr = HXR_WOULD_BLOCK;
}
- return HXR_OK;
+ return hr;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041202/ced50e79/attachment-0001.htm
From mgupta at real.com Thu Dec 2 10:30:41 2004
From: mgupta at real.com (mgupta@real.com)
Date: Thu Dec 2 10:30:46 2004
Subject: [datatype-dev] Re: CN-Client: AVI File Format support
In-Reply-To: <5.1.0.14.2.20041201114711.03880b80@mailone.real.com>
References: <52308.66.119.34.39.1101906596.squirrel@flawless.real.com>
<5.1.0.14.2.20041201114711.03880b80@mailone.real.com>
Message-ID: <3389.192.168.128.131.1102012241.squirrel@serpico.real.com>
Code checked in.
>
> Looks good.
>
> At 05:09 AM 12/1/2004, mgupta@real.com wrote:
>>Content-Type: text/plain; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Modified by: mgupta@real.com
>>Reviewed by: milko@real.com
>>Date: 12:01:04
>>Project: AVI File Format Support
>>
>>Synopsis:
>>1) Riff.cpp was not keeping the exact offset of the file pointer. Fixed
>>the problem.
>>2) Changed the licence headers to tri-licensed in the AVI code.
>>
>>Fix: Offset was being incremented by one when the offset was not short
>>aligned. This is not being done now.
>>
>>Files Modified:
>>
>>/datatype/avi/fileformat/avistrm.cpp
>>/datatype/avi/fileformat/aviffpln.cpp
>>/datatype/avi/fileformat/aviindx.cpp
>>/datatype/common/util/riff.cpp
>>/datatype/avi/fileformat/pub/avistrm.h
>>/datatype/avi/fileformat/pub/aviffpln.h
>>/datatype/avi/fileformat/pub/aviindx.h
>>/datatype/common/util/pub/riff.h
>>
>>
>>Files Added: None
>>
>>Image Size and Heap Use impact: None
>>Platforms and Profiles Build Verified: Win32
>>Platforms and Profiles Functionality verified: Win32
>>
>>Branch: head
>>
>>Copyright assignment:
>>I agree to assign to RealNetworks full copyright ownership of the code
>>represented by the attached patch. I warrant that I am legally entitled
>> to
>>grant the copyright assignment and that my contribution does not violate
>>any law or breach any contract. I understand that RealNetworks may
>> license
>>this code under RPSL, RCSL, and/or any other license at RealNetworks'
>> sole
>>discretion.
>>
>>QA Instructions:
>>None
>>
>>Content-Type: text/plain; name="aviffpln_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviffpln_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviffpln_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviffpln_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviindx_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviindx_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="aviindx_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="aviindx_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="avistrm_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="avistrm_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="avistrm_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="avistrm_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="riff_cpp.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="riff_cpp.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>>
>>Content-Type: text/plain; name="riff_h.txt"; charset=iso-8859-1
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: attachment; filename="riff_h.txt"
>>X-Mime-Autoconverted: from 8bit to 7bit by courier 0.44
>
>
>
From ehodge at real.com Thu Dec 2 10:34:58 2004
From: ehodge at real.com (Erik Hodge)
Date: Thu Dec 2 10:35:31 2004
Subject: [datatype-dev] CR-Client: Fix looping audio at end of
clip, also fixes crossfade hiccups
In-Reply-To: <6.1.2.0.2.20041202091812.043c8460@mailone.real.com>
Message-ID: <5.1.0.14.2.20041202103004.0203c608@mailone.real.com>
Looks good. Note: while watching a live broadcast this past Tues,
the audio looped for a bit just before the server disconnected.
This was live so not an end-of-stream situation. I couldn't repro
after that because it turned out the host's 'net connection had
gone down. Will the below changes will fix that situation as well?
- Erik
At 09:35 AM 12/2/2004 -0800, Kevin Ross wrote:
>Synopsis:
>Fixes looping audio at the end of a clip. Also fixes the audio hiccups
>heard during crossfade in RealPlayer.
>
>Overview:
>The bug comes from the fact that audio services can't tell the difference
>between network congestion or end of stream when it runs dry. It was
>assuming congestion, and that a rebuffer would be required, and would stop
>writing data to the audio device, waiting for the OnDryNotifications to
>signal a rebuffer is needed. This doesn't work in two scenarios. One is
>end of stream. When audio services stops writing to the audio device, but
>allows the audio device to keep playing, then the audio device runs dry
>and starts looping. The second case is when the audio renderer doesn't
>care that audio services has run dry. The renderer might want audio
>services to just continue anyway, inserting silence instead of rebuffering.
>
>The fix is to have a different return value from the OnDryNotification
>that the audio services can act upon. If it returns HXR_OK, then that
>means the audio renderer has no more data to give, and audio services
>should continue normally, inserting silence if needed. HXR_WOULD_BLOCK
>means the audio renderer has run dry and a rebuffer will occur. In this
>case, audio services will stop writing data to the audio device, waiting
>for a rebuffer, just like before.
>
>Files Modified:
>client/audiosvc/hxaudstr_new.cpp - changed the
>CHXAudioStream::MixIntoBuffer to handle different return codes from
>OnDryNotification
>datatype/common/audrend/audrend.cpp - changed OnDryNotification to return
>HXR_WOULD_BLOCK when rebuffering
>datatype/mp3/renderer/mp3rend.cpp
>datatype/rm/audio/renderer/rarender.cpp
>datatype/wav/renderer/pcm/pcmrendr.cpp
>
>Image Size and Heap Use impact:
>none
>
>Platforms and Profiles Affected:
>all
>
>Distribution Libraries affected:
>none
>
>Distribution library impact and planned action:
>none
>
>-----------------------------------------------------------
>
>Platforms and Profiles Build Verified:
>win32-i386-vc7, helix-client-all-defines
>
>Platforms and Profiles Functionality verified:
>win32-i386-vc7, helix-client-all-defines
>
>Branch:
>HEAD
>
>QA Instructions:
>
>
>Index: client/audiosvc/hxaudstr_new.cpp
>===================================================================
>RCS file: /cvsroot/client/audiosvc/hxaudstr_new.cpp,v
>retrieving revision 1.27
>diff -u -w -b -r1.27 hxaudstr_new.cpp
>--- client/audiosvc/hxaudstr_new.cpp 19 Oct 2004 21:30:10 -0000 1.27
>+++ client/audiosvc/hxaudstr_new.cpp 29 Nov 2004 22:47:38 -0000
>@@ -1616,6 +1616,7 @@
> // to the source which sets m_rebufferStatus = REBUFFER_WARNING
> if (m_DryNotificationMap->GetCount() > 0)
> {
>+ BOOL bWouldBlock = FALSE;
> IHXDryNotification* pDryNotification = 0;
> CHXMapPtrToPtr::Iterator lIter = m_DryNotificationMap->Begin();
> for (; lIter != m_DryNotificationMap->End(); ++lIter)
>@@ -1629,9 +1630,13 @@
> {
> return theErr;
> }
>+ else if (theErr == HXR_WOULD_BLOCK)
>+ {
>+ bWouldBlock = TRUE;
>+ }
> }
>
>- if (!bIsMixBufferDirty)
>+ if (bWouldBlock)
> {
> return HXR_WOULD_BLOCK;
> }
>Index: datatype/common/audrend/audrend.cpp
>===================================================================
>RCS file: /cvsroot/datatype/common/audrend/audrend.cpp,v
>retrieving revision 1.34
>diff -u -w -b -r1.34 audrend.cpp
>--- datatype/common/audrend/audrend.cpp 3 Sep 2004 01:24:26 -0000 1.34
>+++ datatype/common/audrend/audrend.cpp 1 Dec 2004 21:24:01 -0000
>@@ -911,6 +911,8 @@
> STDMETHODIMP CAudioRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> MLOG_MISC(m_pErrorMessages, "ODN (%lu,%lu)\n",
> ulCurrentStreamTime, ulMinimumDurationRequired);
> /* If the renderer is delayed, do not report rebuffer status until the
>@@ -954,13 +956,14 @@
> IsTimeLess(m_ulLastWriteTime, ulAudioWantedTime))
> {
> StartRebuffer(ulAudioWantedTime);
>+ hr = HXR_WOULD_BLOCK;
> }
> }
>
> exit:
> m_pMutex->Unlock();
>
>- return HXR_OK;
>+ return hr;
> }
>
>
>Index: datatype/mp3/renderer/mp3rend.cpp
>===================================================================
>RCS file: /cvsroot/datatype/mp3/renderer/mp3rend.cpp,v
>retrieving revision 1.22
>diff -u -w -b -r1.22 mp3rend.cpp
>--- datatype/mp3/renderer/mp3rend.cpp 2 Nov 2004 22:53:05 -0000 1.22
>+++ datatype/mp3/renderer/mp3rend.cpp 1 Dec 2004 21:24:01 -0000
>@@ -845,6 +845,8 @@
> CRnMp3Ren::OnDryNotification(UINT32 /*IN*/ ulCurrentStreamTime,
> UINT32 /*IN*/ ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> // We do not set our rebuffer flag at the end of a stream
> if (m_bEndOfPackets || !m_pStream)
> return HXR_OK;
>@@ -878,10 +880,11 @@
> m_pPacketParser->GetTimePerPkt() + 1);
> }
> m_pStream->ReportRebufferStatus(m_nPacketsNeeded, 0);
>+ hr = HXR_WOULD_BLOCK;
> }
> #endif
>
>- return HXR_OK;
>+ return hr;
> }
>
> STDMETHODIMP
>Index: datatype/rm/audio/renderer/rarender.cpp
>===================================================================
>RCS file: /cvsroot/datatype/rm/audio/renderer/rarender.cpp,v
>retrieving revision 1.44
>diff -u -w -b -r1.44 rarender.cpp
>--- datatype/rm/audio/renderer/rarender.cpp 2 Nov 2004 22:53:05
>-0000 1.44
>+++ datatype/rm/audio/renderer/rarender.cpp 1 Dec 2004 21:24:01 -0000
>@@ -2260,6 +2260,8 @@
> STDMETHODIMP CRealAudioRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> // If we are playing at non-1x playback, then don't
> // take any action on a OnDryNotification
> if (m_lPlaybackVelocity != HX_PLAYBACK_VELOCITY_NORMAL)
>@@ -2453,6 +2455,8 @@
> m_pStream->ReportRebufferStatus(1,0);
> }
>
>+ hr = HXR_WOULD_BLOCK;
>+
> DEBUG_OUTF(SWITCH_FILE,
> (s, "Entering Buffering\t%u\n",
> m_usCurrentDryNotificationStream));
> DEBUG_OUT(m_pErrorMessages, DOL_REALAUDIO,
>@@ -2477,7 +2481,7 @@
> exit:
> m_pMutex->Unlock();
>
>- return HXR_OK;
>+ return hr;
> }
>
> #ifdef _MACINTOSH
>Index: datatype/wav/renderer/pcm/pcmrendr.cpp
>===================================================================
>RCS file: /cvsroot/datatype/wav/renderer/pcm/pcmrendr.cpp,v
>retrieving revision 1.2
>diff -u -w -b -r1.2 pcmrendr.cpp
>--- datatype/wav/renderer/pcm/pcmrendr.cpp 24 Oct 2003 17:07:17
>-0000 1.2
>+++ datatype/wav/renderer/pcm/pcmrendr.cpp 1 Dec 2004 21:24:02 -0000
>@@ -904,6 +904,8 @@
> STDMETHODIMP CPCMRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> if ((!m_bPacketsDone) && m_pStream)
> {
> // {FILE* f1 = ::fopen("c:\\aurend.txt", "a+"); ::fprintf(f1,
> "DryNotification tickCount: %11lu\n", HX_GET_BETTERTICKCOUNT());::fclose(f1);}
>@@ -911,9 +913,10 @@
> m_pStream->ReportRebufferStatus(DRY_BUFFER_COUNT, 0);
> m_bStreamDry = TRUE;
> m_chBufferingCount = 0;
>+ hr = HXR_WOULD_BLOCK;
> }
>
>- return HXR_OK;
>+ return hr;
> }
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From milko at real.com Thu Dec 2 10:49:05 2004
From: milko at real.com (milko)
Date: Thu Dec 2 10:49:32 2004
Subject: [datatype-dev] CR-Client: Fix looping audio at end of
clip, also fixes crossfade hiccups
In-Reply-To: <6.1.2.0.2.20041202091812.043c8460@mailone.real.com>
Message-ID: <5.1.0.14.2.20041202104859.038a7948@mailone.real.com>
Looks good.
At 09:35 AM 12/2/2004, Kevin Ross wrote:
>Synopsis:
>Fixes looping audio at the end of a clip. Also fixes the audio hiccups
>heard during crossfade in RealPlayer.
>
>Overview:
>The bug comes from the fact that audio services can't tell the difference
>between network congestion or end of stream when it runs dry. It was
>assuming congestion, and that a rebuffer would be required, and would stop
>writing data to the audio device, waiting for the OnDryNotifications to
>signal a rebuffer is needed. This doesn't work in two scenarios. One is
>end of stream. When audio services stops writing to the audio device, but
>allows the audio device to keep playing, then the audio device runs dry
>and starts looping. The second case is when the audio renderer doesn't
>care that audio services has run dry. The renderer might want audio
>services to just continue anyway, inserting silence instead of rebuffering.
>
>The fix is to have a different return value from the OnDryNotification
>that the audio services can act upon. If it returns HXR_OK, then that
>means the audio renderer has no more data to give, and audio services
>should continue normally, inserting silence if needed. HXR_WOULD_BLOCK
>means the audio renderer has run dry and a rebuffer will occur. In this
>case, audio services will stop writing data to the audio device, waiting
>for a rebuffer, just like before.
>
>Files Modified:
>client/audiosvc/hxaudstr_new.cpp - changed the
>CHXAudioStream::MixIntoBuffer to handle different return codes from
>OnDryNotification
>datatype/common/audrend/audrend.cpp - changed OnDryNotification to return
>HXR_WOULD_BLOCK when rebuffering
>datatype/mp3/renderer/mp3rend.cpp
>datatype/rm/audio/renderer/rarender.cpp
>datatype/wav/renderer/pcm/pcmrendr.cpp
>
>Image Size and Heap Use impact:
>none
>
>Platforms and Profiles Affected:
>all
>
>Distribution Libraries affected:
>none
>
>Distribution library impact and planned action:
>none
>
>-----------------------------------------------------------
>
>Platforms and Profiles Build Verified:
>win32-i386-vc7, helix-client-all-defines
>
>Platforms and Profiles Functionality verified:
>win32-i386-vc7, helix-client-all-defines
>
>Branch:
>HEAD
>
>QA Instructions:
>
>
>Index: client/audiosvc/hxaudstr_new.cpp
>===================================================================
>RCS file: /cvsroot/client/audiosvc/hxaudstr_new.cpp,v
>retrieving revision 1.27
>diff -u -w -b -r1.27 hxaudstr_new.cpp
>--- client/audiosvc/hxaudstr_new.cpp 19 Oct 2004 21:30:10 -0000 1.27
>+++ client/audiosvc/hxaudstr_new.cpp 29 Nov 2004 22:47:38 -0000
>@@ -1616,6 +1616,7 @@
> // to the source which sets m_rebufferStatus = REBUFFER_WARNING
> if (m_DryNotificationMap->GetCount() > 0)
> {
>+ BOOL bWouldBlock = FALSE;
> IHXDryNotification* pDryNotification = 0;
> CHXMapPtrToPtr::Iterator lIter = m_DryNotificationMap->Begin();
> for (; lIter != m_DryNotificationMap->End(); ++lIter)
>@@ -1629,9 +1630,13 @@
> {
> return theErr;
> }
>+ else if (theErr == HXR_WOULD_BLOCK)
>+ {
>+ bWouldBlock = TRUE;
>+ }
> }
>
>- if (!bIsMixBufferDirty)
>+ if (bWouldBlock)
> {
> return HXR_WOULD_BLOCK;
> }
>Index: datatype/common/audrend/audrend.cpp
>===================================================================
>RCS file: /cvsroot/datatype/common/audrend/audrend.cpp,v
>retrieving revision 1.34
>diff -u -w -b -r1.34 audrend.cpp
>--- datatype/common/audrend/audrend.cpp 3 Sep 2004 01:24:26 -0000 1.34
>+++ datatype/common/audrend/audrend.cpp 1 Dec 2004 21:24:01 -0000
>@@ -911,6 +911,8 @@
> STDMETHODIMP CAudioRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> MLOG_MISC(m_pErrorMessages, "ODN (%lu,%lu)\n",
> ulCurrentStreamTime, ulMinimumDurationRequired);
> /* If the renderer is delayed, do not report rebuffer status until the
>@@ -954,13 +956,14 @@
> IsTimeLess(m_ulLastWriteTime, ulAudioWantedTime))
> {
> StartRebuffer(ulAudioWantedTime);
>+ hr = HXR_WOULD_BLOCK;
> }
> }
>
> exit:
> m_pMutex->Unlock();
>
>- return HXR_OK;
>+ return hr;
> }
>
>
>Index: datatype/mp3/renderer/mp3rend.cpp
>===================================================================
>RCS file: /cvsroot/datatype/mp3/renderer/mp3rend.cpp,v
>retrieving revision 1.22
>diff -u -w -b -r1.22 mp3rend.cpp
>--- datatype/mp3/renderer/mp3rend.cpp 2 Nov 2004 22:53:05 -0000 1.22
>+++ datatype/mp3/renderer/mp3rend.cpp 1 Dec 2004 21:24:01 -0000
>@@ -845,6 +845,8 @@
> CRnMp3Ren::OnDryNotification(UINT32 /*IN*/ ulCurrentStreamTime,
> UINT32 /*IN*/ ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> // We do not set our rebuffer flag at the end of a stream
> if (m_bEndOfPackets || !m_pStream)
> return HXR_OK;
>@@ -878,10 +880,11 @@
> m_pPacketParser->GetTimePerPkt() + 1);
> }
> m_pStream->ReportRebufferStatus(m_nPacketsNeeded, 0);
>+ hr = HXR_WOULD_BLOCK;
> }
> #endif
>
>- return HXR_OK;
>+ return hr;
> }
>
> STDMETHODIMP
>Index: datatype/rm/audio/renderer/rarender.cpp
>===================================================================
>RCS file: /cvsroot/datatype/rm/audio/renderer/rarender.cpp,v
>retrieving revision 1.44
>diff -u -w -b -r1.44 rarender.cpp
>--- datatype/rm/audio/renderer/rarender.cpp 2 Nov 2004 22:53:05
>-0000 1.44
>+++ datatype/rm/audio/renderer/rarender.cpp 1 Dec 2004 21:24:01 -0000
>@@ -2260,6 +2260,8 @@
> STDMETHODIMP CRealAudioRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> // If we are playing at non-1x playback, then don't
> // take any action on a OnDryNotification
> if (m_lPlaybackVelocity != HX_PLAYBACK_VELOCITY_NORMAL)
>@@ -2453,6 +2455,8 @@
> m_pStream->ReportRebufferStatus(1,0);
> }
>
>+ hr = HXR_WOULD_BLOCK;
>+
> DEBUG_OUTF(SWITCH_FILE,
> (s, "Entering Buffering\t%u\n",
> m_usCurrentDryNotificationStream));
> DEBUG_OUT(m_pErrorMessages, DOL_REALAUDIO,
>@@ -2477,7 +2481,7 @@
> exit:
> m_pMutex->Unlock();
>
>- return HXR_OK;
>+ return hr;
> }
>
> #ifdef _MACINTOSH
>Index: datatype/wav/renderer/pcm/pcmrendr.cpp
>===================================================================
>RCS file: /cvsroot/datatype/wav/renderer/pcm/pcmrendr.cpp,v
>retrieving revision 1.2
>diff -u -w -b -r1.2 pcmrendr.cpp
>--- datatype/wav/renderer/pcm/pcmrendr.cpp 24 Oct 2003 17:07:17
>-0000 1.2
>+++ datatype/wav/renderer/pcm/pcmrendr.cpp 1 Dec 2004 21:24:02 -0000
>@@ -904,6 +904,8 @@
> STDMETHODIMP CPCMRenderer::OnDryNotification(UINT32 /*IN*/
> ulCurrentStreamTime,
> UINT32 /*IN*/
> ulMinimumDurationRequired)
> {
>+ HX_RESULT hr = HXR_OK;
>+
> if ((!m_bPacketsDone) && m_pStream)
> {
> // {FILE* f1 = ::fopen("c:\\aurend.txt", "a+"); ::fprintf(f1,
> "DryNotification tickCount: %11lu\n", HX_GET_BETTERTICKCOUNT());::fclose(f1);}
>@@ -911,9 +913,10 @@
> m_pStream->ReportRebufferStatus(DRY_BUFFER_COUNT, 0);
> m_bStreamDry = TRUE;
> m_chBufferingCount = 0;
>+ hr = HXR_WOULD_BLOCK;
> }
>
>- return HXR_OK;
>+ return hr;
> }
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041202/00d89a46/attachment-0001.htm
From kross at real.com Thu Dec 2 11:06:42 2004
From: kross at real.com (Kevin Ross)
Date: Thu Dec 2 11:06:46 2004
Subject: [datatype-dev] CR-Client: Fix looping audio at end of
clip, also fixes crossfade hiccups
In-Reply-To: <5.1.0.14.2.20041202103004.0203c608@mailone.real.com>
References: <6.1.2.0.2.20041202091812.043c8460@mailone.real.com>
<5.1.0.14.2.20041202103004.0203c608@mailone.real.com>
Message-ID: <6.1.2.0.2.20041202110530.01ecb340@mailone.real.com>
Most likely, yes. But I'd be interested if you can repro it, I'd like to
make sure.
Thanks!
-- Kevin
At 10:34 AM 12/2/2004, Erik Hodge wrote:
>Looks good. Note: while watching a live broadcast this past Tues,
>the audio looped for a bit just before the server disconnected.
>This was live so not an end-of-stream situation. I couldn't repro
>after that because it turned out the host's 'net connection had
>gone down. Will the below changes will fix that situation as well?
>
> - Erik
>
>At 09:35 AM 12/2/2004 -0800, Kevin Ross wrote:
>>Synopsis:
>>Fixes looping audio at the end of a clip. Also fixes the audio hiccups
>>heard during crossfade in RealPlayer.
>>
>>Overview:
>>The bug comes from the fact that audio services can't tell the difference
>>between network congestion or end of stream when it runs dry. It was
>>assuming congestion, and that a rebuffer would be required, and would
>>stop writing data to the audio device, waiting for the OnDryNotifications
>>to signal a rebuffer is needed. This doesn't work in two scenarios. One
>>is end of stream. When audio services stops writing to the audio device,
>>but allows the audio device to keep playing, then the audio device runs
>>dry and starts looping. The second case is when the audio renderer
>>doesn't care that audio services has run dry. The renderer might want
>>audio services to just continue anyway, inserting silence instead of
>>rebuffering.
>>
>>The fix is to have a different return value from the OnDryNotification
>>that the audio services can act upon. If it returns HXR_OK, then that
>>means the audio renderer has no more data to give, and audio services
>>should continue normally, inserting silence if needed. HXR_WOULD_BLOCK
>>means the audio renderer has run dry and a rebuffer will occur. In this
>>case, audio services will stop writing data to the audio device, waiting
>>for a rebuffer, just like before.
>>
>>Files Modified:
>>client/audiosvc/hxaudstr_new.cpp - changed the
>>CHXAudioStream::MixIntoBuffer to handle different return codes from
>>OnDryNotification
>>datatype/common/audrend/audrend.cpp - changed OnDryNotification to return
>>HXR_WOULD_BLOCK when rebuffering
>>datatype/mp3/renderer/mp3rend.cpp
>>datatype/rm/audio/renderer/rarender.cpp
>>datatype/wav/renderer/pcm/pcmrendr.cpp
>>
>>Image Size and Heap Use impact:
>>none
>>
>>Platforms and Profiles Affected:
>>all
>>
>>Distribution Libraries affected:
>>none
>>
>>Distribution library impact and planned action:
>>none
>>
>>-----------------------------------------------------------
>>
>>Platforms and Profiles Build Verified:
>>win32-i386-vc7, helix-client-all-defines
>>
>>Platforms and Profiles Functionality verified:
>>win32-i386-vc7, helix-client-all-defines
>>
>>Branch:
>>HEAD
>>
>>QA Instructions:
>>
>>
>>Index: client/audiosvc/hxaudstr_new.cpp
>>===================================================================
>>RCS file: /cvsroot/client/audiosvc/hxaudstr_new.cpp,v
>>retrieving revision 1.27
>>diff -u -w -b -r1.27 hxaudstr_new.cpp
>>--- client/audiosvc/hxaudstr_new.cpp 19 Oct 2004 21:30:10 -0000 1.27
>>+++ client/audiosvc/hxaudstr_new.cpp 29 Nov 2004 22:47:38 -0000
>>@@ -1616,6 +1616,7 @@
>> // to the source which sets m_rebufferStatus = REBUFFER_WARNING
>> if (m_DryNotificationMap->GetCount() > 0)
>> {
>>+ BOOL bWouldBlock = FALSE;
>> IHXDryNotification* pDryNotification = 0;
>> CHXMapPtrToPtr::Iterator lIter = m_DryNotificationMap->Begin();
>> for (; lIter != m_DryNotificationMap->End(); ++lIter)
>>@@ -1629,9 +1630,13 @@
>> {
>> return theErr;
>> }
>>+ else if (theErr == HXR_WOULD_BLOCK)
>>+ {
>>+ bWouldBlock = TRUE;
>>+ }
>> }
>>
>>- if (!bIsMixBufferDirty)
>>+ if (bWouldBlock)
>> {
>> return HXR_WOULD_BLOCK;
>> }
>>Index: datatype/common/audrend/audrend.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/common/audrend/audrend.cpp,v
>>retrieving revision 1.34
>>diff -u -w -b -r1.34 audrend.cpp
>>--- datatype/common/audrend/audrend.cpp 3 Sep 2004 01:24:26 -0000 1.34
>>+++ datatype/common/audrend/audrend.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -911,6 +911,8 @@
>> STDMETHODIMP CAudioRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> MLOG_MISC(m_pErrorMessages, "ODN (%lu,%lu)\n",
>> ulCurrentStreamTime, ulMinimumDurationRequired);
>> /* If the renderer is delayed, do not report rebuffer status until the
>>@@ -954,13 +956,14 @@
>> IsTimeLess(m_ulLastWriteTime, ulAudioWantedTime))
>> {
>> StartRebuffer(ulAudioWantedTime);
>>+ hr = HXR_WOULD_BLOCK;
>> }
>> }
>>
>> exit:
>> m_pMutex->Unlock();
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>>
>>Index: datatype/mp3/renderer/mp3rend.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/mp3/renderer/mp3rend.cpp,v
>>retrieving revision 1.22
>>diff -u -w -b -r1.22 mp3rend.cpp
>>--- datatype/mp3/renderer/mp3rend.cpp 2 Nov 2004 22:53:05 -0000 1.22
>>+++ datatype/mp3/renderer/mp3rend.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -845,6 +845,8 @@
>> CRnMp3Ren::OnDryNotification(UINT32 /*IN*/ ulCurrentStreamTime,
>> UINT32 /*IN*/ ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> // We do not set our rebuffer flag at the end of a stream
>> if (m_bEndOfPackets || !m_pStream)
>> return HXR_OK;
>>@@ -878,10 +880,11 @@
>> m_pPacketParser->GetTimePerPkt() + 1);
>> }
>> m_pStream->ReportRebufferStatus(m_nPacketsNeeded, 0);
>>+ hr = HXR_WOULD_BLOCK;
>> }
>> #endif
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>> STDMETHODIMP
>>Index: datatype/rm/audio/renderer/rarender.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/rm/audio/renderer/rarender.cpp,v
>>retrieving revision 1.44
>>diff -u -w -b -r1.44 rarender.cpp
>>--- datatype/rm/audio/renderer/rarender.cpp 2 Nov 2004 22:53:05
>>-0000 1.44
>>+++ datatype/rm/audio/renderer/rarender.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -2260,6 +2260,8 @@
>> STDMETHODIMP CRealAudioRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> // If we are playing at non-1x playback, then don't
>> // take any action on a OnDryNotification
>> if (m_lPlaybackVelocity != HX_PLAYBACK_VELOCITY_NORMAL)
>>@@ -2453,6 +2455,8 @@
>> m_pStream->ReportRebufferStatus(1,0);
>> }
>>
>>+ hr = HXR_WOULD_BLOCK;
>>+
>> DEBUG_OUTF(SWITCH_FILE,
>> (s, "Entering Buffering\t%u\n",
>> m_usCurrentDryNotificationStream));
>> DEBUG_OUT(m_pErrorMessages, DOL_REALAUDIO,
>>@@ -2477,7 +2481,7 @@
>> exit:
>> m_pMutex->Unlock();
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>> #ifdef _MACINTOSH
>>Index: datatype/wav/renderer/pcm/pcmrendr.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/wav/renderer/pcm/pcmrendr.cpp,v
>>retrieving revision 1.2
>>diff -u -w -b -r1.2 pcmrendr.cpp
>>--- datatype/wav/renderer/pcm/pcmrendr.cpp 24 Oct 2003 17:07:17
>>-0000 1.2
>>+++ datatype/wav/renderer/pcm/pcmrendr.cpp 1 Dec 2004 21:24:02 -0000
>>@@ -904,6 +904,8 @@
>> STDMETHODIMP CPCMRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> if ((!m_bPacketsDone) && m_pStream)
>> {
>> // {FILE* f1 = ::fopen("c:\\aurend.txt", "a+"); ::fprintf(f1,
>> "DryNotification tickCount: %11lu\n", HX_GET_BETTERTICKCOUNT());::fclose(f1);}
>>@@ -911,9 +913,10 @@
>> m_pStream->ReportRebufferStatus(DRY_BUFFER_COUNT, 0);
>> m_bStreamDry = TRUE;
>> m_chBufferingCount = 0;
>>+ hr = HXR_WOULD_BLOCK;
>> }
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041202/9d1cbe57/attachment.htm
From ehyche at real.com Thu Dec 2 11:51:18 2004
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 2 11:51:32 2004
Subject: [datatype-dev] CR-Client: updates to XML writer
Message-ID: <5.1.0.14.2.20041202144509.00c16500@mailone.real.com>
Synopsis: minor updates to XML writer
Overview: 1. Don't output DTD at the start of the .xml file -
we will come up with Schema instead of DTD.
2. Change from using single tag to
using , , and
.
3. Compute CRC32 over the packet buffer and add
"crc32" attribute to element.
4. Add compile-time-configurable indents
5. Link in zlib library
6. Add zlib to xmlwriter dependencies in BIF
Files Modified:
datatype/tools/xmlwriter/Umakefil
datatype/tools/xmlwriter/xmlwriter.cpp
datatype/tools/xmlwriter/pub/xmlwriter.h
common/build/BIF/helix.bif
Image Size and Heap Use impact: none
Platforms and Profiles Affected: all
Distribution Libraries affected: none
Distribution library impact and planned action: n/a
Platforms and Profiles Build Verified: win32
Platforms and Profiles Functionality verified: win32
Branch: HEAD only
QA Instructions: none
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/Umakefil,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 Umakefil
--- Umakefil 21 Jun 2004 16:26:04 -0000 1.1
+++ Umakefil 2 Dec 2004 19:45:12 -0000
@@ -42,7 +42,8 @@
"common/dbgtool[debuglib]",
"common/runtime[runtlib]",
"common/system[syslib]",
- "common/util[utillib]")
+ "common/util[utillib]",
+ "common/import/zlib[zlib]")
project.AddSources("xmlwriter.cpp",
"xmlwriterdll.cpp",
Index: xmlwriter.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/xmlwriter.cpp,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 xmlwriter.cpp
--- xmlwriter.cpp 21 Jun 2004 16:26:04 -0000 1.1
+++ xmlwriter.cpp 2 Dec 2004 19:45:12 -0000
@@ -41,6 +41,7 @@
#include "baseobj.h"
#include "hxver.h"
#include "hxfwrtr.h"
+#include "zlib.h"
#include "xmlwriter.h"
#include "xmlwriter.ver"
@@ -50,28 +51,9 @@
const char* const CXMLFileWriter::m_ppszFileMimeTypes[] =
{"application/xml", NULL};
const char* const CXMLFileWriter::m_ppszFileExtensions[] = {"xml", NULL};
const char* const CXMLFileWriter::m_ppszFileOpenNames[] = {"XML Output
Files (*.xml)", NULL};
-const char* const CXMLFileWriter::m_pszHeaderStr =
- "\n"
- "\n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- "]>\n";
+const char* const CXMLFileWriter::m_pszHeaderStr = "\n";
+
+#define XMLWRITER_INDENT_SIZE 4
CXMLFileWriter::CXMLFileWriter()
{
@@ -82,6 +64,7 @@
m_ulStreamCount = 0;
m_ulNumStreams = 0;
m_bWrotePacketContainerOpen = FALSE;
+ m_pszIndent2 = NULL;
}
@@ -233,6 +216,7 @@
}
HX_RELEASE(m_pContext);
HX_RELEASE(m_pMonitor);
+ HX_VECTOR_DELETE(m_pszIndent2);
return retVal;
}
@@ -248,21 +232,26 @@
if (pHeader && m_fp)
{
+ // Get an indent string for indent level 1
+ char* pszIndent = CreateIndentString(1);
+ if (pszIndent)
+ {
// Print out file header element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Write out the file header properties
- fprintf(m_fp, " \n");
- WriteOutValues(pHeader, m_fp, 12);
- fprintf(m_fp, " \n");
+ WriteOutValues(pHeader, m_fp, 2);
// Print out the file header end element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Print out the stream header container element begin
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Clear the stream header count
m_ulNumStreams = 0;
// Get the stream count
retVal = pHeader->GetPropertyULONG32("StreamCount", m_ulStreamCount);
}
+ // Free the indent string
+ HX_VECTOR_DELETE(pszIndent);
+ }
return retVal;
}
@@ -273,14 +262,17 @@
if (pHeader && m_fp)
{
+ // Create an indent string for indent levels 1 and 2
+ char* pszIndent1 = CreateIndentString(1);
+ char* pszIndent2 = CreateIndentString(2);
+ if (pszIndent1 && pszIndent2)
+ {
// Print out file header element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent2);
// Write out the file header properties
- fprintf(m_fp, " \n");
- WriteOutValues(pHeader, m_fp, 16);
- fprintf(m_fp, " \n");
+ WriteOutValues(pHeader, m_fp, 3);
// Print out the file header end element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent2);
// Increment the stream count
m_ulNumStreams++;
// If we have gotten all our stream headers, then
@@ -288,7 +280,7 @@
if (m_ulNumStreams >= m_ulStreamCount && m_pMonitor)
{
// Print out the stream header container element end
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent1);
// Tell the monitor we're ready
m_pMonitor->OnPacketsReady(HXR_OK);
// Reset the stream count so we can count StreamDone()'s
@@ -297,6 +289,10 @@
// Clear the return value
retVal = HXR_OK;
}
+ // Free the indent strings
+ HX_VECTOR_DELETE(pszIndent1);
+ HX_VECTOR_DELETE(pszIndent2);
+ }
return retVal;
}
@@ -312,16 +308,29 @@
if (pPacket && m_fp)
{
+ // Create indent level 2 string (if it
+ // doesn't already exist)
+ if (!m_pszIndent2)
+ {
+ m_pszIndent2 = CreateIndentString(2);
+ }
// Write out the packet container element open
// (if we have not already)
if (!m_bWrotePacketContainerOpen)
{
if (m_fp)
{
- fprintf(m_fp, " \n");
+ char* pszIndent1 = CreateIndentString(1);
+ if (pszIndent1)
+ {
+ fprintf(m_fp, "%s\n", pszIndent1);
+ }
+ HX_VECTOR_DELETE(pszIndent1);
}
m_bWrotePacketContainerOpen = TRUE;
}
+ if (m_pszIndent2)
+ {
// Get the packet parameters
IHXBuffer* pBuffer = NULL;
UINT32 ulTime = 0;
@@ -331,14 +340,17 @@
retVal = pPacket->Get(pBuffer, ulTime, usStreamNumber,
ucASMFlags, usASMRuleNumber);
if (SUCCEEDED(retVal))
{
+ UINT32 ulCRC32 = ComputeCRC32(pBuffer);
// Print out the packet elemnt
fprintf(m_fp,
- " \n",
- usStreamNumber, ulTime, ucASMFlags, usASMRuleNumber,
pBuffer->GetSize());
+ "%s\n",
+ m_pszIndent2, usStreamNumber, ulTime, ucASMFlags,
usASMRuleNumber,
+ pBuffer->GetSize(), ulCRC32);
}
HX_RELEASE(pBuffer);
}
+ }
return retVal;
}
@@ -370,28 +382,23 @@
return retVal;
}
-void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
ulIndent)
+void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
ulIndentLevel)
{
if (pValues && fp)
{
// Build indent string
- char* pszIndent = new char [ulIndent + 1];
+ char* pszIndent = CreateIndentString(ulIndentLevel);
if (pszIndent)
{
- // Fill in spaces
- if (ulIndent)
- {
- memset((void*) pszIndent, ' ', ulIndent);
- }
- // Fill in NULL terminator
- pszIndent[ulIndent] = '\0';
+ // Write out the open element
+ fprintf(fp, "%s\n", pszIndent);
// Print out ULONG32 properties
const char* pszName = NULL;
UINT32 ulValue = 0;
HX_RESULT rv =
pValues->GetFirstPropertyULONG32(pszName, ulValue);
while (SUCCEEDED(rv))
{
- fprintf(fp, "%s\n",
+ fprintf(fp, "%s \n",
pszIndent, pszName, ulValue);
rv = pValues->GetNextPropertyULONG32(pszName, ulValue);
}
@@ -400,7 +407,7 @@
rv = pValues->GetFirstPropertyCString(pszName, pValue);
while (SUCCEEDED(rv))
{
- fprintf(fp, "%sGetBuffer(), fp);
fprintf(fp, "\"/>\n");
HX_RELEASE(pValue);
@@ -417,7 +424,7 @@
{
memset((void*) pTmp, 0, ulSize);
INT32 lLen = BinTo64(pValue->GetBuffer(),
pValue->GetSize(), pTmp);
- fprintf(fp, "%s\n",
+ fprintf(fp, "%s \n",
pszIndent, pszName, (const char*) pTmp);
}
HX_VECTOR_DELETE(pTmp);
@@ -425,6 +432,8 @@
HX_RELEASE(pValue);
rv = pValues->GetNextPropertyBuffer(pszName, pValue);
}
+ // Write out the close element
+ fprintf(fp, "%s\n", pszIndent);
}
HX_VECTOR_DELETE(pszIndent);
}
@@ -505,5 +514,35 @@
}
return retVal;
+}
+
+char* CXMLFileWriter::CreateIndentString(UINT32 ulIndentLevel)
+{
+ char* pRet = NULL;
+
+ UINT32 ulLen = ulIndentLevel * XMLWRITER_INDENT_SIZE;
+ pRet = new char [ulLen + 1];
+ if (pRet)
+ {
+ memset(pRet, ' ', ulLen);
+ pRet[ulLen] = '\0';
+ }
+
+ return pRet;
+}
+
+UINT32 CXMLFileWriter::ComputeCRC32(IHXBuffer* pBuffer)
+{
+ UINT32 ulRet = 0;
+
+ if (pBuffer)
+ {
+ // Pre-condition the CRC32
+ ulRet = crc32(0, NULL, 0);
+ // Compute the CRC on the buffer
+ ulRet = crc32(ulRet, pBuffer->GetBuffer(), pBuffer->GetSize());
+ }
+
+ return ulRet;
}
cvs server: Diffing pub
Index: pub/xmlwriter.h
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/pub/xmlwriter.h,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 xmlwriter.h
--- pub/xmlwriter.h 21 Jun 2004 16:26:04 -0000 1.1
+++ pub/xmlwriter.h 2 Dec 2004 19:45:12 -0000
@@ -88,6 +88,7 @@
UINT32 m_ulStreamCount;
UINT32 m_ulNumStreams;
BOOL m_bWrotePacketContainerOpen;
+ char* m_pszIndent2;
static const char* const m_pszDescription;
static const char* const m_pszCopyright;
@@ -99,6 +100,8 @@
void WriteOutValues(IHXValues* pValues, FILE* fp, UINT32 ulIndent);
HX_RESULT WriteOutCStringValue(const char* pszValue, FILE* fp);
+ char* CreateIndentString(UINT32 ulIndentLevel);
+ UINT32 ComputeCRC32(IHXBuffer* pBuffer);
};
#endif /* #ifndef XMLWRITER_H */
Index: helix.bif
===================================================================
RCS file: /cvsroot/common/build/BIF/helix.bif,v
retrieving revision 1.492
diff -u -w -u -w -r1.492 helix.bif
--- helix.bif 17 Nov 2004 19:50:30 -0000 1.492
+++ helix.bif 2 Dec 2004 19:50:42 -0000
@@ -1879,6 +1879,7 @@
common_runtime
common_system
common_util
+ common_import_zlib
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From nhart at real.com Thu Dec 2 11:53:37 2004
From: nhart at real.com (Nicholas Hart)
Date: Thu Dec 2 11:53:41 2004
Subject: [datatype-dev] CR: datatype/mp3/import/id3lib
Message-ID: <1102017218.3415.23.camel@localhost.localdomain>
This module is failing on the head on linux because it appears to use
exceptions but these are turned off by default on linux. I'd like to
add the following to a new "linux2.pcf" file in the module to get it to
build.
# this module uses exceptions, so we need to turn them on
cc.args['default'] = cc.args['default'] + "-fexceptions"
cxx.args['default'] = cxx.args['default'] + "-fexceptions"
From nhart at real.com Thu Dec 2 12:01:51 2004
From: nhart at real.com (Nicholas Hart)
Date: Thu Dec 2 12:01:58 2004
Subject: [datatype-dev] CR: datatype/avi/fileformat
Message-ID: <1102017712.3415.27.camel@localhost.localdomain>
The AVI fileformat is b0rken on linux. The following diffs fix two of
the problems. There is one other that is going to require either a hack
or moving some #defines around. The file avistrm.cpp uses the macro
"BI_RGB" which only seems to be defined in client/include/hxvsurf.h
(probably in some windows header somewhere too I bet). So either we
need to define a local version of BI_RGB for this file, or move some/all
of hxvsurf to common/include... or create some header in
datatype/include that can contain the BI_RGB definition.
Index: pub/aviffpln.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
retrieving revision 1.3
diff -u -w -r1.3 aviffpln.h
--- pub/aviffpln.h 2 Dec 2004 18:21:40 -0000 1.3
+++ pub/aviffpln.h 2 Dec 2004 19:59:16 -0000
@@ -119,8 +119,8 @@
, public IHXInterruptSafe
, public IHXFileSystemManagerResponse
{
- friend CAVIStream; // for ExternalEvent()
- friend CAVIIndex; // for ExternalEvent()
+ friend class CAVIStream; // for ExternalEvent()
+ friend class CAVIIndex; // for ExternalEvent()
public:
static HX_RESULT STDAPICALLTYPE HXCreateInstance(IUnknown**
ppIUnknown);
Index: pub/avistrm.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
retrieving revision 1.4
diff -u -w -r1.4 avistrm.h
--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
+++ pub/avistrm.h 2 Dec 2004 19:59:16 -0000
@@ -221,7 +221,7 @@
UINT32 m_ulTotalBytesRead;
UINT32 m_ulTotalBytesPacketised;
BOOL m_bSeeking;
- ULONG m_ulSeekTime;
+ ULONG32 m_ulSeekTime;
From ehyche at real.com Thu Dec 2 12:03:53 2004
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 2 12:04:04 2004
Subject: [datatype-dev] CR: datatype/mp3/import/id3lib
In-Reply-To: <1102017218.3415.23.camel@localhost.localdomain>
Message-ID: <5.1.0.14.2.20041202150347.028b8eb8@mailone.real.com>
Looks good.
Eric
At 11:53 AM 12/2/2004 -0800, Nicholas Hart wrote:
>This module is failing on the head on linux because it appears to use
>exceptions but these are turned off by default on linux. I'd like to
>add the following to a new "linux2.pcf" file in the module to get it to
>build.
>
># this module uses exceptions, so we need to turn them on
>cc.args['default'] = cc.args['default'] + "-fexceptions"
>cxx.args['default'] = cxx.args['default'] + "-fexceptions"
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From rgammon at real.com Thu Dec 2 12:12:44 2004
From: rgammon at real.com (Ryan Gammon)
Date: Thu Dec 2 12:13:20 2004
Subject: [datatype-dev] CR: datatype/mp3/import/id3lib
In-Reply-To: <5.1.0.14.2.20041202150347.028b8eb8@mailone.real.com>
References: <5.1.0.14.2.20041202150347.028b8eb8@mailone.real.com>
Message-ID: <41AF773C.5010401@real.com>
What does this do to our download size, out of curiousity?
Eric Hyche wrote:
>
> Looks good.
>
> Eric
>
> At 11:53 AM 12/2/2004 -0800, Nicholas Hart wrote:
>
>> This module is failing on the head on linux because it appears to use
>> exceptions but these are turned off by default on linux. I'd like to
>> add the following to a new "linux2.pcf" file in the module to get it to
>> build.
>>
>> # this module uses exceptions, so we need to turn them on
>> cc.args['default'] = cc.args['default'] + "-fexceptions"
>> cxx.args['default'] = cxx.args['default'] + "-fexceptions"
>>
>>
>>
>>
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
--
Ryan Gammon
rgammon@real.com
Developer for Helix Player
https://player.helixcommunity.org
From nhart at real.com Thu Dec 2 12:19:13 2004
From: nhart at real.com (Nicholas Hart)
Date: Thu Dec 2 12:19:17 2004
Subject: [datatype-dev] CR: datatype/mp3/import/id3lib
In-Reply-To: <41AF773C.5010401@real.com>
References: <5.1.0.14.2.20041202150347.028b8eb8@mailone.real.com>
<41AF773C.5010401@real.com>
Message-ID: <1102018753.3415.30.camel@localhost.localdomain>
good question. i'll do a release build and see what happens...
On Thu, 2004-12-02 at 12:12 -0800, Ryan Gammon wrote:
> What does this do to our download size, out of curiousity?
>
> Eric Hyche wrote:
>
> >
> > Looks good.
> >
> > Eric
> >
> > At 11:53 AM 12/2/2004 -0800, Nicholas Hart wrote:
> >
> >> This module is failing on the head on linux because it appears to use
> >> exceptions but these are turned off by default on linux. I'd like to
> >> add the following to a new "linux2.pcf" file in the module to get it to
> >> build.
> >>
> >> # this module uses exceptions, so we need to turn them on
> >> cc.args['default'] = cc.args['default'] + "-fexceptions"
> >> cxx.args['default'] = cxx.args['default'] + "-fexceptions"
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Datatype-dev mailing list
> >> Datatype-dev@helixcommunity.org
> >> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> >
> >
> > ======================================
> > M. Eric Hyche (ehyche@real.com)
> > Core Technologies
> > RealNetworks, Inc.
> >
> >
> > _______________________________________________
> > Datatype-dev mailing list
> > Datatype-dev@helixcommunity.org
> > http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> >
>
>
From ehyche at real.com Thu Dec 2 12:19:21 2004
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 2 12:19:29 2004
Subject: [datatype-dev] CR: datatype/avi/fileformat
In-Reply-To: <1102017712.3415.27.camel@localhost.localdomain>
Message-ID: <5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
At 12:01 PM 12/2/2004 -0800, Nicholas Hart wrote:
>The AVI fileformat is b0rken on linux. The following diffs fix two of
>the problems. There is one other that is going to require either a hack
>or moving some #defines around. The file avistrm.cpp uses the macro
>"BI_RGB" which only seems to be defined in client/include/hxvsurf.h
>(probably in some windows header somewhere too I bet).
Yep, BI_RGB is defined in Windows header code.
>So either we
>need to define a local version of BI_RGB for this file, or move some/all
>of hxvsurf to common/include... or create some header in
>datatype/include that can contain the BI_RGB definition.
I would be for moving hxvsurf.h to common/include... others
may have different opinions...
Rest looks good...
Eric
>Index: pub/aviffpln.h
>===================================================================
>RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
>retrieving revision 1.3
>diff -u -w -r1.3 aviffpln.h
>--- pub/aviffpln.h 2 Dec 2004 18:21:40 -0000 1.3
>+++ pub/aviffpln.h 2 Dec 2004 19:59:16 -0000
>@@ -119,8 +119,8 @@
> , public IHXInterruptSafe
> , public IHXFileSystemManagerResponse
> {
>- friend CAVIStream; // for ExternalEvent()
>- friend CAVIIndex; // for ExternalEvent()
>+ friend class CAVIStream; // for ExternalEvent()
>+ friend class CAVIIndex; // for ExternalEvent()
>
> public:
> static HX_RESULT STDAPICALLTYPE HXCreateInstance(IUnknown**
>ppIUnknown);
>Index: pub/avistrm.h
>===================================================================
>RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
>retrieving revision 1.4
>diff -u -w -r1.4 avistrm.h
>--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
>+++ pub/avistrm.h 2 Dec 2004 19:59:16 -0000
>@@ -221,7 +221,7 @@
> UINT32 m_ulTotalBytesRead;
> UINT32 m_ulTotalBytesPacketised;
> BOOL m_bSeeking;
>- ULONG m_ulSeekTime;
>+ ULONG32 m_ulSeekTime;
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From kross at real.com Fri Dec 3 09:23:33 2004
From: kross at real.com (Kevin Ross)
Date: Fri Dec 3 09:23:37 2004
Subject: [datatype-dev] CN-Client: Fix looping audio at end of clip,
also fixes crossfade hiccups
In-Reply-To: <5.1.0.14.2.20041202104859.038a7948@mailone.real.com>
References: <6.1.2.0.2.20041202091812.043c8460@mailone.real.com>
<5.1.0.14.2.20041202104859.038a7948@mailone.real.com>
Message-ID: <6.1.2.0.2.20041203092302.01deacf8@mailone.real.com>
Committed to HEAD.
-- Kevin
At 10:49 AM 12/2/2004, milko wrote:
>Looks good.
>
>At 09:35 AM 12/2/2004, Kevin Ross wrote:
>>Synopsis:
>>Fixes looping audio at the end of a clip. Also fixes the audio hiccups
>>heard during crossfade in RealPlayer.
>>
>>Overview:
>>The bug comes from the fact that audio services can't tell the difference
>>between network congestion or end of stream when it runs dry. It was
>>assuming congestion, and that a rebuffer would be required, and would
>>stop writing data to the audio device, waiting for the OnDryNotifications
>>to signal a rebuffer is needed. This doesn't work in two scenarios. One
>>is end of stream. When audio services stops writing to the audio device,
>>but allows the audio device to keep playing, then the audio device runs
>>dry and starts looping. The second case is when the audio renderer
>>doesn't care that audio services has run dry. The renderer might want
>>audio services to just continue anyway, inserting silence instead of
>>rebuffering.
>>
>>The fix is to have a different return value from the OnDryNotification
>>that the audio services can act upon. If it returns HXR_OK, then that
>>means the audio renderer has no more data to give, and audio services
>>should continue normally, inserting silence if needed. HXR_WOULD_BLOCK
>>means the audio renderer has run dry and a rebuffer will occur. In this
>>case, audio services will stop writing data to the audio device, waiting
>>for a rebuffer, just like before.
>>
>>Files Modified:
>>client/audiosvc/hxaudstr_new.cpp - changed the
>>CHXAudioStream::MixIntoBuffer to handle different return codes from
>>OnDryNotification
>>datatype/common/audrend/audrend.cpp - changed OnDryNotification to return
>>HXR_WOULD_BLOCK when rebuffering
>>datatype/mp3/renderer/mp3rend.cpp
>>datatype/rm/audio/renderer/rarender.cpp
>>datatype/wav/renderer/pcm/pcmrendr.cpp
>>
>>Image Size and Heap Use impact:
>>none
>>
>>Platforms and Profiles Affected:
>>all
>>
>>Distribution Libraries affected:
>>none
>>
>>Distribution library impact and planned action:
>>none
>>
>>-----------------------------------------------------------
>>
>>Platforms and Profiles Build Verified:
>>win32-i386-vc7, helix-client-all-defines
>>
>>Platforms and Profiles Functionality verified:
>>win32-i386-vc7, helix-client-all-defines
>>
>>Branch:
>>HEAD
>>
>>QA Instructions:
>>
>>
>>Index: client/audiosvc/hxaudstr_new.cpp
>>===================================================================
>>RCS file: /cvsroot/client/audiosvc/hxaudstr_new.cpp,v
>>retrieving revision 1.27
>>diff -u -w -b -r1.27 hxaudstr_new.cpp
>>--- client/audiosvc/hxaudstr_new.cpp 19 Oct 2004 21:30:10 -0000 1.27
>>+++ client/audiosvc/hxaudstr_new.cpp 29 Nov 2004 22:47:38 -0000
>>@@ -1616,6 +1616,7 @@
>> // to the source which sets m_rebufferStatus = REBUFFER_WARNING
>> if (m_DryNotificationMap->GetCount() > 0)
>> {
>>+ BOOL bWouldBlock = FALSE;
>> IHXDryNotification* pDryNotification = 0;
>> CHXMapPtrToPtr::Iterator lIter = m_DryNotificationMap->Begin();
>> for (; lIter != m_DryNotificationMap->End(); ++lIter)
>>@@ -1629,9 +1630,13 @@
>> {
>> return theErr;
>> }
>>+ else if (theErr == HXR_WOULD_BLOCK)
>>+ {
>>+ bWouldBlock = TRUE;
>>+ }
>> }
>>
>>- if (!bIsMixBufferDirty)
>>+ if (bWouldBlock)
>> {
>> return HXR_WOULD_BLOCK;
>> }
>>Index: datatype/common/audrend/audrend.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/common/audrend/audrend.cpp,v
>>retrieving revision 1.34
>>diff -u -w -b -r1.34 audrend.cpp
>>--- datatype/common/audrend/audrend.cpp 3 Sep 2004 01:24:26 -0000 1.34
>>+++ datatype/common/audrend/audrend.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -911,6 +911,8 @@
>> STDMETHODIMP CAudioRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> MLOG_MISC(m_pErrorMessages, "ODN (%lu,%lu)\n",
>> ulCurrentStreamTime, ulMinimumDurationRequired);
>> /* If the renderer is delayed, do not report rebuffer status until the
>>@@ -954,13 +956,14 @@
>> IsTimeLess(m_ulLastWriteTime, ulAudioWantedTime))
>> {
>> StartRebuffer(ulAudioWantedTime);
>>+ hr = HXR_WOULD_BLOCK;
>> }
>> }
>>
>> exit:
>> m_pMutex->Unlock();
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>>
>>Index: datatype/mp3/renderer/mp3rend.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/mp3/renderer/mp3rend.cpp,v
>>retrieving revision 1.22
>>diff -u -w -b -r1.22 mp3rend.cpp
>>--- datatype/mp3/renderer/mp3rend.cpp 2 Nov 2004 22:53:05 -0000 1.22
>>+++ datatype/mp3/renderer/mp3rend.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -845,6 +845,8 @@
>> CRnMp3Ren::OnDryNotification(UINT32 /*IN*/ ulCurrentStreamTime,
>> UINT32 /*IN*/ ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> // We do not set our rebuffer flag at the end of a stream
>> if (m_bEndOfPackets || !m_pStream)
>> return HXR_OK;
>>@@ -878,10 +880,11 @@
>> m_pPacketParser->GetTimePerPkt() + 1);
>> }
>> m_pStream->ReportRebufferStatus(m_nPacketsNeeded, 0);
>>+ hr = HXR_WOULD_BLOCK;
>> }
>> #endif
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>> STDMETHODIMP
>>Index: datatype/rm/audio/renderer/rarender.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/rm/audio/renderer/rarender.cpp,v
>>retrieving revision 1.44
>>diff -u -w -b -r1.44 rarender.cpp
>>--- datatype/rm/audio/renderer/rarender.cpp 2 Nov 2004 22:53:05
>>-0000 1.44
>>+++ datatype/rm/audio/renderer/rarender.cpp 1 Dec 2004 21:24:01 -0000
>>@@ -2260,6 +2260,8 @@
>> STDMETHODIMP CRealAudioRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> // If we are playing at non-1x playback, then don't
>> // take any action on a OnDryNotification
>> if (m_lPlaybackVelocity != HX_PLAYBACK_VELOCITY_NORMAL)
>>@@ -2453,6 +2455,8 @@
>> m_pStream->ReportRebufferStatus(1,0);
>> }
>>
>>+ hr = HXR_WOULD_BLOCK;
>>+
>> DEBUG_OUTF(SWITCH_FILE,
>> (s, "Entering Buffering\t%u\n",
>> m_usCurrentDryNotificationStream));
>> DEBUG_OUT(m_pErrorMessages, DOL_REALAUDIO,
>>@@ -2477,7 +2481,7 @@
>> exit:
>> m_pMutex->Unlock();
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>> #ifdef _MACINTOSH
>>Index: datatype/wav/renderer/pcm/pcmrendr.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/wav/renderer/pcm/pcmrendr.cpp,v
>>retrieving revision 1.2
>>diff -u -w -b -r1.2 pcmrendr.cpp
>>--- datatype/wav/renderer/pcm/pcmrendr.cpp 24 Oct 2003 17:07:17
>>-0000 1.2
>>+++ datatype/wav/renderer/pcm/pcmrendr.cpp 1 Dec 2004 21:24:02 -0000
>>@@ -904,6 +904,8 @@
>> STDMETHODIMP CPCMRenderer::OnDryNotification(UINT32 /*IN*/
>> ulCurrentStreamTime,
>> UINT32 /*IN*/
>> ulMinimumDurationRequired)
>> {
>>+ HX_RESULT hr = HXR_OK;
>>+
>> if ((!m_bPacketsDone) && m_pStream)
>> {
>> // {FILE* f1 = ::fopen("c:\\aurend.txt", "a+"); ::fprintf(f1,
>> "DryNotification tickCount: %11lu\n", HX_GET_BETTERTICKCOUNT());::fclose(f1);}
>>@@ -911,9 +913,10 @@
>> m_pStream->ReportRebufferStatus(DRY_BUFFER_COUNT, 0);
>> m_bStreamDry = TRUE;
>> m_chBufferingCount = 0;
>>+ hr = HXR_WOULD_BLOCK;
>> }
>>
>>- return HXR_OK;
>>+ return hr;
>> }
>>
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/1bf8c4cc/attachment-0001.htm
From nhart at real.com Fri Dec 3 14:44:19 2004
From: nhart at real.com (Nicholas Hart)
Date: Fri Dec 3 14:44:22 2004
Subject: [datatype-dev] CR: datatype/avi/fileformat
In-Reply-To: <5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
References: <5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
Message-ID: <1102113859.3232.20.camel@localhost.localdomain>
Using Jamie's suggestion I looked at the version in datatype_rn, and it
looks like it just explicitly defines BI_RGB if it isn't defined
already. If this is a good enough solution then I propose committing
the following to the head. Otherwise we need to have a debate about
relocating hxvsurf.h or the portion which defines BI_RGB.
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.4
diff -u -w -r1.4 avistrm.cpp
--- avistrm.cpp 2 Dec 2004 18:20:14 -0000 1.4
+++ avistrm.cpp 3 Dec 2004 22:42:13 -0000
@@ -259,6 +259,12 @@
#define SIZE_OF_QT_VIDEO_HEADER 10
+#ifndef BI_RGB
+// This is defined by a windows header, so define it for non-windows
platforms
+#define BI_RGB 0
+#endif
+
+
/////////////////////////////////////////////////////////////////////////
// CAVIStream::CAVIStream
//
Index: pub/avistrm.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
retrieving revision 1.4
diff -u -w -r1.4 avistrm.h
--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
+++ pub/avistrm.h 3 Dec 2004 22:42:13 -0000
@@ -221,7 +221,7 @@
UINT32 m_ulTotalBytesRead;
UINT32 m_ulTotalBytesPacketised;
BOOL m_bSeeking;
- ULONG m_ulSeekTime;
+ ULONG32 m_ulSeekTime;
On Thu, 2004-12-02 at 12:19, Eric Hyche wrote:
> At 12:01 PM 12/2/2004 -0800, Nicholas Hart wrote:
> >The AVI fileformat is b0rken on linux. The following diffs fix two of
> >the problems. There is one other that is going to require either a hack
> >or moving some #defines around. The file avistrm.cpp uses the macro
> >"BI_RGB" which only seems to be defined in client/include/hxvsurf.h
> >(probably in some windows header somewhere too I bet).
>
> Yep, BI_RGB is defined in Windows header code.
>
> >So either we
> >need to define a local version of BI_RGB for this file, or move some/all
> >of hxvsurf to common/include... or create some header in
> >datatype/include that can contain the BI_RGB definition.
>
> I would be for moving hxvsurf.h to common/include... others
> may have different opinions...
>
> Rest looks good...
>
> Eric
>
>
> >Index: pub/aviffpln.h
> >===================================================================
> >RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
> >retrieving revision 1.3
> >diff -u -w -r1.3 aviffpln.h
> >--- pub/aviffpln.h 2 Dec 2004 18:21:40 -0000 1.3
> >+++ pub/aviffpln.h 2 Dec 2004 19:59:16 -0000
> >@@ -119,8 +119,8 @@
> > , public IHXInterruptSafe
> > , public IHXFileSystemManagerResponse
> > {
> >- friend CAVIStream; // for ExternalEvent()
> >- friend CAVIIndex; // for ExternalEvent()
> >+ friend class CAVIStream; // for ExternalEvent()
> >+ friend class CAVIIndex; // for ExternalEvent()
> >
> > public:
> > static HX_RESULT STDAPICALLTYPE HXCreateInstance(IUnknown**
> >ppIUnknown);
> >Index: pub/avistrm.h
> >===================================================================
> >RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
> >retrieving revision 1.4
> >diff -u -w -r1.4 avistrm.h
> >--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
> >+++ pub/avistrm.h 2 Dec 2004 19:59:16 -0000
> >@@ -221,7 +221,7 @@
> > UINT32 m_ulTotalBytesRead;
> > UINT32 m_ulTotalBytesPacketised;
> > BOOL m_bSeeking;
> >- ULONG m_ulSeekTime;
> >+ ULONG32 m_ulSeekTime;
> >
> >
> >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
--
Nicholas Hart
nhart@real.com
Technical Lead, Helix Player
https://player.helixcommunity.org
http://www.real.com
From milko at real.com Fri Dec 3 15:05:54 2004
From: milko at real.com (milko)
Date: Fri Dec 3 15:06:04 2004
Subject: [datatype-dev] CR: datatype/avi/fileformat
In-Reply-To: <1102113859.3232.20.camel@localhost.localdomain>
References: <5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
<5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041203150537.035508e0@mailone.real.com>
At 02:44 PM 12/3/2004, Nicholas Hart wrote:
>Using Jamie's suggestion I looked at the version in datatype_rn, and it
>looks like it just explicitly defines BI_RGB if it isn't defined
>already. If this is a good enough solution then I propose committing
>the following to the head.
Looks good to me.
>Otherwise we need to have a debate about
>relocating hxvsurf.h or the portion which defines BI_RGB.
>
>
>Index: avistrm.cpp
>===================================================================
>RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
>retrieving revision 1.4
>diff -u -w -r1.4 avistrm.cpp
>--- avistrm.cpp 2 Dec 2004 18:20:14 -0000 1.4
>+++ avistrm.cpp 3 Dec 2004 22:42:13 -0000
>@@ -259,6 +259,12 @@
> #define SIZE_OF_QT_VIDEO_HEADER 10
>
>
>+#ifndef BI_RGB
>+// This is defined by a windows header, so define it for non-windows
>platforms
>+#define BI_RGB 0
>+#endif
>+
>+
>
>/////////////////////////////////////////////////////////////////////////
> // CAVIStream::CAVIStream
> //
>Index: pub/avistrm.h
>===================================================================
>RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
>retrieving revision 1.4
>diff -u -w -r1.4 avistrm.h
>--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
>+++ pub/avistrm.h 3 Dec 2004 22:42:13 -0000
>@@ -221,7 +221,7 @@
> UINT32 m_ulTotalBytesRead;
> UINT32 m_ulTotalBytesPacketised;
> BOOL m_bSeeking;
>- ULONG m_ulSeekTime;
>+ ULONG32 m_ulSeekTime;
>
>
>
>
>On Thu, 2004-12-02 at 12:19, Eric Hyche wrote:
> > At 12:01 PM 12/2/2004 -0800, Nicholas Hart wrote:
> > >The AVI fileformat is b0rken on linux. The following diffs fix two of
> > >the problems. There is one other that is going to require either a hack
> > >or moving some #defines around. The file avistrm.cpp uses the macro
> > >"BI_RGB" which only seems to be defined in client/include/hxvsurf.h
> > >(probably in some windows header somewhere too I bet).
> >
> > Yep, BI_RGB is defined in Windows header code.
> >
> > >So either we
> > >need to define a local version of BI_RGB for this file, or move some/all
> > >of hxvsurf to common/include... or create some header in
> > >datatype/include that can contain the BI_RGB definition.
> >
> > I would be for moving hxvsurf.h to common/include... others
> > may have different opinions...
> >
> > Rest looks good...
> >
> > Eric
> >
> >
> > >Index: pub/aviffpln.h
> > >===================================================================
> > >RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
> > >retrieving revision 1.3
> > >diff -u -w -r1.3 aviffpln.h
> > >--- pub/aviffpln.h 2 Dec 2004 18:21:40 -0000 1.3
> > >+++ pub/aviffpln.h 2 Dec 2004 19:59:16 -0000
> > >@@ -119,8 +119,8 @@
> > > , public IHXInterruptSafe
> > > , public IHXFileSystemManagerResponse
> > > {
> > >- friend CAVIStream; // for ExternalEvent()
> > >- friend CAVIIndex; // for ExternalEvent()
> > >+ friend class CAVIStream; // for ExternalEvent()
> > >+ friend class CAVIIndex; // for ExternalEvent()
> > >
> > > public:
> > > static HX_RESULT STDAPICALLTYPE HXCreateInstance(IUnknown**
> > >ppIUnknown);
> > >Index: pub/avistrm.h
> > >===================================================================
> > >RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
> > >retrieving revision 1.4
> > >diff -u -w -r1.4 avistrm.h
> > >--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
> > >+++ pub/avistrm.h 2 Dec 2004 19:59:16 -0000
> > >@@ -221,7 +221,7 @@
> > > UINT32 m_ulTotalBytesRead;
> > > UINT32 m_ulTotalBytesPacketised;
> > > BOOL m_bSeeking;
> > >- ULONG m_ulSeekTime;
> > >+ ULONG32 m_ulSeekTime;
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Datatype-dev mailing list
> > >Datatype-dev@helixcommunity.org
> > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> >
> > ======================================
> > M. Eric Hyche (ehyche@real.com)
> > Core Technologies
> > RealNetworks, Inc.
>--
>Nicholas Hart
>nhart@real.com
>Technical Lead, Helix Player
>https://player.helixcommunity.org
>http://www.real.com
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From nhart at real.com Fri Dec 3 15:40:38 2004
From: nhart at real.com (Nicholas Hart)
Date: Fri Dec 3 15:40:41 2004
Subject: [datatype-dev] CN: datatype/avi/fileformat
In-Reply-To: <5.1.0.14.2.20041203150537.035508e0@mailone.real.com>
References: <5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
<5.1.0.14.2.20041202151724.028b8eb8@mailone.real.com>
<5.1.0.14.2.20041203150537.035508e0@mailone.real.com>
Message-ID: <1102117238.3232.28.camel@localhost.localdomain>
This has been committed to HEAD.
On Fri, 2004-12-03 at 15:05, milko wrote:
> At 02:44 PM 12/3/2004, Nicholas Hart wrote:
> >Using Jamie's suggestion I looked at the version in datatype_rn, and it
> >looks like it just explicitly defines BI_RGB if it isn't defined
> >already. If this is a good enough solution then I propose committing
> >the following to the head.
>
> Looks good to me.
>
> >Otherwise we need to have a debate about
> >relocating hxvsurf.h or the portion which defines BI_RGB.
> >
> >
> >Index: avistrm.cpp
> >===================================================================
> >RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
> >retrieving revision 1.4
> >diff -u -w -r1.4 avistrm.cpp
> >--- avistrm.cpp 2 Dec 2004 18:20:14 -0000 1.4
> >+++ avistrm.cpp 3 Dec 2004 22:42:13 -0000
> >@@ -259,6 +259,12 @@
> > #define SIZE_OF_QT_VIDEO_HEADER 10
> >
> >
> >+#ifndef BI_RGB
> >+// This is defined by a windows header, so define it for non-windows
> >platforms
> >+#define BI_RGB 0
> >+#endif
> >+
> >+
> >
> >/////////////////////////////////////////////////////////////////////////
> > // CAVIStream::CAVIStream
> > //
> >Index: pub/avistrm.h
> >===================================================================
> >RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
> >retrieving revision 1.4
> >diff -u -w -r1.4 avistrm.h
> >--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
> >+++ pub/avistrm.h 3 Dec 2004 22:42:13 -0000
> >@@ -221,7 +221,7 @@
> > UINT32 m_ulTotalBytesRead;
> > UINT32 m_ulTotalBytesPacketised;
> > BOOL m_bSeeking;
> >- ULONG m_ulSeekTime;
> >+ ULONG32 m_ulSeekTime;
> >
> >
> >
> >
> >On Thu, 2004-12-02 at 12:19, Eric Hyche wrote:
> > > At 12:01 PM 12/2/2004 -0800, Nicholas Hart wrote:
> > > >The AVI fileformat is b0rken on linux. The following diffs fix two of
> > > >the problems. There is one other that is going to require either a hack
> > > >or moving some #defines around. The file avistrm.cpp uses the macro
> > > >"BI_RGB" which only seems to be defined in client/include/hxvsurf.h
> > > >(probably in some windows header somewhere too I bet).
> > >
> > > Yep, BI_RGB is defined in Windows header code.
> > >
> > > >So either we
> > > >need to define a local version of BI_RGB for this file, or move some/all
> > > >of hxvsurf to common/include... or create some header in
> > > >datatype/include that can contain the BI_RGB definition.
> > >
> > > I would be for moving hxvsurf.h to common/include... others
> > > may have different opinions...
> > >
> > > Rest looks good...
> > >
> > > Eric
> > >
> > >
> > > >Index: pub/aviffpln.h
> > > >===================================================================
> > > >RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
> > > >retrieving revision 1.3
> > > >diff -u -w -r1.3 aviffpln.h
> > > >--- pub/aviffpln.h 2 Dec 2004 18:21:40 -0000 1.3
> > > >+++ pub/aviffpln.h 2 Dec 2004 19:59:16 -0000
> > > >@@ -119,8 +119,8 @@
> > > > , public IHXInterruptSafe
> > > > , public IHXFileSystemManagerResponse
> > > > {
> > > >- friend CAVIStream; // for ExternalEvent()
> > > >- friend CAVIIndex; // for ExternalEvent()
> > > >+ friend class CAVIStream; // for ExternalEvent()
> > > >+ friend class CAVIIndex; // for ExternalEvent()
> > > >
> > > > public:
> > > > static HX_RESULT STDAPICALLTYPE HXCreateInstance(IUnknown**
> > > >ppIUnknown);
> > > >Index: pub/avistrm.h
> > > >===================================================================
> > > >RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
> > > >retrieving revision 1.4
> > > >diff -u -w -r1.4 avistrm.h
> > > >--- pub/avistrm.h 2 Dec 2004 18:23:32 -0000 1.4
> > > >+++ pub/avistrm.h 2 Dec 2004 19:59:16 -0000
> > > >@@ -221,7 +221,7 @@
> > > > UINT32 m_ulTotalBytesRead;
> > > > UINT32 m_ulTotalBytesPacketised;
> > > > BOOL m_bSeeking;
> > > >- ULONG m_ulSeekTime;
> > > >+ ULONG32 m_ulSeekTime;
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Datatype-dev mailing list
> > > >Datatype-dev@helixcommunity.org
> > > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> > >
> > > ======================================
> > > M. Eric Hyche (ehyche@real.com)
> > > Core Technologies
> > > RealNetworks, Inc.
> >--
> >Nicholas Hart
> >nhart@real.com
> >Technical Lead, Helix Player
> >https://player.helixcommunity.org
> >http://www.real.com
> >
> >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
--
Nicholas Hart
nhart@real.com
Technical Lead, Helix Player
https://player.helixcommunity.org
http://www.real.com
From hfrederickson at real.com Fri Dec 3 19:26:00 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Fri Dec 3 19:21:53 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer
Message-ID: <1102130759.1200.910.camel@localhost.localdomain>
Synopsis: A new source handler and plugin have been created to allow
depacketization of RealVideo streams.
Overview:
The main goal of these new components is to provide a tool to create raw
files that contain a sequence of encoded RealVideo frames. When coupled
with the raw filewriter (binwrtr), the RV depacketizer source handler
and plugin do just that. Here's an example of command line usage:
dtdrive.exe +DV 3 -W foo.raw foo.rm
The new raw file format has a header at the top of the file, followed by
the sequence of frames. It looks like this:
[HEADER]
HX_MOF bitstream_header (header size is first member of struct)
[FRAME]
UINT32 dataLength
UINT32 timestamp
UINT16 sequenceNum
UINT16 flags
UINT32 lastPacket
UINT32 numSegments
HXCODEC_SEGMENT_INFO Segments[numSegments]
UINT8 data[dataLength]
With this new raw file format for RealVideo, the command line decoder
test applications will finally be able to exercise the decoder
algorithms with true RealVideo bitstreams, once they are modified to
parse the new format.
The depacketizer plugin produces output packets in the above format
only, so it is not particularly useful for any purpose other than
feeding the raw filewriter.
Files Modified:
/datatype/tools/dtdriver/apps/dtdrive/main.cpp
/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
/datatype/tools/dtdriver/decoder/video/Umakefil
/common/include/hxplugn.h
/client/common/container/pub/basehand.h
/client/common/container/pub/hxplugin.h
/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
New Files:
/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
/datatype/tools/dtdriver/depacker/video/dlliids.cpp
/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
/datatype/tools/dtdriver/depacker/video/rvdepack.ver
/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
/datatype/tools/dtdriver/depacker/video/umakedll
/datatype/tools/dtdriver/depacker/video/Umakefil
/datatype/tools/dtdriver/depacker/video/umakelib
/datatype/tools/dtdriver/depacker/video/win32.pcf
/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
Image Size and Heap Use impact:
Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
is defined. The rvdepacker plugin dll is about 60KB on windows.
Platforms and Profiles Affected:
dtdr video profiles on all platforms. tested on windows and x86-linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apps_dtdrive_main.cpp.diff
Type: text/x-patch
Size: 1270 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/apps_dtdrive_main.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_common_decslcfn.cpp.diff
Type: text/x-patch
Size: 1854 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/decoder_common_decslcfn.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_common_pub_decslcfn.h.diff
Type: text/x-patch
Size: 1186 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/decoder_common_pub_decslcfn.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_video_Umakefil.diff
Type: text/x-patch
Size: 684 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/decoder_video_Umakefil-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix.bif.diff
Type: text/x-patch
Size: 2417 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/helix.bif-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix-dtdr-local-video-transcode.pfi.diff
Type: text/x-patch
Size: 709 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/helix-dtdr-local-video-transcode.pfi-0001.bin
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifdef APSTUDIO_INVOKED
#error this file is not editable by Microsoft Visual C++
#endif //APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
// Add manually edited resources here...
/////////////////////////////////////////////////////////////////////////////
// Version stamp for this deliverable
#ifdef WIN32
#include // Defines for 32bit windows version resources
#else
#include // Defines for 16bit windows version resources
#endif
#include "hxver.h" // Defines for standard deliverables
#include "rvdepack.ver" // Defines for this deliverable created by GETFILES
VS_VERSION_INFO VERSIONINFO
FILEVERSION TARVER_LIST_VERSION
PRODUCTVERSION TARVER_LIST_VERSION
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG|VS_FF_PRIVATEBUILD|VS_FF_PRERELEASE
#else
FILEFLAGS 0 // final version
#endif
FILEOS VER_FILEOS
FILETYPE 0 // not needed
FILESUBTYPE 0 // not needed
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904E4" // Lang=US English, CharSet=Windows Multilingual
BEGIN
VALUE "FileDescription", "RealVideo Depacketizer plugin for RealMedia"
VALUE "InternalName", "rvdepack\0"
VALUE "OriginalFilename","rvdepack.DLL\0"
VALUE "ProductName", "RealVideo Depacketizer plugin for RealMedia"
STRPLATFORM TARVER_STR_BUILD_NAME STREND
VALUE "FileVersion", TARVER_STRING_VERSION
VALUE "ProductVersion", TARVER_STRING_VERSION
VALUE "CompanyName", HXVER_COMPANY
VALUE "LegalCopyright", HXVER_COPYRIGHT
VALUE "LegalTrademarks", HXVER_TRADEMARKS
VALUE "DistCode", "PN01\0"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1252
// English language (0x409) and the Windows ANSI codepage (1252)
END
END
/////////////////////////////////////////////////////////////////////////////
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlliids.cpp
Type: text/x-c++
Size: 1984 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/dlliids-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.cpp
Type: text/x-c++
Size: 18553 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/rvdepack-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepackdll.cpp
Type: text/x-c++
Size: 2194 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/rvdepackdll-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.h
Type: text/x-c-header
Size: 4703 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/rvdepack-0003.bin
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,2)
#project.AddModuleIncludes("HELIX_FEATURE_MIN_HEAP")
project.AddModuleIncludes("common/include",
"client/include",
"client/common/container/pub",
"datatype/common/container/pub",
"datatype/common/util/pub",
"datatype/rm/video/common/pub",
"datatype/rm/include",
"datatype/rm/common/util/pub")
project.AddModuleLibraries("common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"common/util[utillib]",
"common/container[contlib]",
"common/system[syslib]",
"common/log/logutil[logutillib]",
"datatype/rm/common[rmcomlib]",
"datatype/tools/dtdriver/depacker/video[rvdepacklib]",
"datatype/common/util[dtutillib]")
project.AddLibraries(GetSDKPath("rmvidcom_lib"),
GetSDKPath("rmvidpyld_lib"))
project.AddSources("rvdepackdll.cpp",
"dlliids.cpp")
project.ExportFunction("RMACreateInstance",
"IUnknown** ppObj",
"common/include",
"hxcom.h")
project.ExportFunction("CanUnload", "void")
project.ExportFunction("CanUnload2", "void")
if not project.IsDefined("HELIX_FEATURE_DLLACCESS_CLIENT"):
project.ExportFunction("SetDLLAccessPath", "const char* pszPath")
DLLTarget("rvdepack")
DependTarget()
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,1)
MultiTargetMake("umakelib", "umakedll")
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,2)
project.AddModuleIncludes("common/include",
"common/runtime/pub",
"common/dbgtool/pub",
"common/util/pub",
"common/container/pub",
"common/system/pub",
"common/log/logutil/pub",
"client/include",
"client/common/container/pub",
"datatype/common/container/pub",
"datatype/common/util/pub",
"datatype/rm/video/common/pub",
"datatype/rm/common/pub",
"datatype/rm/include",
"datatype/rm/common/util/pub",
"datatype/h263/payload/pub",
"datatype/h263/codec")
project.AddSources("rvdepack.cpp")
LibraryTarget("rvdepacklib")
DependTarget()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdepacker.cpp
Type: text/x-c++
Size: 22551 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/vdepacker-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.pcf
Type: application/x-font-pcf
Size: 211 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/win32-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_common_container_pub_basehand.h.diff
Type: text/x-patch
Size: 1406 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/client_common_container_pub_basehand.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_common_container_pub_hxplugin.h.diff
Type: text/x-patch
Size: 1406 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/client_common_container_pub_hxplugin.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_include_hxplugn.h.diff
Type: text/x-patch
Size: 1380 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/common_include_hxplugn.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdepacker.h
Type: text/x-c-header
Size: 5058 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041203/c34eeea3/vdepacker-0003.bin
From ehyche at real.com Mon Dec 6 08:20:36 2004
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 6 08:20:43 2004
Subject: [datatype-dev] CR-Client-RESEND: Updates to xml writer
Message-ID: <5.1.0.14.2.20041206112010.00c0f4c8@mailone.real.com>
Synopsis: minor updates to XML writer
Overview: 1. Don't output DTD at the start of the .xml file -
we will come up with Schema instead of DTD.
2. Change from using single tag to
using , , and
.
3. Compute CRC32 over the packet buffer and add
"crc32" attribute to element.
4. Add compile-time-configurable indents
5. Link in zlib library
6. Add zlib to xmlwriter dependencies in BIF
Files Modified:
datatype/tools/xmlwriter/Umakefil
datatype/tools/xmlwriter/xmlwriter.cpp
datatype/tools/xmlwriter/pub/xmlwriter.h
common/build/BIF/helix.bif
Image Size and Heap Use impact: none
Platforms and Profiles Affected: all
Distribution Libraries affected: none
Distribution library impact and planned action: n/a
Platforms and Profiles Build Verified: win32
Platforms and Profiles Functionality verified: win32
Branch: HEAD only
QA Instructions: none
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/Umakefil,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 Umakefil
--- Umakefil 21 Jun 2004 16:26:04 -0000 1.1
+++ Umakefil 2 Dec 2004 19:45:12 -0000
@@ -42,7 +42,8 @@
"common/dbgtool[debuglib]",
"common/runtime[runtlib]",
"common/system[syslib]",
- "common/util[utillib]")
+ "common/util[utillib]",
+ "common/import/zlib[zlib]")
project.AddSources("xmlwriter.cpp",
"xmlwriterdll.cpp",
Index: xmlwriter.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/xmlwriter.cpp,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 xmlwriter.cpp
--- xmlwriter.cpp 21 Jun 2004 16:26:04 -0000 1.1
+++ xmlwriter.cpp 2 Dec 2004 19:45:12 -0000
@@ -41,6 +41,7 @@
#include "baseobj.h"
#include "hxver.h"
#include "hxfwrtr.h"
+#include "zlib.h"
#include "xmlwriter.h"
#include "xmlwriter.ver"
@@ -50,28 +51,9 @@
const char* const CXMLFileWriter::m_ppszFileMimeTypes[] =
{"application/xml", NULL};
const char* const CXMLFileWriter::m_ppszFileExtensions[] = {"xml", NULL};
const char* const CXMLFileWriter::m_ppszFileOpenNames[] = {"XML Output
Files (*.xml)", NULL};
-const char* const CXMLFileWriter::m_pszHeaderStr =
- "\n"
- "\n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- " \n"
- "]>\n";
+const char* const CXMLFileWriter::m_pszHeaderStr = "\n";
+
+#define XMLWRITER_INDENT_SIZE 4
CXMLFileWriter::CXMLFileWriter()
{
@@ -82,6 +64,7 @@
m_ulStreamCount = 0;
m_ulNumStreams = 0;
m_bWrotePacketContainerOpen = FALSE;
+ m_pszIndent2 = NULL;
}
@@ -233,6 +216,7 @@
}
HX_RELEASE(m_pContext);
HX_RELEASE(m_pMonitor);
+ HX_VECTOR_DELETE(m_pszIndent2);
return retVal;
}
@@ -248,21 +232,26 @@
if (pHeader && m_fp)
{
+ // Get an indent string for indent level 1
+ char* pszIndent = CreateIndentString(1);
+ if (pszIndent)
+ {
// Print out file header element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Write out the file header properties
- fprintf(m_fp, " \n");
- WriteOutValues(pHeader, m_fp, 12);
- fprintf(m_fp, " \n");
+ WriteOutValues(pHeader, m_fp, 2);
// Print out the file header end element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Print out the stream header container element begin
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent);
// Clear the stream header count
m_ulNumStreams = 0;
// Get the stream count
retVal = pHeader->GetPropertyULONG32("StreamCount", m_ulStreamCount);
}
+ // Free the indent string
+ HX_VECTOR_DELETE(pszIndent);
+ }
return retVal;
}
@@ -273,14 +262,17 @@
if (pHeader && m_fp)
{
+ // Create an indent string for indent levels 1 and 2
+ char* pszIndent1 = CreateIndentString(1);
+ char* pszIndent2 = CreateIndentString(2);
+ if (pszIndent1 && pszIndent2)
+ {
// Print out file header element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent2);
// Write out the file header properties
- fprintf(m_fp, " \n");
- WriteOutValues(pHeader, m_fp, 16);
- fprintf(m_fp, " \n");
+ WriteOutValues(pHeader, m_fp, 3);
// Print out the file header end element
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent2);
// Increment the stream count
m_ulNumStreams++;
// If we have gotten all our stream headers, then
@@ -288,7 +280,7 @@
if (m_ulNumStreams >= m_ulStreamCount && m_pMonitor)
{
// Print out the stream header container element end
- fprintf(m_fp, " \n");
+ fprintf(m_fp, "%s\n", pszIndent1);
// Tell the monitor we're ready
m_pMonitor->OnPacketsReady(HXR_OK);
// Reset the stream count so we can count StreamDone()'s
@@ -297,6 +289,10 @@
// Clear the return value
retVal = HXR_OK;
}
+ // Free the indent strings
+ HX_VECTOR_DELETE(pszIndent1);
+ HX_VECTOR_DELETE(pszIndent2);
+ }
return retVal;
}
@@ -312,16 +308,29 @@
if (pPacket && m_fp)
{
+ // Create indent level 2 string (if it
+ // doesn't already exist)
+ if (!m_pszIndent2)
+ {
+ m_pszIndent2 = CreateIndentString(2);
+ }
// Write out the packet container element open
// (if we have not already)
if (!m_bWrotePacketContainerOpen)
{
if (m_fp)
{
- fprintf(m_fp, " \n");
+ char* pszIndent1 = CreateIndentString(1);
+ if (pszIndent1)
+ {
+ fprintf(m_fp, "%s\n", pszIndent1);
+ }
+ HX_VECTOR_DELETE(pszIndent1);
}
m_bWrotePacketContainerOpen = TRUE;
}
+ if (m_pszIndent2)
+ {
// Get the packet parameters
IHXBuffer* pBuffer = NULL;
UINT32 ulTime = 0;
@@ -331,14 +340,17 @@
retVal = pPacket->Get(pBuffer, ulTime, usStreamNumber,
ucASMFlags, usASMRuleNumber);
if (SUCCEEDED(retVal))
{
+ UINT32 ulCRC32 = ComputeCRC32(pBuffer);
// Print out the packet elemnt
fprintf(m_fp,
- " \n",
- usStreamNumber, ulTime, ucASMFlags, usASMRuleNumber,
pBuffer->GetSize());
+ "%s\n",
+ m_pszIndent2, usStreamNumber, ulTime, ucASMFlags,
usASMRuleNumber,
+ pBuffer->GetSize(), ulCRC32);
}
HX_RELEASE(pBuffer);
}
+ }
return retVal;
}
@@ -370,28 +382,23 @@
return retVal;
}
-void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
ulIndent)
+void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
ulIndentLevel)
{
if (pValues && fp)
{
// Build indent string
- char* pszIndent = new char [ulIndent + 1];
+ char* pszIndent = CreateIndentString(ulIndentLevel);
if (pszIndent)
{
- // Fill in spaces
- if (ulIndent)
- {
- memset((void*) pszIndent, ' ', ulIndent);
- }
- // Fill in NULL terminator
- pszIndent[ulIndent] = '\0';
+ // Write out the open element
+ fprintf(fp, "%s\n", pszIndent);
// Print out ULONG32 properties
const char* pszName = NULL;
UINT32 ulValue = 0;
HX_RESULT rv =
pValues->GetFirstPropertyULONG32(pszName, ulValue);
while (SUCCEEDED(rv))
{
- fprintf(fp, "%s\n",
+ fprintf(fp, "%s \n",
pszIndent, pszName, ulValue);
rv = pValues->GetNextPropertyULONG32(pszName, ulValue);
}
@@ -400,7 +407,7 @@
rv = pValues->GetFirstPropertyCString(pszName, pValue);
while (SUCCEEDED(rv))
{
- fprintf(fp, "%sGetBuffer(), fp);
fprintf(fp, "\"/>\n");
HX_RELEASE(pValue);
@@ -417,7 +424,7 @@
{
memset((void*) pTmp, 0, ulSize);
INT32 lLen = BinTo64(pValue->GetBuffer(),
pValue->GetSize(), pTmp);
- fprintf(fp, "%s\n",
+ fprintf(fp, "%s \n",
pszIndent, pszName, (const char*) pTmp);
}
HX_VECTOR_DELETE(pTmp);
@@ -425,6 +432,8 @@
HX_RELEASE(pValue);
rv = pValues->GetNextPropertyBuffer(pszName, pValue);
}
+ // Write out the close element
+ fprintf(fp, "%s\n", pszIndent);
}
HX_VECTOR_DELETE(pszIndent);
}
@@ -505,5 +514,35 @@
}
return retVal;
+}
+
+char* CXMLFileWriter::CreateIndentString(UINT32 ulIndentLevel)
+{
+ char* pRet = NULL;
+
+ UINT32 ulLen = ulIndentLevel * XMLWRITER_INDENT_SIZE;
+ pRet = new char [ulLen + 1];
+ if (pRet)
+ {
+ memset(pRet, ' ', ulLen);
+ pRet[ulLen] = '\0';
+ }
+
+ return pRet;
+}
+
+UINT32 CXMLFileWriter::ComputeCRC32(IHXBuffer* pBuffer)
+{
+ UINT32 ulRet = 0;
+
+ if (pBuffer)
+ {
+ // Pre-condition the CRC32
+ ulRet = crc32(0, NULL, 0);
+ // Compute the CRC on the buffer
+ ulRet = crc32(ulRet, pBuffer->GetBuffer(), pBuffer->GetSize());
+ }
+
+ return ulRet;
}
cvs server: Diffing pub
Index: pub/xmlwriter.h
===================================================================
RCS file: /cvsroot/datatype/tools/xmlwriter/pub/xmlwriter.h,v
retrieving revision 1.1
diff -u -w -u -w -r1.1 xmlwriter.h
--- pub/xmlwriter.h 21 Jun 2004 16:26:04 -0000 1.1
+++ pub/xmlwriter.h 2 Dec 2004 19:45:12 -0000
@@ -88,6 +88,7 @@
UINT32 m_ulStreamCount;
UINT32 m_ulNumStreams;
BOOL m_bWrotePacketContainerOpen;
+ char* m_pszIndent2;
static const char* const m_pszDescription;
static const char* const m_pszCopyright;
@@ -99,6 +100,8 @@
void WriteOutValues(IHXValues* pValues, FILE* fp, UINT32 ulIndent);
HX_RESULT WriteOutCStringValue(const char* pszValue, FILE* fp);
+ char* CreateIndentString(UINT32 ulIndentLevel);
+ UINT32 ComputeCRC32(IHXBuffer* pBuffer);
};
#endif /* #ifndef XMLWRITER_H */
Index: helix.bif
===================================================================
RCS file: /cvsroot/common/build/BIF/helix.bif,v
retrieving revision 1.492
diff -u -w -u -w -r1.492 helix.bif
--- helix.bif 17 Nov 2004 19:50:30 -0000 1.492
+++ helix.bif 2 Dec 2004 19:50:42 -0000
@@ -1879,6 +1879,7 @@
common_runtime
common_system
common_util
+ common_import_zlib
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From ehyche at real.com Mon Dec 6 08:49:30 2004
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 6 08:49:34 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer
In-Reply-To: <1102130759.1200.910.camel@localhost.localdomain>
Message-ID: <5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
Some comments:
1) In rvdepack.cpp:
const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30";
Why are we only supporting RV8 and 9 with this? Should the depacketization
format also apply to G2 as well?
2) In rvdepack.cpp:
retVal = pPacket->Set(pBuffer, 0, 0, 0, 0);
Why are we not preserving the frame timestamps? It would be very
useful to see the unpacked frame times using dtdrive...
Rest looks good.
Eric
At 07:26 PM 12/3/2004 -0800, Hans Frederickson wrote:
>Synopsis: A new source handler and plugin have been created to allow
>depacketization of RealVideo streams.
>
>Overview:
>The main goal of these new components is to provide a tool to create raw
>files that contain a sequence of encoded RealVideo frames. When coupled
>with the raw filewriter (binwrtr), the RV depacketizer source handler
>and plugin do just that. Here's an example of command line usage:
>
>dtdrive.exe +DV 3 -W foo.raw foo.rm
>
>The new raw file format has a header at the top of the file, followed by
>the sequence of frames. It looks like this:
>
>[HEADER]
>HX_MOF bitstream_header (header size is first member of struct)
>
>[FRAME]
>UINT32 dataLength
>UINT32 timestamp
>UINT16 sequenceNum
>UINT16 flags
>UINT32 lastPacket
>UINT32 numSegments
>HXCODEC_SEGMENT_INFO Segments[numSegments]
>UINT8 data[dataLength]
>
>
>With this new raw file format for RealVideo, the command line decoder
>test applications will finally be able to exercise the decoder
>algorithms with true RealVideo bitstreams, once they are modified to
>parse the new format.
>
>The depacketizer plugin produces output packets in the above format
>only, so it is not particularly useful for any purpose other than
>feeding the raw filewriter.
>
>
>Files Modified:
>/datatype/tools/dtdriver/apps/dtdrive/main.cpp
>/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
>/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
>/datatype/tools/dtdriver/decoder/video/Umakefil
>
>/common/include/hxplugn.h
>/client/common/container/pub/basehand.h
>/client/common/container/pub/hxplugin.h
>
>/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
>/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
>
>New Files:
>/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
>/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
>
>/datatype/tools/dtdriver/depacker/video/dlliids.cpp
>/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
>/datatype/tools/dtdriver/depacker/video/rvdepack.ver
>/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
>/datatype/tools/dtdriver/depacker/video/umakedll
>/datatype/tools/dtdriver/depacker/video/Umakefil
>/datatype/tools/dtdriver/depacker/video/umakelib
>/datatype/tools/dtdriver/depacker/video/win32.pcf
>/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
>/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
>
>Image Size and Heap Use impact:
>Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
>is defined. The rvdepacker plugin dll is about 60KB on windows.
>
>Platforms and Profiles Affected:
>dtdr video profiles on all platforms. tested on windows and x86-linux.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From ehodge at real.com Mon Dec 6 09:34:39 2004
From: ehodge at real.com (Erik Hodge)
Date: Mon Dec 6 09:35:57 2004
Subject: [datatype-dev] CR-Client-RESEND: Updates to xml writer
In-Reply-To: <5.1.0.14.2.20041206112010.00c0f4c8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041206093433.01f08040@mailone.real.com>
Looks good.
At 11:20 AM 12/6/2004 -0500, Eric Hyche wrote:
>Synopsis: minor updates to XML writer
>
>Overview: 1. Don't output DTD at the start of the .xml file -
> we will come up with Schema instead of DTD.
> 2. Change from using single tag to
> using , , and
> .
> 3. Compute CRC32 over the packet buffer and add
> "crc32" attribute to element.
> 4. Add compile-time-configurable indents
> 5. Link in zlib library
> 6. Add zlib to xmlwriter dependencies in BIF
>
>Files Modified:
>datatype/tools/xmlwriter/Umakefil
>datatype/tools/xmlwriter/xmlwriter.cpp
>datatype/tools/xmlwriter/pub/xmlwriter.h
>common/build/BIF/helix.bif
>
>Image Size and Heap Use impact: none
>
>Platforms and Profiles Affected: all
>
>Distribution Libraries affected: none
>
>Distribution library impact and planned action: n/a
>
>Platforms and Profiles Build Verified: win32
>
>Platforms and Profiles Functionality verified: win32
>
>Branch: HEAD only
>
>QA Instructions: none
>
>Index: Umakefil
>===================================================================
>RCS file: /cvsroot/datatype/tools/xmlwriter/Umakefil,v
>retrieving revision 1.1
>diff -u -w -u -w -r1.1 Umakefil
>--- Umakefil 21 Jun 2004 16:26:04 -0000 1.1
>+++ Umakefil 2 Dec 2004 19:45:12 -0000
>@@ -42,7 +42,8 @@
> "common/dbgtool[debuglib]",
> "common/runtime[runtlib]",
> "common/system[syslib]",
>- "common/util[utillib]")
>+ "common/util[utillib]",
>+ "common/import/zlib[zlib]")
>
> project.AddSources("xmlwriter.cpp",
> "xmlwriterdll.cpp",
>Index: xmlwriter.cpp
>===================================================================
>RCS file: /cvsroot/datatype/tools/xmlwriter/xmlwriter.cpp,v
>retrieving revision 1.1
>diff -u -w -u -w -r1.1 xmlwriter.cpp
>--- xmlwriter.cpp 21 Jun 2004 16:26:04 -0000 1.1
>+++ xmlwriter.cpp 2 Dec 2004 19:45:12 -0000
>@@ -41,6 +41,7 @@
> #include "baseobj.h"
> #include "hxver.h"
> #include "hxfwrtr.h"
>+#include "zlib.h"
> #include "xmlwriter.h"
> #include "xmlwriter.ver"
>
>@@ -50,28 +51,9 @@
> const char* const CXMLFileWriter::m_ppszFileMimeTypes[] =
> {"application/xml", NULL};
> const char* const CXMLFileWriter::m_ppszFileExtensions[] = {"xml", NULL};
> const char* const CXMLFileWriter::m_ppszFileOpenNames[] = {"XML Output
> Files (*.xml)", NULL};
>-const char* const CXMLFileWriter::m_pszHeaderStr =
>- "\n"
>- "- " \n"
>- " \n"
>- " \n"
>- " \n"
>- " \n"
>- " \n"
>- " \n"
>- " \n"
>- " - " type (ULONG32 | CString | Buffer) #REQUIRED\n"
>- " name CDATA #REQUIRED\n"
>- " value CDATA #REQUIRED>\n"
>- " - " streamNum CDATA #REQUIRED\n"
>- " timestamp CDATA #REQUIRED\n"
>- " asmFlags CDATA #REQUIRED\n"
>- " asmRuleNum CDATA #REQUIRED\n"
>- " bufferSize CDATA #REQUIRED>\n"
>- "]>\n";
>+const char* const CXMLFileWriter::m_pszHeaderStr = "version=\"1.0\"?>\n";
>+
>+#define XMLWRITER_INDENT_SIZE 4
>
> CXMLFileWriter::CXMLFileWriter()
> {
>@@ -82,6 +64,7 @@
> m_ulStreamCount = 0;
> m_ulNumStreams = 0;
> m_bWrotePacketContainerOpen = FALSE;
>+ m_pszIndent2 = NULL;
> }
>
>
>@@ -233,6 +216,7 @@
> }
> HX_RELEASE(m_pContext);
> HX_RELEASE(m_pMonitor);
>+ HX_VECTOR_DELETE(m_pszIndent2);
>
> return retVal;
> }
>@@ -248,21 +232,26 @@
>
> if (pHeader && m_fp)
> {
>+ // Get an indent string for indent level 1
>+ char* pszIndent = CreateIndentString(1);
>+ if (pszIndent)
>+ {
> // Print out file header element
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent);
> // Write out the file header properties
>- fprintf(m_fp, " \n");
>- WriteOutValues(pHeader, m_fp, 12);
>- fprintf(m_fp, " \n");
>+ WriteOutValues(pHeader, m_fp, 2);
> // Print out the file header end element
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent);
> // Print out the stream header container element begin
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent);
> // Clear the stream header count
> m_ulNumStreams = 0;
> // Get the stream count
> retVal = pHeader->GetPropertyULONG32("StreamCount",
> m_ulStreamCount);
> }
>+ // Free the indent string
>+ HX_VECTOR_DELETE(pszIndent);
>+ }
>
> return retVal;
> }
>@@ -273,14 +262,17 @@
>
> if (pHeader && m_fp)
> {
>+ // Create an indent string for indent levels 1 and 2
>+ char* pszIndent1 = CreateIndentString(1);
>+ char* pszIndent2 = CreateIndentString(2);
>+ if (pszIndent1 && pszIndent2)
>+ {
> // Print out file header element
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent2);
> // Write out the file header properties
>- fprintf(m_fp, " \n");
>- WriteOutValues(pHeader, m_fp, 16);
>- fprintf(m_fp, " \n");
>+ WriteOutValues(pHeader, m_fp, 3);
> // Print out the file header end element
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent2);
> // Increment the stream count
> m_ulNumStreams++;
> // If we have gotten all our stream headers, then
>@@ -288,7 +280,7 @@
> if (m_ulNumStreams >= m_ulStreamCount && m_pMonitor)
> {
> // Print out the stream header container element end
>- fprintf(m_fp, " \n");
>+ fprintf(m_fp, "%s\n", pszIndent1);
> // Tell the monitor we're ready
> m_pMonitor->OnPacketsReady(HXR_OK);
> // Reset the stream count so we can count StreamDone()'s
>@@ -297,6 +289,10 @@
> // Clear the return value
> retVal = HXR_OK;
> }
>+ // Free the indent strings
>+ HX_VECTOR_DELETE(pszIndent1);
>+ HX_VECTOR_DELETE(pszIndent2);
>+ }
>
> return retVal;
> }
>@@ -312,16 +308,29 @@
>
> if (pPacket && m_fp)
> {
>+ // Create indent level 2 string (if it
>+ // doesn't already exist)
>+ if (!m_pszIndent2)
>+ {
>+ m_pszIndent2 = CreateIndentString(2);
>+ }
> // Write out the packet container element open
> // (if we have not already)
> if (!m_bWrotePacketContainerOpen)
> {
> if (m_fp)
> {
>- fprintf(m_fp, " \n");
>+ char* pszIndent1 = CreateIndentString(1);
>+ if (pszIndent1)
>+ {
>+ fprintf(m_fp, "%s\n", pszIndent1);
>+ }
>+ HX_VECTOR_DELETE(pszIndent1);
> }
> m_bWrotePacketContainerOpen = TRUE;
> }
>+ if (m_pszIndent2)
>+ {
> // Get the packet parameters
> IHXBuffer* pBuffer = NULL;
> UINT32 ulTime = 0;
>@@ -331,14 +340,17 @@
> retVal = pPacket->Get(pBuffer, ulTime, usStreamNumber,
> ucASMFlags, usASMRuleNumber);
> if (SUCCEEDED(retVal))
> {
>+ UINT32 ulCRC32 = ComputeCRC32(pBuffer);
> // Print out the packet elemnt
> fprintf(m_fp,
>- " - "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
>bufferSize=\"%lu\"/>\n",
>- usStreamNumber, ulTime, ucASMFlags, usASMRuleNumber,
>pBuffer->GetSize());
>+ "%s+ "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
>bufferSize=\"%lu\" crc32=\"%lu\" />\n",
>+ m_pszIndent2, usStreamNumber, ulTime, ucASMFlags,
>usASMRuleNumber,
>+ pBuffer->GetSize(), ulCRC32);
> }
> HX_RELEASE(pBuffer);
> }
>+ }
>
> return retVal;
> }
>@@ -370,28 +382,23 @@
> return retVal;
> }
>
>-void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
>ulIndent)
>+void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
>ulIndentLevel)
> {
> if (pValues && fp)
> {
> // Build indent string
>- char* pszIndent = new char [ulIndent + 1];
>+ char* pszIndent = CreateIndentString(ulIndentLevel);
> if (pszIndent)
> {
>- // Fill in spaces
>- if (ulIndent)
>- {
>- memset((void*) pszIndent, ' ', ulIndent);
>- }
>- // Fill in NULL terminator
>- pszIndent[ulIndent] = '\0';
>+ // Write out the open element
>+ fprintf(fp, "%s\n", pszIndent);
> // Print out ULONG32 properties
> const char* pszName = NULL;
> UINT32 ulValue = 0;
> HX_RESULT rv =
> pValues->GetFirstPropertyULONG32(pszName, ulValue);
> while (SUCCEEDED(rv))
> {
>- fprintf(fp, "%svalue=\"%lu\"/>\n",
>+ fprintf(fp, "%s value=\"%lu\"/>\n",
> pszIndent, pszName, ulValue);
> rv = pValues->GetNextPropertyULONG32(pszName, ulValue);
> }
>@@ -400,7 +407,7 @@
> rv = pValues->GetFirstPropertyCString(pszName, pValue);
> while (SUCCEEDED(rv))
> {
>- fprintf(fp, "%svalue=\"", pszIndent, pszName);
>+ fprintf(fp, "%s value=\"", pszIndent, pszName);
> WriteOutCStringValue((const char*) pValue->GetBuffer(), fp);
> fprintf(fp, "\"/>\n");
> HX_RELEASE(pValue);
>@@ -417,7 +424,7 @@
> {
> memset((void*) pTmp, 0, ulSize);
> INT32 lLen = BinTo64(pValue->GetBuffer(),
> pValue->GetSize(), pTmp);
>- fprintf(fp, "%svalue=\"%s\"/>\n",
>+ fprintf(fp, "%s value=\"%s\"/>\n",
> pszIndent, pszName, (const char*) pTmp);
> }
> HX_VECTOR_DELETE(pTmp);
>@@ -425,6 +432,8 @@
> HX_RELEASE(pValue);
> rv = pValues->GetNextPropertyBuffer(pszName, pValue);
> }
>+ // Write out the close element
>+ fprintf(fp, "%s\n", pszIndent);
> }
> HX_VECTOR_DELETE(pszIndent);
> }
>@@ -505,5 +514,35 @@
> }
>
> return retVal;
>+}
>+
>+char* CXMLFileWriter::CreateIndentString(UINT32 ulIndentLevel)
>+{
>+ char* pRet = NULL;
>+
>+ UINT32 ulLen = ulIndentLevel * XMLWRITER_INDENT_SIZE;
>+ pRet = new char [ulLen + 1];
>+ if (pRet)
>+ {
>+ memset(pRet, ' ', ulLen);
>+ pRet[ulLen] = '\0';
>+ }
>+
>+ return pRet;
>+}
>+
>+UINT32 CXMLFileWriter::ComputeCRC32(IHXBuffer* pBuffer)
>+{
>+ UINT32 ulRet = 0;
>+
>+ if (pBuffer)
>+ {
>+ // Pre-condition the CRC32
>+ ulRet = crc32(0, NULL, 0);
>+ // Compute the CRC on the buffer
>+ ulRet = crc32(ulRet, pBuffer->GetBuffer(), pBuffer->GetSize());
>+ }
>+
>+ return ulRet;
> }
>
>cvs server: Diffing pub
>Index: pub/xmlwriter.h
>===================================================================
>RCS file: /cvsroot/datatype/tools/xmlwriter/pub/xmlwriter.h,v
>retrieving revision 1.1
>diff -u -w -u -w -r1.1 xmlwriter.h
>--- pub/xmlwriter.h 21 Jun 2004 16:26:04 -0000 1.1
>+++ pub/xmlwriter.h 2 Dec 2004 19:45:12 -0000
>@@ -88,6 +88,7 @@
> UINT32 m_ulStreamCount;
> UINT32 m_ulNumStreams;
> BOOL m_bWrotePacketContainerOpen;
>+ char* m_pszIndent2;
>
> static const char* const m_pszDescription;
> static const char* const m_pszCopyright;
>@@ -99,6 +100,8 @@
>
> void WriteOutValues(IHXValues* pValues, FILE* fp, UINT32 ulIndent);
> HX_RESULT WriteOutCStringValue(const char* pszValue, FILE* fp);
>+ char* CreateIndentString(UINT32 ulIndentLevel);
>+ UINT32 ComputeCRC32(IHXBuffer* pBuffer);
> };
>
> #endif /* #ifndef XMLWRITER_H */
>
>Index: helix.bif
>===================================================================
>RCS file: /cvsroot/common/build/BIF/helix.bif,v
>retrieving revision 1.492
>diff -u -w -u -w -r1.492 helix.bif
>--- helix.bif 17 Nov 2004 19:50:30 -0000 1.492
>+++ helix.bif 2 Dec 2004 19:50:42 -0000
>@@ -1879,6 +1879,7 @@
> common_runtime
> common_system
> common_util
>+ common_import_zlib
>
>
>
>
>
>
>
>
>
>======================================
>M. Eric Hyche (ehyche@real.com)
>Core Technologies
>RealNetworks, Inc.
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From gwright at real.com Mon Dec 6 09:43:01 2004
From: gwright at real.com (Greg Wright)
Date: Mon Dec 6 09:44:52 2004
Subject: [datatype-dev] CR-Client-RESEND: Updates to xml writer
In-Reply-To: <5.1.0.14.2.20041206112010.00c0f4c8@mailone.real.com>
References: <5.1.0.14.2.20041206112010.00c0f4c8@mailone.real.com>
Message-ID: <41B49A25.6020706@real.com>
Looks good.
--greg.
Eric Hyche wrote:
>
>
>
> Synopsis: minor updates to XML writer
>
> Overview: 1. Don't output DTD at the start of the .xml file -
> we will come up with Schema instead of DTD.
> 2. Change from using single tag to
> using , , and
> .
> 3. Compute CRC32 over the packet buffer and add
> "crc32" attribute to element.
> 4. Add compile-time-configurable indents
> 5. Link in zlib library
> 6. Add zlib to xmlwriter dependencies in BIF
>
> Files Modified:
> datatype/tools/xmlwriter/Umakefil
> datatype/tools/xmlwriter/xmlwriter.cpp
> datatype/tools/xmlwriter/pub/xmlwriter.h
> common/build/BIF/helix.bif
>
> Image Size and Heap Use impact: none
>
> Platforms and Profiles Affected: all
>
> Distribution Libraries affected: none
>
> Distribution library impact and planned action: n/a
>
> Platforms and Profiles Build Verified: win32
>
> Platforms and Profiles Functionality verified: win32
>
> Branch: HEAD only
>
> QA Instructions: none
>
> Index: Umakefil
> ===================================================================
> RCS file: /cvsroot/datatype/tools/xmlwriter/Umakefil,v
> retrieving revision 1.1
> diff -u -w -u -w -r1.1 Umakefil
> --- Umakefil 21 Jun 2004 16:26:04 -0000 1.1
> +++ Umakefil 2 Dec 2004 19:45:12 -0000
> @@ -42,7 +42,8 @@
> "common/dbgtool[debuglib]",
> "common/runtime[runtlib]",
> "common/system[syslib]",
> - "common/util[utillib]")
> + "common/util[utillib]",
> + "common/import/zlib[zlib]")
>
> project.AddSources("xmlwriter.cpp",
> "xmlwriterdll.cpp",
> Index: xmlwriter.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/tools/xmlwriter/xmlwriter.cpp,v
> retrieving revision 1.1
> diff -u -w -u -w -r1.1 xmlwriter.cpp
> --- xmlwriter.cpp 21 Jun 2004 16:26:04 -0000 1.1
> +++ xmlwriter.cpp 2 Dec 2004 19:45:12 -0000
> @@ -41,6 +41,7 @@
> #include "baseobj.h"
> #include "hxver.h"
> #include "hxfwrtr.h"
> +#include "zlib.h"
> #include "xmlwriter.h"
> #include "xmlwriter.ver"
>
> @@ -50,28 +51,9 @@
> const char* const CXMLFileWriter::m_ppszFileMimeTypes[] =
> {"application/xml", NULL};
> const char* const CXMLFileWriter::m_ppszFileExtensions[] = {"xml", NULL};
> const char* const CXMLFileWriter::m_ppszFileOpenNames[] = {"XML Output
> Files (*.xml)", NULL};
> -const char* const CXMLFileWriter::m_pszHeaderStr =
> - "\n"
> - " - " \n"
> - " \n"
> - " \n"
> - " \n"
> - " \n"
> - " \n"
> - " \n"
> - " \n"
> - " - " type (ULONG32 | CString | Buffer) #REQUIRED\n"
> - " name CDATA #REQUIRED\n"
> - " value CDATA #REQUIRED>\n"
> - " - " streamNum CDATA #REQUIRED\n"
> - " timestamp CDATA #REQUIRED\n"
> - " asmFlags CDATA #REQUIRED\n"
> - " asmRuleNum CDATA #REQUIRED\n"
> - " bufferSize CDATA #REQUIRED>\n"
> - "]>\n";
> +const char* const CXMLFileWriter::m_pszHeaderStr = " version=\"1.0\"?>\n";
> +
> +#define XMLWRITER_INDENT_SIZE 4
>
> CXMLFileWriter::CXMLFileWriter()
> {
> @@ -82,6 +64,7 @@
> m_ulStreamCount = 0;
> m_ulNumStreams = 0;
> m_bWrotePacketContainerOpen = FALSE;
> + m_pszIndent2 = NULL;
> }
>
>
> @@ -233,6 +216,7 @@
> }
> HX_RELEASE(m_pContext);
> HX_RELEASE(m_pMonitor);
> + HX_VECTOR_DELETE(m_pszIndent2);
>
> return retVal;
> }
> @@ -248,21 +232,26 @@
>
> if (pHeader && m_fp)
> {
> + // Get an indent string for indent level 1
> + char* pszIndent = CreateIndentString(1);
> + if (pszIndent)
> + {
> // Print out file header element
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent);
> // Write out the file header properties
> - fprintf(m_fp, " \n");
> - WriteOutValues(pHeader, m_fp, 12);
> - fprintf(m_fp, " \n");
> + WriteOutValues(pHeader, m_fp, 2);
> // Print out the file header end element
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent);
> // Print out the stream header container element begin
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent);
> // Clear the stream header count
> m_ulNumStreams = 0;
> // Get the stream count
> retVal = pHeader->GetPropertyULONG32("StreamCount",
> m_ulStreamCount);
> }
> + // Free the indent string
> + HX_VECTOR_DELETE(pszIndent);
> + }
>
> return retVal;
> }
> @@ -273,14 +262,17 @@
>
> if (pHeader && m_fp)
> {
> + // Create an indent string for indent levels 1 and 2
> + char* pszIndent1 = CreateIndentString(1);
> + char* pszIndent2 = CreateIndentString(2);
> + if (pszIndent1 && pszIndent2)
> + {
> // Print out file header element
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent2);
> // Write out the file header properties
> - fprintf(m_fp, " \n");
> - WriteOutValues(pHeader, m_fp, 16);
> - fprintf(m_fp, " \n");
> + WriteOutValues(pHeader, m_fp, 3);
> // Print out the file header end element
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent2);
> // Increment the stream count
> m_ulNumStreams++;
> // If we have gotten all our stream headers, then
> @@ -288,7 +280,7 @@
> if (m_ulNumStreams >= m_ulStreamCount && m_pMonitor)
> {
> // Print out the stream header container element end
> - fprintf(m_fp, " \n");
> + fprintf(m_fp, "%s\n", pszIndent1);
> // Tell the monitor we're ready
> m_pMonitor->OnPacketsReady(HXR_OK);
> // Reset the stream count so we can count StreamDone()'s
> @@ -297,6 +289,10 @@
> // Clear the return value
> retVal = HXR_OK;
> }
> + // Free the indent strings
> + HX_VECTOR_DELETE(pszIndent1);
> + HX_VECTOR_DELETE(pszIndent2);
> + }
>
> return retVal;
> }
> @@ -312,16 +308,29 @@
>
> if (pPacket && m_fp)
> {
> + // Create indent level 2 string (if it
> + // doesn't already exist)
> + if (!m_pszIndent2)
> + {
> + m_pszIndent2 = CreateIndentString(2);
> + }
> // Write out the packet container element open
> // (if we have not already)
> if (!m_bWrotePacketContainerOpen)
> {
> if (m_fp)
> {
> - fprintf(m_fp, " \n");
> + char* pszIndent1 = CreateIndentString(1);
> + if (pszIndent1)
> + {
> + fprintf(m_fp, "%s\n", pszIndent1);
> + }
> + HX_VECTOR_DELETE(pszIndent1);
> }
> m_bWrotePacketContainerOpen = TRUE;
> }
> + if (m_pszIndent2)
> + {
> // Get the packet parameters
> IHXBuffer* pBuffer = NULL;
> UINT32 ulTime = 0;
> @@ -331,14 +340,17 @@
> retVal = pPacket->Get(pBuffer, ulTime, usStreamNumber,
> ucASMFlags, usASMRuleNumber);
> if (SUCCEEDED(retVal))
> {
> + UINT32 ulCRC32 = ComputeCRC32(pBuffer);
> // Print out the packet elemnt
> fprintf(m_fp,
> - " - "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
> bufferSize=\"%lu\"/>\n",
> - usStreamNumber, ulTime, ucASMFlags,
> usASMRuleNumber, pBuffer->GetSize());
> + "%s + "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
> bufferSize=\"%lu\" crc32=\"%lu\" />\n",
> + m_pszIndent2, usStreamNumber, ulTime,
> ucASMFlags, usASMRuleNumber,
> + pBuffer->GetSize(), ulCRC32);
> }
> HX_RELEASE(pBuffer);
> }
> + }
>
> return retVal;
> }
> @@ -370,28 +382,23 @@
> return retVal;
> }
>
> -void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp,
> UINT32 ulIndent)
> +void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp,
> UINT32 ulIndentLevel)
> {
> if (pValues && fp)
> {
> // Build indent string
> - char* pszIndent = new char [ulIndent + 1];
> + char* pszIndent = CreateIndentString(ulIndentLevel);
> if (pszIndent)
> {
> - // Fill in spaces
> - if (ulIndent)
> - {
> - memset((void*) pszIndent, ' ', ulIndent);
> - }
> - // Fill in NULL terminator
> - pszIndent[ulIndent] = '\0';
> + // Write out the open element
> + fprintf(fp, "%s\n", pszIndent);
> // Print out ULONG32 properties
> const char* pszName = NULL;
> UINT32 ulValue = 0;
> HX_RESULT rv =
> pValues->GetFirstPropertyULONG32(pszName, ulValue);
> while (SUCCEEDED(rv))
> {
> - fprintf(fp, "%s value=\"%lu\"/>\n",
> + fprintf(fp, "%s value=\"%lu\"/>\n",
> pszIndent, pszName, ulValue);
> rv = pValues->GetNextPropertyULONG32(pszName, ulValue);
> }
> @@ -400,7 +407,7 @@
> rv = pValues->GetFirstPropertyCString(pszName, pValue);
> while (SUCCEEDED(rv))
> {
> - fprintf(fp, "%s value=\"", pszIndent, pszName);
> + fprintf(fp, "%s value=\"", pszIndent, pszName);
> WriteOutCStringValue((const char*) pValue->GetBuffer(),
> fp);
> fprintf(fp, "\"/>\n");
> HX_RELEASE(pValue);
> @@ -417,7 +424,7 @@
> {
> memset((void*) pTmp, 0, ulSize);
> INT32 lLen = BinTo64(pValue->GetBuffer(),
> pValue->GetSize(), pTmp);
> - fprintf(fp, "%s name=\"%s\" value=\"%s\"/>\n",
> + fprintf(fp, "%s value=\"%s\"/>\n",
> pszIndent, pszName, (const char*) pTmp);
> }
> HX_VECTOR_DELETE(pTmp);
> @@ -425,6 +432,8 @@
> HX_RELEASE(pValue);
> rv = pValues->GetNextPropertyBuffer(pszName, pValue);
> }
> + // Write out the close element
> + fprintf(fp, "%s\n", pszIndent);
> }
> HX_VECTOR_DELETE(pszIndent);
> }
> @@ -505,5 +514,35 @@
> }
>
> return retVal;
> +}
> +
> +char* CXMLFileWriter::CreateIndentString(UINT32 ulIndentLevel)
> +{
> + char* pRet = NULL;
> +
> + UINT32 ulLen = ulIndentLevel * XMLWRITER_INDENT_SIZE;
> + pRet = new char [ulLen + 1];
> + if (pRet)
> + {
> + memset(pRet, ' ', ulLen);
> + pRet[ulLen] = '\0';
> + }
> +
> + return pRet;
> +}
> +
> +UINT32 CXMLFileWriter::ComputeCRC32(IHXBuffer* pBuffer)
> +{
> + UINT32 ulRet = 0;
> +
> + if (pBuffer)
> + {
> + // Pre-condition the CRC32
> + ulRet = crc32(0, NULL, 0);
> + // Compute the CRC on the buffer
> + ulRet = crc32(ulRet, pBuffer->GetBuffer(), pBuffer->GetSize());
> + }
> +
> + return ulRet;
> }
>
> cvs server: Diffing pub
> Index: pub/xmlwriter.h
> ===================================================================
> RCS file: /cvsroot/datatype/tools/xmlwriter/pub/xmlwriter.h,v
> retrieving revision 1.1
> diff -u -w -u -w -r1.1 xmlwriter.h
> --- pub/xmlwriter.h 21 Jun 2004 16:26:04 -0000 1.1
> +++ pub/xmlwriter.h 2 Dec 2004 19:45:12 -0000
> @@ -88,6 +88,7 @@
> UINT32 m_ulStreamCount;
> UINT32 m_ulNumStreams;
> BOOL m_bWrotePacketContainerOpen;
> + char* m_pszIndent2;
>
> static const char* const m_pszDescription;
> static const char* const m_pszCopyright;
> @@ -99,6 +100,8 @@
>
> void WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
> ulIndent);
> HX_RESULT WriteOutCStringValue(const char* pszValue, FILE* fp);
> + char* CreateIndentString(UINT32 ulIndentLevel);
> + UINT32 ComputeCRC32(IHXBuffer* pBuffer);
> };
>
> #endif /* #ifndef XMLWRITER_H */
>
> Index: helix.bif
> ===================================================================
> RCS file: /cvsroot/common/build/BIF/helix.bif,v
> retrieving revision 1.492
> diff -u -w -u -w -r1.492 helix.bif
> --- helix.bif 17 Nov 2004 19:50:30 -0000 1.492
> +++ helix.bif 2 Dec 2004 19:50:42 -0000
> @@ -1879,6 +1879,7 @@
> common_runtime
> common_system
> common_util
> + common_import_zlib
>
>
>
>
>
>
>
>
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From ehyche at real.com Mon Dec 6 09:58:41 2004
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 6 09:58:47 2004
Subject: [datatype-dev] CN-Client: Updates to xml writer
In-Reply-To: <5.1.0.14.2.20041206093433.01f08040@mailone.real.com>
References: <5.1.0.14.2.20041206112010.00c0f4c8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041206125822.00c399c8@mailone.real.com>
This is now checked in to HEAD.
At 09:34 AM 12/6/2004 -0800, Erik Hodge wrote:
>Looks good.
>
>At 11:20 AM 12/6/2004 -0500, Eric Hyche wrote:
>
>
>
>>Synopsis: minor updates to XML writer
>>
>>Overview: 1. Don't output DTD at the start of the .xml file -
>> we will come up with Schema instead of DTD.
>> 2. Change from using single tag to
>> using , , and
>> .
>> 3. Compute CRC32 over the packet buffer and add
>> "crc32" attribute to element.
>> 4. Add compile-time-configurable indents
>> 5. Link in zlib library
>> 6. Add zlib to xmlwriter dependencies in BIF
>>
>>Files Modified:
>>datatype/tools/xmlwriter/Umakefil
>>datatype/tools/xmlwriter/xmlwriter.cpp
>>datatype/tools/xmlwriter/pub/xmlwriter.h
>>common/build/BIF/helix.bif
>>
>>Image Size and Heap Use impact: none
>>
>>Platforms and Profiles Affected: all
>>
>>Distribution Libraries affected: none
>>
>>Distribution library impact and planned action: n/a
>>
>>Platforms and Profiles Build Verified: win32
>>
>>Platforms and Profiles Functionality verified: win32
>>
>>Branch: HEAD only
>>
>>QA Instructions: none
>>
>>Index: Umakefil
>>===================================================================
>>RCS file: /cvsroot/datatype/tools/xmlwriter/Umakefil,v
>>retrieving revision 1.1
>>diff -u -w -u -w -r1.1 Umakefil
>>--- Umakefil 21 Jun 2004 16:26:04 -0000 1.1
>>+++ Umakefil 2 Dec 2004 19:45:12 -0000
>>@@ -42,7 +42,8 @@
>> "common/dbgtool[debuglib]",
>> "common/runtime[runtlib]",
>> "common/system[syslib]",
>>- "common/util[utillib]")
>>+ "common/util[utillib]",
>>+ "common/import/zlib[zlib]")
>>
>> project.AddSources("xmlwriter.cpp",
>> "xmlwriterdll.cpp",
>>Index: xmlwriter.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/tools/xmlwriter/xmlwriter.cpp,v
>>retrieving revision 1.1
>>diff -u -w -u -w -r1.1 xmlwriter.cpp
>>--- xmlwriter.cpp 21 Jun 2004 16:26:04 -0000 1.1
>>+++ xmlwriter.cpp 2 Dec 2004 19:45:12 -0000
>>@@ -41,6 +41,7 @@
>> #include "baseobj.h"
>> #include "hxver.h"
>> #include "hxfwrtr.h"
>>+#include "zlib.h"
>> #include "xmlwriter.h"
>> #include "xmlwriter.ver"
>>
>>@@ -50,28 +51,9 @@
>> const char* const CXMLFileWriter::m_ppszFileMimeTypes[] =
>> {"application/xml", NULL};
>> const char* const CXMLFileWriter::m_ppszFileExtensions[] = {"xml", NULL};
>> const char* const CXMLFileWriter::m_ppszFileOpenNames[] = {"XML Output
>> Files (*.xml)", NULL};
>>-const char* const CXMLFileWriter::m_pszHeaderStr =
>>- "\n"
>>- ">- " \n"
>>- " \n"
>>- " \n"
>>- " \n"
>>- " \n"
>>- " \n"
>>- " \n"
>>- " \n"
>>- " >- " type (ULONG32 | CString | Buffer) #REQUIRED\n"
>>- " name CDATA #REQUIRED\n"
>>- " value CDATA #REQUIRED>\n"
>>- " >- " streamNum CDATA #REQUIRED\n"
>>- " timestamp CDATA #REQUIRED\n"
>>- " asmFlags CDATA #REQUIRED\n"
>>- " asmRuleNum CDATA #REQUIRED\n"
>>- " bufferSize CDATA #REQUIRED>\n"
>>- "]>\n";
>>+const char* const CXMLFileWriter::m_pszHeaderStr = ">version=\"1.0\"?>\n";
>>+
>>+#define XMLWRITER_INDENT_SIZE 4
>>
>> CXMLFileWriter::CXMLFileWriter()
>> {
>>@@ -82,6 +64,7 @@
>> m_ulStreamCount = 0;
>> m_ulNumStreams = 0;
>> m_bWrotePacketContainerOpen = FALSE;
>>+ m_pszIndent2 = NULL;
>> }
>>
>>
>>@@ -233,6 +216,7 @@
>> }
>> HX_RELEASE(m_pContext);
>> HX_RELEASE(m_pMonitor);
>>+ HX_VECTOR_DELETE(m_pszIndent2);
>>
>> return retVal;
>> }
>>@@ -248,21 +232,26 @@
>>
>> if (pHeader && m_fp)
>> {
>>+ // Get an indent string for indent level 1
>>+ char* pszIndent = CreateIndentString(1);
>>+ if (pszIndent)
>>+ {
>> // Print out file header element
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent);
>> // Write out the file header properties
>>- fprintf(m_fp, " \n");
>>- WriteOutValues(pHeader, m_fp, 12);
>>- fprintf(m_fp, " \n");
>>+ WriteOutValues(pHeader, m_fp, 2);
>> // Print out the file header end element
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent);
>> // Print out the stream header container element begin
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent);
>> // Clear the stream header count
>> m_ulNumStreams = 0;
>> // Get the stream count
>> retVal = pHeader->GetPropertyULONG32("StreamCount",
>> m_ulStreamCount);
>> }
>>+ // Free the indent string
>>+ HX_VECTOR_DELETE(pszIndent);
>>+ }
>>
>> return retVal;
>> }
>>@@ -273,14 +262,17 @@
>>
>> if (pHeader && m_fp)
>> {
>>+ // Create an indent string for indent levels 1 and 2
>>+ char* pszIndent1 = CreateIndentString(1);
>>+ char* pszIndent2 = CreateIndentString(2);
>>+ if (pszIndent1 && pszIndent2)
>>+ {
>> // Print out file header element
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent2);
>> // Write out the file header properties
>>- fprintf(m_fp, " \n");
>>- WriteOutValues(pHeader, m_fp, 16);
>>- fprintf(m_fp, " \n");
>>+ WriteOutValues(pHeader, m_fp, 3);
>> // Print out the file header end element
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent2);
>> // Increment the stream count
>> m_ulNumStreams++;
>> // If we have gotten all our stream headers, then
>>@@ -288,7 +280,7 @@
>> if (m_ulNumStreams >= m_ulStreamCount && m_pMonitor)
>> {
>> // Print out the stream header container element end
>>- fprintf(m_fp, " \n");
>>+ fprintf(m_fp, "%s\n", pszIndent1);
>> // Tell the monitor we're ready
>> m_pMonitor->OnPacketsReady(HXR_OK);
>> // Reset the stream count so we can count StreamDone()'s
>>@@ -297,6 +289,10 @@
>> // Clear the return value
>> retVal = HXR_OK;
>> }
>>+ // Free the indent strings
>>+ HX_VECTOR_DELETE(pszIndent1);
>>+ HX_VECTOR_DELETE(pszIndent2);
>>+ }
>>
>> return retVal;
>> }
>>@@ -312,16 +308,29 @@
>>
>> if (pPacket && m_fp)
>> {
>>+ // Create indent level 2 string (if it
>>+ // doesn't already exist)
>>+ if (!m_pszIndent2)
>>+ {
>>+ m_pszIndent2 = CreateIndentString(2);
>>+ }
>> // Write out the packet container element open
>> // (if we have not already)
>> if (!m_bWrotePacketContainerOpen)
>> {
>> if (m_fp)
>> {
>>- fprintf(m_fp, " \n");
>>+ char* pszIndent1 = CreateIndentString(1);
>>+ if (pszIndent1)
>>+ {
>>+ fprintf(m_fp, "%s\n", pszIndent1);
>>+ }
>>+ HX_VECTOR_DELETE(pszIndent1);
>> }
>> m_bWrotePacketContainerOpen = TRUE;
>> }
>>+ if (m_pszIndent2)
>>+ {
>> // Get the packet parameters
>> IHXBuffer* pBuffer = NULL;
>> UINT32 ulTime = 0;
>>@@ -331,14 +340,17 @@
>> retVal = pPacket->Get(pBuffer, ulTime, usStreamNumber,
>> ucASMFlags, usASMRuleNumber);
>> if (SUCCEEDED(retVal))
>> {
>>+ UINT32 ulCRC32 = ComputeCRC32(pBuffer);
>> // Print out the packet elemnt
>> fprintf(m_fp,
>>- " >- "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
>>bufferSize=\"%lu\"/>\n",
>>- usStreamNumber, ulTime, ucASMFlags, usASMRuleNumber,
>>pBuffer->GetSize());
>>+ "%s>+ "asmFlags=\"0x%02x\" asmRuleNum=\"%u\"
>>bufferSize=\"%lu\" crc32=\"%lu\" />\n",
>>+ m_pszIndent2, usStreamNumber, ulTime,
>>ucASMFlags, usASMRuleNumber,
>>+ pBuffer->GetSize(), ulCRC32);
>> }
>> HX_RELEASE(pBuffer);
>> }
>>+ }
>>
>> return retVal;
>> }
>>@@ -370,28 +382,23 @@
>> return retVal;
>> }
>>
>>-void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
>>ulIndent)
>>+void CXMLFileWriter::WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
>>ulIndentLevel)
>> {
>> if (pValues && fp)
>> {
>> // Build indent string
>>- char* pszIndent = new char [ulIndent + 1];
>>+ char* pszIndent = CreateIndentString(ulIndentLevel);
>> if (pszIndent)
>> {
>>- // Fill in spaces
>>- if (ulIndent)
>>- {
>>- memset((void*) pszIndent, ' ', ulIndent);
>>- }
>>- // Fill in NULL terminator
>>- pszIndent[ulIndent] = '\0';
>>+ // Write out the open element
>>+ fprintf(fp, "%s\n", pszIndent);
>> // Print out ULONG32 properties
>> const char* pszName = NULL;
>> UINT32 ulValue = 0;
>> HX_RESULT rv =
>> pValues->GetFirstPropertyULONG32(pszName, ulValue);
>> while (SUCCEEDED(rv))
>> {
>>- fprintf(fp, "%s>value=\"%lu\"/>\n",
>>+ fprintf(fp, "%s >value=\"%lu\"/>\n",
>> pszIndent, pszName, ulValue);
>> rv = pValues->GetNextPropertyULONG32(pszName, ulValue);
>> }
>>@@ -400,7 +407,7 @@
>> rv = pValues->GetFirstPropertyCString(pszName, pValue);
>> while (SUCCEEDED(rv))
>> {
>>- fprintf(fp, "%s>value=\"", pszIndent, pszName);
>>+ fprintf(fp, "%s >value=\"", pszIndent, pszName);
>> WriteOutCStringValue((const char*) pValue->GetBuffer(),
>> fp);
>> fprintf(fp, "\"/>\n");
>> HX_RELEASE(pValue);
>>@@ -417,7 +424,7 @@
>> {
>> memset((void*) pTmp, 0, ulSize);
>> INT32 lLen = BinTo64(pValue->GetBuffer(),
>> pValue->GetSize(), pTmp);
>>- fprintf(fp, "%s>type=\"Buffer\" name=\"%s\" value=\"%s\"/>\n",
>>+ fprintf(fp, "%s >value=\"%s\"/>\n",
>> pszIndent, pszName, (const char*) pTmp);
>> }
>> HX_VECTOR_DELETE(pTmp);
>>@@ -425,6 +432,8 @@
>> HX_RELEASE(pValue);
>> rv = pValues->GetNextPropertyBuffer(pszName, pValue);
>> }
>>+ // Write out the close element
>>+ fprintf(fp, "%s\n", pszIndent);
>> }
>> HX_VECTOR_DELETE(pszIndent);
>> }
>>@@ -505,5 +514,35 @@
>> }
>>
>> return retVal;
>>+}
>>+
>>+char* CXMLFileWriter::CreateIndentString(UINT32 ulIndentLevel)
>>+{
>>+ char* pRet = NULL;
>>+
>>+ UINT32 ulLen = ulIndentLevel * XMLWRITER_INDENT_SIZE;
>>+ pRet = new char [ulLen + 1];
>>+ if (pRet)
>>+ {
>>+ memset(pRet, ' ', ulLen);
>>+ pRet[ulLen] = '\0';
>>+ }
>>+
>>+ return pRet;
>>+}
>>+
>>+UINT32 CXMLFileWriter::ComputeCRC32(IHXBuffer* pBuffer)
>>+{
>>+ UINT32 ulRet = 0;
>>+
>>+ if (pBuffer)
>>+ {
>>+ // Pre-condition the CRC32
>>+ ulRet = crc32(0, NULL, 0);
>>+ // Compute the CRC on the buffer
>>+ ulRet = crc32(ulRet, pBuffer->GetBuffer(), pBuffer->GetSize());
>>+ }
>>+
>>+ return ulRet;
>> }
>>
>>cvs server: Diffing pub
>>Index: pub/xmlwriter.h
>>===================================================================
>>RCS file: /cvsroot/datatype/tools/xmlwriter/pub/xmlwriter.h,v
>>retrieving revision 1.1
>>diff -u -w -u -w -r1.1 xmlwriter.h
>>--- pub/xmlwriter.h 21 Jun 2004 16:26:04 -0000 1.1
>>+++ pub/xmlwriter.h 2 Dec 2004 19:45:12 -0000
>>@@ -88,6 +88,7 @@
>> UINT32 m_ulStreamCount;
>> UINT32 m_ulNumStreams;
>> BOOL m_bWrotePacketContainerOpen;
>>+ char* m_pszIndent2;
>>
>> static const char* const m_pszDescription;
>> static const char* const m_pszCopyright;
>>@@ -99,6 +100,8 @@
>>
>> void WriteOutValues(IHXValues* pValues, FILE* fp, UINT32
>> ulIndent);
>> HX_RESULT WriteOutCStringValue(const char* pszValue, FILE* fp);
>>+ char* CreateIndentString(UINT32 ulIndentLevel);
>>+ UINT32 ComputeCRC32(IHXBuffer* pBuffer);
>> };
>>
>> #endif /* #ifndef XMLWRITER_H */
>>
>>Index: helix.bif
>>===================================================================
>>RCS file: /cvsroot/common/build/BIF/helix.bif,v
>>retrieving revision 1.492
>>diff -u -w -u -w -r1.492 helix.bif
>>--- helix.bif 17 Nov 2004 19:50:30 -0000 1.492
>>+++ helix.bif 2 Dec 2004 19:50:42 -0000
>>@@ -1879,6 +1879,7 @@
>> common_runtime
>> common_system
>> common_util
>>+ common_import_zlib
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>======================================
>>M. Eric Hyche (ehyche@real.com)
>>Core Technologies
>>RealNetworks, Inc.
>>
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From gstacey at atico.com Mon Dec 6 10:38:47 2004
From: gstacey at atico.com (Greg Stacey)
Date: Mon Dec 6 10:40:57 2004
Subject: [datatype-dev] cvs trouble
Message-ID:
I am trying to do a cvs diff in the datatype directory and I keep getting
the following error:
cvs server: Diffing aac/codec/codingtechnologiesSDK
cvs server: failed to create lock directory for
`/cvsroot/datatype/aac/codec/codingtechnologiesSDK'
(/cvsroot/datatype/aac/codec/codingtechnologiesSDK/#cvs.lock): No such file
or directory
cvs server: failed to obtain dir lock in repository
`/cvsroot/datatype/aac/codec/codingtechnologiesSDK'
cvs [server aborted]: read lock failed - giving up
This results in getting only a partial diff, as it seems to skip a whole
bunch of other directories also.
I am using the bingo-gold branch.
Thanks,
Greg Stacey
Principal Consultant
Advanced Technologies Integration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041206/d8d80bc5/attachment.htm
From hfrederickson at real.com Mon Dec 6 14:16:29 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Mon Dec 6 14:12:29 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer
In-Reply-To: <5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
References: <5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
Message-ID: <1102371389.1200.1067.camel@localhost.localdomain>
Thanks for the CR Eric...
On Mon, 2004-12-06 at 08:49, Eric Hyche wrote:
> Some comments:
>
> 1) In rvdepack.cpp:
> const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30";
>
> Why are we only supporting RV8 and 9 with this? Should the depacketization
> format also apply to G2 as well?
Yes, G2 is supported also. This const string is a holdover from renderer
code... it's basically just a comment because it's not used anywhere.
But I went ahead and added "rv20" to it anyway... as long as it's going
to be a comment, it might as well be correct ;)
>
> 2) In rvdepack.cpp:
>
> retVal = pPacket->Set(pBuffer, 0, 0, 0, 0);
>
> Why are we not preserving the frame timestamps? It would be very
> useful to see the unpacked frame times using dtdrive...
I agree, that is useful. I added the unpacked timestamp as the second
arg here. Updated file attached.
If nobody else has any comments, I'll check this in tomorrow morning.
Thanks,
-Hans
> Rest looks good.
>
> Eric
>
> At 07:26 PM 12/3/2004 -0800, Hans Frederickson wrote:
> >Synopsis: A new source handler and plugin have been created to allow
> >depacketization of RealVideo streams.
> >
> >Overview:
> >The main goal of these new components is to provide a tool to create raw
> >files that contain a sequence of encoded RealVideo frames. When coupled
> >with the raw filewriter (binwrtr), the RV depacketizer source handler
> >and plugin do just that. Here's an example of command line usage:
> >
> >dtdrive.exe +DV 3 -W foo.raw foo.rm
> >
> >The new raw file format has a header at the top of the file, followed by
> >the sequence of frames. It looks like this:
> >
> >[HEADER]
> >HX_MOF bitstream_header (header size is first member of struct)
> >
> >[FRAME]
> >UINT32 dataLength
> >UINT32 timestamp
> >UINT16 sequenceNum
> >UINT16 flags
> >UINT32 lastPacket
> >UINT32 numSegments
> >HXCODEC_SEGMENT_INFO Segments[numSegments]
> >UINT8 data[dataLength]
> >
> >
> >With this new raw file format for RealVideo, the command line decoder
> >test applications will finally be able to exercise the decoder
> >algorithms with true RealVideo bitstreams, once they are modified to
> >parse the new format.
> >
> >The depacketizer plugin produces output packets in the above format
> >only, so it is not particularly useful for any purpose other than
> >feeding the raw filewriter.
> >
> >
> >Files Modified:
> >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> >/datatype/tools/dtdriver/decoder/video/Umakefil
> >
> >/common/include/hxplugn.h
> >/client/common/container/pub/basehand.h
> >/client/common/container/pub/hxplugin.h
> >
> >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> >
> >New Files:
> >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> >
> >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> >/datatype/tools/dtdriver/depacker/video/umakedll
> >/datatype/tools/dtdriver/depacker/video/Umakefil
> >/datatype/tools/dtdriver/depacker/video/umakelib
> >/datatype/tools/dtdriver/depacker/video/win32.pcf
> >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> >
> >Image Size and Heap Use impact:
> >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> >is defined. The rvdepacker plugin dll is about 60KB on windows.
> >
> >Platforms and Profiles Affected:
> >dtdr video profiles on all platforms. tested on windows and x86-linux.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.cpp
Type: text/x-c++
Size: 18625 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041206/49615401/rvdepack-0001.bin
From milko at real.com Mon Dec 6 15:56:28 2004
From: milko at real.com (milko)
Date: Mon Dec 6 15:56:35 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer
In-Reply-To: <1102371389.1200.1067.camel@localhost.localdomain>
References: <5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
<5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041206151403.03591e60@mailone.real.com>
At 02:16 PM 12/6/2004, Hans Frederickson wrote:
>Thanks for the CR Eric...
>
>On Mon, 2004-12-06 at 08:49, Eric Hyche wrote:
> > Some comments:
> >
> > 1) In rvdepack.cpp:
> > const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30";
> >
> > Why are we only supporting RV8 and 9 with this? Should the
> depacketization
> > format also apply to G2 as well?
>
>Yes, G2 is supported also. This const string is a holdover from renderer
>code... it's basically just a comment because it's not used anywhere.
>But I went ahead and added "rv20" to it anyway... as long as it's going
>to be a comment, it might as well be correct ;)
"rv10" should be in this list as well.
> >
> > 2) In rvdepack.cpp:
> >
> > retVal = pPacket->Set(pBuffer, 0, 0, 0, 0);
> >
> > Why are we not preserving the frame timestamps? It would be very
> > useful to see the unpacked frame times using dtdrive...
>
>I agree, that is useful. I added the unpacked timestamp as the second
>arg here. Updated file attached.
>
>If nobody else has any comments, I'll check this in tomorrow morning.
1.)
The stream that is produced by the depacketizer needs be treated and
formatted as fully quealified stream to be used within Helix architecture
rather than a stream that just needs to work with a particular file writer.
The unpacketized RV stream may as well find its uses beyond producing
reference test streams.
This means the following for the output produced by the RV depacker:
- Every packet should have HX_ASM_SWITCH_OFF flag set.
- Every packet that is a key-frame should have HX_ASM_SWITCH_IN flag set
- We should be consistent in mine type naming and not mix '-' and '_' .
- HX_MOF bitstream_header should be stored as OpaqueData in the stream
header instead of in-band with the first packet. File writer should have
the responsibility of writing this into the file appropriately.
- Stream Header should have custom mime type uniquely identifying this type
of stream (unpacketized RV):
video/x-pn-realvideo-raw
It should also include the basic ASM rule book and duration:
ASMRuleBook = "Marker=0;Marker=1;"
Duration =
It should not include any information from the older stream header that no
longer applies or is no longer accurate for the new stream.
E.g.: AvgPacketSize or MaxPacketSize.
Note: the stream header cannot simply be the altered source stream
header. The source stream header must be newly created not to interfere
with users of source header.
2.) CVideoSourceDepacketizer::MakeStreamHeader does nothing - should be
removed.
Milko
>Thanks,
>-Hans
>
> > Rest looks good.
> >
> > Eric
> >
> > At 07:26 PM 12/3/2004 -0800, Hans Frederickson wrote:
> > >Synopsis: A new source handler and plugin have been created to allow
> > >depacketization of RealVideo streams.
> > >
> > >Overview:
> > >The main goal of these new components is to provide a tool to create raw
> > >files that contain a sequence of encoded RealVideo frames. When coupled
> > >with the raw filewriter (binwrtr), the RV depacketizer source handler
> > >and plugin do just that. Here's an example of command line usage:
> > >
> > >dtdrive.exe +DV 3 -W foo.raw foo.rm
> > >
> > >The new raw file format has a header at the top of the file, followed by
> > >the sequence of frames. It looks like this:
> > >
> > >[HEADER]
> > >HX_MOF bitstream_header (header size is first member of struct)
> > >
> > >[FRAME]
> > >UINT32 dataLength
> > >UINT32 timestamp
> > >UINT16 sequenceNum
> > >UINT16 flags
> > >UINT32 lastPacket
> > >UINT32 numSegments
> > >HXCODEC_SEGMENT_INFO Segments[numSegments]
> > >UINT8 data[dataLength]
> > >
> > >
> > >With this new raw file format for RealVideo, the command line decoder
> > >test applications will finally be able to exercise the decoder
> > >algorithms with true RealVideo bitstreams, once they are modified to
> > >parse the new format.
> > >
> > >The depacketizer plugin produces output packets in the above format
> > >only, so it is not particularly useful for any purpose other than
> > >feeding the raw filewriter.
> > >
> > >
> > >Files Modified:
> > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> > >/datatype/tools/dtdriver/decoder/video/Umakefil
> > >
> > >/common/include/hxplugn.h
> > >/client/common/container/pub/basehand.h
> > >/client/common/container/pub/hxplugin.h
> > >
> > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> > >
> > >New Files:
> > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> > >
> > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> > >/datatype/tools/dtdriver/depacker/video/umakedll
> > >/datatype/tools/dtdriver/depacker/video/Umakefil
> > >/datatype/tools/dtdriver/depacker/video/umakelib
> > >/datatype/tools/dtdriver/depacker/video/win32.pcf
> > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> > >
> > >Image Size and Heap Use impact:
> > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> > >is defined. The rvdepacker plugin dll is about 60KB on windows.
> > >
> > >Platforms and Profiles Affected:
> > >dtdr video profiles on all platforms. tested on windows and x86-linux.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Datatype-dev mailing list
> > >Datatype-dev@helixcommunity.org
> > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> >
> > ======================================
> > M. Eric Hyche (ehyche@real.com)
> > Core Technologies
> > RealNetworks, Inc.
> >
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From ehyche at real.com Tue Dec 7 06:20:34 2004
From: ehyche at real.com (Eric Hyche)
Date: Tue Dec 7 06:20:42 2004
Subject: [datatype-dev] cvs trouble
In-Reply-To: <200412061840.iB6Ier6n009178@maytag01.real.com>
Message-ID: <5.1.0.14.2.20041207091942.00c16cc0@mailone.real.com>
At 12:38 PM 12/6/2004 -0600, Greg Stacey wrote:
>I am trying to do a cvs diff in the datatype directory and I keep getting
>the following error:
>
>
>
>cvs server: Diffing aac/codec/codingtechnologiesSDK
>
>cvs server: failed to create lock directory for
>`/cvsroot/datatype/aac/codec/codingtechnologiesSDK'
>(/cvsroot/datatype/aac/codec/codingtechnologiesSDK/#cvs.lock): No such
>file or directory
>
>cvs server: failed to obtain dir lock in repository
>`/cvsroot/datatype/aac/codec/codingtechnologiesSDK'
>
>cvs [server aborted]: read lock failed - giving up
I think that directory was empty and we deleted it from
the cvs repository. You should delete it from your locally
checked-out code tree.
Eric
>
>
>This results in getting only a partial diff, as it seems to skip a whole
>bunch of other directories also.
>
>
>
>I am using the bingo-gold branch.
>
>
>
>Thanks,
>
>
>
>Greg Stacey
>
>Principal Consultant
>
>Advanced Technologies Integration
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From Nat.Pham at nokia.com Tue Dec 7 11:20:39 2004
From: Nat.Pham at nokia.com (Nat.Pham@nokia.com)
Date: Tue Dec 7 11:21:29 2004
Subject: [datatype-dev] Cannot find datatype/common/dspcodec
Message-ID: <77DD81E268885348A1B5019CBBAA69FF0209DC73@daebe003.americas.nokia.com>
Hi,
The document DSP_integration.pdf states that:
"How to Use DSPDecoderBase
The source code for DSPDecoderBase is located in datatype/common/dspcodec ...."
I got some versions of Emulator and Thumb source code downloaded via CVS and some other versions coming from Helix website, like all_clients-helix-2004xxxx-source.zip. Unfortunately, none of them has the DSP source code datatype/common/dspcodec.
Could anyone show me where and how I can get it.
Thanks,
Nat.
From gwright at real.com Tue Dec 7 11:55:28 2004
From: gwright at real.com (Greg Wright)
Date: Tue Dec 7 11:57:14 2004
Subject: [datatype-dev] Cannot find datatype/common/dspcodec
In-Reply-To: <77DD81E268885348A1B5019CBBAA69FF0209DC73@daebe003.americas.nokia.com>
References: <77DD81E268885348A1B5019CBBAA69FF0209DC73@daebe003.americas.nokia.com>
Message-ID: <41B60AB0.6090103@real.com>
I answered this on your bulletin board post you made.
Let me know if you need any more help.
--greg.
Nat.Pham@nokia.com wrote:
> Hi,
>
> The document DSP_integration.pdf states that:
>
> "How to Use DSPDecoderBase
> The source code for DSPDecoderBase is located in datatype/common/dspcodec ...."
>
> I got some versions of Emulator and Thumb source code downloaded via CVS and some other versions coming from Helix website, like all_clients-helix-2004xxxx-source.zip. Unfortunately, none of them has the DSP source code datatype/common/dspcodec.
>
> Could anyone show me where and how I can get it.
>
> Thanks,
> Nat.
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From Nat.Pham at nokia.com Tue Dec 7 12:10:29 2004
From: Nat.Pham at nokia.com (Nat.Pham@nokia.com)
Date: Tue Dec 7 12:11:56 2004
Subject: [datatype-dev] Cannot find datatype/common/dspcodec
Message-ID: <77DD81E268885348A1B5019CBBAA69FF0194DEF5@daebe003.americas.nokia.com>
Great! Thanks a lot for your help and quick response.
Yes, I just checked it out; both of the commands from your instruction below worked perfectly.
Now I got the datatype/common/dspcodec :o)
BR,
Nat.
-----Original Message-----
From: ext [mailto:noreply@helixcommunity.org]
Sent: 07 December, 2004 01:33 PM
To: noreply@helixcommunity.org
Subject: [symbian - Symbian Player] RE: Cannot find
datatype/common/dspcodec
Read and respond to this message at:
http://helixcommunity.org/forum/message.php?msg_id=2850
By: gwright
You need to check it out by hand. Also, it is only on the HEAD and
hxclient_1_3_0_neptunex right now.
cvs -d :ext:gwright@cvs.helixcommunity.org:/cvsroot/datatype co -r
hxclient_1_3_0_neptunex common/dspcodec
or, for HEAD:
cvs -d :ext:gwright@cvs.helixcommunity.org:/cvsroot/datatype co common/dspcodec
______________________________________________________________________
Read and respond to this message at:
http://helixcommunity.org/forum/message.php?msg_id=2850
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to Helix Community and visit:
http://helixcommunity.org/forum/monitor.php?forum_id=25&group_id=84&stop=1
-----Original Message-----
From: ext Greg Wright [mailto:gwright@real.com]
Sent: 07 December, 2004 01:55 PM
To: Pham Nat (Nokia-TP-MSW/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Cannot find datatype/common/dspcodec
I answered this on your bulletin board post you made.
Let me know if you need any more help.
--greg.
Nat.Pham@nokia.com wrote:
> Hi,
>
> The document DSP_integration.pdf states that:
>
> "How to Use DSPDecoderBase
> The source code for DSPDecoderBase is located in datatype/common/dspcodec ...."
>
> I got some versions of Emulator and Thumb source code downloaded via CVS and some other versions coming from Helix website, like all_clients-helix-2004xxxx-source.zip. Unfortunately, none of them has the DSP source code datatype/common/dspcodec.
>
> Could anyone show me where and how I can get it.
>
> Thanks,
> Nat.
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From pallavi.shah at hp.com Tue Dec 7 15:10:03 2004
From: pallavi.shah at hp.com (Shah, Pallavi)
Date: Tue Dec 7 15:14:15 2004
Subject: [datatype-dev] Helix DRM and MPEG2
Message-ID: <85ECA15B7BB46944BFD4C73AEA554824014E4496@cacexc07.americas.cpqcorp.net>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 19418 bytes
Desc: HP.bmp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041207/afa5f669/attachment-0001.bin
From hfrederickson at real.com Tue Dec 7 17:01:36 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Tue Dec 7 16:57:39 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer
In-Reply-To: <5.1.0.14.2.20041206151403.03591e60@mailone.real.com>
References: <5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
<5.1.0.14.2.20041206114005.00c0f4c8@mailone.real.com>
<5.1.0.14.2.20041206151403.03591e60@mailone.real.com>
Message-ID: <1102467696.1200.1424.camel@localhost.localdomain>
Milko,
Thanks for the comments...
On Mon, 2004-12-06 at 15:56, milko wrote:
> At 02:16 PM 12/6/2004, Hans Frederickson wrote:
> >Thanks for the CR Eric...
> >
> >On Mon, 2004-12-06 at 08:49, Eric Hyche wrote:
> > > Some comments:
> > >
> > > 1) In rvdepack.cpp:
> > > const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30";
> > >
> > > Why are we only supporting RV8 and 9 with this? Should the
> > depacketization
> > > format also apply to G2 as well?
> >
> >Yes, G2 is supported also. This const string is a holdover from renderer
> >code... it's basically just a comment because it's not used anywhere.
> >But I went ahead and added "rv20" to it anyway... as long as it's going
> >to be a comment, it might as well be correct ;)
>
> "rv10" should be in this list as well.
Ok.
>
>
> > >
> > > 2) In rvdepack.cpp:
> > >
> > > retVal = pPacket->Set(pBuffer, 0, 0, 0, 0);
> > >
> > > Why are we not preserving the frame timestamps? It would be very
> > > useful to see the unpacked frame times using dtdrive...
> >
> >I agree, that is useful. I added the unpacked timestamp as the second
> >arg here. Updated file attached.
> >
> >If nobody else has any comments, I'll check this in tomorrow morning.
>
> 1.)
> The stream that is produced by the depacketizer needs be treated and
> formatted as fully quealified stream to be used within Helix architecture
> rather than a stream that just needs to work with a particular file writer.
> The unpacketized RV stream may as well find its uses beyond producing
> reference test streams.
>
> This means the following for the output produced by the RV depacker:
> - Every packet should have HX_ASM_SWITCH_OFF flag set.
> - Every packet that is a key-frame should have HX_ASM_SWITCH_IN flag set
> - We should be consistent in mine type naming and not mix '-' and '_' .
> - HX_MOF bitstream_header should be stored as OpaqueData in the stream
> header instead of in-band with the first packet. File writer should have
> the responsibility of writing this into the file appropriately.
> - Stream Header should have custom mime type uniquely identifying this type
> of stream (unpacketized RV):
> video/x-pn-realvideo-raw
>
> It should also include the basic ASM rule book and duration:
> ASMRuleBook = "Marker=0;Marker=1;"
> Duration =
>
> It should not include any information from the older stream header that no
> longer applies or is no longer accurate for the new stream.
> E.g.: AvgPacketSize or MaxPacketSize.
>
> Note: the stream header cannot simply be the altered source stream
> header. The source stream header must be newly created not to interfere
> with users of source header.
I agree with you about the above changes. They will take some time to
implement however. I'll start working on it and provide a new CR when
complete.
> 2.) CVideoSourceDepacketizer::MakeStreamHeader does nothing - should be
> removed.
Ok.
Thanks,
-Hans
>
> Milko
>
> >Thanks,
> >-Hans
> >
> > > Rest looks good.
> > >
> > > Eric
> > >
> > > At 07:26 PM 12/3/2004 -0800, Hans Frederickson wrote:
> > > >Synopsis: A new source handler and plugin have been created to allow
> > > >depacketization of RealVideo streams.
> > > >
> > > >Overview:
> > > >The main goal of these new components is to provide a tool to create raw
> > > >files that contain a sequence of encoded RealVideo frames. When coupled
> > > >with the raw filewriter (binwrtr), the RV depacketizer source handler
> > > >and plugin do just that. Here's an example of command line usage:
> > > >
> > > >dtdrive.exe +DV 3 -W foo.raw foo.rm
> > > >
> > > >The new raw file format has a header at the top of the file, followed by
> > > >the sequence of frames. It looks like this:
> > > >
> > > >[HEADER]
> > > >HX_MOF bitstream_header (header size is first member of struct)
> > > >
> > > >[FRAME]
> > > >UINT32 dataLength
> > > >UINT32 timestamp
> > > >UINT16 sequenceNum
> > > >UINT16 flags
> > > >UINT32 lastPacket
> > > >UINT32 numSegments
> > > >HXCODEC_SEGMENT_INFO Segments[numSegments]
> > > >UINT8 data[dataLength]
> > > >
> > > >
> > > >With this new raw file format for RealVideo, the command line decoder
> > > >test applications will finally be able to exercise the decoder
> > > >algorithms with true RealVideo bitstreams, once they are modified to
> > > >parse the new format.
> > > >
> > > >The depacketizer plugin produces output packets in the above format
> > > >only, so it is not particularly useful for any purpose other than
> > > >feeding the raw filewriter.
> > > >
> > > >
> > > >Files Modified:
> > > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> > > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> > > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> > > >/datatype/tools/dtdriver/decoder/video/Umakefil
> > > >
> > > >/common/include/hxplugn.h
> > > >/client/common/container/pub/basehand.h
> > > >/client/common/container/pub/hxplugin.h
> > > >
> > > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> > > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> > > >
> > > >New Files:
> > > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> > > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> > > >
> > > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> > > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> > > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> > > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> > > >/datatype/tools/dtdriver/depacker/video/umakedll
> > > >/datatype/tools/dtdriver/depacker/video/Umakefil
> > > >/datatype/tools/dtdriver/depacker/video/umakelib
> > > >/datatype/tools/dtdriver/depacker/video/win32.pcf
> > > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> > > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> > > >
> > > >Image Size and Heap Use impact:
> > > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> > > >is defined. The rvdepacker plugin dll is about 60KB on windows.
> > > >
> > > >Platforms and Profiles Affected:
> > > >dtdr video profiles on all platforms. tested on windows and x86-linux.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Datatype-dev mailing list
> > > >Datatype-dev@helixcommunity.org
> > > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> > >
> > > ======================================
> > > M. Eric Hyche (ehyche@real.com)
> > > Core Technologies
> > > RealNetworks, Inc.
> > >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
From jeffa at real.com Wed Dec 8 08:46:42 2004
From: jeffa at real.com (Jeff Ayars)
Date: Wed Dec 8 08:50:25 2004
Subject: [datatype-dev] Helix DRM and MPEG2
In-Reply-To: <85ECA15B7BB46944BFD4C73AEA554824014E4496@cacexc07.americas
.cpqcorp.net>
Message-ID: <5.1.0.14.2.20041208084239.031d8008@mailone.real.com>
At 03:10 PM 12/7/2004 -0800, Shah, Pallavi wrote:
>Content-Type: multipart/related; type="multipart/alternative";
>boundary="=_flawless.real.com-19695-1102461259-0001-3"
>Content-class: urn:content-classes:message
>
>Does Helix DRM support MPEG2 format? I do not see any mention of MPEG2 in
>your product data sheet.
>Pallavi
Two answers: Architectural and Product
Architecturally, it can support MPEG2. The DRM is format agnostic and uses
the same data type plug-ins our server and player use so if there is a file
format plug-in for MPEG2 we can package it and if there is a renderer (or
renderers depending on choice of audio codec) that's signed by us as
trusted we can play it back.
Product wise, the answer that probably matters most to you, no, the Helix
DRM Product doesn't currently support MPEG 2 due to lack of the player side
trusted renderer for MPEG2 video.
JEff
From Brian.Yan at nokia.com Fri Dec 10 13:18:19 2004
From: Brian.Yan at nokia.com (Brian.Yan@nokia.com)
Date: Fri Dec 10 13:36:58 2004
Subject: [datatype-dev] audio/video codec optimizations
Message-ID: <78E9902B779FD5428DB035B5F6A50EFB024E7965@daebe004.americas.nokia.com>
Hi,
Just want to know whether current audio/video codecs from Helix DNA Client (for Symbian) are optimized in ARM assembly. If they are, which ARM version? ARM7, ARM9T, or ARM9E?
Thanks,
Brian
From ngokhale at real.com Fri Dec 10 14:41:31 2004
From: ngokhale at real.com (Neelesh Gokhale)
Date: Fri Dec 10 14:43:26 2004
Subject: [datatype-dev] audio/video codec optimizations
In-Reply-To: <78E9902B779FD5428DB035B5F6A50EFB024E7965@daebe004.americas
.nokia.com>
References: <78E9902B779FD5428DB035B5F6A50EFB024E7965@daebe004.americas.nokia.com>
Message-ID: <6.0.0.22.2.20041210143908.032a7aa0@mailone.real.com>
At 01:18 PM 12/10/2004, Brian.Yan@nokia.com wrote:
>Hi,
>
>Just want to know whether current audio/video codecs from Helix DNA Client
>(for Symbian) are optimized in ARM assembly. If they are, which ARM
>version? ARM7, ARM9T, or ARM9E?
For ARM7 & ARM9T, the Video codecs are optimized with ARM4 instruction set.
For ARM9E they optimized with ARM5E instruction set.
Thanks,
-Neelesh
>Thanks,
>Brian
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
Neelesh Gokhale ? ngokhale@real.com ? 206.892.6665
Codec Engineer
RealNetworks ? http://www.realnetworks.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/da31636a/attachment.htm
From hfrederickson at real.com Fri Dec 10 15:15:38 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Fri Dec 10 15:10:55 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
Message-ID: <1102720537.1088.129.camel@localhost.localdomain>
Synopsis: A new source handler and plugin have been created to allow
depacketization of RealVideo streams. The raw filewriter has also been
modified to handle the special formatting needs of these streams.
Overview:
The main goal of these new components is to provide a tool to create raw
files that contain a sequence of encoded RealVideo frames. When coupled
with the raw filewriter (binwrtr), the RV depacketizer source handler
and plugin do just that. Here's an example of command line usage:
dtdrive.exe +DV 3 -W foo.raw foo.rm
The new raw file format has a header at the top of the file, followed by
the sequence of frames. It looks like this:
[HEADER]
HX_MOF bitstream_header (header size is first member of struct)
[FRAME]
UINT32 dataLength
UINT32 timestamp
UINT16 sequenceNum
UINT16 flags
UINT32 lastPacket
UINT32 numSegments
HXCODEC_SEGMENT_INFO Segments[numSegments]
UINT8 data[dataLength]
With this new raw file format for RealVideo, the command line decoder
test applications will finally be able to exercise the decoder
algorithms with true RealVideo bitstreams, once they are modified to
parse the new format.
The major updates since the previous CR pertain to the way the HX_MOF
bitstream header is passed into the filewriter, and some custom file
extensions are now used instead of .raw for easy identification of the
output files.
Both the bitstream header and custom file extension are now passed to
the binwrtr with the stream header. The binwrtr examines the mimetype
included in the stream header. If it is "video/x-pn-realvideo-raw", the
buffer containing the bitstream buffer is saved so it can be written to
the output file ahead of the first packet. It also looks at the
"FileExtension" property in the stream header, which will be one of the
following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
renamed with the appropriate file extension so the codec used to encode
the bitstream is easily identified.
Other changes since the previous CR, following suggestions from eric and
milko:
1) In rvdepack.cpp[73]:
const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
2) In rvdepack.cpp[557]:
retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
3) In vdepacketizer.cpp:
CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
Files Modified:
/datatype/tools/dtdriver/apps/dtdrive/main.cpp
/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
/datatype/tools/dtdriver/decoder/video/Umakefil
/datatype/tools/binwrtr/binarch.cpp
/datatype/tools/binwrtr/binarch.h
/common/include/hxplugn.h
/client/common/container/pub/basehand.h
/client/common/container/pub/hxplugin.h
/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
New Files:
/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
/datatype/tools/dtdriver/depacker/video/dlliids.cpp
/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
/datatype/tools/dtdriver/depacker/video/rvdepack.ver
/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
/datatype/tools/dtdriver/depacker/video/umakedll
/datatype/tools/dtdriver/depacker/video/Umakefil
/datatype/tools/dtdriver/depacker/video/umakelib
/datatype/tools/dtdriver/depacker/video/win32.pcf
/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
Image Size and Heap Use impact:
Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
is defined. The rvdepacker plugin dll is about 60KB on windows.
Platforms and Profiles Affected:
dtdr video profiles on all platforms. tested on windows and x86-linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apps_dtdrive_main.cpp.diff
Type: text/x-patch
Size: 1270 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/apps_dtdrive_main.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binarch.cpp.diff
Type: text/x-patch
Size: 2645 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/binarch.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binarch.h.diff
Type: text/x-patch
Size: 813 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/binarch.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_common_container_pub_basehand.h.diff
Type: text/x-patch
Size: 1406 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/client_common_container_pub_basehand.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_common_container_pub_hxplugin.h.diff
Type: text/x-patch
Size: 1406 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/client_common_container_pub_hxplugin.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_include_hxplugn.h.diff
Type: text/x-patch
Size: 1380 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/common_include_hxplugn.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_common_decslcfn.cpp.diff
Type: text/x-patch
Size: 1854 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/decoder_common_decslcfn.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_common_pub_decslcfn.h.diff
Type: text/x-patch
Size: 1186 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/decoder_common_pub_decslcfn.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decoder_video_Umakefil.diff
Type: text/x-patch
Size: 684 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/decoder_video_Umakefil-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix.bif.diff
Type: text/x-patch
Size: 2417 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/helix.bif-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix-dtdr-local-video-transcode.pfi.diff
Type: text/x-patch
Size: 709 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/helix-dtdr-local-video-transcode.pfi-0001.bin
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifdef APSTUDIO_INVOKED
#error this file is not editable by Microsoft Visual C++
#endif //APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
// Add manually edited resources here...
/////////////////////////////////////////////////////////////////////////////
// Version stamp for this deliverable
#ifdef WIN32
#include // Defines for 32bit windows version resources
#else
#include // Defines for 16bit windows version resources
#endif
#include "hxver.h" // Defines for standard deliverables
#include "rvdepack.ver" // Defines for this deliverable created by GETFILES
VS_VERSION_INFO VERSIONINFO
FILEVERSION TARVER_LIST_VERSION
PRODUCTVERSION TARVER_LIST_VERSION
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG|VS_FF_PRIVATEBUILD|VS_FF_PRERELEASE
#else
FILEFLAGS 0 // final version
#endif
FILEOS VER_FILEOS
FILETYPE 0 // not needed
FILESUBTYPE 0 // not needed
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904E4" // Lang=US English, CharSet=Windows Multilingual
BEGIN
VALUE "FileDescription", "RealVideo Depacketizer plugin for RealMedia"
VALUE "InternalName", "rvdepack\0"
VALUE "OriginalFilename","rvdepack.DLL\0"
VALUE "ProductName", "RealVideo Depacketizer plugin for RealMedia"
STRPLATFORM TARVER_STR_BUILD_NAME STREND
VALUE "FileVersion", TARVER_STRING_VERSION
VALUE "ProductVersion", TARVER_STRING_VERSION
VALUE "CompanyName", HXVER_COMPANY
VALUE "LegalCopyright", HXVER_COPYRIGHT
VALUE "LegalTrademarks", HXVER_TRADEMARKS
VALUE "DistCode", "PN01\0"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1252
// English language (0x409) and the Windows ANSI codepage (1252)
END
END
/////////////////////////////////////////////////////////////////////////////
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlliids.cpp
Type: text/x-c++
Size: 1984 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/dlliids-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.cpp
Type: text/x-c++
Size: 20458 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/rvdepack-0002.bin
-------------- next part --------------
DESCRIPTION 'RealMedia Player'
HEAPSIZE 1024
EXPORTS
RMACreateInstance
CanUnload
CanUnload2
SetDLLAccessPath
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepackdll.cpp
Type: text/x-c++
Size: 2194 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/rvdepackdll-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.h
Type: text/x-c-header
Size: 4703 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/rvdepack-0003.bin
-------------- next part --------------
/* THIS FILE IS GENERATED BY THE BUILD SYSTEM -- DO NOT EDIT
* Copyright (C) 1997-2002 RealNetworks Corporation. All rights reserved.
*/
#ifdef _MACINTOSH
#define TARVER_ULONG32_VERSION ((6<<28)|(0<<20)|(9<<12)|1)
#else
#define TARVER_ULONG32_VERSION (UINT32)((6L<<28L)|(0L<<20L)|(9L<< 12L)|1L)
#endif
#define TARVER_LIST_VERSION 6,0,9,1
#define TARVER_MAJOR_VERSION 6
#define TARVER_MINOR_VERSION 0
#define TARVER_STRING_VERSION "6.0.9.1"
#define TARVER_STR_BUILD_NAME ""
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,2)
#project.AddModuleIncludes("HELIX_FEATURE_MIN_HEAP")
project.AddModuleIncludes("common/include",
"client/include",
"client/common/container/pub",
"datatype/common/container/pub",
"datatype/common/util/pub",
"datatype/rm/video/common/pub",
"datatype/rm/include",
"datatype/rm/common/util/pub")
project.AddModuleLibraries("common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"common/util[utillib]",
"common/container[contlib]",
"common/system[syslib]",
"common/log/logutil[logutillib]",
"datatype/rm/common[rmcomlib]",
"datatype/tools/dtdriver/depacker/video[rvdepacklib]",
"datatype/common/util[dtutillib]")
project.AddLibraries(GetSDKPath("rmvidcom_lib"),
GetSDKPath("rmvidpyld_lib"))
project.AddSources("rvdepackdll.cpp",
"dlliids.cpp")
project.ExportFunction("RMACreateInstance",
"IUnknown** ppObj",
"common/include",
"hxcom.h")
project.ExportFunction("CanUnload", "void")
project.ExportFunction("CanUnload2", "void")
if not project.IsDefined("HELIX_FEATURE_DLLACCESS_CLIENT"):
project.ExportFunction("SetDLLAccessPath", "const char* pszPath")
DLLTarget("rvdepack")
DependTarget()
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,1)
MultiTargetMake("umakelib", "umakedll")
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,2)
project.AddModuleIncludes("common/include",
"common/runtime/pub",
"common/dbgtool/pub",
"common/util/pub",
"common/container/pub",
"common/system/pub",
"common/log/logutil/pub",
"client/include",
"client/common/container/pub",
"datatype/common/container/pub",
"datatype/common/util/pub",
"datatype/rm/video/common/pub",
"datatype/rm/common/pub",
"datatype/rm/include",
"datatype/rm/common/util/pub",
"datatype/h263/payload/pub",
"datatype/h263/codec")
project.AddSources("rvdepack.cpp")
LibraryTarget("rvdepacklib")
DependTarget()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdepacker.cpp
Type: text/x-c++
Size: 18111 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/vdepacker-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdepacker.h
Type: text/x-c-header
Size: 5058 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/vdepacker-0003.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.pcf
Type: application/x-font-pcf
Size: 211 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/0c68843f/win32-0001.bin
From milko at real.com Fri Dec 10 15:45:27 2004
From: milko at real.com (milko)
Date: Fri Dec 10 15:45:46 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <1102720537.1088.129.camel@localhost.localdomain>
Message-ID: <5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
One comment:
Instead of using property "FileExtension", consider using property
associated with the media stream independent of file container.
E.g.: CodecName = "rv7" . It is up to a particular file writer to
store this as it chooses.
Binary writer, for example, could look for CodecName and use it as
extension if found. If not found, it would use the extension specified by
the user.
Milko
At 03:15 PM 12/10/2004, Hans Frederickson wrote:
>Synopsis: A new source handler and plugin have been created to allow
>depacketization of RealVideo streams. The raw filewriter has also been
>modified to handle the special formatting needs of these streams.
>
>Overview:
>The main goal of these new components is to provide a tool to create raw
>files that contain a sequence of encoded RealVideo frames. When coupled
>with the raw filewriter (binwrtr), the RV depacketizer source handler
>and plugin do just that. Here's an example of command line usage:
>
>dtdrive.exe +DV 3 -W foo.raw foo.rm
>
>The new raw file format has a header at the top of the file, followed by
>the sequence of frames. It looks like this:
>
>[HEADER]
>HX_MOF bitstream_header (header size is first member of struct)
>
>[FRAME]
>UINT32 dataLength
>UINT32 timestamp
>UINT16 sequenceNum
>UINT16 flags
>UINT32 lastPacket
>UINT32 numSegments
>HXCODEC_SEGMENT_INFO Segments[numSegments]
>UINT8 data[dataLength]
>
>
>With this new raw file format for RealVideo, the command line decoder
>test applications will finally be able to exercise the decoder
>algorithms with true RealVideo bitstreams, once they are modified to
>parse the new format.
>
>The major updates since the previous CR pertain to the way the HX_MOF
>bitstream header is passed into the filewriter, and some custom file
>extensions are now used instead of .raw for easy identification of the
>output files.
>
>Both the bitstream header and custom file extension are now passed to
>the binwrtr with the stream header. The binwrtr examines the mimetype
>included in the stream header. If it is "video/x-pn-realvideo-raw", the
>buffer containing the bitstream buffer is saved so it can be written to
>the output file ahead of the first packet. It also looks at the
>"FileExtension" property in the stream header, which will be one of the
>following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
>renamed with the appropriate file extension so the codec used to encode
>the bitstream is easily identified.
>
>Other changes since the previous CR, following suggestions from eric and
>milko:
>
>1) In rvdepack.cpp[73]:
>const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
>
>2) In rvdepack.cpp[557]:
>retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
>
>3) In vdepacketizer.cpp:
>CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
>
>
>Files Modified:
>/datatype/tools/dtdriver/apps/dtdrive/main.cpp
>/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
>/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
>/datatype/tools/dtdriver/decoder/video/Umakefil
>/datatype/tools/binwrtr/binarch.cpp
>/datatype/tools/binwrtr/binarch.h
>
>/common/include/hxplugn.h
>/client/common/container/pub/basehand.h
>/client/common/container/pub/hxplugin.h
>
>/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
>/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
>
>New Files:
>/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
>/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
>
>/datatype/tools/dtdriver/depacker/video/dlliids.cpp
>/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
>/datatype/tools/dtdriver/depacker/video/rvdepack.ver
>/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
>/datatype/tools/dtdriver/depacker/video/umakedll
>/datatype/tools/dtdriver/depacker/video/Umakefil
>/datatype/tools/dtdriver/depacker/video/umakelib
>/datatype/tools/dtdriver/depacker/video/win32.pcf
>/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
>/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
>
>Image Size and Heap Use impact:
>Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
>is defined. The rvdepacker plugin dll is about 60KB on windows.
>
>Platforms and Profiles Affected:
>dtdr video profiles on all platforms. tested on windows and x86-linux.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From hfrederickson at real.com Fri Dec 10 16:06:36 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Fri Dec 10 16:01:50 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
References: <5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
Message-ID: <1102723595.1088.137.camel@localhost.localdomain>
Ok. How about "CodecExtension"? I agree that using the "FileExtension"
property in a stream header is a bit odd, but I wanted to be clear that
the string is supposed to be a filename extension and has no other
purpose. If "CodecExtension" is ok with you, I will make the change.
I'll leave this CR open for additional comments, and check it in EOD
Monday if there are no further issues.
Thanks,
-Hans
On Fri, 2004-12-10 at 15:45, milko wrote:
> One comment:
>
> Instead of using property "FileExtension", consider using property
> associated with the media stream independent of file container.
> E.g.: CodecName = "rv7" . It is up to a particular file writer to
> store this as it chooses.
>
> Binary writer, for example, could look for CodecName and use it as
> extension if found. If not found, it would use the extension specified by
> the user.
>
> Milko
>
>
> At 03:15 PM 12/10/2004, Hans Frederickson wrote:
> >Synopsis: A new source handler and plugin have been created to allow
> >depacketization of RealVideo streams. The raw filewriter has also been
> >modified to handle the special formatting needs of these streams.
> >
> >Overview:
> >The main goal of these new components is to provide a tool to create raw
> >files that contain a sequence of encoded RealVideo frames. When coupled
> >with the raw filewriter (binwrtr), the RV depacketizer source handler
> >and plugin do just that. Here's an example of command line usage:
> >
> >dtdrive.exe +DV 3 -W foo.raw foo.rm
> >
> >The new raw file format has a header at the top of the file, followed by
> >the sequence of frames. It looks like this:
> >
> >[HEADER]
> >HX_MOF bitstream_header (header size is first member of struct)
> >
> >[FRAME]
> >UINT32 dataLength
> >UINT32 timestamp
> >UINT16 sequenceNum
> >UINT16 flags
> >UINT32 lastPacket
> >UINT32 numSegments
> >HXCODEC_SEGMENT_INFO Segments[numSegments]
> >UINT8 data[dataLength]
> >
> >
> >With this new raw file format for RealVideo, the command line decoder
> >test applications will finally be able to exercise the decoder
> >algorithms with true RealVideo bitstreams, once they are modified to
> >parse the new format.
> >
> >The major updates since the previous CR pertain to the way the HX_MOF
> >bitstream header is passed into the filewriter, and some custom file
> >extensions are now used instead of .raw for easy identification of the
> >output files.
> >
> >Both the bitstream header and custom file extension are now passed to
> >the binwrtr with the stream header. The binwrtr examines the mimetype
> >included in the stream header. If it is "video/x-pn-realvideo-raw", the
> >buffer containing the bitstream buffer is saved so it can be written to
> >the output file ahead of the first packet. It also looks at the
> >"FileExtension" property in the stream header, which will be one of the
> >following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
> >renamed with the appropriate file extension so the codec used to encode
> >the bitstream is easily identified.
> >
> >Other changes since the previous CR, following suggestions from eric and
> >milko:
> >
> >1) In rvdepack.cpp[73]:
> >const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
> >
> >2) In rvdepack.cpp[557]:
> >retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
> >
> >3) In vdepacketizer.cpp:
> >CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
> >
> >
> >Files Modified:
> >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> >/datatype/tools/dtdriver/decoder/video/Umakefil
> >/datatype/tools/binwrtr/binarch.cpp
> >/datatype/tools/binwrtr/binarch.h
> >
> >/common/include/hxplugn.h
> >/client/common/container/pub/basehand.h
> >/client/common/container/pub/hxplugin.h
> >
> >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> >
> >New Files:
> >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> >
> >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> >/datatype/tools/dtdriver/depacker/video/umakedll
> >/datatype/tools/dtdriver/depacker/video/Umakefil
> >/datatype/tools/dtdriver/depacker/video/umakelib
> >/datatype/tools/dtdriver/depacker/video/win32.pcf
> >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> >
> >Image Size and Heap Use impact:
> >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> >is defined. The rvdepacker plugin dll is about 60KB on windows.
> >
> >Platforms and Profiles Affected:
> >dtdr video profiles on all platforms. tested on windows and x86-linux.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
From milko at real.com Fri Dec 10 16:21:24 2004
From: milko at real.com (milko)
Date: Fri Dec 10 16:21:38 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <1102723595.1088.137.camel@localhost.localdomain>
References: <5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
I understand the intent, but that is too application specific to be present
in content meta-data.
The concept of the file extension is tied to a file system.
Once the data is in stream format, it makes no sense for it to contain
reference to a file system or file format.
It should just be describing what it is.
"CodecExtension" is unclear.
I think either CodecName = "rv9" or Codec4CC = "rv40" are acceptable.
Anything that is meant as file extension or includes assumed extension
characters such as '.' does not belong to stream meta-data.
Milko
At 04:06 PM 12/10/2004, Hans Frederickson wrote:
>Ok. How about "CodecExtension"? I agree that using the "FileExtension"
>property in a stream header is a bit odd, but I wanted to be clear that
>the string is supposed to be a filename extension and has no other
>purpose. If "CodecExtension" is ok with you, I will make the change.
>
>I'll leave this CR open for additional comments, and check it in EOD
>Monday if there are no further issues.
>
>Thanks,
>-Hans
>
>On Fri, 2004-12-10 at 15:45, milko wrote:
> > One comment:
> >
> > Instead of using property "FileExtension", consider using property
> > associated with the media stream independent of file container.
> > E.g.: CodecName = "rv7" . It is up to a particular file writer to
> > store this as it chooses.
> >
> > Binary writer, for example, could look for CodecName and use it as
> > extension if found. If not found, it would use the extension specified by
> > the user.
> >
> > Milko
> >
> >
> > At 03:15 PM 12/10/2004, Hans Frederickson wrote:
> > >Synopsis: A new source handler and plugin have been created to allow
> > >depacketization of RealVideo streams. The raw filewriter has also been
> > >modified to handle the special formatting needs of these streams.
> > >
> > >Overview:
> > >The main goal of these new components is to provide a tool to create raw
> > >files that contain a sequence of encoded RealVideo frames. When coupled
> > >with the raw filewriter (binwrtr), the RV depacketizer source handler
> > >and plugin do just that. Here's an example of command line usage:
> > >
> > >dtdrive.exe +DV 3 -W foo.raw foo.rm
> > >
> > >The new raw file format has a header at the top of the file, followed by
> > >the sequence of frames. It looks like this:
> > >
> > >[HEADER]
> > >HX_MOF bitstream_header (header size is first member of struct)
> > >
> > >[FRAME]
> > >UINT32 dataLength
> > >UINT32 timestamp
> > >UINT16 sequenceNum
> > >UINT16 flags
> > >UINT32 lastPacket
> > >UINT32 numSegments
> > >HXCODEC_SEGMENT_INFO Segments[numSegments]
> > >UINT8 data[dataLength]
> > >
> > >
> > >With this new raw file format for RealVideo, the command line decoder
> > >test applications will finally be able to exercise the decoder
> > >algorithms with true RealVideo bitstreams, once they are modified to
> > >parse the new format.
> > >
> > >The major updates since the previous CR pertain to the way the HX_MOF
> > >bitstream header is passed into the filewriter, and some custom file
> > >extensions are now used instead of .raw for easy identification of the
> > >output files.
> > >
> > >Both the bitstream header and custom file extension are now passed to
> > >the binwrtr with the stream header. The binwrtr examines the mimetype
> > >included in the stream header. If it is "video/x-pn-realvideo-raw", the
> > >buffer containing the bitstream buffer is saved so it can be written to
> > >the output file ahead of the first packet. It also looks at the
> > >"FileExtension" property in the stream header, which will be one of the
> > >following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
> > >renamed with the appropriate file extension so the codec used to encode
> > >the bitstream is easily identified.
> > >
> > >Other changes since the previous CR, following suggestions from eric and
> > >milko:
> > >
> > >1) In rvdepack.cpp[73]:
> > >const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
> > >
> > >2) In rvdepack.cpp[557]:
> > >retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
> > >
> > >3) In vdepacketizer.cpp:
> > >CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
> > >
> > >
> > >Files Modified:
> > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> > >/datatype/tools/dtdriver/decoder/video/Umakefil
> > >/datatype/tools/binwrtr/binarch.cpp
> > >/datatype/tools/binwrtr/binarch.h
> > >
> > >/common/include/hxplugn.h
> > >/client/common/container/pub/basehand.h
> > >/client/common/container/pub/hxplugin.h
> > >
> > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> > >
> > >New Files:
> > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> > >
> > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> > >/datatype/tools/dtdriver/depacker/video/umakedll
> > >/datatype/tools/dtdriver/depacker/video/Umakefil
> > >/datatype/tools/dtdriver/depacker/video/umakelib
> > >/datatype/tools/dtdriver/depacker/video/win32.pcf
> > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> > >
> > >Image Size and Heap Use impact:
> > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> > >is defined. The rvdepacker plugin dll is about 60KB on windows.
> > >
> > >Platforms and Profiles Affected:
> > >dtdr video profiles on all platforms. tested on windows and x86-linux.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Datatype-dev mailing list
> > >Datatype-dev@helixcommunity.org
> > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> >
> >
From jrecker at real.com Fri Dec 10 16:47:31 2004
From: jrecker at real.com (Jon Recker)
Date: Fri Dec 10 16:42:07 2004
Subject: [datatype-dev] audio/video codec optimizations
In-Reply-To: <6.0.0.22.2.20041210143908.032a7aa0@mailone.real.com>
References: <78E9902B779FD5428DB035B5F6A50EFB024E7965@daebe004.americas
.nokia.com>
<78E9902B779FD5428DB035B5F6A50EFB024E7965@daebe004.americas.nokia.com>
Message-ID: <5.1.0.14.2.20041210162649.00a3aec0@mailone.real.com>
The audio codecs use the ARM v4 ISA, and should run on any ARM7TDMI or later. Also note that the C code is highly optimized (fast algorithms). It is tuned to compile well with the ARM toolchain (ADS) but will also work with gcc.
- Jon
At 02:41 PM 12/10/04, Neelesh Gokhale wrote:
>At 01:18 PM 12/10/2004, Brian.Yan@nokia.com wrote:
>>Hi,
>>
>>Just want to know whether current audio/video codecs from Helix DNA Client (for Symbian) are optimized in ARM assembly. If they are, which ARM version? ARM7, ARM9T, or ARM9E?
>
>For ARM7 & ARM9T, the Video codecs are optimized with ARM4 instruction set.
>For ARM9E they optimized with ARM5E instruction set.
>
>Thanks,
>-Neelesh
>
>>Thanks,
>>Brian
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>Neelesh Gokhale ? ngokhale@real.com ? 206.892.6665
>Codec Engineer
>RealNetworks ? http://www.realnetworks.com
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041210/7340287f/attachment.htm
From ehyche at real.com Mon Dec 13 06:59:11 2004
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 13 06:59:15 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
References: <1102723595.1088.137.camel@localhost.localdomain>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041213095852.00c5eb40@mailone.real.com>
At 04:21 PM 12/10/2004 -0800, milko wrote:
>I understand the intent, but that is too application specific to be
>present in content meta-data.
>The concept of the file extension is tied to a file system.
>Once the data is in stream format, it makes no sense for it to contain
>reference to a file system or file format.
>It should just be describing what it is.
>
>"CodecExtension" is unclear.
>
>I think either CodecName = "rv9" or Codec4CC = "rv40" are acceptable.
I like "Codec4CC".
Eric
>Anything that is meant as file extension or includes assumed extension
>characters such as '.' does not belong to stream meta-data.
>
>Milko
>
>At 04:06 PM 12/10/2004, Hans Frederickson wrote:
>>Ok. How about "CodecExtension"? I agree that using the "FileExtension"
>>property in a stream header is a bit odd, but I wanted to be clear that
>>the string is supposed to be a filename extension and has no other
>>purpose. If "CodecExtension" is ok with you, I will make the change.
>>
>>I'll leave this CR open for additional comments, and check it in EOD
>>Monday if there are no further issues.
>>
>>Thanks,
>>-Hans
>>
>>On Fri, 2004-12-10 at 15:45, milko wrote:
>> > One comment:
>> >
>> > Instead of using property "FileExtension", consider using property
>> > associated with the media stream independent of file container.
>> > E.g.: CodecName = "rv7" . It is up to a particular file writer to
>> > store this as it chooses.
>> >
>> > Binary writer, for example, could look for CodecName and use it as
>> > extension if found. If not found, it would use the extension specified by
>> > the user.
>> >
>> > Milko
>> >
>> >
>> > At 03:15 PM 12/10/2004, Hans Frederickson wrote:
>> > >Synopsis: A new source handler and plugin have been created to allow
>> > >depacketization of RealVideo streams. The raw filewriter has also been
>> > >modified to handle the special formatting needs of these streams.
>> > >
>> > >Overview:
>> > >The main goal of these new components is to provide a tool to create raw
>> > >files that contain a sequence of encoded RealVideo frames. When coupled
>> > >with the raw filewriter (binwrtr), the RV depacketizer source handler
>> > >and plugin do just that. Here's an example of command line usage:
>> > >
>> > >dtdrive.exe +DV 3 -W foo.raw foo.rm
>> > >
>> > >The new raw file format has a header at the top of the file, followed by
>> > >the sequence of frames. It looks like this:
>> > >
>> > >[HEADER]
>> > >HX_MOF bitstream_header (header size is first member of struct)
>> > >
>> > >[FRAME]
>> > >UINT32 dataLength
>> > >UINT32 timestamp
>> > >UINT16 sequenceNum
>> > >UINT16 flags
>> > >UINT32 lastPacket
>> > >UINT32 numSegments
>> > >HXCODEC_SEGMENT_INFO Segments[numSegments]
>> > >UINT8 data[dataLength]
>> > >
>> > >
>> > >With this new raw file format for RealVideo, the command line decoder
>> > >test applications will finally be able to exercise the decoder
>> > >algorithms with true RealVideo bitstreams, once they are modified to
>> > >parse the new format.
>> > >
>> > >The major updates since the previous CR pertain to the way the HX_MOF
>> > >bitstream header is passed into the filewriter, and some custom file
>> > >extensions are now used instead of .raw for easy identification of the
>> > >output files.
>> > >
>> > >Both the bitstream header and custom file extension are now passed to
>> > >the binwrtr with the stream header. The binwrtr examines the mimetype
>> > >included in the stream header. If it is "video/x-pn-realvideo-raw", the
>> > >buffer containing the bitstream buffer is saved so it can be written to
>> > >the output file ahead of the first packet. It also looks at the
>> > >"FileExtension" property in the stream header, which will be one of the
>> > >following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
>> > >renamed with the appropriate file extension so the codec used to encode
>> > >the bitstream is easily identified.
>> > >
>> > >Other changes since the previous CR, following suggestions from eric and
>> > >milko:
>> > >
>> > >1) In rvdepack.cpp[73]:
>> > >const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
>> > >
>> > >2) In rvdepack.cpp[557]:
>> > >retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
>> > >
>> > >3) In vdepacketizer.cpp:
>> > >CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
>> > >
>> > >
>> > >Files Modified:
>> > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
>> > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
>> > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
>> > >/datatype/tools/dtdriver/decoder/video/Umakefil
>> > >/datatype/tools/binwrtr/binarch.cpp
>> > >/datatype/tools/binwrtr/binarch.h
>> > >
>> > >/common/include/hxplugn.h
>> > >/client/common/container/pub/basehand.h
>> > >/client/common/container/pub/hxplugin.h
>> > >
>> > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
>> > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
>> > >
>> > >New Files:
>> > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
>> > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
>> > >
>> > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
>> > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
>> > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
>> > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
>> > >/datatype/tools/dtdriver/depacker/video/umakedll
>> > >/datatype/tools/dtdriver/depacker/video/Umakefil
>> > >/datatype/tools/dtdriver/depacker/video/umakelib
>> > >/datatype/tools/dtdriver/depacker/video/win32.pcf
>> > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
>> > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
>> > >
>> > >Image Size and Heap Use impact:
>> > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
>> > >is defined. The rvdepacker plugin dll is about 60KB on windows.
>> > >
>> > >Platforms and Profiles Affected:
>> > >dtdr video profiles on all platforms. tested on windows and x86-linux.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >_______________________________________________
>> > >Datatype-dev mailing list
>> > >Datatype-dev@helixcommunity.org
>> > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>> >
>> >
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From hfrederickson at real.com Mon Dec 13 12:36:23 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Mon Dec 13 12:31:47 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
References: <5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
Message-ID: <1102970182.1088.185.camel@localhost.localdomain>
Ok, the property is now named "Codec4CC" and the corresponding data is
just the ULONG32 4CC code. binwrtr chooses an extension string based on
the 4CC code. Attached are the updated diff for binarch.cpp and the
updated rvdepack.cpp.
I have one other question... I'd like to get some comments on the
location of the new depacker directory tree. Currently, I have it here:
/datatype/tools/dtdriver/depacker/video
But since it really is a separate component from the dtdrive engine and
app, I thought perhaps it should go here:
/datatype/tools/depacker/video
Which is where the binwrtr is, coincidentally. Anybody have a preference
either way? Or an alternate suggestion?
-Hans
On Fri, 2004-12-10 at 16:21, milko wrote:
> I understand the intent, but that is too application specific to be present
> in content meta-data.
> The concept of the file extension is tied to a file system.
> Once the data is in stream format, it makes no sense for it to contain
> reference to a file system or file format.
> It should just be describing what it is.
>
> "CodecExtension" is unclear.
>
> I think either CodecName = "rv9" or Codec4CC = "rv40" are acceptable.
> Anything that is meant as file extension or includes assumed extension
> characters such as '.' does not belong to stream meta-data.
>
> Milko
>
> At 04:06 PM 12/10/2004, Hans Frederickson wrote:
> >Ok. How about "CodecExtension"? I agree that using the "FileExtension"
> >property in a stream header is a bit odd, but I wanted to be clear that
> >the string is supposed to be a filename extension and has no other
> >purpose. If "CodecExtension" is ok with you, I will make the change.
> >
> >I'll leave this CR open for additional comments, and check it in EOD
> >Monday if there are no further issues.
> >
> >Thanks,
> >-Hans
> >
> >On Fri, 2004-12-10 at 15:45, milko wrote:
> > > One comment:
> > >
> > > Instead of using property "FileExtension", consider using property
> > > associated with the media stream independent of file container.
> > > E.g.: CodecName = "rv7" . It is up to a particular file writer to
> > > store this as it chooses.
> > >
> > > Binary writer, for example, could look for CodecName and use it as
> > > extension if found. If not found, it would use the extension specified by
> > > the user.
> > >
> > > Milko
> > >
> > >
> > > At 03:15 PM 12/10/2004, Hans Frederickson wrote:
> > > >Synopsis: A new source handler and plugin have been created to allow
> > > >depacketization of RealVideo streams. The raw filewriter has also been
> > > >modified to handle the special formatting needs of these streams.
> > > >
> > > >Overview:
> > > >The main goal of these new components is to provide a tool to create raw
> > > >files that contain a sequence of encoded RealVideo frames. When coupled
> > > >with the raw filewriter (binwrtr), the RV depacketizer source handler
> > > >and plugin do just that. Here's an example of command line usage:
> > > >
> > > >dtdrive.exe +DV 3 -W foo.raw foo.rm
> > > >
> > > >The new raw file format has a header at the top of the file, followed by
> > > >the sequence of frames. It looks like this:
> > > >
> > > >[HEADER]
> > > >HX_MOF bitstream_header (header size is first member of struct)
> > > >
> > > >[FRAME]
> > > >UINT32 dataLength
> > > >UINT32 timestamp
> > > >UINT16 sequenceNum
> > > >UINT16 flags
> > > >UINT32 lastPacket
> > > >UINT32 numSegments
> > > >HXCODEC_SEGMENT_INFO Segments[numSegments]
> > > >UINT8 data[dataLength]
> > > >
> > > >
> > > >With this new raw file format for RealVideo, the command line decoder
> > > >test applications will finally be able to exercise the decoder
> > > >algorithms with true RealVideo bitstreams, once they are modified to
> > > >parse the new format.
> > > >
> > > >The major updates since the previous CR pertain to the way the HX_MOF
> > > >bitstream header is passed into the filewriter, and some custom file
> > > >extensions are now used instead of .raw for easy identification of the
> > > >output files.
> > > >
> > > >Both the bitstream header and custom file extension are now passed to
> > > >the binwrtr with the stream header. The binwrtr examines the mimetype
> > > >included in the stream header. If it is "video/x-pn-realvideo-raw", the
> > > >buffer containing the bitstream buffer is saved so it can be written to
> > > >the output file ahead of the first packet. It also looks at the
> > > >"FileExtension" property in the stream header, which will be one of the
> > > >following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output file is
> > > >renamed with the appropriate file extension so the codec used to encode
> > > >the bitstream is easily identified.
> > > >
> > > >Other changes since the previous CR, following suggestions from eric and
> > > >milko:
> > > >
> > > >1) In rvdepack.cpp[73]:
> > > >const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
> > > >
> > > >2) In rvdepack.cpp[557]:
> > > >retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
> > > >
> > > >3) In vdepacketizer.cpp:
> > > >CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
> > > >
> > > >
> > > >Files Modified:
> > > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> > > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> > > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> > > >/datatype/tools/dtdriver/decoder/video/Umakefil
> > > >/datatype/tools/binwrtr/binarch.cpp
> > > >/datatype/tools/binwrtr/binarch.h
> > > >
> > > >/common/include/hxplugn.h
> > > >/client/common/container/pub/basehand.h
> > > >/client/common/container/pub/hxplugin.h
> > > >
> > > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> > > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> > > >
> > > >New Files:
> > > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> > > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> > > >
> > > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> > > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> > > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> > > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> > > >/datatype/tools/dtdriver/depacker/video/umakedll
> > > >/datatype/tools/dtdriver/depacker/video/Umakefil
> > > >/datatype/tools/dtdriver/depacker/video/umakelib
> > > >/datatype/tools/dtdriver/depacker/video/win32.pcf
> > > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> > > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> > > >
> > > >Image Size and Heap Use impact:
> > > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> > > >is defined. The rvdepacker plugin dll is about 60KB on windows.
> > > >
> > > >Platforms and Profiles Affected:
> > > >dtdr video profiles on all platforms. tested on windows and x86-linux.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >Datatype-dev mailing list
> > > >Datatype-dev@helixcommunity.org
> > > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> > >
> > >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binarch.cpp.diff
Type: text/x-patch
Size: 2977 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041213/21db03fc/binarch.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvdepack.cpp
Type: text/x-c++
Size: 19944 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041213/21db03fc/rvdepack-0001.bin
From rgammon at real.com Mon Dec 13 13:46:10 2004
From: rgammon at real.com (Ryan Gammon)
Date: Mon Dec 13 13:48:11 2004
Subject: [datatype-dev] Codec suffixes
Message-ID: <41BE0DA2.5000402@real.com>
Hi all,
I notice on windows I get a suffix of 32100 on some dll's, for example:
cook32100.dll
Some don't have this, eg:
atrc.dll
On linux, these are cook.so, atrc.so
This is confusing the installer, which isn't expecting the suffixes.
Should these suffixes be there?
--
Ryan Gammon
rgammon@real.com
Developer for Helix Player
https://player.helixcommunity.org
From nhart at real.com Mon Dec 13 13:54:40 2004
From: nhart at real.com (Nicholas Hart)
Date: Mon Dec 13 13:54:44 2004
Subject: [datatype-dev] Codec suffixes
In-Reply-To: <41BE0DA2.5000402@real.com>
References: <41BE0DA2.5000402@real.com>
Message-ID: <1102974880.31567.230.camel@localhost.localdomain>
not sure about that inconsistency on windows, but it's possible we could
change the installer to be a little more robust on windows. i think
there's some way the installer scripts can use ribosome to obtain the
actual filename as opposed to having to guess it (or we could change it
to guess smarter.
On Mon, 2004-12-13 at 13:46 -0800, Ryan Gammon wrote:
> Hi all,
>
> I notice on windows I get a suffix of 32100 on some dll's, for example:
> cook32100.dll
>
> Some don't have this, eg:
> atrc.dll
>
> On linux, these are cook.so, atrc.so
>
> This is confusing the installer, which isn't expecting the suffixes.
> Should these suffixes be there?
>
From ehyche at real.com Mon Dec 13 14:36:36 2004
From: ehyche at real.com (Eric Hyche)
Date: Mon Dec 13 14:36:43 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <1102970182.1088.185.camel@localhost.localdomain>
References: <5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
Message-ID: <5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
At 12:36 PM 12/13/2004 -0800, Hans Frederickson wrote:
>Ok, the property is now named "Codec4CC" and the corresponding data is
>just the ULONG32 4CC code. binwrtr chooses an extension string based on
>the 4CC code. Attached are the updated diff for binarch.cpp and the
>updated rvdepack.cpp.
>
>I have one other question... I'd like to get some comments on the
>location of the new depacker directory tree. Currently, I have it here:
>
>/datatype/tools/dtdriver/depacker/video
>But since it really is a separate component from the dtdrive engine and
>app, I thought perhaps it should go here:
>
>/datatype/tools/depacker/video
Hmmmm... this is a component that uses RVXPayloadFormat, which is
defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
(restricted). So since we define RVXPayloadFormat in the public
tree, it should be fine to put it there. I would probably
put it at
datatype/rm/video/common
and put the header file in datatype/rm/video/common/pub.
Eric
>Which is where the binwrtr is, coincidentally. Anybody have a preference
>either way? Or an alternate suggestion?
>
>-Hans
>
>On Fri, 2004-12-10 at 16:21, milko wrote:
> > I understand the intent, but that is too application specific to be
> present
> > in content meta-data.
> > The concept of the file extension is tied to a file system.
> > Once the data is in stream format, it makes no sense for it to contain
> > reference to a file system or file format.
> > It should just be describing what it is.
> >
> > "CodecExtension" is unclear.
> >
> > I think either CodecName = "rv9" or Codec4CC = "rv40" are acceptable.
> > Anything that is meant as file extension or includes assumed extension
> > characters such as '.' does not belong to stream meta-data.
> >
> > Milko
> >
> > At 04:06 PM 12/10/2004, Hans Frederickson wrote:
> > >Ok. How about "CodecExtension"? I agree that using the "FileExtension"
> > >property in a stream header is a bit odd, but I wanted to be clear that
> > >the string is supposed to be a filename extension and has no other
> > >purpose. If "CodecExtension" is ok with you, I will make the change.
> > >
> > >I'll leave this CR open for additional comments, and check it in EOD
> > >Monday if there are no further issues.
> > >
> > >Thanks,
> > >-Hans
> > >
> > >On Fri, 2004-12-10 at 15:45, milko wrote:
> > > > One comment:
> > > >
> > > > Instead of using property "FileExtension", consider using property
> > > > associated with the media stream independent of file container.
> > > > E.g.: CodecName = "rv7" . It is up to a particular file writer to
> > > > store this as it chooses.
> > > >
> > > > Binary writer, for example, could look for CodecName and use it as
> > > > extension if found. If not found, it would use the extension
> specified by
> > > > the user.
> > > >
> > > > Milko
> > > >
> > > >
> > > > At 03:15 PM 12/10/2004, Hans Frederickson wrote:
> > > > >Synopsis: A new source handler and plugin have been created to allow
> > > > >depacketization of RealVideo streams. The raw filewriter has also been
> > > > >modified to handle the special formatting needs of these streams.
> > > > >
> > > > >Overview:
> > > > >The main goal of these new components is to provide a tool to
> create raw
> > > > >files that contain a sequence of encoded RealVideo frames. When
> coupled
> > > > >with the raw filewriter (binwrtr), the RV depacketizer source handler
> > > > >and plugin do just that. Here's an example of command line usage:
> > > > >
> > > > >dtdrive.exe +DV 3 -W foo.raw foo.rm
> > > > >
> > > > >The new raw file format has a header at the top of the file,
> followed by
> > > > >the sequence of frames. It looks like this:
> > > > >
> > > > >[HEADER]
> > > > >HX_MOF bitstream_header (header size is first member of struct)
> > > > >
> > > > >[FRAME]
> > > > >UINT32 dataLength
> > > > >UINT32 timestamp
> > > > >UINT16 sequenceNum
> > > > >UINT16 flags
> > > > >UINT32 lastPacket
> > > > >UINT32 numSegments
> > > > >HXCODEC_SEGMENT_INFO Segments[numSegments]
> > > > >UINT8 data[dataLength]
> > > > >
> > > > >
> > > > >With this new raw file format for RealVideo, the command line decoder
> > > > >test applications will finally be able to exercise the decoder
> > > > >algorithms with true RealVideo bitstreams, once they are modified to
> > > > >parse the new format.
> > > > >
> > > > >The major updates since the previous CR pertain to the way the HX_MOF
> > > > >bitstream header is passed into the filewriter, and some custom file
> > > > >extensions are now used instead of .raw for easy identification of the
> > > > >output files.
> > > > >
> > > > >Both the bitstream header and custom file extension are now passed to
> > > > >the binwrtr with the stream header. The binwrtr examines the mimetype
> > > > >included in the stream header. If it is
> "video/x-pn-realvideo-raw", the
> > > > >buffer containing the bitstream buffer is saved so it can be
> written to
> > > > >the output file ahead of the first packet. It also looks at the
> > > > >"FileExtension" property in the stream header, which will be one
> of the
> > > > >following for raw realvideo (.rv1, .rv7, .rv8, .rv9). The output
> file is
> > > > >renamed with the appropriate file extension so the codec used to
> encode
> > > > >the bitstream is easily identified.
> > > > >
> > > > >Other changes since the previous CR, following suggestions from
> eric and
> > > > >milko:
> > > > >
> > > > >1) In rvdepack.cpp[73]:
> > > > >const char* CRVDepacker::zm_pSupportedCodecs = "rv40 rv30 rv20 rv10";
> > > > >
> > > > >2) In rvdepack.cpp[557]:
> > > > >retVal = pPacket->Set(pBuffer, timestamp, 0, asmFlags, 0);
> > > > >
> > > > >3) In vdepacketizer.cpp:
> > > > >CVideoSourceDepacketizer::MakeStreamHeader and callees are removed.
> > > > >
> > > > >
> > > > >Files Modified:
> > > > >/datatype/tools/dtdriver/apps/dtdrive/main.cpp
> > > > >/datatype/tools/dtdriver/decoder/common/decslcfn.cpp
> > > > >/datatype/tools/dtdriver/decoder/common/pub/decslcfn.h
> > > > >/datatype/tools/dtdriver/decoder/video/Umakefil
> > > > >/datatype/tools/binwrtr/binarch.cpp
> > > > >/datatype/tools/binwrtr/binarch.h
> > > > >
> > > > >/common/include/hxplugn.h
> > > > >/client/common/container/pub/basehand.h
> > > > >/client/common/container/pub/hxplugin.h
> > > > >
> > > > >/ribosome/build/umakepf/helix-dtdr-local-video-transcode.pfi
> > > > >/ribosome/build/bif-cvs/helix/common/build/BIF/helix.bif
> > > > >
> > > > >New Files:
> > > > >/datatype/tools/dtdriver/decoder/video/vdepacker.cpp
> > > > >/datatype/tools/dtdriver/decoder/video/pub/vdepacker.h
> > > > >
> > > > >/datatype/tools/dtdriver/depacker/video/dlliids.cpp
> > > > >/datatype/tools/dtdriver/depacker/video/rvdepack.cpp
> > > > >/datatype/tools/dtdriver/depacker/video/rvdepack.ver
> > > > >/datatype/tools/dtdriver/depacker/video/rvdepackdll.cpp
> > > > >/datatype/tools/dtdriver/depacker/video/umakedll
> > > > >/datatype/tools/dtdriver/depacker/video/Umakefil
> > > > >/datatype/tools/dtdriver/depacker/video/umakelib
> > > > >/datatype/tools/dtdriver/depacker/video/win32.pcf
> > > > >/datatype/tools/dtdriver/depacker/video/pub/rvdepack.h
> > > > >/datatype/tools/dtdriver/depacker/video/platform/win/depackhdr.rc
> > > > >
> > > > >Image Size and Heap Use impact:
> > > > >Size of dtdr increases slightly when HELIX_FEATURE_DTDR_VIDEO_DEPACKER
> > > > >is defined. The rvdepacker plugin dll is about 60KB on windows.
> > > > >
> > > > >Platforms and Profiles Affected:
> > > > >dtdr video profiles on all platforms. tested on windows and x86-linux.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Datatype-dev mailing list
> > > > >Datatype-dev@helixcommunity.org
> > > > >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> > > >
> > > >
> >
> >
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From rgammon at real.com Mon Dec 13 14:45:40 2004
From: rgammon at real.com (Ryan Gammon)
Date: Mon Dec 13 14:47:38 2004
Subject: [datatype-dev] id3lib
Message-ID: <41BE1B94.4080206@real.com>
The building of id3lib is failing on windows.
This is a vs issue, and an exceptions not
being enabled issue.
Do I add /EHsc to my windows .cf file?
--
Ryan Gammon
rgammon@real.com
Developer for Helix Player
https://player.helixcommunity.org
From jgordon at real.com Mon Dec 13 15:18:29 2004
From: jgordon at real.com (Jamie Gordon)
Date: Mon Dec 13 15:18:21 2004
Subject: [datatype-dev] Codec suffixes
In-Reply-To: <1102974880.31567.230.camel@localhost.localdomain>
References: <41BE0DA2.5000402@real.com>
<1102974880.31567.230.camel@localhost.localdomain>
Message-ID: <41BE2345.9090609@real.com>
I don't think there's much the installer script could feasibly do.
There may be a build system method it could use instead of its own,
(which just appends the platform.dll_ext to the dll name) but that
would just create a dll name based on the installer project settings -
which won't be right for all the DLLs if they are not all the same, as
indicated here.
The installer doesn't know if a particular DLL was built with an
option to use versioning (or whatever caused this to happen for just
a select few DLLs), it would have to go through all the motions of
parsing the Umakefil and pcfs and all for the module to be able to
figure that out.
Even if it were to just try both ways (versioned and unversioned), in
order to get the right version to add to a given dll name it would
have to parse the .ver file for that module.
Probably simpler to just specify the versioned name for only those
DLLs that need it. Or get rid of the versioning in these DLL names
if it's not necessary!
Jamie
Nicholas Hart wrote:
> not sure about that inconsistency on windows, but it's possible we could
> change the installer to be a little more robust on windows. i think
> there's some way the installer scripts can use ribosome to obtain the
> actual filename as opposed to having to guess it (or we could change it
> to guess smarter.
>
>
> On Mon, 2004-12-13 at 13:46 -0800, Ryan Gammon wrote:
>
>>Hi all,
>>
>>I notice on windows I get a suffix of 32100 on some dll's, for example:
>>cook32100.dll
>>
>>Some don't have this, eg:
>>atrc.dll
>>
>>On linux, these are cook.so, atrc.so
>>
>>This is confusing the installer, which isn't expecting the suffixes.
>>Should these suffixes be there?
From nhart at real.com Mon Dec 13 17:08:42 2004
From: nhart at real.com (Nicholas Hart)
Date: Mon Dec 13 17:08:46 2004
Subject: [datatype-dev] id3lib
In-Reply-To: <41BE1B94.4080206@real.com>
References: <41BE1B94.4080206@real.com>
Message-ID: <1102986522.31567.260.camel@localhost.localdomain>
There's a similar issue on Linux. It only gives a warning for the
header but fails to link because of exceptions. I hadn't gotten around
to dealing with this yet, but maybe we can kill 2 birds w/1 stone here.
On Mon, 2004-12-13 at 14:45 -0800, Ryan Gammon wrote:
> The building of id3lib is failing on windows.
>
> This is a vs issue, and an exceptions not
> being enabled issue.
>
> Do I add /EHsc to my windows .cf file?
>
From hfrederickson at real.com Mon Dec 13 18:01:03 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Mon Dec 13 17:56:27 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
References: <5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
Message-ID: <1102989662.1088.380.camel@localhost.localdomain>
On Mon, 2004-12-13 at 14:36, Eric Hyche wrote:
> >I have one other question... I'd like to get some comments on the
> >location of the new depacker directory tree. Currently, I have it here:
> >
> >/datatype/tools/dtdriver/depacker/video
>
> >But since it really is a separate component from the dtdrive engine and
> >app, I thought perhaps it should go here:
> >
> >/datatype/tools/depacker/video
>
> Hmmmm... this is a component that uses RVXPayloadFormat, which is
> defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
> implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
> (restricted). So since we define RVXPayloadFormat in the public
> tree, it should be fine to put it there. I would probably
> put it at
>
> datatype/rm/video/common
>
> and put the header file in datatype/rm/video/common/pub.
In principle, this sounds good, but I'm concerned that the rv
depacketizer plugin, which is really only intended to be used by dtdrive
source handlers, would create some confusion placed in with the general
purpose client datatypes code, which really focuses more on renderers as
plugins and depacketizers as component libraries.
Also, there would be a bit of overloading, because over in
datatype-restricted/rm/video/common, we have dbg and rel directories
containing rvcomlib.lib. Adding a depacker tree here seems a bit messy,
even if it is all in the public area.
Do you agree? Milko, what are your thoughts on this?
Thanks,
-Hans
From milko at real.com Mon Dec 13 20:27:51 2004
From: milko at real.com (milko)
Date: Mon Dec 13 20:27:58 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <1102989662.1088.380.camel@localhost.localdomain>
References: <5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
Message-ID: <5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
It should be placed in datatype/rm/video/payload .
I do not see a conflict with existing code.
This simply creates plugin incarnation of RV depacketizer.
datatype/tools directory is not appropriate for any datatype specific code.
The binwrtr is arguably not a datatype but simply a binary dumping tool.
The generic depacker source handler class (part of dtdrive) should go into
datatype/tools/dtdriver/decoder/video since it is treated as decoder function.
Thanks,
Milko
At 06:01 PM 12/13/2004, Hans Frederickson wrote:
>On Mon, 2004-12-13 at 14:36, Eric Hyche wrote:
> > >I have one other question... I'd like to get some comments on the
> > >location of the new depacker directory tree. Currently, I have it here:
> > >
> > >/datatype/tools/dtdriver/depacker/video
> >
> > >But since it really is a separate component from the dtdrive engine and
> > >app, I thought perhaps it should go here:
> > >
> > >/datatype/tools/depacker/video
> >
> > Hmmmm... this is a component that uses RVXPayloadFormat, which is
> > defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
> > implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
> > (restricted). So since we define RVXPayloadFormat in the public
> > tree, it should be fine to put it there. I would probably
> > put it at
> >
> > datatype/rm/video/common
> >
> > and put the header file in datatype/rm/video/common/pub.
>
>In principle, this sounds good, but I'm concerned that the rv
>depacketizer plugin, which is really only intended to be used by dtdrive
>source handlers, would create some confusion placed in with the general
>purpose client datatypes code, which really focuses more on renderers as
>plugins and depacketizers as component libraries.
>
>Also, there would be a bit of overloading, because over in
>datatype-restricted/rm/video/common, we have dbg and rel directories
>containing rvcomlib.lib. Adding a depacker tree here seems a bit messy,
>even if it is all in the public area.
>
>Do you agree? Milko, what are your thoughts on this?
>
>Thanks,
>-Hans
From ehyche at real.com Tue Dec 14 05:40:31 2004
From: ehyche at real.com (Eric Hyche)
Date: Tue Dec 14 05:40:36 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
References: <1102989662.1088.380.camel@localhost.localdomain>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214083501.021b8d00@mailone.real.com>
There is currently no datatype/rm/video/payload. There
is a datatype-restricted/rm/video/payload, which is
where the CRVUnpack and the RVXPayloadFormat classes
live .cpp files live. However, the .h file for
RVXPayloadFormat lives in datatype/rm/video/common/pub
for some reason. That was why I suggested putting it
in datatype/rm/video/common.
However, I see Han's point. datatype/rm/video/common
(and any other /common directories, for that matter) are
generally considered to be static libs. It sound like this
is going to build into a dll (is that correct?).
If so, then I agree that we should create a new directory
called datatype/rm/video/payload and put it in there. If we
do create datatype/rm/video/payload, then we should eventually
move datatype/rm/video/common/pub/rvxpyld.h into
datatype/rm/video/payload/pub.
Eric
At 08:27 PM 12/13/2004 -0800, milko wrote:
>It should be placed in datatype/rm/video/payload .
>I do not see a conflict with existing code.
>This simply creates plugin incarnation of RV depacketizer.
>
>datatype/tools directory is not appropriate for any datatype specific code.
>The binwrtr is arguably not a datatype but simply a binary dumping tool.
>
>The generic depacker source handler class (part of dtdrive) should go into
>datatype/tools/dtdriver/decoder/video since it is treated as decoder function.
>
>Thanks,
>Milko
>
>At 06:01 PM 12/13/2004, Hans Frederickson wrote:
>>On Mon, 2004-12-13 at 14:36, Eric Hyche wrote:
>> > >I have one other question... I'd like to get some comments on the
>> > >location of the new depacker directory tree. Currently, I have it here:
>> > >
>> > >/datatype/tools/dtdriver/depacker/video
>> >
>> > >But since it really is a separate component from the dtdrive engine and
>> > >app, I thought perhaps it should go here:
>> > >
>> > >/datatype/tools/depacker/video
>> >
>> > Hmmmm... this is a component that uses RVXPayloadFormat, which is
>> > defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
>> > implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
>> > (restricted). So since we define RVXPayloadFormat in the public
>> > tree, it should be fine to put it there. I would probably
>> > put it at
>> >
>> > datatype/rm/video/common
>> >
>> > and put the header file in datatype/rm/video/common/pub.
>>
>>In principle, this sounds good, but I'm concerned that the rv
>>depacketizer plugin, which is really only intended to be used by dtdrive
>>source handlers, would create some confusion placed in with the general
>>purpose client datatypes code, which really focuses more on renderers as
>>plugins and depacketizers as component libraries.
>>
>>Also, there would be a bit of overloading, because over in
>>datatype-restricted/rm/video/common, we have dbg and rel directories
>>containing rvcomlib.lib. Adding a depacker tree here seems a bit messy,
>>even if it is all in the public area.
>>
>>Do you agree? Milko, what are your thoughts on this?
>>
>>Thanks,
>>-Hans
>
>
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From ehodge at real.com Tue Dec 14 09:50:57 2004
From: ehodge at real.com (Erik Hodge)
Date: Tue Dec 14 09:51:05 2004
Subject: [datatype-dev] CR-Client: adds prog dnld QI passthrough to
FileswitcherPassthrough
Message-ID: <5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
Synopsis: adds prog dnld QI passthrough to RileswitcherPassthrough
Overview:
If QTCONFIG_FSWITCHER was not defined, progressive-download
status-reporting interfaces were not being exposed. In that
case, CFileSwitcherPassthrough is used instead of CFileSwitcher,
and the former did not pass along QI's for
IID_IHXMediaBytesToMediaDur and for IID_IHXPDStatusMgr to
its FileResponse.
Files Modified:
/cvsroot/datatype/mp4/fileformat/fswtchr_passthrough.cpp
Image Size and Heap Use impact:
+a few bytes image
The diff:
Index: fswtchr_passthrough.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/fswtchr_passthrough.cpp,v
retrieving revision 1.5
diff -U10 -r1.5 fswtchr_passthrough.cpp
--- fswtchr_passthrough.cpp 10 Oct 2003 21:57:35 -0000 1.5
+++ fswtchr_passthrough.cpp 14 Dec 2004 17:36:14 -0000
@@ -32,20 +32,23 @@
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
/****************************************************************************
* Includes
*/
#include "fswtchr_passthrough.h"
#include "hxassert.h"
#include "qtffrefcounter.h"
+#if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS)
+#include "hxprdnld.h" // IHXMediaBytesToMediaDur, IHXPDStatusMgr
+#endif /* #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS) */
/****************************************************************************
* Class CFileSwitcherPassthrough
*/
/****************************************************************************
* Constructor/Destructor
*/
CFileSwitcherPassthrough::CFileSwitcherPassthrough(void)
: m_pFileObject(NULL)
@@ -386,20 +389,39 @@
AddRef();
*ppvObj = this;
return HXR_OK;
}
else if (IsEqualIID(riid, IID_IHXThreadSafeMethods))
{
AddRef();
*ppvObj = (IHXThreadSafeMethods*) this;
return HXR_OK;
}
+
+#if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS)
+ else if (IsEqualIID(riid, IID_IHXMediaBytesToMediaDur))
+ {
+ if (m_pResponse)
+ {
+ return m_pResponse->QueryInterface(IID_IHXMediaBytesToMediaDur,
+ ppvObj);
+ }
+ }
+ else if (m_pResponse && IsEqualIID(riid, IID_IHXPDStatusMgr))
+ {
+ if (m_pResponse)
+ {
+ return m_pResponse->QueryInterface(IID_IHXPDStatusMgr,
+ ppvObj);
+ }
+ }
+#endif /* #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS). */
*ppvObj = NULL;
return HXR_NOINTERFACE;
}
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::AddRef
//
From tmarshall at helixcommunity.org Tue Dec 14 10:17:30 2004
From: tmarshall at helixcommunity.org (Tom Marshall)
Date: Tue Dec 14 10:25:05 2004
Subject: [datatype-dev] CR-Client: adds prog dnld QI passthrough to
FileswitcherPassthrough
In-Reply-To: <5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
References: <5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
Message-ID: <20041214181730.GA14673@real.com>
> +#if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS)
> + else if (IsEqualIID(riid, IID_IHXMediaBytesToMediaDur))
> + {
> + if (m_pResponse)
> + {
> + return m_pResponse->QueryInterface(IID_IHXMediaBytesToMediaDur,
> + ppvObj);
> + }
> + }
> + else if (m_pResponse && IsEqualIID(riid, IID_IHXPDStatusMgr))
> + {
> + if (m_pResponse)
> + {
> + return m_pResponse->QueryInterface(IID_IHXPDStatusMgr,
> + ppvObj);
> + }
> + }
> +#endif /* #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS). */
I'm pretty sure this is a violation of COM rules. If you QI down to one of
these interfaces, you can't QI back to the original. I've always assumed
that we stick as close to COM as possible. Do we care about this particular
rule?
Also note m_pResponse is checked twice in the second block.
--
Nothing will dispel enthusiasm like a small admission fee.
-- Kim Hubbard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041214/855f8193/attachment.bin
From hfrederickson at real.com Tue Dec 14 11:54:43 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Tue Dec 14 11:50:09 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
References: <5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
Message-ID: <1103054083.1088.581.camel@localhost.localdomain>
On Mon, 2004-12-13 at 20:27, milko wrote:
> It should be placed in datatype/rm/video/payload .
> I do not see a conflict with existing code.
> This simply creates plugin incarnation of RV depacketizer.
This looks ok for video. But looking ahead to the creation of a RA
depacketizer plugin, I see that the corresponding audio directory is
already in use:
/datatype/rm/audio/payload
The CVBRSimpleDepacketizer lives there. I think it would be nice if the
RA and RV depacketizer plugins were located symmetrically in the source
tree, and I'm not sure we want to overload the audio/payload directory
with multiple components, at least when they are different types of
components (plugin dll vs. static lib).
Since the depacketizer I've created is a special purpose plugin similar
to a renderer, why not give it a clearly named location, like:
/datatype/rm/video/depacker
or
/datatype/rm/video/depacketizer
??
The corresponding locations for an audio plugin are also available. If
you want to push the depacker a bit further up the tree, perhaps these:
/datatype/rm/video/payload/depacker
or
/datatype/rm/video/payload/depacketizer
??
Thanks,
-Hans
> datatype/tools directory is not appropriate for any datatype specific code.
> The binwrtr is arguably not a datatype but simply a binary dumping tool.
>
> The generic depacker source handler class (part of dtdrive) should go into
> datatype/tools/dtdriver/decoder/video since it is treated as decoder function.
>
> Thanks,
> Milko
>
> At 06:01 PM 12/13/2004, Hans Frederickson wrote:
> >On Mon, 2004-12-13 at 14:36, Eric Hyche wrote:
> > > >I have one other question... I'd like to get some comments on the
> > > >location of the new depacker directory tree. Currently, I have it here:
> > > >
> > > >/datatype/tools/dtdriver/depacker/video
> > >
> > > >But since it really is a separate component from the dtdrive engine and
> > > >app, I thought perhaps it should go here:
> > > >
> > > >/datatype/tools/depacker/video
> > >
> > > Hmmmm... this is a component that uses RVXPayloadFormat, which is
> > > defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
> > > implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
> > > (restricted). So since we define RVXPayloadFormat in the public
> > > tree, it should be fine to put it there. I would probably
> > > put it at
> > >
> > > datatype/rm/video/common
> > >
> > > and put the header file in datatype/rm/video/common/pub.
> >
> >In principle, this sounds good, but I'm concerned that the rv
> >depacketizer plugin, which is really only intended to be used by dtdrive
> >source handlers, would create some confusion placed in with the general
> >purpose client datatypes code, which really focuses more on renderers as
> >plugins and depacketizers as component libraries.
> >
> >Also, there would be a bit of overloading, because over in
> >datatype-restricted/rm/video/common, we have dbg and rel directories
> >containing rvcomlib.lib. Adding a depacker tree here seems a bit messy,
> >even if it is all in the public area.
> >
> >Do you agree? Milko, what are your thoughts on this?
> >
> >Thanks,
> >-Hans
>
>
From ehyche at real.com Tue Dec 14 12:14:18 2004
From: ehyche at real.com (Eric Hyche)
Date: Tue Dec 14 12:14:24 2004
Subject: [datatype-dev] CR-Client: DTDR RealVideo Depacketizer [UPDATED]
In-Reply-To: <1103054083.1088.581.camel@localhost.localdomain>
References: <5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210153452.03298fc8@mailone.real.com>
<5.1.0.14.2.20041210161256.0333a090@mailone.real.com>
<5.1.0.14.2.20041213172749.00c5eb40@mailone.real.com>
<5.1.0.14.2.20041213200545.02d94b28@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214151233.021d9120@mailone.real.com>
At 11:54 AM 12/14/2004 -0800, Hans Frederickson wrote:
>On Mon, 2004-12-13 at 20:27, milko wrote:
> > It should be placed in datatype/rm/video/payload .
> > I do not see a conflict with existing code.
> > This simply creates plugin incarnation of RV depacketizer.
>
>This looks ok for video. But looking ahead to the creation of a RA
>depacketizer plugin, I see that the corresponding audio directory is
>already in use:
>
>/datatype/rm/audio/payload
>
>The CVBRSimpleDepacketizer lives there. I think it would be nice if the
>RA and RV depacketizer plugins were located symmetrically in the source
>tree, and I'm not sure we want to overload the audio/payload directory
>with multiple components, at least when they are different types of
>components (plugin dll vs. static lib).
>
>Since the depacketizer I've created is a special purpose plugin similar
>to a renderer, why not give it a clearly named location, like:
>
>/datatype/rm/video/depacker
>or
>/datatype/rm/video/depacketizer
>
>??
>
>The corresponding locations for an audio plugin are also available. If
>you want to push the depacker a bit further up the tree, perhaps these:
>
>/datatype/rm/video/payload/depacker
>or
>/datatype/rm/video/payload/depacketizer
I like putting a new directory under datatype/rm/video/payload.
And it might be nice to give it a name that indicates it's a
plugin versus a static lib.
How about datatype/rm/video/payload/depackpln
or datatype/rm/video/payload/depack_plugin?
Eric
>??
>
>Thanks,
>-Hans
>
>
> > datatype/tools directory is not appropriate for any datatype specific code.
> > The binwrtr is arguably not a datatype but simply a binary dumping tool.
> >
> > The generic depacker source handler class (part of dtdrive) should go into
> > datatype/tools/dtdriver/decoder/video since it is treated as decoder
> function.
> >
> > Thanks,
> > Milko
> >
> > At 06:01 PM 12/13/2004, Hans Frederickson wrote:
> > >On Mon, 2004-12-13 at 14:36, Eric Hyche wrote:
> > > > >I have one other question... I'd like to get some comments on the
> > > > >location of the new depacker directory tree. Currently, I have it
> here:
> > > > >
> > > > >/datatype/tools/dtdriver/depacker/video
> > > >
> > > > >But since it really is a separate component from the dtdrive
> engine and
> > > > >app, I thought perhaps it should go here:
> > > > >
> > > > >/datatype/tools/depacker/video
> > > >
> > > > Hmmmm... this is a component that uses RVXPayloadFormat, which is
> > > > defined in datatype/rm/video/common/pub/rvxpyld.h (public) but
> > > > implemented in datatype-restricted/rm/video/payload/rvxpyld.cpp
> > > > (restricted). So since we define RVXPayloadFormat in the public
> > > > tree, it should be fine to put it there. I would probably
> > > > put it at
> > > >
> > > > datatype/rm/video/common
> > > >
> > > > and put the header file in datatype/rm/video/common/pub.
> > >
> > >In principle, this sounds good, but I'm concerned that the rv
> > >depacketizer plugin, which is really only intended to be used by dtdrive
> > >source handlers, would create some confusion placed in with the general
> > >purpose client datatypes code, which really focuses more on renderers as
> > >plugins and depacketizers as component libraries.
> > >
> > >Also, there would be a bit of overloading, because over in
> > >datatype-restricted/rm/video/common, we have dbg and rel directories
> > >containing rvcomlib.lib. Adding a depacker tree here seems a bit messy,
> > >even if it is all in the public area.
> > >
> > >Do you agree? Milko, what are your thoughts on this?
> > >
> > >Thanks,
> > >-Hans
> >
> >
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From ehodge at real.com Tue Dec 14 13:17:58 2004
From: ehodge at real.com (Erik Hodge)
Date: Tue Dec 14 13:23:25 2004
Subject: [datatype-dev] CR-Client: adds prog dnld QI passthrough to
FileswitcherPassthrough
In-Reply-To: <20041214181730.GA14673@real.com>
References: <5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
<5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214131144.0210b348@mailone.real.com>
At 10:17 AM 12/14/2004 -0800, Tom Marshall wrote:
> > +#if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS)
> > + else if (IsEqualIID(riid, IID_IHXMediaBytesToMediaDur))
> > + {
> > + if (m_pResponse)
> > + {
> > + return m_pResponse->QueryInterface(IID_IHXMediaBytesToMediaDur,
> > + ppvObj);
> > + }
> > + }
> > + else if (m_pResponse && IsEqualIID(riid, IID_IHXPDStatusMgr))
> > + {
> > + if (m_pResponse)
> > + {
> > + return m_pResponse->QueryInterface(IID_IHXPDStatusMgr,
> > + ppvObj);
> > + }
> > + }
> > +#endif /* #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS). */
>
>I'm pretty sure this is a violation of COM rules. If you QI down to one of
>these interfaces, you can't QI back to the original. I've always assumed
>that we stick as close to COM as possible. Do we care about this particular
>rule?
Apparently I don't care about it. After a few minutes of
thinking about it, I'm not sure how to redo this to avoid
the transgression without a lot more code. There is some
precedent in at least several modules of the client code,
although I realize that is not a license to break the rule.
>Also note m_pResponse is checked twice in the second block.
Ah, yes. I removed the "m_pResponse && " instead of the
inner check to avoid cascading through the other elses if
the IID matches.
Thanks,
- Erik
From ehyche at real.com Tue Dec 14 13:32:10 2004
From: ehyche at real.com (Eric Hyche)
Date: Tue Dec 14 13:32:15 2004
Subject: [datatype-dev] CR-Client: Build old avi fileformat both as lib and
dll
Message-ID: <5.1.0.14.2.20041214162350.021d9120@mailone.real.com>
Synopsis: Build old avi fileformat both as lib and dll
Description: On the client, we currently only build the "old"
AVI fileformat (datatype_rn/avi/fileformat) as a lib
and then link it into vidplin (datatype_rn/group/video).
This one-liner change will cause it to now be built
as both a dll and a lib.
cIndex: Umakefil
===================================================================
RCS file: /home/helixprvt/datatype_rn/avi/fileformat/Umakefil,v
retrieving revision 1.4
diff -u -w -u -w -r1.4 Umakefil
--- Umakefil vs diff: Diffing platform
cvs diff: Diffing platform/mac
cvs diff: Diffing platform/win
cvs diff: Diffing pub
28 Feb 2003 21:30:08 -0000 1.4
+++ Umakefil 14 Dec 2004 21:23:34 -0000
@@ -5,4 +5,4 @@
if project.IsDefined("HELIX_FEATURE_SERVER"):
MultiTargetMake("aviffdll")
else:
- MultiTargetMake("avifflib")
+ MultiTargetMake("avifflib", "aviffdll")
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From liamm at real.com Tue Dec 14 13:45:22 2004
From: liamm at real.com (Liam Murray)
Date: Tue Dec 14 13:47:30 2004
Subject: [datatype-dev] CR-Client: Build old avi fileformat both as
lib and dll
In-Reply-To: <5.1.0.14.2.20041214162350.021d9120@mailone.real.com>
References: <5.1.0.14.2.20041214162350.021d9120@mailone.real.com>
Message-ID: <6.1.1.1.0.20041214134455.044c02a8@mailone.real.com>
Looks good.
Liam
At 01:32 PM 12/14/2004, Eric Hyche wrote:
>Synopsis: Build old avi fileformat both as lib and dll
>
>Description: On the client, we currently only build the "old"
> AVI fileformat (datatype_rn/avi/fileformat) as a lib
> and then link it into vidplin (datatype_rn/group/video).
> This one-liner change will cause it to now be built
> as both a dll and a lib.
>
>cIndex: Umakefil
>===================================================================
>RCS file: /home/helixprvt/datatype_rn/avi/fileformat/Umakefil,v
>retrieving revision 1.4
>diff -u -w -u -w -r1.4 Umakefil
>--- Umakefil vs diff: Diffing platform
>cvs diff: Diffing platform/mac
>cvs diff: Diffing platform/win
>cvs diff: Diffing pub
>28 Feb 2003 21:30:08 -0000 1.4
>+++ Umakefil 14 Dec 2004 21:23:34 -0000
>@@ -5,4 +5,4 @@
> if project.IsDefined("HELIX_FEATURE_SERVER"):
> MultiTargetMake("aviffdll")
> else:
>- MultiTargetMake("avifflib")
>+ MultiTargetMake("avifflib", "aviffdll")
>
>
>
>======================================
>M. Eric Hyche (ehyche@real.com)
>Core Technologies
>RealNetworks, Inc.
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From dhedbor at real.com Tue Dec 14 13:45:50 2004
From: dhedbor at real.com (dhedbor@real.com)
Date: Tue Dec 14 13:51:12 2004
Subject: [datatype-dev] CR: Bugfix: Missing dummy method for
ReportDecodedFrame
Message-ID: <87ekhspn8x.fsf@asgard.prognet.com>
Description:
The method CVideoRenderer::ReportDecodedFrame doesn't have a dummy
implementation for when HELIX_FEATURE_STATS isn't defined. This in
turn causes datatype/rm/video/renderer/rvxvdfmt.cpp to not compile.
This patch adds this missing dummy method.
Branches:
HEAD
--
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stats.diff
Type: text/x-patch
Size: 562 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041214/09af4815/stats-0001.bin
From ehyche at real.com Tue Dec 14 13:56:35 2004
From: ehyche at real.com (Eric Hyche)
Date: Tue Dec 14 13:56:40 2004
Subject: [datatype-dev] CR-Client: Build old avi fileformat both as
lib and dll
In-Reply-To: <6.1.1.1.0.20041214134455.044c02a8@mailone.real.com>
References: <5.1.0.14.2.20041214162350.021d9120@mailone.real.com>
<5.1.0.14.2.20041214162350.021d9120@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214165630.021d9120@mailone.real.com>
This is now checked into HEAD.
Eric
At 01:45 PM 12/14/2004 -0800, Liam Murray wrote:
>Looks good.
>
>Liam
>
>At 01:32 PM 12/14/2004, Eric Hyche wrote:
>
>>Synopsis: Build old avi fileformat both as lib and dll
>>
>>Description: On the client, we currently only build the "old"
>> AVI fileformat (datatype_rn/avi/fileformat) as a lib
>> and then link it into vidplin (datatype_rn/group/video).
>> This one-liner change will cause it to now be built
>> as both a dll and a lib.
>>
>>cIndex: Umakefil
>>===================================================================
>>RCS file: /home/helixprvt/datatype_rn/avi/fileformat/Umakefil,v
>>retrieving revision 1.4
>>diff -u -w -u -w -r1.4 Umakefil
>>--- Umakefil vs diff: Diffing platform
>>cvs diff: Diffing platform/mac
>>cvs diff: Diffing platform/win
>>cvs diff: Diffing pub
>>28 Feb 2003 21:30:08 -0000 1.4
>>+++ Umakefil 14 Dec 2004 21:23:34 -0000
>>@@ -5,4 +5,4 @@
>> if project.IsDefined("HELIX_FEATURE_SERVER"):
>> MultiTargetMake("aviffdll")
>> else:
>>- MultiTargetMake("avifflib")
>>+ MultiTargetMake("avifflib", "aviffdll")
>>
>>
>>
>>======================================
>>M. Eric Hyche (ehyche@real.com)
>>Core Technologies
>>RealNetworks, Inc.
>>
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From bmm at optx.com Tue Dec 14 13:57:27 2004
From: bmm at optx.com (Brian Meyerpeter)
Date: Tue Dec 14 13:57:41 2004
Subject: [datatype-dev] Build setup for debugging mac realplayer
Message-ID: <5.2.1.1.0.20041214135633.02872130@mailserv.optx.com>
Hi All,
I am chasing down a random crash and need to debug via the realplayer on
the mac. Can you let me know what target, branch, and settings in the
build menu I should set to build the system for debugging via splay?
Thanks,
Brian
From bobclark at real.com Tue Dec 14 14:24:36 2004
From: bobclark at real.com (Bob Clark)
Date: Tue Dec 14 14:24:41 2004
Subject: [datatype-dev] Build setup for debugging mac realplayer
In-Reply-To: <5.2.1.1.0.20041214135633.02872130@mailserv.optx.com>
Message-ID:
Hi Brian.
I'd use:
BIF branch hxclient_1_2_2_neptune
target splay
profile helix-client-all-defines
--Bob
On Tuesday, December 14, 2004, at 01:57 PM, Brian Meyerpeter wrote:
> Hi All,
>
> I am chasing down a random crash and need to debug via the realplayer
> on the mac. Can you let me know what target, branch, and settings in
> the build menu I should set to build the system for debugging via
> splay?
>
> Thanks,
>
> Brian
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From ehodge at real.com Tue Dec 14 15:10:35 2004
From: ehodge at real.com (Erik Hodge)
Date: Tue Dec 14 15:10:45 2004
Subject: [datatype-dev] CR-Client: adds prog dnld QI passthrough to
FileswitcherPassthrough
In-Reply-To: <5.1.0.14.2.20041214131144.0210b348@mailone.real.com>
References: <20041214181730.GA14673@real.com>
<5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
<5.1.0.14.2.20041214093946.0215e9c8@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214150813.021d18a8@mailone.real.com>
Please provide your objections if you have any. I will check
this in at 17:00PST today if there are none by then as a
customer needs this change.
Thanks,
- Erik
At 01:17 PM 12/14/2004 -0800, Erik Hodge wrote:
>At 10:17 AM 12/14/2004 -0800, Tom Marshall wrote:
>> > +#if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS)
>> > + else if (IsEqualIID(riid, IID_IHXMediaBytesToMediaDur))
>> > + {
>> > + if (m_pResponse)
>> > + {
>> > + return m_pResponse->QueryInterface(IID_IHXMediaBytesToMediaDur,
>> > + ppvObj);
>> > + }
>> > + }
>> > + else if (m_pResponse && IsEqualIID(riid, IID_IHXPDStatusMgr))
>> > + {
>> > + if (m_pResponse)
>> > + {
>> > + return m_pResponse->QueryInterface(IID_IHXPDStatusMgr,
>> > + ppvObj);
>> > + }
>> > + }
>> > +#endif /* #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS). */
>>
>>I'm pretty sure this is a violation of COM rules. If you QI down to one of
>>these interfaces, you can't QI back to the original. I've always assumed
>>that we stick as close to COM as possible. Do we care about this particular
>>rule?
>
>Apparently I don't care about it. After a few minutes of
>thinking about it, I'm not sure how to redo this to avoid
>the transgression without a lot more code. There is some
>precedent in at least several modules of the client code,
>although I realize that is not a license to break the rule.
>
>>Also note m_pResponse is checked twice in the second block.
>
>Ah, yes. I removed the "m_pResponse && " instead of the
>inner check to avoid cascading through the other elses if
>the IID matches.
>
>Thanks,
>
> - Erik
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From milko at real.com Tue Dec 14 16:40:27 2004
From: milko at real.com (milko)
Date: Tue Dec 14 16:40:41 2004
Subject: [datatype-dev] CR-Client: standalone rgb renderer
Message-ID: <5.1.0.14.2.20041214163523.04e1a738@mailone.real.com>
Synopsis: Created a dll build of rgb renderer plugin
Overview:
Previously rgb renderer built only into a library which
was linked into the group video plugin dll.
This modification creates rgb renderer plugin standalone
dll in addition to the library.
Files Modified:
/common/build/BIF/helix.bif
/datatype/rgb/renderer/Umakefil
File Added:
/datatype/rgb/renderer/guids.cpp
/datatype/rgb/renderer/rgbrenddll.cpp
/datatype/rgb/renderer/libumakefil
/datatype/rgb/renderer/dllumakefil
Image Size and Heap Use impact:
None.
Platforms and Profiles Affected:
all platforms, all profiles
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/rgb/renderer/Umakefil,v
retrieving revision 1.1
diff -u -r1.1 Umakefil
--- Umakefil 21 Jan 2004 20:22:28 -0000 1.1
+++ Umakefil 14 Dec 2004 22:10:40 -0000
@@ -37,22 +37,7 @@
UmakefileVersion(2,1)
-project.AddModuleIncludes("common/include",
- "common/container/pub",
- "common/dbgtool/pub",
- "common/system/pub",
- "common/util/pub/",
- "common/runtime/pub",
- "client/include",
- "datatype/common/util/pub",
- "datatype/common/container/pub",
- "datatype/common/vidrend/pub",
- "video/include",
- "video/colconverter/pub")
+MultiTargetMake("libumakefil",
+ "dllumakefil")
-project.AddSources("rgbvideo.cpp",
- "rgbvidfmt.cpp")
-LibraryTarget("rgbrendlib")
-
-DependTarget()
Index: win32.pcf
===================================================================
RCS file: /cvsroot/datatype/rgb/renderer/win32.pcf,v
retrieving revision 1.1
diff -u -r1.1 win32.pcf
--- win32.pcf 21 Jan 2004 20:22:28 -0000 1.1
+++ win32.pcf 14 Dec 2004 22:10:40 -0000
@@ -35,7 +35,7 @@
# ***** END LICENSE BLOCK *****
#
-project.AddIncludes(GetSDKPath("dxsdk") + "/include")
+# project.AddIncludes(GetSDKPath("dxsdk") + "/include")
project.AddSystemLibraries("version.lib",
"wsock32.lib",
Index: helix.bif
===================================================================
RCS file: /cvsroot/common/build/BIF/helix.bif,v
retrieving revision 1.494
diff -u -r1.494 helix.bif
--- helix.bif 8 Dec 2004 22:42:08 -0000 1.494
+++ helix.bif 14 Dec 2004 22:30:38 -0000
@@ -3573,19 +3573,23 @@
common_include
- common_runtime
- common_dbgtool
- common_container
- common_system
- common_util
client_include
- datatype_common_util
- datatype_common_container
- datatype_common_vidrend
video_include
video_colconverter
- dxsdk_name
+
+
+ datatype_common_vidrend
+ datatype_common_container
+ datatype_common_util
+ video_vidutil
+ common_log_logutil
+ common_runtime
+ common_dbgtool
+ common_util
+ common_container
+ common_system
+
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,2)
project.AddModuleIncludes("common/include",
"client/include",
"datatype/common/container/pub")
project.AddModuleLibraries("datatype/rgb/renderer[rgbrendlib]",
"datatype/common/vidrend[vidrend]",
"datatype/common/container[dtcomcontlib]",
"datatype/common/util[dtutillib]",
"video/vidutil[vidutillib]",
"common/log/logutil[logutillib]",
"common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"common/util[utillib]",
"common/container[contlib]",
"common/system[syslib]")
project.AddSources("rgbrenddll.cpp",
"guids.cpp")
project.ExportFunction("RMACreateInstance",
"IUnknown** ppObj",
"common/include",
"hxcom.h")
project.ExportFunction("CanUnload2", "void")
DLLTarget("rgbrender")
DependTarget()
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0 and Exhibits.
* REALNETWORKS CONFIDENTIAL--NOT FOR DISTRIBUTION IN SOURCE CODE FORM
* Portions Copyright (c) 1995-2002 RealNetworks, Inc.
* All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Community Source
* License Version 1.0 (the "RCSL"), including Attachments A though H,
* all available at http://www.helixcommunity.org/content/rcsl.
* You may also obtain the license terms directly from RealNetworks.
* You may not use this file except in compliance with the RCSL and
* its Attachments. There are no redistribution rights for the source
* code of this file. Please see the applicable RCSL for the rights,
* obligations and limitations governing use of the contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* https://rarvcode-tck.helixcommunity.org
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#define INITGUID 1
#include "hxtypes.h"
#include "hxwintyp.h"
#include "hxresult.h"
#include "hxcom.h"
#include "hxevent.h"
#include "hxcomm.h"
#include "ihxpckts.h"
#include "hxcore.h"
#include "hxrendr.h"
#include "hxhyper.h"
#include "hxplugn.h"
#include "hxasm.h"
#include "hxupgrd.h"
#include "hxengin.h"
#include "hxprefs.h"
#include "hxerror.h"
#include "hxwin.h"
#include "hxvsurf.h"
#include "hxvctrl.h"
#include "hxsite2.h"
#include "hxthread.h"
#include "hxmon.h"
#include "hxformt.h"
#include "hxpcmkr.h"
#include "hxdllaccess.h"
#include "hxplayvelocity.h"
#include "ihxtlogsystem.h"
#include "ihxtlogsystemcontext.h"
#undef INITGUID
#if !defined(HELIX_FEATURE_DLLACCESS_CLIENT)
#include "dllpath.h"
ENABLE_DLLACCESS_PATHS(rgbrend);
#endif // HELIX_FEATURE_DLLACCESS_CLIENT
-------------- next part --------------
#
# ***** BEGIN LICENSE BLOCK *****
# Version: RCSL 1.0/RPSL 1.0
#
# Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file, are
# subject to the current version of the RealNetworks Public Source License
# Version 1.0 (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the RealNetworks Community Source License Version 1.0
# (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
# in which case the RCSL will apply. You may also obtain the license terms
# directly from RealNetworks. You may not use this file except in
# compliance with the RPSL or, if you have a valid RCSL with RealNetworks
# applicable to this file, the RCSL. Please see the applicable RPSL or
# RCSL for the rights, obligations and limitations governing use of the
# contents of the file.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the portions
# it created.
#
# This file, and the files included with this file, is distributed and made
# available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
# EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
# INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,1)
project.AddModuleIncludes("common/include",
"common/container/pub",
"common/dbgtool/pub",
"common/system/pub",
"common/util/pub/",
"common/runtime/pub",
"client/include",
"datatype/common/util/pub",
"datatype/common/container/pub",
"datatype/common/vidrend/pub",
"video/include",
"video/colconverter/pub")
project.AddSources("rgbvideo.cpp",
"rgbvidfmt.cpp")
LibraryTarget("rgbrendlib")
DependTarget()
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#include "hxtypes.h"
#include "hxcomm.h"
#include "rgbvideo.h"
STDAPI ENTRYPOINT(HXCREATEINSTANCE)(IUnknown** ppIUnknown)
{
return CRGBVideoRenderer::HXCreateInstance(ppIUnknown);
}
STDAPI ENTRYPOINT(CanUnload2)(void)
{
return CRGBVideoRenderer::CanUnload2();
}
-------------- next part --------------
From ehodge at real.com Tue Dec 14 17:15:34 2004
From: ehodge at real.com (Erik Hodge)
Date: Tue Dec 14 17:37:27 2004
Subject: [datatype-dev] CR-Client: standalone rgb renderer
In-Reply-To: <5.1.0.14.2.20041214163523.04e1a738@mailone.real.com>
Message-ID: <5.1.0.14.2.20041214171429.0208fe60@mailone.real.com>
Looks good.
At 04:40 PM 12/14/2004 -0800, milko wrote:
>Synopsis: Created a dll build of rgb renderer plugin
>
>Overview:
> Previously rgb renderer built only into a library which
>was linked into the group video plugin dll.
> This modification creates rgb renderer plugin standalone
>dll in addition to the library.
>
>Files Modified:
>
>/common/build/BIF/helix.bif
>/datatype/rgb/renderer/Umakefil
>
>File Added:
>/datatype/rgb/renderer/guids.cpp
>/datatype/rgb/renderer/rgbrenddll.cpp
>/datatype/rgb/renderer/libumakefil
>/datatype/rgb/renderer/dllumakefil
>
>Image Size and Heap Use impact:
>None.
>
>Platforms and Profiles Affected:
>all platforms, all profiles
>
>
>Index: Umakefil
>===================================================================
>RCS file: /cvsroot/datatype/rgb/renderer/Umakefil,v
>retrieving revision 1.1
>diff -u -r1.1 Umakefil
>--- Umakefil 21 Jan 2004 20:22:28 -0000 1.1
>+++ Umakefil 14 Dec 2004 22:10:40 -0000
>@@ -37,22 +37,7 @@
>
> UmakefileVersion(2,1)
>
>-project.AddModuleIncludes("common/include",
>- "common/container/pub",
>- "common/dbgtool/pub",
>- "common/system/pub",
>- "common/util/pub/",
>- "common/runtime/pub",
>- "client/include",
>- "datatype/common/util/pub",
>- "datatype/common/container/pub",
>- "datatype/common/vidrend/pub",
>- "video/include",
>- "video/colconverter/pub")
>+MultiTargetMake("libumakefil",
>+ "dllumakefil")
>
>-project.AddSources("rgbvideo.cpp",
>- "rgbvidfmt.cpp")
>
>-LibraryTarget("rgbrendlib")
>-
>-DependTarget()
>Index: win32.pcf
>===================================================================
>RCS file: /cvsroot/datatype/rgb/renderer/win32.pcf,v
>retrieving revision 1.1
>diff -u -r1.1 win32.pcf
>--- win32.pcf 21 Jan 2004 20:22:28 -0000 1.1
>+++ win32.pcf 14 Dec 2004 22:10:40 -0000
>@@ -35,7 +35,7 @@
> # ***** END LICENSE BLOCK *****
> #
>
>-project.AddIncludes(GetSDKPath("dxsdk") + "/include")
>+# project.AddIncludes(GetSDKPath("dxsdk") + "/include")
>
> project.AddSystemLibraries("version.lib",
> "wsock32.lib",
>
>Index: helix.bif
>===================================================================
>RCS file: /cvsroot/common/build/BIF/helix.bif,v
>retrieving revision 1.494
>diff -u -r1.494 helix.bif
>--- helix.bif 8 Dec 2004 22:42:08 -0000 1.494
>+++ helix.bif 14 Dec 2004 22:30:38 -0000
>@@ -3573,19 +3573,23 @@
>
>
> common_include
>- common_runtime
>- common_dbgtool
>- common_container
>- common_system
>- common_util
> client_include
>- datatype_common_util
>- datatype_common_container
>- datatype_common_vidrend
> video_include
> video_colconverter
>- dxsdk_name
>
>+
>+
>+ datatype_common_vidrend
>+ datatype_common_container
>+ datatype_common_util
>+ video_vidutil
>+ common_log_logutil
>+ common_runtime
>+ common_dbgtool
>+ common_util
>+ common_container
>+ common_system
>+
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From mgupta at real.com Wed Dec 15 04:30:48 2004
From: mgupta at real.com (mgupta@real.com)
Date: Wed Dec 15 04:30:51 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
Message-ID: <1582.192.168.129.40.1103113848.squirrel@goodfellas.real.com>
Modified by: mgupta@real.com
Reviewed by: ehyche@real.com
Date: 12:15:04
Project: AVI File Format Support
Synopsis:
1. Fixed the problem of video not coming in AVI files when played using
.ram files.
2. AVI code was throwing exception while exiting during playback of
Top_Gear.avi.
3. AVI code was not able to play AVI files having MPG4 video compression.
Fix:
1. 'PacketsSegmented' property was not being set in AVI code. This has
been set now.
2. Memory allocation was not enough while setting the format. This has
been fixed.
3. There was some problem in reading the index table. This required some
changes in AVIIndex.cpp.
Files Modified:
/datatype/avi/fileformat/avistrm.cpp
/datatype/avi/fileformat/aviindx.cpp
Files Added: None
Image Size and Heap Use impact: None
Platforms and Profiles Build Verified: Win32
Platforms and Profiles Functionality verified: Win32
Branch: head
Copyright assignment:
I agree to assign to RealNetworks full copyright ownership of the code
represented by the attached patch. I warrant that I am legally entitled to
grant the copyright assignment and that my contribution does not violate
any law or breach any contract. I understand that RealNetworks may license
this code under RPSL, RCSL, and/or any other license at RealNetworks' sole
discretion.
QA Instructions:
None
-------------- next part --------------
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.5
diff -u -w -r1.5 avistrm.cpp
--- avistrm.cpp 3 Dec 2004 23:40:05 -0000 1.5
+++ avistrm.cpp 15 Dec 2004 06:03:09 -0000
@@ -259,12 +259,6 @@
#define SIZE_OF_QT_VIDEO_HEADER 10
-#ifndef BI_RGB
-// This is defined by a windows header, so define it for non-windows platforms
-#define BI_RGB 0
-#endif
-
-
/////////////////////////////////////////////////////////////////////////
// CAVIStream::CAVIStream
//
@@ -299,6 +293,7 @@
, m_ulTotalBytesRead(0)
, m_ulTotalBytesPacketised(0)
, m_ulSeekTime (0)
+ , m_pFile (NULL)
{
HX_ASSERT_VALID_PTR(m_pOuter);
HX_ASSERT_VALID_PTR(m_pContext);
@@ -451,7 +446,12 @@
return HXR_FAIL;
}
- m_pFormat = new UCHAR[sizeof(WaveInfo)];
+ if (len < sizeof(WaveInfo))
+ {
+ len = sizeof(WaveInfo);
+ }
+
+ m_pFormat = new UCHAR[len];
memcpy(m_pFormat, buf, len);
WaveInfo* bi = (WaveInfo*) m_pFormat;
@@ -686,13 +686,18 @@
INT32 ulMaxChunkSize = m_pIndex->GetMaxChunkSize(m_usStream);
- if (m_bLocalPlayback && ulMaxChunkSize)
+ if (m_bLocalPlayback)
+ {
+ if (ulMaxChunkSize)
{
ulMaxPacketSize = ulMaxChunkSize;
}
+
+ pHeader->SetPropertyULONG32("PacketsSegmented", 0);
+ }
else
{
- pHeader->SetPropertyULONG32("PacketsSegmented", 0);
+ pHeader->SetPropertyULONG32("PacketsSegmented", 1);
}
pHeader->SetPropertyULONG32("SamplesPerSecond", (UINT32) m_fSamplesPerSecond);
-------------- next part --------------
Index: aviindx.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/aviindx.cpp,v
retrieving revision 1.4
diff -u -w -r1.4 aviindx.cpp
--- aviindx.cpp 2 Dec 2004 18:19:33 -0000 1.4
+++ aviindx.cpp 15 Dec 2004 06:01:47 -0000
@@ -831,8 +831,6 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[CAVIFileFormat::GetStream(pEntry->ulChunkId)];
- if (pStream->ulSliceEndOffset == m_pReader->GetOffset() - i*sizeof(idx1Entry))
- {
if ((INT64) pStream->ulSliceEndChunk - pStream->ulNextChunkRequired < MAX_SLICE_SIZE)
{
pStream->bSliceOffsetCapped = FALSE;
@@ -870,11 +868,6 @@
{
pStream->bSliceOffsetCapped = TRUE;
pStream->ulSliceEndOffset = m_pReader->GetOffset() - i*sizeof(idx1Entry);
- }
- }
- else
- {
- pStream->bSliceOffsetCapped = TRUE;
}
for (UINT16 j = 0; j < m_usStreamCount; j++)
From infidel at pakkotoisto.com Wed Dec 15 04:22:09 2004
From: infidel at pakkotoisto.com (infidel)
Date: Wed Dec 15 05:25:42 2004
Subject: [datatype-dev] MP4Fileformat and AVC
Message-ID: <20041215122210.6DDA840ED@apache3.myvisio.com>
Hi,
I'm wondering how mp4 fileformat splits AVC data to be carried with helix
packets? In other words what does a helix packet contain? Is it a nal unit,
several nal units, a frame, what?
Thanks,
-i
From ehyche at real.com Wed Dec 15 05:43:39 2004
From: ehyche at real.com (Eric Hyche)
Date: Wed Dec 15 05:43:41 2004
Subject: [datatype-dev] CR: Bugfix: Missing dummy method for
ReportDecodedFrame
In-Reply-To: <87ekhspn8x.fsf@asgard.prognet.com>
Message-ID: <5.1.0.14.2.20041215084331.021a1a48@mailone.real.com>
Looks good.
Eric
At 01:45 PM 12/14/2004 -0800, dhedbor@real.com wrote:
>Description:
>
>The method CVideoRenderer::ReportDecodedFrame doesn't have a dummy
>implementation for when HELIX_FEATURE_STATS isn't defined. This in
>turn causes datatype/rm/video/renderer/rvxvdfmt.cpp to not compile.
>
>This patch adds this missing dummy method.
>
>Branches:
>
>HEAD
>
>--
>David Hedbor, Software Development Engineer - Real Networks
>Helix Community: http://helixcommunity.org
>Index: datatype/common/vidrend/pub/vidrend.h
>===================================================================
>RCS file: /cvsroot/datatype/common/vidrend/pub/vidrend.h,v
>retrieving revision 1.26
>diff -u -r1.26 vidrend.h
>--- datatype/common/vidrend/pub/vidrend.h 26 Oct 2004 23:25:22
>-0000 1.26
>+++ datatype/common/vidrend/pub/vidrend.h 14 Dec 2004 21:49:22 -0000
>@@ -853,6 +853,11 @@
> return;
> }
>
>+ void ReportDecodedFrame(ULONG32 ulCount = 1)
>+ {
>+ return;
>+ }
>+
> void ReportUpsampledFrame(ULONG32 ulCount = 1)
> {
> return;
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From hfrederickson at real.com Wed Dec 15 13:40:54 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Wed Dec 15 13:36:23 2004
Subject: [datatype-dev] CR-Client: Network byte order output from
RVXPayloadFormat
Message-ID: <1103146853.15845.90.camel@localhost.localdomain>
Synopsis: Add support to RVXPayloadFormat and CRVXHeader classes for
obtaining the RV bitstream header in network byte order.
Overview:
The new realvideo raw format will use network/big-endian byte order for
all the data in the file. The existing RV payload code returns all the
data in native byte order. It is easy to get the bitstream header in
network byte order by just copying the corresponding packed opaque data.
These changes accomplish that.
Files Modified:
/datatype/rm/video/common/pub/rvxpyld.h
/datatype-restricted/rm/video/payload/rvxpyld.cpp
/datatype-restricted/rm/video/payload/rvxhdr.h
/datatype-restricted/rm/video/payload/rvxhdr.cpp
Image Size and Heap Use impact:
Minimal increase in rvx payload and header classes for additional
methods.
Platforms and Profiles Affected:
all platforms and profiles. tested on windows and x86-linux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype-restricted_rm_video_payload_rvxhdr.cpp.diff
Type: text/x-patch
Size: 992 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041215/63961e57/datatype-restricted_rm_video_payload_rvxhdr.cpp.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype-restricted_rm_video_payload_rvxhdr.h.diff
Type: text/x-patch
Size: 804 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041215/63961e57/datatype-restricted_rm_video_payload_rvxhdr.h.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype-restricted_rm_video_payload_rvxpyld.cpp.diff
Type: text/x-patch
Size: 1829 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041215/63961e57/datatype-restricted_rm_video_payload_rvxpyld.cpp.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_rm_video_common_pub_rvxpyld.h.diff
Type: text/x-patch
Size: 830 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041215/63961e57/datatype_rm_video_common_pub_rvxpyld.h.bin
From bmm at optx.com Wed Dec 15 20:18:11 2004
From: bmm at optx.com (Brian Meyerpeter)
Date: Wed Dec 15 20:18:24 2004
Subject: [datatype-dev] Subrect Region 1x1 causing crash?
Message-ID: <5.2.1.1.0.20041215201128.01b3f890@mailserv.optx.com>
Hi All,
I have been debugging a crash on the mac realplayer with our datatype. We
are using the Subrect system because we only paint a portion of the screen.
It appears that I get a consistent crash when we pass in an hregion with
the hbox parameter being set to a rectangle with size 1x1.
We are making a call:
Site->SubRectDamageRegion(&hregion);
And then there are 4 RMACreateInstance's on top of that when doing a
backtrace in gdb.
The actual HBOX params in the region are x1:425, y1:560 x2:426 y2:561
My inclination is to force my update larger in the case just to work
around. I am not positive this will work and will try it.
If that turns out not to help, then I'll post back.
Just an FYI,
Brian
From bmm at optx.com Thu Dec 16 00:12:28 2004
From: bmm at optx.com (Brian Meyerpeter)
Date: Thu Dec 16 00:12:41 2004
Subject: [datatype-dev] More on the 1x1 Crash
Message-ID: <5.2.1.1.0.20041216000950.02843df8@mailserv.optx.com>
Hi All,
I am thinking this crash is due to my accessing it from an external thread
that is outside the player. But now I am wondering how to get concurrency.
We have a separate thread that makes changes to the master bitmap, then we
call the site's updateregion and do a forceredraw. This gives us great
granularity instead of using a hook into ontimesync etc..
Any ideas for adding concurrency to the site so that we can update the
subrect region in a safe way is appreciated,
Thanks,
Brian
From bobclark at real.com Thu Dec 16 06:30:00 2004
From: bobclark at real.com (Bob Clark)
Date: Thu Dec 16 06:30:04 2004
Subject: [datatype-dev] More on the 1x1 Crash
In-Reply-To: <5.2.1.1.0.20041216000950.02843df8@mailserv.optx.com>
Message-ID:
Hi Brian.
The site's Mac drawing code, internally, needs to be run on the main
app thread (actually, any cooperative thread, but 99.999% of the time
that means the main app thread).
But it's designed that if ForceRedraw() is called from a different
thread it will itself set up a callback on the main app thread and
internally call ForceRedraw later.
(This logic is largely in macsite.cpp's _ShouldEnterForceRedraw()
function.)
Updating the region should be threadsafe, but from your description in
your earlier email it looks like it's not. I'm looking at that now --
if I stumble across anything suspicious I'll pass it on.
Does it always crash, instantly, the first time you call
SubRectDamageRegion from a non-main-app (preemptive) thread?
If it turns out that SubRectDamageRegion really truly can't be called
from a preemptive thread, you may be forced into a sledge hammer
approach, and duplicate some of _ShouldEnterForceRedraw's logic in your
own code, to ensure that SubRectDamageRegion is only called from the
main app thread. Setting up a CFTimer isn't too tough, but
synchronizing the data might be more challenging.
What you could try building a debug version of vidsite.bundle to get a
better backtrace. (You'll want to save off the original
vidsite.bundle.) But I was just able to build a debug vidsite using the
following parameters in the build system:
[0] Set BIF branch (helix)
[1] Set Target(s) (video_site)
[2] Set Profile (helix-client-all-defines)
[3] run: build
--Bob
On Thursday, December 16, 2004, at 12:12 AM, Brian Meyerpeter wrote:
> I am thinking this crash is due to my accessing it from an external
> thread that is outside the player. But now I am wondering how to get
> concurrency.
>
> We have a separate thread that makes changes to the master bitmap,
> then we call the site's updateregion and do a forceredraw. This gives
> us great granularity instead of using a hook into ontimesync etc..
>
> Any ideas for adding concurrency to the site so that we can update the
> subrect region in a safe way is appreciated,
>
> Thanks,
> Brian
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From ehyche at real.com Thu Dec 16 07:07:42 2004
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 16 07:07:46 2004
Subject: [datatype-dev] CR-Client: Network byte order output from
RVXPayloadFormat
In-Reply-To: <1103146853.15845.90.camel@localhost.localdomain>
Message-ID: <5.1.0.14.2.20041216100655.021ca998@mailone.real.com>
These changes look good to me. Works out nice that
the rvxhdr.cpp class already had the bitstream header
in network order anyway...
Eric
At 01:40 PM 12/15/2004 -0800, Hans Frederickson wrote:
>Synopsis: Add support to RVXPayloadFormat and CRVXHeader classes for
>obtaining the RV bitstream header in network byte order.
>
>Overview:
>The new realvideo raw format will use network/big-endian byte order for
>all the data in the file. The existing RV payload code returns all the
>data in native byte order. It is easy to get the bitstream header in
>network byte order by just copying the corresponding packed opaque data.
>These changes accomplish that.
>
>Files Modified:
>/datatype/rm/video/common/pub/rvxpyld.h
>/datatype-restricted/rm/video/payload/rvxpyld.cpp
>/datatype-restricted/rm/video/payload/rvxhdr.h
>/datatype-restricted/rm/video/payload/rvxhdr.cpp
>
>Image Size and Heap Use impact:
>Minimal increase in rvx payload and header classes for additional
>methods.
>
>Platforms and Profiles Affected:
>all platforms and profiles. tested on windows and x86-linux.
>
>
>
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From ehyche at real.com Thu Dec 16 07:40:01 2004
From: ehyche at real.com (Eric Hyche)
Date: Thu Dec 16 07:40:07 2004
Subject: [datatype-dev] Re: [Common-dev] Re: [Helix-dna-dev] Re:
[Helix-server-dev] CR: stat on a directory
In-Reply-To: <5.1.0.14.2.20041215114047.028606b0@mailone.real.com>
References: <5.1.0.14.2.20041215090014.021a1a48@mailone.real.com>
<5.1.0.14.2.20041214184448.02698008@mailone.real.com>
<6.0.0.22.2.20041210112112.01dbd4b8@mailone.real.com>
<6.0.0.22.2.20041210091931.01e57ff0@mailone.real.com>
Message-ID: <5.1.0.14.2.20041216102943.021ca998@mailone.real.com>
[Moving the thread to datatype-dev...]
Here's the relevant code in CFileCreator::StatDone():
============================================================
// A file or directory with that name already exists
if (HXR_OK == status)
{
if (m_FCStatus == FC_CREATING_DIR)
{
if ((ulMode & HX_S_IFDIR) && (!m_bResolveConflict))
{
// If we are creating a directory and the existing object
// is a directory, just leave it alone and return success
m_FCStatus = FC_READY;
m_pOwner->ArchiveDirReady(HXR_OK);
}
else
{
// If we are creating a directory and the existing object
// is a file or a directory that must be moved out of the way,
// rename it and create the directory
hResult = RenameObject(pObject);
// snip ...
}
}
============================================================
So it looks like what we want to happen is for ArchiveDirReady(HXR_OK)
to be called instead of RenameObject(pObject). So for that to happen,
the following has to be TRUE:
(ulMode & HX_S_IFDIR) && (!m_bResolveConflict)
m_bResolveConflict should be easy to check. It is set by the
bResolveConflict argument to CreateArchiveDir(). Is bResolveConflict
FALSE in the call to CreateArchiveDir()?
The other problem could be if the HX_S_IFDIR flag is not set
in the ulMode coming back in the StatDone(). Can you verify
if this is the problem?
Eric
Explanation of working before this change
>For first time CFileCreator::CreateArchiveDir pName is "file::/c:/'
>MemoryMapDataFile::Stat call use to fail.
>This use to result in call to
>pFileStatResponse->StatDone( HXR_FAIL ...)
>
>This use to some how result in recursive call to MemoryMapDataFile::Stat
>with argument c:/Document~1
>Above step continued till full path of Temp directory.
>
>
>Explanation of working after this change
>------------------------------------------------------------------------
>Now MemoryMapDataFile::Stat return SUCCESS.
>This result in call
>
>CFileCreator::StatDone() calling RenameObject.
>Hence this error message.
>
>Rest of steps happens as before.
>
>
>Thanks
>Sujeet
>
>
>
>
>
>
>
>
>
>
>>I've included the change here so folks don't have
>>to go hunting for it.
>>
>>Index: mmapdatf.cpp
>>===================================================================
>>RCS file: /cvsroot/common/fileio/platform/win/mmapdatf.cpp,v
>>retrieving revision 1.7
>>retrieving revision 1.8
>>diff -u -w -u -w -r1.7 -r1.8
>>--- mmapdatf.cpp 9 Jul 2004 18:20:11 -0000 1.7
>>+++ mmapdatf.cpp 13 Dec 2004 21:39:53 -0000 1.8
>>@@ -1,5 +1,5 @@
>> /* ***** BEGIN LICENSE BLOCK *****
>>- * Source last modified: $Id: mmapdatf.cpp,v 1.7 2004/07/09 18:20:11
>>hubbe Exp $
>>+ * Source last modified: $Id: mmapdatf.cpp,v 1.8 2004/12/13 21:39:53
>>jzeng Exp $
>> *
>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
>> *
>>@@ -745,6 +745,20 @@
>> OPEN_EXISTING,
>> FILE_ATTRIBUTE_NORMAL,
>> NULL);
>>+ }
>>+
>>+ if (hUse == INVALID_HANDLE_VALUE)
>>+ {
>>+ // if m_pFilename points to a directory, the above call will
>>fail, per msdn.
>>+ // we need to call CreateFile with a FILE_FLAG_BACKUP_SEMANTICS
>>for it to succeed.
>>+ bClose = TRUE;
>>+ hUse = CreateFile(OS_STRING(m_pFilename),
>>+ 0, //query
>>+ FILE_SHARE_READ,
>>+ NULL,
>>+ OPEN_EXISTING,
>>+ FILE_FLAG_BACKUP_SEMANTICS,
>>+ NULL);
>> }
>>
>> if (hUse == INVALID_HANDLE_VALUE)
>>
>>Eric
>>
>>At 06:55 PM 12/14/2004 -0800, Sujeet Kharkar wrote:
>>>Hi,
>>>
>>>Following change is causing bug 3505 in producer.
>>>https://bugs.helixcommunity.org/show_bug.cgi?id=3505
>>>
>>>Producer prints following error message.
>>>ERROR: RealMedia File Writer Plug-in IGNORE error with UserCode 8:
>>>Unable to rename "
>>>This error is reported by rmwrtr.dll CFileCreator::Rename
>>>
>>>Can the owner of this code please comment on this change?
>>>
>>>Thanks
>>>Sujeet
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>At 11:21 AM 12/10/2004 -0800, JJ Zeng wrote:
>>>>That is on SERVER_10_1_STABLE.
>>>>
>>>>On the head, the ifdef is removed on 2/2004.
>>>>
>>>>JJ
>>>>
>>>>At 11:10 AM 12/10/2004, Go Hori wrote:
>>>>>isn't this code #if 0 out?
>>>>>#if 0
>>>>> BOOL bClose = 0;
>>>>> HANDLE hUse = m_hFile;
>>>>> if (hUse == INVALID_HANDLE_VALUE)
>>>>> {
>>>>> bClose = 1;
>>>>> hUse = CreateFile(OS_STRING(m_pFilename),
>>>>> 0, //query
>>>>> FILE_SHARE_READ,
>>>>> NULL,
>>>>> OPEN_EXISTING,
>>>>> FILE_ATTRIBUTE_NORMAL,
>>>>> NULL);
>>>>> }
>>>>>
>>>>> if (hUse == INVALID_HANDLE_VALUE)
>>>>> {
>>>>> return HXR_FAIL;
>>>>> }
>>>>>
>>>>> BY_HANDLE_FILE_INFORMATION mss;
>>>>> memset(buffer, 0, sizeof(*buffer));
>>>>>
>>>>> buffer->st_nlink = 1;
>>>>>
>>>>> HX_RESULT res;
>>>>> if (GetFileInformationByHandle(hUse,
>>>>> &mss))
>>>>> {
>>>>> buffer->st_atime = mss.ftLastAccessTime.dwLowDateTime;
>>>>> buffer->st_ctime = mss.ftCreationTime.dwLowDateTime;
>>>>> buffer->st_mtime = mss.ftLastWriteTime.dwLowDateTime;
>>>>> buffer->st_size = mss.nFileSizeLow;
>>>>> res = HXR_OK;
>>>>> }
>>>>> else
>>>>> {
>>>>> res = HXR_FAIL;
>>>>> }
>>>>>
>>>>> if (bClose)
>>>>> {
>>>>> CloseHandle(hUse);
>>>>> }
>>>>>
>>>>> return res;
>>>>>#endif /* 0 */
>>>>>
>>>>>
>>>>>On Fri, 10 Dec 2004, JJ Zeng wrote:
>>>>>
>>>>> > This time with a diff.
>>>>> >
>>>>> > At 05:37 PM 12/9/2004, Go Hori wrote:
>>>>> > >diff?
>>>>> > >
>>>>> > >On Thu, 9 Dec 2004, JJ Zeng wrote:
>>>>> > >
>>>>> > > > Synopsis
>>>>> > > > ========
>>>>> > > >
>>>>> > > > On windows, Call DoesExist on a directory through simple file
>>>>> system will
>>>>> > > > fail. There is no bug number for it. I discovered it while
>>>>> debugging rtp
>>>>> > > > live.
>>>>> > > >
>>>>> > > > branches: SERVER_CURRENT_RN and SERVER_11_0_STABLE
>>>>> > > >
>>>>> > > > Suggested reviewer: anyone, dcollins.
>>>>> > > >
>>>>> > > >
>>>>> > > > Description
>>>>> > > > ===========
>>>>> > > >
>>>>> > > > We used to call _stat in MemoryMapDataFile::Stat on windows.
>>>>> Now we switch
>>>>> > > > to native CreateFile for better performance. But CreateFile
>>>>> will fail on
>>>>> > > > diretory if we don't pass in FILE_FLAG_BACKUP_SEMANTICS, per msdn.
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > Files Affected
>>>>> > > > ==============
>>>>> > > >
>>>>> > > > common/fileio/platform/win/mmapdatf.cpp
>>>>> > > >
>>>>> > > > Testing Performed
>>>>> > > > =================
>>>>> > > >
>>>>> > > >
>>>>> > > > Unit Tests:
>>>>> > > >
>>>>> > > > Verify DoesExist return TRUE for directories.
>>>>> > > >
>>>>> > > > Integration Tests:
>>>>> > > > None.
>>>>> > > >
>>>>> > > > Leak Tests:
>>>>> > > > None.
>>>>> > > >
>>>>> > > >
>>>>> > > > Performance Tests:
>>>>> > > > None.
>>>>> > > >
>>>>> > > > Platforms Tested: win32-i386-vc7
>>>>> > > > Build verified: win32-i386-vc7
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > _______________________________________________
>>>>> > > > Helix-server-dev mailing list
>>>>> > > > Helix-server-dev@helixcommunity.org
>>>>> > > > http://lists.helixcommunity.org/mailman/listinfo/helix-server-dev
>>>>> > > >
>>>>> > >
>>>>> > >--
>>>>> > >Go Hori
>>>>> > >ghori@real.com
>>>>> >
>>>>>
>>>>>--
>>>>>Go Hori
>>>>>ghori@real.com
>>>>
>>>>
>>>>_______________________________________________
>>>>Helix-dna-dev mailing list
>>>>Helix-dna-dev@helixcommunity.org
>>>>http://lists.helixcommunity.org/mailman/listinfo/helix-dna-dev
>>>
>>>
>>>_______________________________________________
>>>Common-dev mailing list
>>>Common-dev@helixcommunity.org
>>>http://lists.helixcommunity.org/mailman/listinfo/common-dev
>>
>>======================================
>>M. Eric Hyche (ehyche@real.com)
>>Core Technologies
>>RealNetworks, Inc.
>
======================================
M. Eric Hyche (ehyche@real.com)
Core Technologies
RealNetworks, Inc.
From hfrederickson at real.com Thu Dec 16 16:40:20 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Thu Dec 16 16:35:51 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
In-Reply-To: <1582.192.168.129.40.1103113848.squirrel@goodfellas.real.com>
References: <1582.192.168.129.40.1103113848.squirrel@goodfellas.real.com>
Message-ID: <1103244020.27315.40.camel@localhost.localdomain>
This checkin breaks any non-windows build. I noticed it on Linux. These
lines were removed from avistrm.cpp:
-#ifndef BI_RGB
-// This is defined by a windows header, so define it for non-windows
platforms
-#define BI_RGB 0
-#endif
But BI_RGB is still referenced on line 583. Adding these lines back in
fixed the problem.
-Hans
On Wed, 2004-12-15 at 04:30, mgupta@real.com wrote:
> Modified by: mgupta@real.com
> Reviewed by: ehyche@real.com
> Date: 12:15:04
> Project: AVI File Format Support
>
> Synopsis:
> 1. Fixed the problem of video not coming in AVI files when played using
> .ram files.
>
> 2. AVI code was throwing exception while exiting during playback of
> Top_Gear.avi.
>
> 3. AVI code was not able to play AVI files having MPG4 video compression.
>
> Fix:
> 1. 'PacketsSegmented' property was not being set in AVI code. This has
> been set now.
>
> 2. Memory allocation was not enough while setting the format. This has
> been fixed.
>
> 3. There was some problem in reading the index table. This required some
> changes in AVIIndex.cpp.
>
> Files Modified:
> /datatype/avi/fileformat/avistrm.cpp
> /datatype/avi/fileformat/aviindx.cpp
>
> Files Added: None
>
> Image Size and Heap Use impact: None
> Platforms and Profiles Build Verified: Win32
> Platforms and Profiles Functionality verified: Win32
>
> Branch: head
>
> Copyright assignment:
> I agree to assign to RealNetworks full copyright ownership of the code
> represented by the attached patch. I warrant that I am legally entitled to
> grant the copyright assignment and that my contribution does not violate
> any law or breach any contract. I understand that RealNetworks may license
> this code under RPSL, RCSL, and/or any other license at RealNetworks' sole
> discretion.
>
> QA Instructions:
> None
>
> ______________________________________________________________________
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From hfrederickson at real.com Thu Dec 16 17:32:04 2004
From: hfrederickson at real.com (Hans Frederickson)
Date: Thu Dec 16 17:27:35 2004
Subject: [datatype-dev] CN-Client: Network byte order output from
RVXPayloadFormat
In-Reply-To: <5.1.0.14.2.20041216100655.021ca998@mailone.real.com>
References: <5.1.0.14.2.20041216100655.021ca998@mailone.real.com>
Message-ID: <1103247123.27315.117.camel@localhost.localdomain>
Committed to head.
On Thu, 2004-12-16 at 07:07, Eric Hyche wrote:
> These changes look good to me. Works out nice that
> the rvxhdr.cpp class already had the bitstream header
> in network order anyway...
>
> Eric
>
> At 01:40 PM 12/15/2004 -0800, Hans Frederickson wrote:
> >Synopsis: Add support to RVXPayloadFormat and CRVXHeader classes for
> >obtaining the RV bitstream header in network byte order.
> >
> >Overview:
> >The new realvideo raw format will use network/big-endian byte order for
> >all the data in the file. The existing RV payload code returns all the
> >data in native byte order. It is easy to get the bitstream header in
> >network byte order by just copying the corresponding packed opaque data.
> >These changes accomplish that.
> >
> >Files Modified:
> >/datatype/rm/video/common/pub/rvxpyld.h
> >/datatype-restricted/rm/video/payload/rvxpyld.cpp
> >/datatype-restricted/rm/video/payload/rvxhdr.h
> >/datatype-restricted/rm/video/payload/rvxhdr.cpp
> >
> >Image Size and Heap Use impact:
> >Minimal increase in rvx payload and header classes for additional
> >methods.
> >
> >Platforms and Profiles Affected:
> >all platforms and profiles. tested on windows and x86-linux.
> >
> >
> >
> >
> >_______________________________________________
> >Datatype-dev mailing list
> >Datatype-dev@helixcommunity.org
> >http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
>
From mgupta at real.com Mon Dec 20 04:52:00 2004
From: mgupta at real.com (mgupta@real.com)
Date: Mon Dec 20 04:52:02 2004
Subject: [datatype-dev] CN-Client: AVI File Format support
In-Reply-To: <1103244020.27315.40.camel@localhost.localdomain>
References: <1582.192.168.129.40.1103113848.squirrel@goodfellas.real.com>
<1103244020.27315.40.camel@localhost.localdomain>
Message-ID: <2700.192.168.128.226.1103547120.squirrel@flawless.real.com>
Hi Hans,
This change has been done by some other person. I thought that I am the
only person who is working on this file and I didn't checked out the
latest version of the file. Thats why the changes were lost.
I will again check in the file with the following changes. I apologize for
the inconvenience caused.
Regards,
Mukesh
> This checkin breaks any non-windows build. I noticed it on Linux. These
> lines were removed from avistrm.cpp:
>
> -#ifndef BI_RGB
> -// This is defined by a windows header, so define it for non-windows
> platforms
> -#define BI_RGB 0
> -#endif
>
> But BI_RGB is still referenced on line 583. Adding these lines back in
> fixed the problem.
>
> -Hans
>
> On Wed, 2004-12-15 at 04:30, mgupta@real.com wrote:
>> Modified by: mgupta@real.com
>> Reviewed by: ehyche@real.com
>> Date: 12:15:04
>> Project: AVI File Format Support
>>
>> Synopsis:
>> 1. Fixed the problem of video not coming in AVI files when played using
>> .ram files.
>>
>> 2. AVI code was throwing exception while exiting during playback of
>> Top_Gear.avi.
>>
>> 3. AVI code was not able to play AVI files having MPG4 video
>> compression.
>>
>> Fix:
>> 1. 'PacketsSegmented' property was not being set in AVI code. This has
>> been set now.
>>
>> 2. Memory allocation was not enough while setting the format. This has
>> been fixed.
>>
>> 3. There was some problem in reading the index table. This required some
>> changes in AVIIndex.cpp.
>>
>> Files Modified:
>> /datatype/avi/fileformat/avistrm.cpp
>> /datatype/avi/fileformat/aviindx.cpp
>>
>> Files Added: None
>>
>> Image Size and Heap Use impact: None
>> Platforms and Profiles Build Verified: Win32
>> Platforms and Profiles Functionality verified: Win32
>>
>> Branch: head
>>
>> Copyright assignment:
>> I agree to assign to RealNetworks full copyright ownership of the code
>> represented by the attached patch. I warrant that I am legally entitled
>> to
>> grant the copyright assignment and that my contribution does not violate
>> any law or breach any contract. I understand that RealNetworks may
>> license
>> this code under RPSL, RCSL, and/or any other license at RealNetworks'
>> sole
>> discretion.
>>
>> QA Instructions:
>> None
>>
>> ______________________________________________________________________
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
From mnarra at real.com Mon Dec 20 16:18:52 2004
From: mnarra at real.com (Murali Narra)
Date: Mon Dec 20 16:18:39 2004
Subject: [datatype-dev] CR: PR 129812, ASMRuleBook AvgBitRate property
Message-ID: <5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Synopsis
========
fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
Branches: SERVER_10_1_STABLE_RN
Suggested Reviewer: Go, Jamie, anybody
Description
===========
10.0 serve fails to play hinted 3gp content and sends 404.
The problem is mp4 file format fails to set AverageBandwidth property in
the SMRuleBook because it fails to compute AvgBitRate in some cases.
The fix is to get the AvgBitRate from the header incase all other methods
to compute this property fail.
Files Affected
==========
datatype/mp4/fileformat/qtffplin.cpp
Testing Performed
==============
Verified the bug.
QA hints
=======
n/a
-------------------------------------------------
Index: qtffplin.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
retrieving revision 1.30.2.2
diff -u -w -b -r1.30.2.2 qtffplin.cpp
--- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
+++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
@@ -912,6 +912,11 @@
ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
}
+ if (ulAvgBitRate == 0)
+ {
+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
+ }
+
pHeader->SetPropertyULONG32("Duration", ulDuration);
if (ulAvgBitRate != 0)
--------------------------------------------------------
thanks
Murali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041220/c233febb/attachment.htm
From milko at real.com Tue Dec 21 10:12:54 2004
From: milko at real.com (milko)
Date: Tue Dec 21 10:13:05 2004
Subject: [datatype-dev] CR: PR 129812, ASMRuleBook AvgBitRate
property
In-Reply-To: <5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Message-ID: <5.1.0.14.2.20041221101153.0361e670@mailone.real.com>
Looks good.
Is CR for HEAD and v11 going to be sent out separately?
Milko
At 04:18 PM 12/20/2004, Murali Narra wrote:
>Synopsis
>========
>fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
>Branches: SERVER_10_1_STABLE_RN
>Suggested Reviewer: Go, Jamie, anybody
>
>Description
>===========
>10.0 serve fails to play hinted 3gp content and sends 404.
>The problem is mp4 file format fails to set AverageBandwidth property in
>the SMRuleBook because it fails to compute AvgBitRate in some cases.
>The fix is to get the AvgBitRate from the header incase all other methods
>to compute this property fail.
>
>Files Affected
>==========
>datatype/mp4/fileformat/qtffplin.cpp
>
>Testing Performed
>==============
>Verified the bug.
>
>QA hints
>=======
>n/a
>
>-------------------------------------------------
>Index: qtffplin.cpp
>===================================================================
>RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
>retrieving revision 1.30.2.2
>diff -u -w -b -r1.30.2.2 qtffplin.cpp
>--- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
>+++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
>@@ -912,6 +912,11 @@
>ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
>}
>+ if (ulAvgBitRate == 0)
>+ {
>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>+ }
>+
>pHeader->SetPropertyULONG32("Duration", ulDuration);
>if (ulAvgBitRate != 0)
>--------------------------------------------------------
>
>thanks
>Murali
>
>_______________________________________________
>Datatype-dev mailing list
>Datatype-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041221/441b7560/attachment-0001.htm
From tmarshall at helixcommunity.org Tue Dec 21 10:23:13 2004
From: tmarshall at helixcommunity.org (Tom Marshall)
Date: Tue Dec 21 10:23:40 2004
Subject: [datatype-dev] CR: PR 129812, ASMRuleBook AvgBitRate property
In-Reply-To: <5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
References: <5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Message-ID: <20041221182313.GE8478@real.com>
On Mon, Dec 20, 2004 at 04:18:52PM -0800, Murali Narra wrote:
> Synopsis
> ========
> fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
> Branches: SERVER_10_1_STABLE_RN
> Suggested Reviewer: Go, Jamie, anybody
>
> Description
> ===========
> 10.0 serve fails to play hinted 3gp content and sends 404.
> The problem is mp4 file format fails to set AverageBandwidth property in the
> SMRuleBook because it fails to compute AvgBitRate in some cases.
> The fix is to get the AvgBitRate from the header incase all other methods to
> compute this property fail.
>
> Files Affected
> ==========
> datatype/mp4/fileformat/qtffplin.cpp
>
> Testing Performed
> ==============
> Verified the bug.
>
> QA hints
> =======
> n/a
Okay for SERVER_10_1_STABLE_RN
>
> -------------------------------------------------
> Index: qtffplin.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
> retrieving revision 1.30.2.2
> diff -u -w -b -r1.30.2.2 qtffplin.cpp
> --- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
> +++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
> @@ -912,6 +912,11 @@
> ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
> }
> + if (ulAvgBitRate == 0)
> + {
> + pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
> + }
> +
> pHeader->SetPropertyULONG32("Duration", ulDuration);
> if (ulAvgBitRate != 0)
> --------------------------------------------------------
>
> thanks
> Murali
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
--
A lot of people are afraid of heights. Not me. I'm afraid of widths.
-- Steven Wright
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041221/c112e82e/attachment.bin
From dhedbor at real.com Tue Dec 21 16:45:29 2004
From: dhedbor at real.com (dhedbor@real.com)
Date: Tue Dec 21 16:52:21 2004
Subject: [datatype-dev] CN: Bugfix: Missing dummy method for
ReportDecodedFrame
In-Reply-To: <5.1.0.14.2.20041215084331.021a1a48@mailone.real.com> (Eric
Hyche's message of "Wed, 15 Dec 2004 08:43:39 -0500")
References: <5.1.0.14.2.20041215084331.021a1a48@mailone.real.com>
Message-ID: <87oegni2ja.fsf@asgard.prognet.com>
Thanks. Committed to HEAD.
Eric Hyche writes:
> Looks good.
>
> Eric
>
> At 01:45 PM 12/14/2004 -0800, dhedbor@real.com wrote:
>>Description:
>>
>>The method CVideoRenderer::ReportDecodedFrame doesn't have a dummy
>>implementation for when HELIX_FEATURE_STATS isn't defined. This in
>>turn causes datatype/rm/video/renderer/rvxvdfmt.cpp to not compile.
>>
>>This patch adds this missing dummy method.
>>
>>Branches:
>>
>>HEAD
>>
>>--
>>David Hedbor, Software Development Engineer - Real Networks
>>Helix Community: http://helixcommunity.org
>>Index: datatype/common/vidrend/pub/vidrend.h
>>===================================================================
>>RCS file: /cvsroot/datatype/common/vidrend/pub/vidrend.h,v
>>retrieving revision 1.26
>>diff -u -r1.26 vidrend.h
>> --- datatype/common/vidrend/pub/vidrend.h 26 Oct 2004 23:25:22
>> -0000 1.26
>>+++ datatype/common/vidrend/pub/vidrend.h 14 Dec 2004 21:49:22 -0000
>>@@ -853,6 +853,11 @@
>> return;
>> }
>>
>>+ void ReportDecodedFrame(ULONG32 ulCount = 1)
>>+ {
>>+ return;
>>+ }
>>+
>> void ReportUpsampledFrame(ULONG32 ulCount = 1)
>> {
>> return;
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> ======================================
> M. Eric Hyche (ehyche@real.com)
> Core Technologies
> RealNetworks, Inc.
--
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org
From mnarra at real.com Tue Dec 21 18:28:15 2004
From: mnarra at real.com (Murali Narra)
Date: Tue Dec 21 18:27:57 2004
Subject: [datatype-dev] CR: PR 129812, ASMRuleBook AvgBitRate
property
In-Reply-To: <5.1.0.14.2.20041221101153.0361e670@mailone.real.com>
References: <5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Message-ID: <5.1.0.14.2.20041221141259.04427d58@mailone.real.com>
Following diff is for Head and v11. Fix is in different file.
Files Affected
==========
datatype/mp4/fileformat/qttrack.cpp
Testing Performed
==============
Verified AverageBandwidth header is included in the ASMRuleBook.
----------------
Index: qttrack.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qttrack.cpp,v
retrieving revision 1.16
diff -u -w -b -r1.16 qttrack.cpp
--- qttrack.cpp 6 Aug 2004 04:42:37 -0000 1.16
+++ qttrack.cpp 22 Dec 2004 02:17:18 -0000
@@ -456,6 +456,10 @@
{
ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
}
+ if (ulAvgBitRate == 0)
+ {
+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
+ }
ulMaxBitRate = m_TrackInfo.GetMaxBitrate();
------------------------
thanks
Murali
At 10:12 AM 12/21/2004, milko wrote:
>Looks good.
>
>Is CR for HEAD and v11 going to be sent out separately?
>
>Milko
>
>At 04:18 PM 12/20/2004, Murali Narra wrote:
>>Synopsis
>>========
>>fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
>>Branches: SERVER_10_1_STABLE_RN
>>Suggested Reviewer: Go, Jamie, anybody
>>
>>Description
>>===========
>>10.0 serve fails to play hinted 3gp content and sends 404.
>>The problem is mp4 file format fails to set AverageBandwidth property in
>>the SMRuleBook because it fails to compute AvgBitRate in some cases.
>>The fix is to get the AvgBitRate from the header incase all other methods
>>to compute this property fail.
>>
>>Files Affected
>>==========
>>datatype/mp4/fileformat/qtffplin.cpp
>>
>>Testing Performed
>>==============
>>Verified the bug.
>>
>>QA hints
>>=======
>>n/a
>>
>>-------------------------------------------------
>>Index: qtffplin.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
>>retrieving revision 1.30.2.2
>>diff -u -w -b -r1.30.2.2 qtffplin.cpp
>>--- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
>>+++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
>>@@ -912,6 +912,11 @@
>>ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
>>}
>>+ if (ulAvgBitRate == 0)
>>+ {
>>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>>+ }
>>+
>>pHeader->SetPropertyULONG32("Duration", ulDuration);
>>if (ulAvgBitRate != 0)
>>--------------------------------------------------------
>>
>>thanks
>>Murali
>>
>>_______________________________________________
>>Datatype-dev mailing list
>>Datatype-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041221/814ce53f/attachment.htm
From milko at real.com Tue Dec 21 22:54:55 2004
From: milko at real.com (milko)
Date: Tue Dec 21 23:08:29 2004
Subject: [datatype-dev] CR: PR 129812, ASMRuleBook AvgBitRate
property
In-Reply-To: <5.1.0.14.2.20041221141259.04427d58@mailone.real.com>
References: <5.1.0.14.2.20041221101153.0361e670@mailone.real.com>
<5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Message-ID: <5.1.0.14.2.20041221225437.034c3c78@mailone.real.com>
Looks good.
At 06:28 PM 12/21/2004, Murali Narra wrote:
>Following diff is for Head and v11. Fix is in different file.
>
>Files Affected
>==========
>datatype/mp4/fileformat/qttrack.cpp
>
>
>Testing Performed
>==============
>Verified AverageBandwidth header is included in the ASMRuleBook.
>
>
>----------------
>Index: qttrack.cpp
>===================================================================
>RCS file: /cvsroot/datatype/mp4/fileformat/qttrack.cpp,v
>retrieving revision 1.16
>diff -u -w -b -r1.16 qttrack.cpp
>--- qttrack.cpp 6 Aug 2004 04:42:37 -0000 1.16
>+++ qttrack.cpp 22 Dec 2004 02:17:18 -0000
>@@ -456,6 +456,10 @@
> {
> ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
> }
>+ if (ulAvgBitRate == 0)
>+ {
>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>+ }
>
> ulMaxBitRate = m_TrackInfo.GetMaxBitrate();
> ------------------------
>
>thanks
>Murali
>
>At 10:12 AM 12/21/2004, milko wrote:
>
>>Looks good.
>>
>>Is CR for HEAD and v11 going to be sent out separately?
>>
>>Milko
>>
>>At 04:18 PM 12/20/2004, Murali Narra wrote:
>>>Synopsis
>>>========
>>>fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
>>>Branches: SERVER_10_1_STABLE_RN
>>>Suggested Reviewer: Go, Jamie, anybody
>>>
>>>Description
>>>===========
>>>10.0 serve fails to play hinted 3gp content and sends 404.
>>>The problem is mp4 file format fails to set AverageBandwidth property in
>>>the SMRuleBook because it fails to compute AvgBitRate in some cases.
>>>The fix is to get the AvgBitRate from the header incase all other
>>>methods to compute this property fail.
>>>
>>>Files Affected
>>>==========
>>>datatype/mp4/fileformat/qtffplin.cpp
>>>
>>>Testing Performed
>>>==============
>>>Verified the bug.
>>>
>>>QA hints
>>>=======
>>>n/a
>>>
>>>-------------------------------------------------
>>>Index: qtffplin.cpp
>>>===================================================================
>>>RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
>>>retrieving revision 1.30.2.2
>>>diff -u -w -b -r1.30.2.2 qtffplin.cpp
>>>--- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
>>>+++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
>>>@@ -912,6 +912,11 @@
>>>ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
>>>}
>>>+ if (ulAvgBitRate == 0)
>>>+ {
>>>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>>>+ }
>>>+
>>>pHeader->SetPropertyULONG32("Duration", ulDuration);
>>>if (ulAvgBitRate != 0)
>>>--------------------------------------------------------
>>>
>>>thanks
>>>Murali
>>>
>>>_______________________________________________
>>>Datatype-dev mailing list
>>>Datatype-dev@helixcommunity.org
>>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041221/a8bf811e/attachment.htm
From mnarra at real.com Wed Dec 22 08:39:04 2004
From: mnarra at real.com (Murali Narra)
Date: Wed Dec 22 08:38:44 2004
Subject: [datatype-dev] Checkin: PR 129812, ASMRuleBook AvgBitRate property
In-Reply-To: <5.1.0.14.2.20041221225437.034c3c78@mailone.real.com>
References: <5.1.0.14.2.20041221141259.04427d58@mailone.real.com>
<5.1.0.14.2.20041221101153.0361e670@mailone.real.com>
<5.1.0.14.2.20041220161351.0441ab20@mailone.real.com>
Message-ID: <5.1.0.14.2.20041222083131.03eaf6c8@mailone.real.com>
The Fix has been checked into :
Head , SERVER_10_1_STABLE_RN and SERVER_11_0_STABLE_RN branches.
thanks
Murali
At 10:54 PM 12/21/2004, milko wrote:
>Looks good.
>
>At 06:28 PM 12/21/2004, Murali Narra wrote:
>>Following diff is for Head and v11. Fix is in different file.
>>
>>Files Affected
>>==========
>>datatype/mp4/fileformat/qttrack.cpp
>>
>>
>>Testing Performed
>>==============
>>Verified AverageBandwidth header is included in the ASMRuleBook.
>>
>>
>>----------------
>>Index: qttrack.cpp
>>===================================================================
>>RCS file: /cvsroot/datatype/mp4/fileformat/qttrack.cpp,v
>>retrieving revision 1.16
>>diff -u -w -b -r1.16 qttrack.cpp
>>--- qttrack.cpp 6 Aug 2004 04:42:37 -0000 1.16
>>+++ qttrack.cpp 22 Dec 2004 02:17:18 -0000
>>@@ -456,6 +456,10 @@
>> {
>> ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
>> }
>>+ if (ulAvgBitRate == 0)
>>+ {
>>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>>+ }
>>
>> ulMaxBitRate = m_TrackInfo.GetMaxBitrate();
>> ------------------------
>>
>>thanks
>>Murali
>>
>>At 10:12 AM 12/21/2004, milko wrote:
>>
>>>Looks good.
>>>
>>>Is CR for HEAD and v11 going to be sent out separately?
>>>
>>>Milko
>>>
>>>At 04:18 PM 12/20/2004, Murali Narra wrote:
>>>>Synopsis
>>>>========
>>>>fix for PR : https://bugs.dev.prognet.com/show_bug.cgi?id=129812
>>>>Branches: SERVER_10_1_STABLE_RN
>>>>Suggested Reviewer: Go, Jamie, anybody
>>>>
>>>>Description
>>>>===========
>>>>10.0 serve fails to play hinted 3gp content and sends 404.
>>>>The problem is mp4 file format fails to set AverageBandwidth property
>>>>in the SMRuleBook because it fails to compute AvgBitRate in some cases.
>>>>The fix is to get the AvgBitRate from the header incase all other
>>>>methods to compute this property fail.
>>>>
>>>>Files Affected
>>>>==========
>>>>datatype/mp4/fileformat/qtffplin.cpp
>>>>
>>>>Testing Performed
>>>>==============
>>>>Verified the bug.
>>>>
>>>>QA hints
>>>>=======
>>>>n/a
>>>>
>>>>-------------------------------------------------
>>>>Index: qtffplin.cpp
>>>>===================================================================
>>>>RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
>>>>retrieving revision 1.30.2.2
>>>>diff -u -w -b -r1.30.2.2 qtffplin.cpp
>>>>--- qtffplin.cpp 27 Apr 2004 22:37:05 -0000 1.30.2.2
>>>>+++ qtffplin.cpp 20 Dec 2004 23:33:43 -0000
>>>>@@ -912,6 +912,11 @@
>>>>ulAvgBitRate = SDPMapPayloadToBitrate(ulPayloadType);
>>>>}
>>>>+ if (ulAvgBitRate == 0)
>>>>+ {
>>>>+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
>>>>+ }
>>>>+
>>>>pHeader->SetPropertyULONG32("Duration", ulDuration);
>>>>if (ulAvgBitRate != 0)
>>>>--------------------------------------------------------
>>>>
>>>>thanks
>>>>Murali
>>>>
>>>>_______________________________________________
>>>>Datatype-dev mailing list
>>>>Datatype-dev@helixcommunity.org
>>>>http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041222/ca6e950f/attachment-0001.htm
From dhedbor at real.com Wed Dec 22 15:05:58 2004
From: dhedbor at real.com (dhedbor@real.com)
Date: Wed Dec 22 15:13:04 2004
Subject: [datatype-dev] CR: Add missing UmakefileVersion>
Message-ID: <87ekhic4rt.fsf@asgard.prognet.com>
On December 8th the Umakefil's of datatype/rm/codec/sipro and ra8lbr
were split into one main file and two included files. The ordinary
"XXXHelixDll" files are missing a UmakefileVersion statement which got
the effect that the resulting .so files had a version number (i.e
sipro.so.1.0.0 or similar). This patch fixes these two instances.
--
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: umakeversion.diff
Type: text/x-patch
Size: 1206 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041222/c2888007/umakeversion.bin
From rmathew at real.com Tue Dec 28 16:46:32 2004
From: rmathew at real.com (Rishi Mathew)
Date: Tue Dec 28 16:52:32 2004
Subject: [datatype-dev] CR: Bug fix for AAC ADTS fileformat
Message-ID: <6.1.2.0.2.20041228163221.0376d728@mailone.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: aacff.cpp
===================================================================
RCS file: /cvsroot/datatype/aac/fileformat/aacff.cpp,v
retrieving revision 1.28
diff -u -w -r1.28 aacff.cpp
--- aacff.cpp 16 Nov 2004 07:25:47 -0000 1.28
+++ aacff.cpp 29 Dec 2004 00:41:05 -0000
@@ -826,20 +826,18 @@
}
if (ulNumBytesIn < 0x1FFFFFFF)
{
- m_ulAvgBitRate = ((ulNumBytesIn - m_ulID3TagSize) << 3)
- / ulTimeStamp;
+ m_ulAvgBitRate = (UINT32)((double)((ulNumBytesIn - m_ulID3TagSize) << 3) * 1000.0
+ / (double)ulTimeStamp);
}
else
{
- m_ulAvgBitRate = ((ulNumBytesIn - m_ulID3TagSize) << 1)
- / (ulTimeStamp >> 2);
+ m_ulAvgBitRate = (UINT32)((double)((ulNumBytesIn - m_ulID3TagSize) << 1) * 1000.0
+ / ((double)(ulTimeStamp >> 2)));
}
- m_ulAvgBitRate *= 1000;
- }
- if (m_ulAvgBitRate >= 4000)
- {
- ulDuration = (m_ulFileSize << 1) / (m_ulAvgBitRate/4000);
}
+
+ ulDuration = (UINT32)((double)(m_ulFileSize << 1)*4000.0 / (double)(m_ulAvgBitRate));
+
if (m_bFirstPacket && !m_ulDuration)
{
m_ulDuration = ulDuration;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: al09_08.adts
Type: application/octet-stream
Size: 218894 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20041228/d0097cf5/al09_08-0001.obj
From Nat.Pham at nokia.com Tue Dec 28 17:21:17 2004
From: Nat.Pham at nokia.com (Nat.Pham@nokia.com)
Date: Tue Dec 28 17:21:32 2004
Subject: [datatype-dev] How to create/build/run a Helix unit-test app
Message-ID: <77DD81E268885348A1B5019CBBAA69FF0209DD3F@daebe003.americas.nokia.com>
Hi All,
I now start creating a unit-test for my project and don't have any documentation
for Helix unit-test framework or test application.
Any information on Helix unit-test framework documentation, what is required to create
a Helix unit-test app, where to find a working source code version of Helix unit-test framework,
instruction on how to create, build and execute a Helix unit-test app from you is greatly appreciated.
Here is what I am hacking now:
I search for different test source code in \MyHelix\ and try to build them.
"build" command does not work for any of those test source code.
Notes: Prior to building these unit-test, I built the whole thing of \MyHelix\ using "build"
with hxclient_1_4_2_neptunex, symbian-70s-emulator and helix-client-s60-advanced just fine.
Then I have to build the test source code using commands "umake" and "make".
Now, I have \MyHelix\common\fileio\test built successfully and
\MyHelix\common\fileio\test\wins-dbg32\tihxfile.exe generated.
Then I try to run "tihxfile.exe" or "tihxfile.exe tihxfile.in" from DOS prompt.
It crashes and pops up an error message "The application failed to initialize properly (0x0000005) ..."
I also try to build and run \MyHelix\datatype\common\util\test\wins-dbg32\tbitpack.exe
and have the same problem.
Please let me know whether the way above I built and ran the test apps is correct or not?
Or I need to load the *.exe (+ *.lib, *.dll) onto the Emulator and run the *.exe from there?
Thanks,
Nat.
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.