From Gang.Jia at nokia.com Mon Mar 1 13:22:08 2010
From: Gang.Jia at nokia.com (Gang.Jia@nokia.com)
Date: Mon Mar 1 20:34:24 2010
Subject: [datatype-dev] CR:Case ou1cimx1#259923 Helix Cannot play MPEG4 avi
with 5.1ch AC3
Message-ID: <6F45DEE63C5BB542B6A7B0C4E41467D0152EC16FD7@NOK-EUMSG-03.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 ***** */
#ifndef DD_DEPACK_H
#define DD_DEPACK_H
#include "hxtypes.h"
#include "mp4a-mux-cfg.h"
typedef void (*OnFrameCB)(void* pUserData, ULONG32 ulTime,
const UINT8* pData, ULONG32 ulSize,
HXBOOL bPreviousLoss);
class DDDepack
{
public:
DDDepack();
~DDDepack();
HXBOOL Init(OnFrameCB pFrameCB,
void* pUserData,
HXBOOL bIsDDPlus);
HXBOOL Reset(); // Completely reset the depacketizer state
HXBOOL Flush(); // Indicates end of stream
HXBOOL OnPacket(ULONG32 ulTime, const UINT8* pData,
ULONG32 ulSize);
HXBOOL OnLoss(ULONG32 ulNumPackets); // called to indicate lost packets
protected:
HXBOOL FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize);
HXBOOL ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize);
private:
void* m_pUserData;
OnFrameCB m_pCallback;
ULONG32 m_ulCurrentTime;
UINT8* m_pStagingBuf;
ULONG32 m_ulStagingBufSize;
ULONG32 m_ulBytesStaged;
UINT8* m_pPayloadBuf;
ULONG32 m_ulPayloadBufSize;
HXBOOL m_bHadLoss;
HXBOOL m_bNeedNextPkt;
HXBOOL m_bIsDDPlus;
};
#endif // DD_DEPACK_H
-------------- next part --------------
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/Umakefil,v
retrieving revision 1.14.2.2
diff -u -w -r1.14.2.2 Umakefil
--- Umakefil 7 Mar 2006 20:03:35 -0000 1.14.2.2
+++ Umakefil 26 Feb 2010 16:19:48 -0000
@@ -72,6 +72,7 @@
"mp4-latm-depack.cpp",
"qclppyld.cpp",
"qcelp-depack.cpp",
+ "dd-depack.cpp",
"fmtfact.cpp",
"hxamrpack.cpp")
Index: mp4apyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
retrieving revision 1.14.6.5
diff -u -w -r1.14.6.5 mp4apyld.cpp
--- mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
+++ mp4apyld.cpp 26 Feb 2010 16:19:48 -0000
@@ -62,6 +62,7 @@
#include "hxengin.h"
#include "mp4-latm-depack.h"
+#include "dd-depack.h"
#include "mp4desc.h"
#include "mp4apyld.h"
@@ -79,6 +80,7 @@
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
, m_pLATMDepack (NULL)
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ , m_pDDDepack (NULL)
, m_pAudioConfig (NULL)
, m_ulAudioConfigSize (0)
, m_unAudioConfigType (2)
@@ -98,6 +100,7 @@
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
HX_DELETE(m_pLATMDepack);
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ HX_DELETE(m_pDDDepack);
HX_RELEASE(m_pClassFactory);
HX_RELEASE(m_pStreamHeader);
}
@@ -203,6 +206,10 @@
m_pLATMDepack->Reset();
}
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ if (m_pDDDepack)
+ {
+ m_pDDDepack->Reset();
+ }
m_TSConverter.Reset();
return HXR_OK;
@@ -288,7 +295,7 @@
}
else if (strcasecmp(pMimeTypeData, "audio/EAC3") == 0)
{
- m_PayloadID = PYID_DOLBYDIGITAL;
+ m_PayloadID = PYID_DOLBYDIGITALPLUS;
}
else if (strcasecmp(pMimeTypeData, "audio/AC3") == 0)
{
@@ -317,7 +324,10 @@
retVal = SetAssemblerQCELPHeader(pHeader);
break;
case PYID_DOLBYDIGITAL:
- retVal = SetAssemblerDDHeader(pHeader);
+ retVal = SetAssemblerDDHeader(pHeader, FALSE);
+ break;
+ case PYID_DOLBYDIGITALPLUS:
+ retVal = SetAssemblerDDHeader(pHeader, TRUE);
break;
default:
retVal = HXR_NOTIMPL;
@@ -477,10 +487,14 @@
return retVal;
}
-HX_RESULT MP4APayloadFormat::SetAssemblerDDHeader(IHXValues* pHeader)
+HX_RESULT MP4APayloadFormat::SetAssemblerDDHeader(IHXValues* pHeader, HXBOOL bIsDDPlus)
{
HX_RESULT retVal = HXR_OK;
+ retVal = SetAssemblerDDConfig(bIsDDPlus);
+
+ if (SUCCEEDED(retVal))
+ {
m_ulAudioConfigSize = 12;
m_pAudioConfig = new UINT8 [m_ulAudioConfigSize];
@@ -505,6 +519,35 @@
{
retVal = HXR_OUTOFMEMORY;
}
+ }
+ return retVal;
+}
+
+HX_RESULT MP4APayloadFormat::SetAssemblerDDConfig(HXBOOL bIsDDPlus)
+{
+ HX_RESULT retVal = HXR_OK;
+
+ // Create and initialize the DD depacketizer
+ HX_DELETE(m_pDDDepack);
+ m_pDDDepack = new DDDepack;
+
+ retVal = HXR_OUTOFMEMORY;
+ if (m_pDDDepack)
+ {
+ retVal = HXR_OK;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+
+ retVal = HXR_FAIL;
+ if (m_pDDDepack->Init(OnFrameCallback, this, bIsDDPlus))
+ {
+ retVal = HXR_OK;
+ }
+
+ }
+
return retVal;
}
@@ -678,11 +721,42 @@
case PYID_X_HX_3GPP_QCELP:
case PYID_X_HX_MP4_RAWAU:
case PYID_X_HX_AAC_GENERIC:
- case PYID_DOLBYDIGITAL:
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
break;
+
+ case PYID_DOLBYDIGITAL:
+ case PYID_DOLBYDIGITALPLUS:
+ retVal = HXR_FAIL;
+ if (m_pDDDepack)
+ {
+ if (pPacket->IsLost())
+ {
+ if (m_pDDDepack->OnLoss(1))
+ {
+ retVal = HXR_OK;
+ }
+ }
+ else
+ {
+ IHXBuffer* pBuffer = pPacket->GetBuffer();
+
+ if (pBuffer)
+ {
+ if (m_pDDDepack->OnPacket(GetPacketTime(pPacket),
+ pBuffer->GetBuffer(),
+ pBuffer->GetSize()))
+ {
+ retVal = HXR_OK;
+ }
+
+ pBuffer->Release();
+ }
+ }
+ }
+ break;
+
case PYID_MP4A_LATM:
retVal = HXR_FAIL;
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
@@ -837,10 +911,11 @@
{
case PYID_X_HX_AAC_GENERIC:
case PYID_X_HX_MP4_RAWAU:
- case PYID_DOLBYDIGITAL:
retVal = CreateRawAUMediaPacket(pOutMediaPacket);
break;
+ case PYID_DOLBYDIGITAL:
+ case PYID_DOLBYDIGITALPLUS:
case PYID_MP4A_LATM:
if (m_OutMediaPacketQueue.IsEmpty())
{
@@ -1043,6 +1118,10 @@
m_pLATMDepack->Flush();
}
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ if (m_pDDDepack)
+ {
+ m_pDDDepack->Flush();
+ }
m_bFlushed = TRUE;
return HXR_OK;
Index: pub/mp4apyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4apyld.h,v
retrieving revision 1.7.8.1
diff -u -w -r1.7.8.1 mp4apyld.h
--- pub/mp4apyld.h 13 Nov 2009 19:33:44 -0000 1.7.8.1
+++ pub/mp4apyld.h 26 Feb 2010 16:19:48 -0000
@@ -43,6 +43,7 @@
#include "tsconvrt.h"
class MP4LATMDepack;
+class DDDepack;
/****************************************************************************
* MP4APayloadFormat
@@ -103,7 +104,8 @@
PYID_MP4A_LATM,
PYID_X_HX_AAC_GENERIC,
PYID_X_HX_3GPP_QCELP,
- PYID_DOLBYDIGITAL
+ PYID_DOLBYDIGITAL,
+ PYID_DOLBYDIGITALPLUS
} PayloadID;
inline HX_RESULT CreateRawAUMediaPacket(CMediaPacket* &pOutMediaPacket);
@@ -117,7 +119,8 @@
HX_RESULT SetAssemblerQCELPHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerLATMConfig(IHXValues* pHeader);
- HX_RESULT SetAssemblerDDHeader(IHXValues* pHeader);
+ HX_RESULT SetAssemblerDDHeader(IHXValues* pHeader, HXBOOL bIsDDPlus);
+ HX_RESULT SetAssemblerDDConfig(HXBOOL bIsDDPlus);
HX_RESULT OnFrame(ULONG32 ulTime,
const UINT8* pData,
ULONG32 ulSize,
@@ -154,6 +157,7 @@
MP4LATMDepack* m_pLATMDepack;
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ DDDepack* m_pDDDepack;
UINT8* m_pAudioConfig;
ULONG32 m_ulAudioConfigSize;
UINT8 m_unAudioConfigType;
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 "hlxclib/string.h"
#include "dd-depack.h"
#define DEFAULT_PAYLOAD_BUF_SIZE 5120
#define DEFAULT_STAGING_BUF_SIZE 5120
//Dolby Digital frame size table, the first column is framesizecode, it is the lower 6 bits
// of the 4th byte, the 2nd column is the norminal bit rate, the 3rd, 4th and 5th columns are
// the framesizes(in 16bit word) for sample rate at 32K, 44.1K and 48K respectively
/*
frmsizecode nominal bit rate 16-bit words per syncframe Fs=32K Fs=44.1K Fs=48K
000000 32Kbps 96 69 64
000001 32Kbps 96 70 64
000010 40Kbps 120 87 80
000011 40Kbps 120 88 80
000100 48Kbps 144 104 96
000101 48Kbps 144 105 96
000110 56Kbps 168 121 112
000111 56Kbps 168 122 112
001000 64Kbps 192 139 128
001001 64Kbps 192 140 128
001010 80Kbps 240 174 160
001011 80Kbps 240 175 160
001100 96Kbps 288 208 192
001101 96Kbps 288 209 192
001110 112Kbps 336 243 224
001111 112Kbps 336 244 224
010000 128Kbps 384 278 256
010001 128Kbps 384 279 256
010010 160Kbps 480 348 320
010011 160Kbps 480 349 320
010100 192Kbps 576 417 384
010101 192Kbps 576 418 384
010110 224Kbps 672 487 448
010111 224Kbps 672 488 448
011000 256Kbps 768 557 512
011001 256Kbps 768 558 512
011010 320Kbps 960 696 640
011011 320Kbps 960 697 640
011100 384Kbps 1152 835 768
011101 384Kbps 1152 836 768
011110 448Kbps 1344 975 896
011111 448Kbps 1344 976 896
100000 512Kbps 1536 1114 1024
100001 512Kbps 1536 1115 1024
100010 576Kbps 1728 1253 1152
100011 576Kbps 1728 1254 1152
100100 640Kbps 1920 1393 1280
100101 640Kbps 1920 1394 1280
100110 to 111111 reserved */
//Dolby Digital frame size (in bytes) table used to parse the frame header
const UINT32 uDDFrameSizetTbl [38][3] =
{
128, 138, 192,
128, 140, 192,
160, 174, 240,
160, 176, 240,
192, 208, 288,
192, 210, 288,
224, 242, 336,
224, 244, 336,
256, 278, 384,
256, 280, 384,
320, 348, 480,
320, 350, 480,
384, 416, 576,
384, 418, 576,
448, 486, 672,
448, 488, 672,
512, 556, 768,
512, 558, 768,
640, 696, 960,
640, 698, 960,
768, 834, 1152,
768, 836, 1152,
896, 974, 1344,
896, 976, 1344,
1024, 1114, 1536,
1024, 1116, 1536,
1280, 1392, 1920,
1280, 1394, 1920,
1536, 1670, 2304,
1536, 1672, 2304,
1792, 1950, 2688,
1792, 1952, 2688,
2048, 2228, 3072,
2048, 2230, 3072,
2304, 2506, 3456,
2304, 2508, 3456,
2560, 2786, 3840,
2560, 2788, 3840,
};
DDDepack::DDDepack() :
m_pUserData(0),
m_pCallback(0),
m_ulCurrentTime(0),
m_ulBytesStaged(0),
m_bHadLoss(FALSE),
m_bNeedNextPkt(FALSE)
{}
DDDepack::~DDDepack()
{
if(m_pStagingBuf)
{
delete [] m_pStagingBuf;
}
m_pStagingBuf = 0;
if(m_pPayloadBuf)
{
delete [] m_pPayloadBuf;
}
m_ulPayloadBufSize = 0;
}
HXBOOL DDDepack::Init(OnFrameCB pFrameCB, void* pUserData, HXBOOL bIsDDPlus)
{
HXBOOL ret = FALSE;
m_pCallback = pFrameCB;
m_pUserData = pUserData;
m_bIsDDPlus = bIsDDPlus;
m_pStagingBuf = new UINT8[DEFAULT_STAGING_BUF_SIZE];
if(m_pStagingBuf)
{
ret = TRUE;
}
m_ulStagingBufSize = DEFAULT_PAYLOAD_BUF_SIZE;
m_pPayloadBuf = new UINT8[DEFAULT_PAYLOAD_BUF_SIZE];
if(ret && m_pPayloadBuf)
{
ret = TRUE;
}
m_ulPayloadBufSize = DEFAULT_PAYLOAD_BUF_SIZE;
return TRUE;
}
HXBOOL DDDepack::Reset() // Completely reset the depacketizer state
{
m_ulBytesStaged = 0;
m_bHadLoss = FALSE;
m_bNeedNextPkt = FALSE;
return FALSE;
}
HXBOOL DDDepack::Flush() // Indicates end of stream
{
return FALSE;
}
HXBOOL DDDepack::FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize)
{
HXBOOL ret = FALSE;
if( !(*pBuffer == 0x0b) || !(*(pBuffer+1) == 0x77))
{
//Discard data until the first sync word
for(ULONG32 i=1; i m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[ulPayloadLen];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
ret = FALSE;
}
else
{
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = ulPayloadLen;
}
}
if(ret)
{
memcpy(m_pStagingBuf, &pBuffer[ulOffset], ulPayloadLen);
m_ulBytesStaged += ulPayloadLen;
}
}
}
else //continue to the previous pkt
{
if ((m_ulBytesStaged + ulSize) > m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[m_ulBytesStaged + ulSize];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
ret = FALSE;
}
else
{
memcpy(pNewBuf, m_pStagingBuf, m_ulBytesStaged);
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = m_ulBytesStaged + ulSize;
}
}
if(ret)
{
memcpy(&m_pStagingBuf[m_ulBytesStaged], pData, ulSize);
m_ulBytesStaged += ulSize;
}
}
if(ret)
{
ret = ProcessStagingBuffer(m_pStagingBuf,m_ulBytesStaged);
}
return ret;
}
HXBOOL DDDepack::OnLoss(ULONG32 ulNumPackets) // called to indicate lost
// packets
{
m_bHadLoss = TRUE;
m_ulBytesStaged = 0;
return TRUE;
}
HXBOOL DDDepack::ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize)
{
ULONG32 ulFrameTime = m_ulCurrentTime;
ULONG32 ulOffset = 0;
UINT32 uFrameLen = 0;
UINT8* pPayloadBuf;
ULONG32 ulPayloadLen = 0;
if(m_ulPayloadBufSize < ulSize)
{
// We need to make the payload buffer larger
UINT8* pNewBuf = new UINT8[ulSize];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
return FALSE;
}
delete [] m_pPayloadBuf;
m_pPayloadBuf = pNewBuf;
m_ulPayloadBufSize = ulSize;
}
do
{
pPayloadBuf = pBuffer + ulOffset;
//Audio data need to start with a valid Dolby Digital frame, check Syncword 0x0b77
if( *pPayloadBuf == 0x0b && *(pPayloadBuf+1) == 0x77)
{
if(m_bIsDDPlus)
{
//Get Dolby Digital Plus frame length
/*First 2 byte of the PayloadData block contains the Syncword (0x0b77)
Word Size
bsi()
{
strmtyp 2
substreamid 3
frmsiz 11
...
..
}
To extract the framesize we need last 3 bits from the third byte of PayloadData block and the next byte
of PayloadData block.
'frmsiz' field indicates a value one less than the overall size of the coded frame in 16-bit words. That
is, this field may assume a value ranging from 0 to 2047, and these values correspond to frame
sizes ranging from 1 to 2048. */
uFrameLen = ((((*(pPayloadBuf+2)&0x07)<<8) | *(pPayloadBuf+3)) + 1) * 2;
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
memcpy(m_pPayloadBuf + ulOffset, pPayloadBuf, uFrameLen);
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//Get Dolby Digital frame length
UINT8 uFrameInfoByte = *(pPayloadBuf+4);
UINT8 uFameSizeCode = uFrameInfoByte & 0x3f;
UINT8 uSampleRateCode = uFrameInfoByte >> 6;
if ( uFameSizeCode < 38 && uSampleRateCode < 3 )
{
uFrameLen = uDDFrameSizetTbl[uFameSizeCode][uSampleRateCode];
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
memcpy(m_pPayloadBuf + ulOffset, pPayloadBuf, uFrameLen);
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//This is not a real sync word, try to find the next sync word
*pPayloadBuf = 0;
}
}
}
else
{
//Lost sync, try to find the next sync word in the buffer
ULONG32 ulNextSyncOffset = 0;
if((ulSize - ulOffset)>1 && FindSyncWord(pPayloadBuf, ulNextSyncOffset, ulSize - ulOffset))
{
ulOffset+= ulNextSyncOffset;
continue;
}
else
{
//can not find sync word in the buffer, discard the buffer
ulOffset = ulSize;
break;
}
}
}while(ulOffset < ulSize);
if(ulPayloadLen)
{
m_pCallback( m_pUserData, m_ulCurrentTime,
m_pPayloadBuf,
ulPayloadLen,
m_bHadLoss);
m_bHadLoss = FALSE;
}
if(ulOffset < ulSize)
{
//Frame fragmented, need next pkt to reassemble the frame
m_ulBytesStaged = ulSize - ulOffset;
memcpy(m_pStagingBuf, pBuffer+ulOffset, m_ulBytesStaged);
m_bNeedNextPkt = TRUE;
}
else
{
//End of buffer reached
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
}
return TRUE;
}
From jgordon at real.com Mon Mar 1 17:37:20 2010
From: jgordon at real.com (Jamie Gordon)
Date: Tue Mar 2 00:49:39 2010
Subject: [datatype-dev] CR: PR 251853: Poor QoS on high bitrate content with
via RTP/UDP w/PPM
Message-ID: <4B8C6BD0.9030101@real.com>
Synopsis
========
Fixes PR 251853
Branches: SERVER_14_0, HEAD (SERVER_CURRENT)
Suggested Reviewer: jj, anyone
Description
===========
Pure TimeStampDelivery causes much too bursty sending for high bitrate
content, thus causing avoidable packet loss. Change is to smooth sending
times of packets with the same delivery/decode timestamp based on
MaxBitRate if present, AvgBitrate * OversendRate if oversending, or
AvgBitRate*2.
Also fixes a bug in mp4ff where it was no longer setting the MaxBitRate
for mp4v and mp4a. This backs out a changed made to fix something for
client local playback I think (checkin comment just says "Changes to fix
problem of high memory consumption"). Whatever the problem was, it needs
to be fixed properly, not by not passing the MaxBitRate along as
expected.
Files Affected
==============
server/engine/dataflow/ppm.cpp
server/engine/dataflow/pub/ppm.h
server/engine/dataflow/pub/strmdata.h
datatype/mp4/fileformat/qtatmmgs.cpp
datatype/mp4/fileformat/qttrack.cpp
datatype/mp4/fileformat/pub/qtatmmgs.h
Testing Performed
=================
Unit Tests:
Integration Tests:
* RealPlayer SP (set to RTP): Verified no loss reported in player
stats, smooth non-bursty, non-lossy delivery rate apparent in packet
capture, and good playback QoS
* QuickTime: Verified smooth non-bursty, non-lossy delivery rate
apparent in packet capture, and good playback QoS. (Except when bring
window
in/out of focus, but that is a QT player bug).
* VLC: Verified smooth non-bursty, non-lossy delivery rate apparent in
packet capture, and good playback QoS.
Leak Tests:
Performance Tests:
Platforms Tested: win32-i386-vc7
Build verified: win32-i386-vc7
QA Hints
===============
-------------- next part --------------
Index: server/engine/dataflow/ppm.cpp
===================================================================
RCS file: /cvsroot/server/engine/dataflow/ppm.cpp,v
retrieving revision 1.131.2.4
diff -u -w -r1.131.2.4 ppm.cpp
--- server/engine/dataflow/ppm.cpp 22 Feb 2010 04:33:46 -0000 1.131.2.4
+++ server/engine/dataflow/ppm.cpp 2 Mar 2010 01:07:11 -0000
@@ -506,6 +506,7 @@
PPMStreamData::PPMStreamData()
: m_pPauseAdvise(NULL)
, m_pExpectedRuleSeqNoArray(NULL)
+ , m_tLastSendTime(0, 0)
{
#ifdef PAULM_STREAMDATATIMING
g_StreamDataTimer.Add(this);
@@ -561,6 +562,9 @@
m_ulFirstDeliveryTime = 0;
m_pTSConverter = NULL;
+ m_ulLastPacketTime = 0;
+ m_ulLastPacketSize = 0;
+
m_pLinkCharParams = NULL;
m_pStreamAdaptParams = NULL;
m_bNeedsConfigPacket = FALSE; // For RTMP Live
@@ -1800,37 +1804,74 @@
}
void
-PPM::Session::JumpStart(UINT16 uStreamNumber)
+PPM::Session::ScheduleTSD(PPMStreamData* pStreamData,
+ ServerPacket* pNextPacket, HXBOOL bFirstPacket)
{
- HX_ASSERT(!m_bIsLive);
- if (m_bIsLive)
+ Timeval tNow = m_pProc->pc->engine->now;
+ Timeval tScheduleTime;
+
+ ULONG32 ulPacketTimeStamp = pNextPacket->GetTime();
+ INT32 lTSDiff = 0;
+ if (!bFirstPacket)
{
- return;
+ lTSDiff = DiffTimeStamp(ulPacketTimeStamp,
+ pStreamData->m_ulLastPacketTime);
}
- PPMStreamData* pStreamData = m_pStreamData + uStreamNumber;
- HX_ASSERT(pStreamData->m_bStreamRegistered);
+ // If we have multiple packets with the same time stamp,
+ // send at the MaxBitRate until we hit the next time stamp.
- /* Jump start the PPM if it's idle or the next packet is TS delivered */
- ServerPacket* pNextPacket = pStreamData->m_pPackets.PeekPacket();
- if (pNextPacket)
- {
- if (!m_bSessionPlaying && !m_bTimeLineSuspended)
+ // If it's less than 5ms difference, just treat is as same
+ // delivery time. That should only happen during RSD queue
+ // sending of RTP live with out of order RTP time stamps
+ if (!bFirstPacket && lTSDiff < 5)
{
- BOOL bIsFirstSeekPckt = m_bSeekPacketPending ? TRUE : FALSE;
- ResetSessionTimeline(pNextPacket, uStreamNumber, bIsFirstSeekPckt);
+ tScheduleTime = pStreamData->m_tLastSendTime;
+ UINT32 ulRate;
- m_bSeekPacketPending = FALSE;
- m_bSessionPlaying = TRUE;
+ if (pStreamData->m_ulMaxBitRate)
+ {
+ // if we have a max bitrate, send based on that rate
+ ulRate = pStreamData->m_ulMaxBitRate;
+ }
+ else if (m_fDeliveryRatio > 1.0)
+ {
+ // if we are already oversending, just send at the oversend
+ // ratio of the average rate
+ ulRate = pStreamData->m_ulAvgBitRate;
+ }
+ else
+ {
+ // if we do not have a max bitrate and are not oversending,
+ // let's go with 2x AvgBitRate
+ ulRate = pStreamData->m_ulAvgBitRate * 2;
}
- if ((pStreamData->m_pRules[pNextPacket->m_uASMRuleNumber].
- m_bTimeStampDelivery) &&
- (!pStreamData->m_uTimeStampScheduledSendID) && (!IsPaused()))
+ // for crazy low bit rate stuff (like text) don't try to do this,
+ // just send it now
+ if (ulRate > 500)
{
- Timeval tTimeStamp;
- ULONG32 ulPacketTimeStamp = pNextPacket->GetTime();
+ // Get time offset (in microseconds)
+ lTSDiff = 1000 * ((INT32)(8000 * pStreamData->m_ulLastPacketSize) / ulRate);
+
+ if (m_fDeliveryRatio > 0.0)
+ {
+ lTSDiff = (INT32)((lTSDiff / m_fDeliveryRatio) + .5);
+ }
+ tScheduleTime += lTSDiff;
+ }
+ else if (lTSDiff > 0)
+ {
+ tScheduleTime += lTSDiff * 1000;
+ }
+ if (tScheduleTime < tNow)
+ {
+ tScheduleTime = tNow;
+ }
+ }
+ else
+ {
if (pStreamData->m_pSession->m_bIsLive)
{
//If this is the first live packet since the player requested
@@ -1862,34 +1903,28 @@
ulPacketTimeStamp = (UINT32) ((float)ulPacketTimeStamp / m_fDeliveryRatio);
}
- tTimeStamp.tv_sec = ulPacketTimeStamp / 1000;
- tTimeStamp.tv_usec = (ulPacketTimeStamp % 1000) * 1000;
-
/*
* Schedule the next packet based on it's
* delivery time with respect to the current
* timeline.
*/
- if ( (m_tTimeLineStart + tTimeStamp) >
- m_pProc->pc->engine->now)
+ tScheduleTime.tv_sec = ulPacketTimeStamp / 1000;
+ tScheduleTime.tv_usec = (ulPacketTimeStamp % 1000) * 1000;
+ tScheduleTime += m_tTimeLineStart;
+
+ if (tScheduleTime > tNow)
{
/* early: schedule for some time in the future */
- pStreamData->m_uTimeStampScheduledSendID =
- m_pProc->pc->engine->ischedule.enter(
- m_tTimeLineStart + tTimeStamp,
- pStreamData->m_pTimeStampCallback);
- pStreamData->m_tLastScheduledTime = m_tTimeLineStart +
- tTimeStamp;
}
- else if ( ((m_tTimeLineStart + tTimeStamp) <
- m_pProc->pc->engine->now) &&
- (pStreamData->m_ulMaxBitRate > 500) )
+ else if (tScheduleTime < tNow && pStreamData->m_ulMaxBitRate > 500)
+ {
+ /* late: send now! (unless we excede max birate) */
+
/* The MaxBitRate > 500 constraint exists to account for event streams
wherein the current bitrate may exceed in the case of seek, etc. the
max bit rate. */
- {
- /* late: send now! (unless we excede max birate) */
+
UINT32 ulCurrentBitRate = pStreamData->m_pRules[pNextPacket->m_uASMRuleNumber].
m_BitRate.GetAverageBandwidth();
@@ -1904,33 +1939,61 @@
#endif
(ulCurrentBitRate <= pStreamData->m_ulMaxBitRate) )
{
- pStreamData->m_uTimeStampScheduledSendID =
- m_pProc->pc->engine->ischedule.enter(
- m_pProc->pc->engine->now,
- pStreamData->m_pTimeStampCallback);
- pStreamData->m_tLastScheduledTime = m_pProc->pc->engine->now;
+ tScheduleTime = tNow;
}
else
{
- pStreamData->m_tLastScheduledTime =
- pStreamData->m_tLastScheduledTime + (1000 *
- (INT32)((1000 * pNextPacket->GetSize() * 8) /
+ tScheduleTime = pStreamData->m_tLastScheduledTime +
+ (1000 *(INT32)((1000 * pNextPacket->GetSize() * 8) /
pStreamData->m_ulMaxBitRate));
- pStreamData->m_uTimeStampScheduledSendID =
- m_pProc->pc->engine->ischedule.enter(
- pStreamData->m_tLastScheduledTime,
- pStreamData->m_pTimeStampCallback);
}
}
else
{
/* on-time or no max bitrate: schedule for "now" */
+ tScheduleTime = tNow;
+ }
+ }
+
pStreamData->m_uTimeStampScheduledSendID =
- m_pProc->pc->engine->ischedule.enter(
- m_pProc->pc->engine->now,
+ m_pProc->pc->engine->ischedule.enter(tScheduleTime,
pStreamData->m_pTimeStampCallback);
- pStreamData->m_tLastScheduledTime = m_pProc->pc->engine->now;
+
+ pStreamData->m_tLastScheduledTime = tScheduleTime;
}
+
+void
+PPM::Session::JumpStart(UINT16 uStreamNumber)
+{
+ HX_ASSERT(!m_bIsLive);
+ if (m_bIsLive)
+ {
+ return;
+ }
+
+ PPMStreamData* pStreamData = m_pStreamData + uStreamNumber;
+ HX_ASSERT(pStreamData->m_bStreamRegistered);
+
+ /* Jump start the PPM if it's idle or the next packet is TS delivered */
+ ServerPacket* pNextPacket = pStreamData->m_pPackets.PeekPacket();
+ if (pNextPacket)
+ {
+ HXBOOL bFirstPacket = FALSE;
+ if (!m_bSessionPlaying && !m_bTimeLineSuspended)
+ {
+ bFirstPacket = TRUE;
+ BOOL bIsFirstSeekPckt = m_bSeekPacketPending ? TRUE : FALSE;
+ ResetSessionTimeline(pNextPacket, uStreamNumber, bIsFirstSeekPckt);
+
+ m_bSeekPacketPending = FALSE;
+ m_bSessionPlaying = TRUE;
+ }
+
+ if ((pStreamData->m_pRules[pNextPacket->m_uASMRuleNumber].
+ m_bTimeStampDelivery) &&
+ (!pStreamData->m_uTimeStampScheduledSendID) && (!IsPaused()))
+ {
+ ScheduleTSD(pStreamData, pNextPacket, bFirstPacket);
}
else
{
@@ -2010,10 +2073,13 @@
* We should support BackToBack packets & aggregation here. But we never
* did before, so...
*/
- m_ulCurrentPacketTS = pPacket->GetTime();
+
+ pSD->m_ulLastPacketTime = m_ulCurrentPacketTS = pPacket->GetTime();
+ pSD->m_ulLastPacketSize = pPacket->GetSize();
+ pSD->m_tLastSendTime = m_pProc->pc->engine->now;
pSD->m_pTransport->sendPacket(pPacket);
- *g_pBytesServed += pPacket->GetSize();
+ *g_pBytesServed += pSD->m_ulLastPacketSize;
(*g_pPPS)++;
if (pSD->IsStreamDone())
@@ -2046,14 +2112,23 @@
if (m_bTimeLineSuspended && (bState == TRUE))
{
m_bTimeLineSuspended = FALSE;
- m_usStreamsRestarted = 0;
m_bRTPInfoRequired = TRUE;
+ for (UINT16 i = 0; i < m_unStreamCount; i++)
+ {
+ m_pStreamData[i].ResumeTimeline();
+ }
}
else if ((!m_bTimeLineSuspended) && (bState == FALSE))
{
m_bTimeLineSuspended = TRUE;
m_unSyncStream = HX_INVALID_STREAM;
m_unSyncReadyStreams = 0;
+
+ if(m_RSDCBhandle)
+ {
+ m_pPPM->m_pProc->pc->engine->ischedule.remove(m_RSDCBhandle);
+ m_RSDCBhandle = 0;
+ }
for (UINT16 i = 0; i < m_unStreamCount; i++)
{
m_pStreamData[i].SuspendTimeline(m_tTimeLineStart);
@@ -7165,6 +7240,15 @@
}
void
+PPMStreamData::ResumeTimeline(void)
+{
+ if (m_bStreamRegistered)
+ {
+ m_unStartingSeqNum = m_unSequenceNumber;
+ }
+}
+
+void
PPMStreamData::SuspendTimeline(Timeval& tvTimelineStart)
{
if (m_bStreamRegistered)
@@ -7173,6 +7257,11 @@
m_ulFirstPacketTS = 0;
m_bFirstPacketTSSet = FALSE;
m_bSyncReady = FALSE;
- m_unStartingSeqNum = m_unSequenceNumber;
+
+ if (m_uTimeStampScheduledSendID)
+ {
+ m_pSession->m_pPPM->m_pProc->pc->engine->ischedule.remove(m_uTimeStampScheduledSendID);
+ m_uTimeStampScheduledSendID = 0;
+ }
}
}
Index: server/engine/dataflow/pub/ppm.h
===================================================================
RCS file: /cvsroot/server/engine/dataflow/pub/ppm.h,v
retrieving revision 1.53.20.1
diff -u -w -r1.53.20.1 ppm.h
--- server/engine/dataflow/pub/ppm.h 29 Jan 2010 19:57:13 -0000 1.53.20.1
+++ server/engine/dataflow/pub/ppm.h 2 Mar 2010 01:07:11 -0000
@@ -309,6 +309,9 @@
UINT32 ulTimestamp);
void JumpStart(UINT16 uStreamNumber);
+ void ScheduleTSD(PPMStreamData* pStreamData,
+ ServerPacket* pNextPacket,
+ HXBOOL bFirstPacket);
void ScheduleStreamDone(Session* pSession,
Transport* pTransport,
PPMStreamData* pSD,
@@ -425,7 +428,6 @@
BOOL m_bSeekPacketPending;
BOOL m_bSessionPlaying;
BOOL m_bStallPackets;
- UINT16 m_usStreamsRestarted;
BOOL m_bNeedStreamStartTime;
IHXList* m_pBlockedQ;
@@ -494,6 +496,7 @@
UINT32 m_ulCurrentPacketTS;
UINT32 m_ulNPTStartTime;
+
#ifdef HELIX_FEATURE_SERVER_FCS
BOOL m_bFCSUpdateBandwidth;
BOOL m_bIsFCSRequest;
Index: server/engine/dataflow/pub/strmdata.h
===================================================================
RCS file: /cvsroot/server/engine/dataflow/pub/strmdata.h,v
retrieving revision 1.17
diff -u -w -r1.17 strmdata.h
--- server/engine/dataflow/pub/strmdata.h 8 Jan 2010 23:50:47 -0000 1.17
+++ server/engine/dataflow/pub/strmdata.h 2 Mar 2010 01:07:11 -0000
@@ -92,7 +92,6 @@
public:
Packets();
~Packets();
- void Init(UINT32 ulSize);
ServerPacket* GetPacket();
ServerPacket* PeekPacket(); /* This function violates COM Reference Rules */
HX_RESULT PutPacket(ServerPacket*);
@@ -143,11 +142,13 @@
StreamAdaptationParams* pStreamAdaptParams);
void SuspendTimeline(Timeval& tvTimelineStart);
+ void ResumeTimeline(void);
UINT16 m_unSequenceNumber;
UINT16 m_unStartingSeqNum;
- struct SequenceHistory {
+ struct SequenceHistory
+ {
UINT32 m_ulRefCount;
UINT16 m_unOutSeqNo;
UINT16* m_pRuleSeqNoArray;
@@ -212,6 +213,10 @@
UINT32 m_ulFirstRTPTS;
UINT32 m_ulFirstDeliveryTime;
+ UINT32 m_ulLastPacketTime;
+ UINT32 m_ulLastPacketSize;
+ Timeval m_tLastSendTime;
+
CHXTimestampConverter* m_pTSConverter;
UINT32 m_ulPreroll;
-------------- next part --------------
Index: datatype/mp4/fileformat/qtatmmgs.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtatmmgs.cpp,v
retrieving revision 1.69
diff -u -w -r1.69 qtatmmgs.cpp
--- datatype/mp4/fileformat/qtatmmgs.cpp 12 Jan 2010 16:54:33 -0000 1.69
+++ datatype/mp4/fileformat/qtatmmgs.cpp 2 Mar 2010 00:19:03 -0000
@@ -2307,7 +2307,6 @@
, m_ulTrackSelectionMask(0)
, m_ulAvgBitrate(0)
, m_ulMaxBitrate(0)
- , m_ulMaxRawBitrate(0)
, m_ulBandwidth(0)
, m_ulPreroll(0)
, m_ulPredata(0)
@@ -3063,7 +3062,7 @@
if (pDCDesc)
{
m_ulAvgBitrate = pDCDesc->m_ulAvgBitrate;
- m_ulMaxRawBitrate = pDCDesc->m_ulMaxBitrate;
+ m_ulMaxBitrate = pDCDesc->m_ulMaxBitrate;
uProfileObjectIndication = pDCDesc->m_uObjectProfileIndication;
uStreamType = pDCDesc->m_uStreamType;
retVal = HXR_OK;
Index: datatype/mp4/fileformat/qttrack.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qttrack.cpp,v
retrieving revision 1.45
diff -u -w -r1.45 qttrack.cpp
--- datatype/mp4/fileformat/qttrack.cpp 8 Jan 2010 04:28:17 -0000 1.45
+++ datatype/mp4/fileformat/qttrack.cpp 2 Mar 2010 00:19:03 -0000
@@ -349,7 +349,6 @@
ULONG32 ulPayloadType = QT_BAD_PAYLOAD;
ULONG32 ulAvgBitRate = 0;
ULONG32 ulMaxBitRate = 0;
- ULONG32 ulMaxRawBitRate = 0;
ULONG32 ulAvgPacketSize = 0;
ULONG32 ulPreroll = 0;
@@ -474,10 +473,7 @@
}
ulAvgPacketSize = m_TrackInfo.GetAvgPacketSize();
-
ulMaxBitRate = m_TrackInfo.GetMaxBitrate();
-
- ulMaxRawBitRate = m_TrackInfo.GetMaxRawBitrate();
ulPreroll = m_TrackInfo.GetPreroll();
ulPredata = m_TrackInfo.GetPredata();
@@ -498,11 +494,6 @@
pHeader->SetPropertyULONG32("MaxBitRate", ulMaxBitRate);
}
- if (ulMaxRawBitRate != 0)
- {
- pHeader->SetPropertyULONG32("MaxRawBitRate", ulMaxRawBitRate);
- }
-
if (ulPreroll != 0)
{
pHeader->SetPropertyULONG32("Preroll", ulPreroll);
Index: datatype/mp4/fileformat/pub/qtatmmgs.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatmmgs.h,v
retrieving revision 1.34
diff -u -w -r1.34 qtatmmgs.h
--- datatype/mp4/fileformat/pub/qtatmmgs.h 8 Jan 2010 04:29:25 -0000 1.34
+++ datatype/mp4/fileformat/pub/qtatmmgs.h 2 Mar 2010 00:19:03 -0000
@@ -921,9 +921,7 @@
}
ULONG32 GetAvgBitrate(void) { return m_ulAvgBitrate; }
-
ULONG32 GetMaxBitrate(void) { return m_ulMaxBitrate; }
- ULONG32 GetMaxRawBitrate(void) { return m_ulMaxRawBitrate; }
ULONG32 GetNeededBandwidth(void){ return m_ulBandwidth; }
void SetNeededBandwidth(ULONG32 ulBandwidth)
@@ -989,7 +987,6 @@
ULONG32 m_ulTrackSelectionMask;
ULONG32 m_ulAvgBitrate;
ULONG32 m_ulMaxBitrate;
- ULONG32 m_ulMaxRawBitrate;
ULONG32 m_ulBandwidth;
ULONG32 m_ulPreroll;
ULONG32 m_ulPredata;
From anuj.dhamija at nokia.com Tue Mar 2 12:27:18 2010
From: anuj.dhamija at nokia.com (anuj.dhamija@nokia.com)
Date: Tue Mar 2 19:39:57 2010
Subject: [datatype-dev] CR: ou1cimx1#286262/RBRO-82WBZS - Seek not working
for audio only Matroska Clip
In-Reply-To:
References:
Message-ID:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: anuj.dhamija@nokia.com
Reviewed by:
Date: 03/01/2010
Case ID: ou1cimx1#286262 /RBRO-82WBZS
Synopsis: Seek not working for audio only Matroska Clip
Overview/Fix:
Logic to parse Cue Data (used for seeking in Matroska Files) has check for including cue data for only Video Tracks.
Due to this, cue data for audio-only track is not parsed and seeking fails.
New check is introduced to include cue data anyways if only one track is present (for multiple tracks however consider only video track).
Files modified & changes:
datatype\mkv\libmatroska\matroska.cpp
Image Size and Heap Use impact: None
Module Release testing (STIF, Audio) : Passed
Test case(s) Added : None
Memory leak check performed : Passed, No leaks found
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Branches: 210Cays, HEAD, 420Brizo
CVS Diff:
Index: Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.5
diff -u -r1.1.1.1.2.5 Matroska.cpp
--- Matroska.cpp 3 Feb 2010 23:00:17 -0000 1.1.1.1.2.5
+++ Matroska.cpp 2 Mar 2010 19:34:16 -0000
@@ -249,7 +249,7 @@
idx->uTrack = uint16( ctrack );
MKVTrack* trk = FindTrack(idx->uTrack);
- if(trk && trk->type == TrackVideo)
+ if(trk && ((m_Tracks.size() <= 1) || (trk->type == TrackVideo)))
{
if(fTimeMS >= 0.0)
{
thnx & regds
AD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100302/bce270c8/attachment-0001.html
From gwright at real.com Tue Mar 2 13:15:26 2010
From: gwright at real.com (Gregory Wright)
Date: Tue Mar 2 20:27:21 2010
Subject: [datatype-dev] CR: TRLM-82LFA5:mpxplaybackserver crashing with
EExcDataAbort, 23. 9.2 defect
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE2240096D87@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE2240096D87@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <7D6E8457-6BE3-4467-9445-BE3FE6021F80@real.com>
Wasn't this already CR'ed?
Anyway, looks good.
--greg.
On Feb 22, 2010, at 4:38 AM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement?
>
> Modified By: ext-g.manikanda@nokia.com
>
> Reviewed By:rajesh.rathinasamy@nokia.com
>
> TSW-ID: TRLM-82LFA5
>
> Date: 02/22/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Playing corrupted avi file Mpxplaybackserver crashing with EExcDataAbort.
>
> Overview:
> When intializing fileformat CRIFFReader( as m_pReader) is created by CAVIIndex it increments reference count to 1. In CRIFFReader::Open(), CHXMiniFileObject adds one more reference to this object(reference count is now 2 for m_pReader). For attached corrupt file playback CAVIIndex::RIFFFindChunkDone fails with HXR_READ_ERROR, following this it deletes m_pReader(CRIFFReader) object (even though refernce count was 2). When reporting error through m_pFileResponse is NULL in CHXMiniFileObject::ReadDoneError() because CHXMiniFileObject::Close() was called when m_pReader was deleted , so it causes the crash.
>
> Fix: There is no need to delete m_pReader in CAVIIndex::RIFFFindChunkDone() as this is done in CAVIIndex::Close(). Therefore removing the unnecessary call.
>
> Files modified & changes for 420Brizo, 210Cays and Head.
> \sf\mw\helix\helix_ren\src\datatype\avi\fileformat\aviindx.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Yes
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5 and winscw
>
> Branch : 210Cays, 420Brizo & Head
>
> CVS Diff:
> Index: avi/fileformat/aviindx.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/avi/fileformat/aviindx.cpp,v
> retrieving revision 1.6.6.2
> diff -u -w -r1.6.6.2 aviindx.cpp
> --- avi/fileformat/aviindx.cpp 21 Jan 2009 16:15:47 -0000 1.6.6.2
> +++ avi/fileformat/aviindx.cpp 19 Feb 2010 13:41:28 -0000
> @@ -622,8 +622,6 @@
>
> if (FAILED(status) || len == 0)
> {
> - // No index; release reader:
> - HX_DELETE(m_pReader);
> m_state = eReady;
> m_pOuter->IOEvent();
> return HXR_OK;
>
>
From gwright at real.com Tue Mar 2 13:20:22 2010
From: gwright at real.com (Gregory Wright)
Date: Tue Mar 2 20:32:13 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:
ou1cimx1#286262/RBRO-82WBZS - Seek not
working for audio only Matroska Clip
In-Reply-To:
References:
Message-ID: <04E8E281-1A20-47AB-A694-D51030DA0336@real.com>
Looks good.
Is this code Helix code or pulled form the Matroska libs? If the later,
we should probably see if there has been an update from Xiph.
--greg.
On Mar 2, 2010, at 12:27 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: anuj.dhamija@nokia.com
>
> Reviewed by:
>
> Date: 03/01/2010
> Case ID: ou1cimx1#286262 /RBRO-82WBZS
> Synopsis: Seek not working for audio only Matroska Clip
> Overview/Fix:
> Logic to parse Cue Data (used for seeking in Matroska Files) has check for including cue data for only Video Tracks.
> Due to this, cue data for audio-only track is not parsed and seeking fails.
> New check is introduced to include cue data anyways if only one track is present (for multiple tracks however consider only video track).
>
> Files modified & changes:
> datatype\mkv\libmatroska\matroska.cpp
>
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF, Audio) : Passed
>
> Test case(s) Added : None
>
> Memory leak check performed : Passed, No leaks found
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Branches: 210Cays, HEAD, 420Brizo
>
> CVS Diff:
>
> Index: Matroska.cpp
> ===================================================================
> RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
> retrieving revision 1.1.1.1.2.5
> diff -u -r1.1.1.1.2.5 Matroska.cpp
> --- Matroska.cpp 3 Feb 2010 23:00:17 -0000 1.1.1.1.2.5
> +++ Matroska.cpp 2 Mar 2010 19:34:16 -0000
> @@ -249,7 +249,7 @@
> idx->uTrack = uint16( ctrack );
>
> MKVTrack* trk = FindTrack(idx->uTrack);
> - if(trk && trk->type == TrackVideo)
> + if(trk && ((m_Tracks.size() <= 1) || (trk->type == TrackVideo)))
> {
> if(fTimeMS >= 0.0)
> {
>
> thnx & regds
> AD
>
>
>
>
>
>
From anuj.dhamija at nokia.com Tue Mar 2 13:35:46 2010
From: anuj.dhamija at nokia.com (anuj.dhamija@nokia.com)
Date: Tue Mar 2 20:48:17 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR:
ou1cimx1#286262/RBRO-82WBZS - Seek not
working for audio only Matroska Clip
In-Reply-To: <04E8E281-1A20-47AB-A694-D51030DA0336@real.com>
References:
<04E8E281-1A20-47AB-A694-D51030DA0336@real.com>
Message-ID:
Hi Greg,
Matroska.cpp is helix code..
thnx ..i will checkin.
regds
AD
-----Original Message-----
From: ext Gregory Wright [mailto:gwright@real.com]
Sent: Tuesday, March 02, 2010 3:20 PM
To: Dhamija Anuj (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: ou1cimx1#286262/RBRO-82WBZS - Seek not working for audio only Matroska Clip
Looks good.
Is this code Helix code or pulled form the Matroska libs? If the later,
we should probably see if there has been an update from Xiph.
--greg.
On Mar 2, 2010, at 12:27 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: anuj.dhamija@nokia.com
>
> Reviewed by:
>
> Date: 03/01/2010
> Case ID: ou1cimx1#286262 /RBRO-82WBZS
> Synopsis: Seek not working for audio only Matroska Clip
> Overview/Fix:
> Logic to parse Cue Data (used for seeking in Matroska Files) has check for including cue data for only Video Tracks.
> Due to this, cue data for audio-only track is not parsed and seeking fails.
> New check is introduced to include cue data anyways if only one track is present (for multiple tracks however consider only video track).
>
> Files modified & changes:
> datatype\mkv\libmatroska\matroska.cpp
>
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF, Audio) : Passed
>
> Test case(s) Added : None
>
> Memory leak check performed : Passed, No leaks found
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Branches: 210Cays, HEAD, 420Brizo
>
> CVS Diff:
>
> Index: Matroska.cpp
> ===================================================================
> RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
> retrieving revision 1.1.1.1.2.5
> diff -u -r1.1.1.1.2.5 Matroska.cpp
> --- Matroska.cpp 3 Feb 2010 23:00:17 -0000 1.1.1.1.2.5
> +++ Matroska.cpp 2 Mar 2010 19:34:16 -0000
> @@ -249,7 +249,7 @@
> idx->uTrack = uint16( ctrack );
>
> MKVTrack* trk = FindTrack(idx->uTrack);
> - if(trk && trk->type == TrackVideo)
> + if(trk && ((m_Tracks.size() <= 1) || (trk->type == TrackVideo)))
> {
> if(fTimeMS >= 0.0)
> {
>
> thnx & regds
> AD
>
>
>
>
>
>
From anuj.dhamija at nokia.com Tue Mar 2 14:15:32 2010
From: anuj.dhamija at nokia.com (anuj.dhamija@nokia.com)
Date: Tue Mar 2 21:28:10 2010
Subject: [datatype-dev] CN: ou1cimx1#286262/RBRO-82WBZS - Seek not working
for audio only Matroska Clip
References:
<04E8E281-1A20-47AB-A694-D51030DA0336@real.com>
Message-ID:
Checked in on 210Cays, Head and 420Brizo
thnx & Regds
AD
-----Original Message-----
From: Dhamija Anuj (Nokia-D/Dallas)
Sent: Tuesday, March 02, 2010 3:36 PM
To: 'ext Gregory Wright'
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: RE: [Nokia-private-dev] CR: ou1cimx1#286262/RBRO-82WBZS - Seek not working for audio only Matroska Clip
Hi Greg,
Matroska.cpp is helix code..
thnx ..i will checkin.
regds
AD
-----Original Message-----
From: ext Gregory Wright [mailto:gwright@real.com]
Sent: Tuesday, March 02, 2010 3:20 PM
To: Dhamija Anuj (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: ou1cimx1#286262/RBRO-82WBZS - Seek not working for audio only Matroska Clip
Looks good.
Is this code Helix code or pulled form the Matroska libs? If the later,
we should probably see if there has been an update from Xiph.
--greg.
On Mar 2, 2010, at 12:27 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: anuj.dhamija@nokia.com
>
> Reviewed by:
>
> Date: 03/01/2010
> Case ID: ou1cimx1#286262 /RBRO-82WBZS
> Synopsis: Seek not working for audio only Matroska Clip
> Overview/Fix:
> Logic to parse Cue Data (used for seeking in Matroska Files) has check for including cue data for only Video Tracks.
> Due to this, cue data for audio-only track is not parsed and seeking fails.
> New check is introduced to include cue data anyways if only one track is present (for multiple tracks however consider only video track).
>
> Files modified & changes:
> datatype\mkv\libmatroska\matroska.cpp
>
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF, Audio) : Passed
>
> Test case(s) Added : None
>
> Memory leak check performed : Passed, No leaks found
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Branches: 210Cays, HEAD, 420Brizo
>
> CVS Diff:
>
> Index: Matroska.cpp
> ===================================================================
> RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
> retrieving revision 1.1.1.1.2.5
> diff -u -r1.1.1.1.2.5 Matroska.cpp
> --- Matroska.cpp 3 Feb 2010 23:00:17 -0000 1.1.1.1.2.5
> +++ Matroska.cpp 2 Mar 2010 19:34:16 -0000
> @@ -249,7 +249,7 @@
> idx->uTrack = uint16( ctrack );
>
> MKVTrack* trk = FindTrack(idx->uTrack);
> - if(trk && trk->type == TrackVideo)
> + if(trk && ((m_Tracks.size() <= 1) || (trk->type == TrackVideo)))
> {
> if(fTimeMS >= 0.0)
> {
>
> thnx & regds
> AD
>
>
>
>
>
>
From ehyche at real.com Wed Mar 3 10:17:26 2010
From: ehyche at real.com (Eric Hyche)
Date: Wed Mar 3 17:29:58 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A28C5D34132@NOK-EUMSG-02.mgdnok.nokia.com>
References: <19113978AB61DA44AC317B211CF1C32A28C5D34132@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07DAEFAC39@SEAMBX.corp.real.com>
Sheldon/Qiang:
Can one of you take a look at this?
Eric
Eric Hyche
Principal Engineer, RealNetworks
ehyche@real.com
________________________________
From: saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
Sent: Wednesday, March 03, 2010 12:55 PM
To: Eric Hyche
Subject: FW: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
Any comment on this?
______________________________________________
From: Adookkattil Saleem (Nokia-D/Dallas)
Sent: Tuesday, March 02, 2010 6:04 PM
To: 'nokia-private-dev@helixcommunity.org'
Subject: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
Hi,
DRM protected MP4 file parsing is failing due to a change in MP4 file format project (qtffplin.cpp) made recently. Please see the below given diff.
https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.cpp?r1=1.60.2.8&r2=1.60.2.3.14.1
Function call retVal = m_pAtomizer->Atomize(); changed to retVal = m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
When we pass the file size as the second parameter, DRM file parsing is failing in the below given function of CAtomizer class (atomizer.cpp) with error code HXR_CORRUPT_FILE.
/****************************************************************************
* CompleteAtomization
*/
void CAtomizer::CompleteAtomization(HX_RESULT status)
{
CQTAtom* pRoot;
fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset, *(((INT32*)(&m_ullCurrentOffset)) + 1));
fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization m_ullFinalOffset %d, %d\n", m_ullFinalOffset, *(((INT32*)(&m_ullFinalOffset)) + 1));
if (!m_pRoot)
{
return;
}
if (SUCCEEDED(status))
{
// Record the amount of data atomized
CQTAtom *pRoot = m_pCurrentRoot;
HX_ASSERT(pRoot);
// If we have the position of where next atom would be,
// compute unspecified atom sizes
if (m_ullNewAtomOffset != ATOMIZE_ALL)
{
while (pRoot)
{
if (pRoot->GetSize() == ATOMIZE_ALL)
{
pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
}
// Move to the parent
pRoot = pRoot->GetParent();
}
m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
}
status = AdjustCurrentRoot();
}
if (SUCCEEDED(status))
{
if (m_ullFinalOffset != ATOMIZE_ALL)
{
m_ullCurrentOffset = m_ullCurrentOffset > m_ullFinalOffset ? m_ullFinalOffset : m_ullCurrentOffset;
}
// See if parsing fully completed
if (((m_ullFinalOffset != ATOMIZE_ALL) &&
(m_ullFinalOffset != m_ullCurrentOffset)) ||
(m_pRoot != m_pCurrentRoot))
{
status = HXR_CORRUPT_FILE;
}
}
else
{
// Data compromizing failure occured during atomization
HX_RELEASE(m_pRoot);
}
HX_RELEASE(m_pNewAtom);
m_State = ATMZR_Ready;
pRoot = m_pRoot;
m_pRoot = NULL;
m_pCurrentRoot = NULL;
m_pResponse->AtomReady(status, pRoot);
if (pRoot)
{
pRoot->Release();
}
}
The reason for the failure is the value of ullCurrentOffset is less than m_ullFinalOffset.
If we keep the previous function call, there is no error (ie, retVal = m_pAtomizer->Atomize(); )
Whats the reason for this change? Any suggestion to fix this error?
Thanks & regards
Saleem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100303/090fe3aa/attachment-0001.html
From ext-liz.fu at nokia.com Wed Mar 3 12:55:38 2010
From: ext-liz.fu at nokia.com (ext-liz.fu@nokia.com)
Date: Wed Mar 3 20:08:30 2010
Subject: [datatype-dev] CR: Merge Real's fix of seek to end problem to 420
and 210 Branches
Message-ID: <218D7B58E1EF544A8DF24C14758BE77028BF1FC3D3@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: [Nokia-private-dev] FW: FW: [datatype-dev] CR: Fixing asf
fileformat clips sitting in idle for few seconds instead of returning
immediately after seeking to the end
Date: Fri, 19 Feb 2010 20:45:20 +0100
Size: 13086
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100303/06f90935/attachment.mht
-------------- next part --------------
Index: asf_file_format_file.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
retrieving revision 1.22.4.2
diff -u -w -r1.22.4.2 asf_file_format_file.cpp
--- asf_file_format_file.cpp 19 Oct 2009 17:14:59 -0000 1.22.4.2
+++ asf_file_format_file.cpp 3 Mar 2010 18:56:47 -0000
@@ -1127,9 +1127,14 @@
}
else
{
- // We tried to find another index object but could not, so just
- // seek to the first packet and read from there.
- m_ullSeekOffsetRequested = m_ullFirstASFPacketFileOffset;
+ // We tried to find another index object but could not, so seek to the largest index.
+ // if failed, just seek to the first packet and read from there.
+ UINT32 ulActualSeekTime = 0;
+ UINT64 ullSeekOffset = 0;
+
+ retVal = SearchIndexTable(m_ulDesiredSeekPresTime, TRUE, ulActualSeekTime, ullSeekOffset);
+ m_ullSeekOffsetRequested = SUCCEEDED(retVal) ? ullSeekOffset : m_ullFirstASFPacketFileOffset;
+
// Set the state saying this is the final seek prior to calling SeekDone()
m_ulState = kStateSeekFinalSeekDonePending;
// Now seek the file object to the first ASF packet
-------------- next part --------------
Index: asf_file_format_file.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
retrieving revision 1.5.4.16
diff -u -w -r1.5.4.16 asf_file_format_file.cpp
--- asf_file_format_file.cpp 24 Feb 2010 20:35:05 -0000 1.5.4.16
+++ asf_file_format_file.cpp 3 Mar 2010 19:03:36 -0000
@@ -1133,8 +1133,20 @@
}
else
{
- // The read failed
- retVal = status;
+ // We tried to find another index object but could not, so seek to the largest index.
+ // if failed, just seek to the first packet and read from there.
+ UINT32 ulActualSeekTime = 0;
+ UINT64 ullSeekOffset = 0;
+
+ retVal = SearchIndexTable(m_ulDesiredSeekPresTime, TRUE, ulActualSeekTime, ullSeekOffset);
+ m_ullSeekOffsetRequested = SUCCEEDED(retVal) ? ullSeekOffset : m_ullFirstASFPacketFileOffset;
+
+ // Set the state saying this is the final seek prior to calling SeekDone()
+ m_ulState = kStateSeekFinalSeekDonePending;
+ // Now seek the file object to the first ASF packet
+ m_pFileObject->Seek(m_ullSeekOffsetRequested, FALSE);
+ // Clear the return value
+ retVal = HXR_OK;
}
if (FAILED(retVal))
{
From sfu at real.com Wed Mar 3 13:05:17 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Mar 3 20:17:25 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: Merge Real's fix of seek
to end problem to 420 and 210 Branches
In-Reply-To: <218D7B58E1EF544A8DF24C14758BE77028BF1FC3D3@NOK-EUMSG-02.mgdnok.nokia.com>
References: <218D7B58E1EF544A8DF24C14758BE77028BF1FC3D3@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B8ECF0D.6070704@real.com>
Looks good.
fxd
ext-liz.fu@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
> Modified by: ext-liz.fu@nokia.com
> Reviewed by:
> Date: 03/03/2010
> Project: asf-fileformat
> ErrorId: N/A
> Synopsis: Merge Real?s fix of seeking to the end problem in
> asf-fileformat to 420 Brizo and 210 Cayennes
> Overview: Real fixed a problem in asf-fileformat (Fixing asf
> fileformat clips sitting in idle for few seconds instead of returning
> immediately after seeking to the end) and checked code in HEAD, 310,
> 361 and 401. Norkia is responsible to merge the fix in 420 Brizo and
> 210 Cay branches.
> Solution: Modified the code with the same code logic as Real did and
> changed variable type to match with 210 and 420. Both branches have
> the same code.
> Files Added: None.
> Files Modified:
> datatype/wm/fileformat/asf_file_format_file.cpp
> Image Size and Heap Use impact: Minor
> Module Release testing (STIF) : Tested with two clips provided by Real
> on HW for both branches.
> Test case(s) Added : No.
> Memory leak check performed : No
> Platforms and Profiles Build Verified:
> helix-client-s60-52-mmf-mdf-dsp, helix-client-symbian-4,
> Platforms and Profiles Functionality verified: armv5
> Branch: 420-Brizo, 210-Cay
> Thanks,
> Liz Fu
>
> ------------------------------------------------------------------------
>
> Subject:
> [Nokia-private-dev] FW: FW: [datatype-dev] CR: Fixing asf fileformat
> clips sitting in idle for few seconds instead of returning immediately
> after seeking to the end
> From:
> Kinson Liu
> Date:
> Fri, 19 Feb 2010 11:45:20 -0800
> To:
> "nokia-private-dev@helixcommunity.org"
>
>
> To:
> "nokia-private-dev@helixcommunity.org"
>
>
>
> Hi Nokia,
>
> This CR has been approved and checked into HEAD, 310, 361 and 401. I found 210 & 420 are so different from the other branches that I cannot just do a patch command. Since this patch is very simple and you know 210 & 420 better than I do, would it be OK if I pass this patch to you and you do the integration work?
>
> Thanks,
>
> Kinson
>
> -----Original Message-----
> From: Kinson Liu
> Sent: Thursday, February 18, 2010 5:06 PM
> To: Xiaodong (Sheldon) Fu
> Cc: Charles Chen; Qiang Luo; Eric Hyche
> Subject: RE: FW: [datatype-dev] CR: Fixing asf fileformat clips sitting in idle for few seconds instead of returning immediately after seeking to the end
>
> Thanks Sheldon. Please see the updated diff.
>
> Kinson
>
> -----Original Message-----
> From: Xiaodong (Sheldon) Fu
> Sent: Thursday, February 18, 2010 10:13 AM
> To: Kinson Liu
> Cc: Charles Chen; Qiang Luo; Eric Hyche
> Subject: Re: FW: [datatype-dev] CR: Fixing asf fileformat clips sitting in idle for few seconds instead of returning immediately after seeking to the end
>
> Firstly the PlayerDriver.cpp design of seeking to (duration-1) is wrong
> and I imagine it will cause trouble for other file format too. If
> possible we should revisit that (I remember it was added as a fix for
> some kind of bug).
>
> And This change will always bypass the 'else' logic to read the next
> index object thus will break seeking for files with multiple index
> objects (if there is any that is, but the logic implies there is). the
> fix in asf file format I think should be that after we read ALL the
> index objects at the end of file and still couldn't find an index entry,
> then we can turn the flag to TRUE and do a final SearchIndexTable and
> use the latest seek point returned from there, the code needs to be
> changed should be the else block starting at line 1141 (sorry I am on
> brizo401 so line number may not work):
>
> else
> {
> // We tried to find another index object but could not, so just
> // seek to the first packet and read from there.
> m_ulSeekOffsetRequested = m_ulFirstASFPacketFileOffset;
> // Set the state saying this is the final seek prior to calling SeekDone()
> m_ulState = kStateSeekFinalSeekDonePending;
> // Now seek the file object to the first ASF packet
> m_pFileObject->Seek(m_ulSeekOffsetRequested, FALSE);
> // Clear the return value
> retVal = HXR_OK;
> }
>
> We should add a SearchIndexTable(TRUE) here to get the latest seek point
> and go from there, instead of going back to the first packet.
>
> fxd
>
> Charles Chen wrote:
>
>> Sheldon & Qiang,
>> Eric is busy working on his own tasks, could you please review
>> Kinson's CR?
>> Thanks,
>> Charles
>>
>> ------------------------------------------------------------------------
>> *From:* datatype-dev-bounces@helixcommunity.org
>> [mailto:datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Kinson Liu
>> *Sent:* Wednesday, February 17, 2010 12:30 PM
>> *To:* datatype-dev@helixcommunity.org
>> *Subject:* [datatype-dev] CR: Fixing asf fileformat clips sitting in
>> idle for few seconds instead of returning immediately after seeking to
>> the end
>>
>> This CR is specifically for Eric Hyche as Eric wrote the asf
>> fileformat. Eric, please let me know if you see any problem changing
>> SearchIndexTable from FALSE to TRUE for that particular line of code.
>>
>> Modified by: kliu@real.com
>> Date: 02/17/2010
>>
>> Project: RealPlayer for Android Smartphones
>>
>> Bug Number: 10043
>> Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=10043
>>
>> Synopsis: Fixing asf fileformat clips sitting in idle for few seconds
>> instead of returning immediately after seeking to the end
>>
>>
>> Overview: Per the existing design of asf fileformat, if a seek does
>> not resolve to a seek index entry, file offset will point back to the
>> first packet, meaning there will be buffering and buffering will start
>> from the beginning. In this bug, we are running to exactly this
>> problem. When the user seeks to the very end of the file, the seek
>> time will be the clip duration - 1 ms (by design of PlayerDriver.cpp).
>> Because the seek time will be beyond the largest seek index entry, no
>> seek index entry will be resolved, buffering will start from the
>> beginning of the clip until it hits the seek time then the playback
>> will return. The idleness users experience comes from the buffering.
>>
>> The fix will be instead of resolving to no search index entry, resolve
>> to the largest index entry when seek time is beyond the largest index
>> entry. The SearchIndexTable function already has logic to take of
>> that, we simply turn that logic on instead of off as by default.
>>
>>
>> Files Added:
>> None
>>
>>
>> Files Modified:
>> datatype/wm/fileformat/asf_file_format_file.cpp
>>
>>
>> Image Size and Heap Use impact (Client -Only):
>> None
>>
>> Platforms and Profiles Affected:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Distribution Libraries Affected:
>> None
>>
>> Distribution library impact and planned action:
>> None
>>
>> Platforms and Profiles Build Verified:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Platforms and Profiles Functionality verified:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Branch: head, hxclient_3_1_0_atlas, hxclient_3_6_1_atlas,
>> hxclient_4_0_1brizo
>>
>>
>> Copyright assignment: I am a RealNetworks employee or contractor
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.435 / Virus Database: 271.1.1/2693 - Release Date:
>> 02/17/10 07:35:00
>>
>>
>
>
From qluo at real.com Wed Mar 3 15:53:42 2010
From: qluo at real.com (Qiang Luo)
Date: Wed Mar 3 23:04:39 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07DAEFAC39@SEAMBX.corp.real.com>
References: <19113978AB61DA44AC317B211CF1C32A28C5D34132@NOK-EUMSG-02.mgdnok.nokia.com>
<7ECCEA249B7CDC49A079EC0075E999AA07DAEFAC39@SEAMBX.corp.real.com>
Message-ID: <4B8EF686.7090406@real.com>
Hi Saleem,
I made the change of passing ulFileSize to the Atomize() function. This
was an attempt to fix a few mp4 http streaming issues. The basic idea
was to limit the atomizer offset range to be within the actual file size
if the filesystem supports IHXFileStat.
In your parsing failure case, what is your DRM and the container format
used? Is the m_ullFinalOffset the correct encrypted file size? What is
the m_ullCurrentOffset value? Does the mp4 ff handles encrypted data or
the filesystem decrypt the data first? In general, if there is no
decryptor in or sit between the filesystem and the fileformat, then the
mp4 ff logic for clear data should work for drm data.
Qiang
> ------------------------------------------------------------------------
> *From:* saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
> *Sent:* Wednesday, March 03, 2010 12:55 PM
> *To:* Eric Hyche
> *Subject:* FW: DRM protected MP4 file parsing failure with error code
> HXR_CORRUPT_FILE due to recent change
>
> Any comment on this?
> ______________________________________________
> *From: *Adookkattil Saleem (Nokia-D/Dallas)
> *Sent: *Tuesday, March 02, 2010 6:04 PM
> *To: *'nokia-private-dev@helixcommunity.org'
> *Subject: *DRM protected MP4 file parsing failure with error code
> HXR_CORRUPT_FILE due to recent change
> Hi,
> DRM protected MP4 file parsing is failing due to a change in MP4 file
> format project (qtffplin.cpp) made recently. Please see the below
> given diff.
> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>
> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
> When we pass the file size as the second parameter, DRM file parsing
> is failing in the below given function of CAtomizer class
> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
> /****************************************************************************
> * CompleteAtomization
> */
> void CAtomizer::CompleteAtomization(HX_RESULT status)
> {
> CQTAtom* pRoot;
> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
> *(((INT32*)(&m_ullCurrentOffset)) + 1));
> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
> *(((INT32*)(&m_ullFinalOffset)) + 1));
> if (!m_pRoot)
> {
> return;
> }
> if (SUCCEEDED(status))
> {
> // Record the amount of data atomized
> CQTAtom *pRoot = m_pCurrentRoot;
> HX_ASSERT(pRoot);
> // If we have the position of where next atom would be,
> // compute unspecified atom sizes
> if (m_ullNewAtomOffset != ATOMIZE_ALL)
> {
> while (pRoot)
> {
> if (pRoot->GetSize() == ATOMIZE_ALL)
> {
> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
> }
> // Move to the parent
> pRoot = pRoot->GetParent();
> }
> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
> }
> status = AdjustCurrentRoot();
> }
> if (SUCCEEDED(status))
> {
> if (m_ullFinalOffset != ATOMIZE_ALL)
> {
> m_ullCurrentOffset = m_ullCurrentOffset > m_ullFinalOffset
> ? m_ullFinalOffset : m_ullCurrentOffset;
> }
> // See if parsing fully completed
> if (((m_ullFinalOffset != ATOMIZE_ALL) &&
> (m_ullFinalOffset != m_ullCurrentOffset)) ||
> (m_pRoot != m_pCurrentRoot))
> {
> status = HXR_CORRUPT_FILE;
> }
> }
> else
> {
> // Data compromizing failure occured during atomization
> HX_RELEASE(m_pRoot);
> }
> HX_RELEASE(m_pNewAtom);
> m_State = ATMZR_Ready;
> pRoot = m_pRoot;
> m_pRoot = NULL;
> m_pCurrentRoot = NULL;
> m_pResponse->AtomReady(status, pRoot);
> if (pRoot)
> {
> pRoot->Release();
> }
> }
> The reason for the failure is the value of ullCurrentOffset is less
> than m_ullFinalOffset.
> If we keep the previous function call, there is no error (ie, retVal =
> m_pAtomizer->Atomize(); )
> Whats the reason for this change? Any suggestion to fix this error?
> Thanks & regards
> Saleem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100303/78e71792/attachment.html
From ext-liz.fu at nokia.com Wed Mar 3 15:54:26 2010
From: ext-liz.fu at nokia.com (ext-liz.fu@nokia.com)
Date: Wed Mar 3 23:06:48 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: Merge Real's fix of seek
to end problem to 420 and 210 Branches
In-Reply-To: <4B8ECF0D.6070704@real.com>
References: <218D7B58E1EF544A8DF24C14758BE77028BF1FC3D3@NOK-EUMSG-02.mgdnok.nokia.com>
<4B8ECF0D.6070704@real.com>
Message-ID: <218D7B58E1EF544A8DF24C14758BE77028BF1FC452@NOK-EUMSG-02.mgdnok.nokia.com>
Thanks,
Checked in 420 and 210 branches.
Liz
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Wednesday, March 03, 2010 3:05 PM
To: Fu Liz (EXT-DextraTech/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: Merge Real's fix of seek to end problem to 420 and 210 Branches
Looks good.
fxd
ext-liz.fu@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
> Modified by: ext-liz.fu@nokia.com
> Reviewed by:
> Date: 03/03/2010
> Project: asf-fileformat
> ErrorId: N/A
> Synopsis: Merge Real's fix of seeking to the end problem in
> asf-fileformat to 420 Brizo and 210 Cayennes
> Overview: Real fixed a problem in asf-fileformat (Fixing asf
> fileformat clips sitting in idle for few seconds instead of returning
> immediately after seeking to the end) and checked code in HEAD, 310,
> 361 and 401. Norkia is responsible to merge the fix in 420 Brizo and
> 210 Cay branches.
> Solution: Modified the code with the same code logic as Real did and
> changed variable type to match with 210 and 420. Both branches have
> the same code.
> Files Added: None.
> Files Modified:
> datatype/wm/fileformat/asf_file_format_file.cpp
> Image Size and Heap Use impact: Minor
> Module Release testing (STIF) : Tested with two clips provided by Real
> on HW for both branches.
> Test case(s) Added : No.
> Memory leak check performed : No
> Platforms and Profiles Build Verified:
> helix-client-s60-52-mmf-mdf-dsp, helix-client-symbian-4, Platforms and
> Profiles Functionality verified: armv5
> Branch: 420-Brizo, 210-Cay
> Thanks,
> Liz Fu
>
> ----------------------------------------------------------------------
> --
>
> Subject:
> [Nokia-private-dev] FW: FW: [datatype-dev] CR: Fixing asf fileformat
> clips sitting in idle for few seconds instead of returning immediately
> after seeking to the end
> From:
> Kinson Liu
> Date:
> Fri, 19 Feb 2010 11:45:20 -0800
> To:
> "nokia-private-dev@helixcommunity.org"
>
>
> To:
> "nokia-private-dev@helixcommunity.org"
>
>
>
> Hi Nokia,
>
> This CR has been approved and checked into HEAD, 310, 361 and 401. I found 210 & 420 are so different from the other branches that I cannot just do a patch command. Since this patch is very simple and you know 210 & 420 better than I do, would it be OK if I pass this patch to you and you do the integration work?
>
> Thanks,
>
> Kinson
>
> -----Original Message-----
> From: Kinson Liu
> Sent: Thursday, February 18, 2010 5:06 PM
> To: Xiaodong (Sheldon) Fu
> Cc: Charles Chen; Qiang Luo; Eric Hyche
> Subject: RE: FW: [datatype-dev] CR: Fixing asf fileformat clips
> sitting in idle for few seconds instead of returning immediately after
> seeking to the end
>
> Thanks Sheldon. Please see the updated diff.
>
> Kinson
>
> -----Original Message-----
> From: Xiaodong (Sheldon) Fu
> Sent: Thursday, February 18, 2010 10:13 AM
> To: Kinson Liu
> Cc: Charles Chen; Qiang Luo; Eric Hyche
> Subject: Re: FW: [datatype-dev] CR: Fixing asf fileformat clips
> sitting in idle for few seconds instead of returning immediately after
> seeking to the end
>
> Firstly the PlayerDriver.cpp design of seeking to (duration-1) is
> wrong and I imagine it will cause trouble for other file format too.
> If possible we should revisit that (I remember it was added as a fix
> for some kind of bug).
>
> And This change will always bypass the 'else' logic to read the next
> index object thus will break seeking for files with multiple index
> objects (if there is any that is, but the logic implies there is). the
> fix in asf file format I think should be that after we read ALL the
> index objects at the end of file and still couldn't find an index
> entry, then we can turn the flag to TRUE and do a final
> SearchIndexTable and use the latest seek point returned from there,
> the code needs to be changed should be the else block starting at line
> 1141 (sorry I am on
> brizo401 so line number may not work):
>
> else
> {
> // We tried to find another index object but could not, so just //
> seek to the first packet and read from there.
> m_ulSeekOffsetRequested = m_ulFirstASFPacketFileOffset; // Set the
> state saying this is the final seek prior to calling SeekDone()
> m_ulState = kStateSeekFinalSeekDonePending; // Now seek the file
> object to the first ASF packet
> m_pFileObject->Seek(m_ulSeekOffsetRequested, FALSE); // Clear the
> return value retVal = HXR_OK; }
>
> We should add a SearchIndexTable(TRUE) here to get the latest seek
> point and go from there, instead of going back to the first packet.
>
> fxd
>
> Charles Chen wrote:
>
>> Sheldon & Qiang,
>> Eric is busy working on his own tasks, could you please review
>> Kinson's CR?
>> Thanks,
>> Charles
>>
>> ---------------------------------------------------------------------
>> ---
>> *From:* datatype-dev-bounces@helixcommunity.org
>> [mailto:datatype-dev-bounces@helixcommunity.org] *On Behalf Of
>> *Kinson Liu
>> *Sent:* Wednesday, February 17, 2010 12:30 PM
>> *To:* datatype-dev@helixcommunity.org
>> *Subject:* [datatype-dev] CR: Fixing asf fileformat clips sitting in
>> idle for few seconds instead of returning immediately after seeking
>> to the end
>>
>> This CR is specifically for Eric Hyche as Eric wrote the asf
>> fileformat. Eric, please let me know if you see any problem changing
>> SearchIndexTable from FALSE to TRUE for that particular line of code.
>>
>> Modified by: kliu@real.com
>> Date: 02/17/2010
>>
>> Project: RealPlayer for Android Smartphones
>>
>> Bug Number: 10043
>> Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=10043
>>
>> Synopsis: Fixing asf fileformat clips sitting in idle for few seconds
>> instead of returning immediately after seeking to the end
>>
>>
>> Overview: Per the existing design of asf fileformat, if a seek does
>> not resolve to a seek index entry, file offset will point back to the
>> first packet, meaning there will be buffering and buffering will
>> start from the beginning. In this bug, we are running to exactly this
>> problem. When the user seeks to the very end of the file, the seek
>> time will be the clip duration - 1 ms (by design of PlayerDriver.cpp).
>> Because the seek time will be beyond the largest seek index entry, no
>> seek index entry will be resolved, buffering will start from the
>> beginning of the clip until it hits the seek time then the playback
>> will return. The idleness users experience comes from the buffering.
>>
>> The fix will be instead of resolving to no search index entry,
>> resolve to the largest index entry when seek time is beyond the
>> largest index entry. The SearchIndexTable function already has logic
>> to take of that, we simply turn that logic on instead of off as by default.
>>
>>
>> Files Added:
>> None
>>
>>
>> Files Modified:
>> datatype/wm/fileformat/asf_file_format_file.cpp
>>
>>
>> Image Size and Heap Use impact (Client -Only):
>> None
>>
>> Platforms and Profiles Affected:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Distribution Libraries Affected:
>> None
>>
>> Distribution library impact and planned action:
>> None
>>
>> Platforms and Profiles Build Verified:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Platforms and Profiles Functionality verified:
>> Platform: android-donut3230-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>>
>> Branch: head, hxclient_3_1_0_atlas, hxclient_3_6_1_atlas,
>> hxclient_4_0_1brizo
>>
>>
>> Copyright assignment: I am a RealNetworks employee or contractor
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.435 / Virus Database: 271.1.1/2693 - Release Date:
>> 02/17/10 07:35:00
>>
>>
>
>
From Gang.Jia at nokia.com Wed Mar 3 16:03:08 2010
From: Gang.Jia at nokia.com (Gang.Jia@nokia.com)
Date: Wed Mar 3 23:15:36 2010
Subject: [datatype-dev] [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix
Cannot play MPEG4 avi with 5.1ch AC3
Message-ID: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 ***** */
#ifndef DD_DEPACK_H
#define DD_DEPACK_H
#include "hxtypes.h"
#include "mp4a-mux-cfg.h"
typedef void (*OnFrameCB)(void* pUserData, ULONG32 ulTime,
const UINT8* pData, ULONG32 ulSize,
HXBOOL bPreviousLoss);
class DDDepack
{
public:
DDDepack();
~DDDepack();
HXBOOL Init(OnFrameCB pFrameCB,
void* pUserData,
HXBOOL bIsDDPlus);
HXBOOL Reset(); // Completely reset the depacketizer state
HXBOOL Flush(); // Indicates end of stream
HXBOOL OnPacket(ULONG32 ulTime, const UINT8* pData,
ULONG32 ulSize);
HXBOOL OnLoss(ULONG32 ulNumPackets); // called to indicate lost packets
protected:
HXBOOL FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize);
HXBOOL ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize);
private:
void* m_pUserData;
OnFrameCB m_pCallback;
ULONG32 m_ulCurrentTime;
UINT8* m_pStagingBuf;
ULONG32 m_ulStagingBufSize;
ULONG32 m_ulBytesStaged;
UINT8* m_pPayloadBuf;
ULONG32 m_ulPayloadBufSize;
HXBOOL m_bHadLoss;
HXBOOL m_bNeedNextPkt;
HXBOOL m_bIsDDPlus;
};
#endif // DD_DEPACK_H
-------------- next part --------------
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/Umakefil,v
retrieving revision 1.14.2.2
diff -u -w -r1.14.2.2 Umakefil
--- Umakefil 7 Mar 2006 20:03:35 -0000 1.14.2.2
+++ Umakefil 26 Feb 2010 16:19:48 -0000
@@ -72,6 +72,7 @@
"mp4-latm-depack.cpp",
"qclppyld.cpp",
"qcelp-depack.cpp",
+ "dd-depack.cpp",
"fmtfact.cpp",
"hxamrpack.cpp")
Index: mp4apyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
retrieving revision 1.14.6.5
diff -u -w -r1.14.6.5 mp4apyld.cpp
--- mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
+++ mp4apyld.cpp 26 Feb 2010 16:19:48 -0000
@@ -62,6 +62,7 @@
#include "hxengin.h"
#include "mp4-latm-depack.h"
+#include "dd-depack.h"
#include "mp4desc.h"
#include "mp4apyld.h"
@@ -79,6 +80,7 @@
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
, m_pLATMDepack (NULL)
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ , m_pDDDepack (NULL)
, m_pAudioConfig (NULL)
, m_ulAudioConfigSize (0)
, m_unAudioConfigType (2)
@@ -98,6 +100,7 @@
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
HX_DELETE(m_pLATMDepack);
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ HX_DELETE(m_pDDDepack);
HX_RELEASE(m_pClassFactory);
HX_RELEASE(m_pStreamHeader);
}
@@ -203,6 +206,10 @@
m_pLATMDepack->Reset();
}
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ if (m_pDDDepack)
+ {
+ m_pDDDepack->Reset();
+ }
m_TSConverter.Reset();
return HXR_OK;
@@ -288,7 +295,7 @@
}
else if (strcasecmp(pMimeTypeData, "audio/EAC3") == 0)
{
- m_PayloadID = PYID_DOLBYDIGITAL;
+ m_PayloadID = PYID_DOLBYDIGITALPLUS;
}
else if (strcasecmp(pMimeTypeData, "audio/AC3") == 0)
{
@@ -317,7 +324,10 @@
retVal = SetAssemblerQCELPHeader(pHeader);
break;
case PYID_DOLBYDIGITAL:
- retVal = SetAssemblerDDHeader(pHeader);
+ retVal = SetAssemblerDDHeader(pHeader, FALSE);
+ break;
+ case PYID_DOLBYDIGITALPLUS:
+ retVal = SetAssemblerDDHeader(pHeader, TRUE);
break;
default:
retVal = HXR_NOTIMPL;
@@ -477,10 +487,14 @@
return retVal;
}
-HX_RESULT MP4APayloadFormat::SetAssemblerDDHeader(IHXValues* pHeader)
+HX_RESULT MP4APayloadFormat::SetAssemblerDDHeader(IHXValues* pHeader, HXBOOL bIsDDPlus)
{
HX_RESULT retVal = HXR_OK;
+ retVal = SetAssemblerDDConfig(bIsDDPlus);
+
+ if (SUCCEEDED(retVal))
+ {
m_ulAudioConfigSize = 12;
m_pAudioConfig = new UINT8 [m_ulAudioConfigSize];
@@ -505,6 +519,35 @@
{
retVal = HXR_OUTOFMEMORY;
}
+ }
+ return retVal;
+}
+
+HX_RESULT MP4APayloadFormat::SetAssemblerDDConfig(HXBOOL bIsDDPlus)
+{
+ HX_RESULT retVal = HXR_OK;
+
+ // Create and initialize the DD depacketizer
+ HX_DELETE(m_pDDDepack);
+ m_pDDDepack = new DDDepack;
+
+ retVal = HXR_OUTOFMEMORY;
+ if (m_pDDDepack)
+ {
+ retVal = HXR_OK;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+
+ retVal = HXR_FAIL;
+ if (m_pDDDepack->Init(OnFrameCallback, this, bIsDDPlus))
+ {
+ retVal = HXR_OK;
+ }
+
+ }
+
return retVal;
}
@@ -678,11 +721,42 @@
case PYID_X_HX_3GPP_QCELP:
case PYID_X_HX_MP4_RAWAU:
case PYID_X_HX_AAC_GENERIC:
- case PYID_DOLBYDIGITAL:
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
break;
+
+ case PYID_DOLBYDIGITAL:
+ case PYID_DOLBYDIGITALPLUS:
+ retVal = HXR_FAIL;
+ if (m_pDDDepack)
+ {
+ if (pPacket->IsLost())
+ {
+ if (m_pDDDepack->OnLoss(1))
+ {
+ retVal = HXR_OK;
+ }
+ }
+ else
+ {
+ IHXBuffer* pBuffer = pPacket->GetBuffer();
+
+ if (pBuffer)
+ {
+ if (m_pDDDepack->OnPacket(GetPacketTime(pPacket),
+ pBuffer->GetBuffer(),
+ pBuffer->GetSize()))
+ {
+ retVal = HXR_OK;
+ }
+
+ pBuffer->Release();
+ }
+ }
+ }
+ break;
+
case PYID_MP4A_LATM:
retVal = HXR_FAIL;
#if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM)
@@ -837,10 +911,11 @@
{
case PYID_X_HX_AAC_GENERIC:
case PYID_X_HX_MP4_RAWAU:
- case PYID_DOLBYDIGITAL:
retVal = CreateRawAUMediaPacket(pOutMediaPacket);
break;
+ case PYID_DOLBYDIGITAL:
+ case PYID_DOLBYDIGITALPLUS:
case PYID_MP4A_LATM:
if (m_OutMediaPacketQueue.IsEmpty())
{
@@ -1043,6 +1118,10 @@
m_pLATMDepack->Flush();
}
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ if (m_pDDDepack)
+ {
+ m_pDDDepack->Flush();
+ }
m_bFlushed = TRUE;
return HXR_OK;
Index: pub/mp4apyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4apyld.h,v
retrieving revision 1.7.8.1
diff -u -w -r1.7.8.1 mp4apyld.h
--- pub/mp4apyld.h 13 Nov 2009 19:33:44 -0000 1.7.8.1
+++ pub/mp4apyld.h 26 Feb 2010 16:19:48 -0000
@@ -43,6 +43,7 @@
#include "tsconvrt.h"
class MP4LATMDepack;
+class DDDepack;
/****************************************************************************
* MP4APayloadFormat
@@ -103,7 +104,8 @@
PYID_MP4A_LATM,
PYID_X_HX_AAC_GENERIC,
PYID_X_HX_3GPP_QCELP,
- PYID_DOLBYDIGITAL
+ PYID_DOLBYDIGITAL,
+ PYID_DOLBYDIGITALPLUS
} PayloadID;
inline HX_RESULT CreateRawAUMediaPacket(CMediaPacket* &pOutMediaPacket);
@@ -117,7 +119,8 @@
HX_RESULT SetAssemblerQCELPHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerLATMConfig(IHXValues* pHeader);
- HX_RESULT SetAssemblerDDHeader(IHXValues* pHeader);
+ HX_RESULT SetAssemblerDDHeader(IHXValues* pHeader, HXBOOL bIsDDPlus);
+ HX_RESULT SetAssemblerDDConfig(HXBOOL bIsDDPlus);
HX_RESULT OnFrame(ULONG32 ulTime,
const UINT8* pData,
ULONG32 ulSize,
@@ -154,6 +157,7 @@
MP4LATMDepack* m_pLATMDepack;
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ DDDepack* m_pDDDepack;
UINT8* m_pAudioConfig;
ULONG32 m_ulAudioConfigSize;
UINT8 m_unAudioConfigType;
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 "hlxclib/string.h"
#include "dd-depack.h"
#define DEFAULT_PAYLOAD_BUF_SIZE 5120
#define DEFAULT_STAGING_BUF_SIZE 5120
//Dolby Digital frame size table, the first column is framesizecode, it is the lower 6 bits
// of the 4th byte, the 2nd column is the norminal bit rate, the 3rd, 4th and 5th columns are
// the framesizes(in 16bit word) for sample rate at 32K, 44.1K and 48K respectively
/*
frmsizecode nominal bit rate 16-bit words per syncframe Fs=32K Fs=44.1K Fs=48K
000000 32Kbps 96 69 64
000001 32Kbps 96 70 64
000010 40Kbps 120 87 80
000011 40Kbps 120 88 80
000100 48Kbps 144 104 96
000101 48Kbps 144 105 96
000110 56Kbps 168 121 112
000111 56Kbps 168 122 112
001000 64Kbps 192 139 128
001001 64Kbps 192 140 128
001010 80Kbps 240 174 160
001011 80Kbps 240 175 160
001100 96Kbps 288 208 192
001101 96Kbps 288 209 192
001110 112Kbps 336 243 224
001111 112Kbps 336 244 224
010000 128Kbps 384 278 256
010001 128Kbps 384 279 256
010010 160Kbps 480 348 320
010011 160Kbps 480 349 320
010100 192Kbps 576 417 384
010101 192Kbps 576 418 384
010110 224Kbps 672 487 448
010111 224Kbps 672 488 448
011000 256Kbps 768 557 512
011001 256Kbps 768 558 512
011010 320Kbps 960 696 640
011011 320Kbps 960 697 640
011100 384Kbps 1152 835 768
011101 384Kbps 1152 836 768
011110 448Kbps 1344 975 896
011111 448Kbps 1344 976 896
100000 512Kbps 1536 1114 1024
100001 512Kbps 1536 1115 1024
100010 576Kbps 1728 1253 1152
100011 576Kbps 1728 1254 1152
100100 640Kbps 1920 1393 1280
100101 640Kbps 1920 1394 1280
100110 to 111111 reserved */
//Dolby Digital frame size (in bytes) table used to parse the frame header
const UINT32 uDDFrameSizetTbl [38][3] =
{
128, 138, 192,
128, 140, 192,
160, 174, 240,
160, 176, 240,
192, 208, 288,
192, 210, 288,
224, 242, 336,
224, 244, 336,
256, 278, 384,
256, 280, 384,
320, 348, 480,
320, 350, 480,
384, 416, 576,
384, 418, 576,
448, 486, 672,
448, 488, 672,
512, 556, 768,
512, 558, 768,
640, 696, 960,
640, 698, 960,
768, 834, 1152,
768, 836, 1152,
896, 974, 1344,
896, 976, 1344,
1024, 1114, 1536,
1024, 1116, 1536,
1280, 1392, 1920,
1280, 1394, 1920,
1536, 1670, 2304,
1536, 1672, 2304,
1792, 1950, 2688,
1792, 1952, 2688,
2048, 2228, 3072,
2048, 2230, 3072,
2304, 2506, 3456,
2304, 2508, 3456,
2560, 2786, 3840,
2560, 2788, 3840,
};
DDDepack::DDDepack() :
m_pUserData(0),
m_pCallback(0),
m_ulCurrentTime(0),
m_ulBytesStaged(0),
m_bHadLoss(FALSE),
m_bNeedNextPkt(FALSE)
{}
DDDepack::~DDDepack()
{
if(m_pStagingBuf)
{
delete [] m_pStagingBuf;
}
m_pStagingBuf = 0;
if(m_pPayloadBuf)
{
delete [] m_pPayloadBuf;
}
m_ulPayloadBufSize = 0;
}
HXBOOL DDDepack::Init(OnFrameCB pFrameCB, void* pUserData, HXBOOL bIsDDPlus)
{
HXBOOL ret = FALSE;
m_pCallback = pFrameCB;
m_pUserData = pUserData;
m_bIsDDPlus = bIsDDPlus;
m_pStagingBuf = new UINT8[DEFAULT_STAGING_BUF_SIZE];
if(m_pStagingBuf)
{
ret = TRUE;
}
m_ulStagingBufSize = DEFAULT_PAYLOAD_BUF_SIZE;
m_pPayloadBuf = new UINT8[DEFAULT_PAYLOAD_BUF_SIZE];
if(ret && m_pPayloadBuf)
{
ret = TRUE;
}
m_ulPayloadBufSize = DEFAULT_PAYLOAD_BUF_SIZE;
return TRUE;
}
HXBOOL DDDepack::Reset() // Completely reset the depacketizer state
{
m_ulBytesStaged = 0;
m_bHadLoss = FALSE;
m_bNeedNextPkt = FALSE;
return FALSE;
}
HXBOOL DDDepack::Flush() // Indicates end of stream
{
return FALSE;
}
HXBOOL DDDepack::FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize)
{
HXBOOL ret = FALSE;
if( !(*pBuffer == 0x0b) || !(*(pBuffer+1) == 0x77))
{
//Discard data until the first sync word
for(ULONG32 i=1; i m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[ulPayloadLen];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
ret = FALSE;
}
else
{
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = ulPayloadLen;
}
}
if(ret)
{
memcpy(m_pStagingBuf, &pBuffer[ulOffset], ulPayloadLen);
m_ulBytesStaged += ulPayloadLen;
}
}
}
else //continue to the previous pkt
{
if ((m_ulBytesStaged + ulSize) > m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[m_ulBytesStaged + ulSize];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
ret = FALSE;
}
else
{
memcpy(pNewBuf, m_pStagingBuf, m_ulBytesStaged);
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = m_ulBytesStaged + ulSize;
}
}
if(ret)
{
memcpy(&m_pStagingBuf[m_ulBytesStaged], pData, ulSize);
m_ulBytesStaged += ulSize;
}
}
if(ret)
{
ret = ProcessStagingBuffer(m_pStagingBuf,m_ulBytesStaged);
}
return ret;
}
HXBOOL DDDepack::OnLoss(ULONG32 ulNumPackets) // called to indicate lost
// packets
{
m_bHadLoss = TRUE;
m_ulBytesStaged = 0;
return TRUE;
}
HXBOOL DDDepack::ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize)
{
ULONG32 ulFrameTime = m_ulCurrentTime;
ULONG32 ulOffset = 0;
UINT32 uFrameLen = 0;
UINT8* pPayloadBuf;
ULONG32 ulPayloadLen = 0;
if(m_ulPayloadBufSize < ulSize)
{
// We need to make the payload buffer larger
UINT8* pNewBuf = new UINT8[ulSize];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
return FALSE;
}
delete [] m_pPayloadBuf;
m_pPayloadBuf = pNewBuf;
m_ulPayloadBufSize = ulSize;
}
do
{
pPayloadBuf = pBuffer + ulOffset;
//Audio data need to start with a valid Dolby Digital frame, check Syncword 0x0b77
if( *pPayloadBuf == 0x0b && *(pPayloadBuf+1) == 0x77)
{
if(m_bIsDDPlus)
{
//Get Dolby Digital Plus frame length
/*First 2 byte of the PayloadData block contains the Syncword (0x0b77)
Word Size
bsi()
{
strmtyp 2
substreamid 3
frmsiz 11
...
..
}
To extract the framesize we need last 3 bits from the third byte of PayloadData block and the next byte
of PayloadData block.
'frmsiz' field indicates a value one less than the overall size of the coded frame in 16-bit words. That
is, this field may assume a value ranging from 0 to 2047, and these values correspond to frame
sizes ranging from 1 to 2048. */
uFrameLen = ((((*(pPayloadBuf+2)&0x07)<<8) | *(pPayloadBuf+3)) + 1) * 2;
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
memcpy(m_pPayloadBuf + ulOffset, pPayloadBuf, uFrameLen);
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//Get Dolby Digital frame length
UINT8 uFrameInfoByte = *(pPayloadBuf+4);
UINT8 uFameSizeCode = uFrameInfoByte & 0x3f;
UINT8 uSampleRateCode = uFrameInfoByte >> 6;
if ( uFameSizeCode < 38 && uSampleRateCode < 3 )
{
uFrameLen = uDDFrameSizetTbl[uFameSizeCode][uSampleRateCode];
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
memcpy(m_pPayloadBuf + ulOffset, pPayloadBuf, uFrameLen);
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//This is not a real sync word, try to find the next sync word
*pPayloadBuf = 0;
}
}
}
else
{
//Lost sync, try to find the next sync word in the buffer
ULONG32 ulNextSyncOffset = 0;
if((ulSize - ulOffset)>1 && FindSyncWord(pPayloadBuf, ulNextSyncOffset, ulSize - ulOffset))
{
ulOffset+= ulNextSyncOffset;
continue;
}
else
{
//can not find sync word in the buffer, discard the buffer
ulOffset = ulSize;
break;
}
}
}while(ulOffset < ulSize);
if(ulPayloadLen)
{
m_pCallback( m_pUserData, m_ulCurrentTime,
m_pPayloadBuf,
ulPayloadLen,
m_bHadLoss);
m_bHadLoss = FALSE;
}
if(ulOffset < ulSize)
{
//Frame fragmented, need next pkt to reassemble the frame
m_ulBytesStaged = ulSize - ulOffset;
memcpy(m_pStagingBuf, pBuffer+ulOffset, m_ulBytesStaged);
m_bNeedNextPkt = TRUE;
}
else
{
//End of buffer reached
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
}
return TRUE;
}
-------------- next part --------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From jgordon at real.com Wed Mar 3 16:05:42 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Mar 3 23:17:37 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <4B8EF686.7090406@real.com>
References: <19113978AB61DA44AC317B211CF1C32A28C5D34132@NOK-EUMSG-02.mgdnok.nokia.com> <7ECCEA249B7CDC49A079EC0075E999AA07DAEFAC39@SEAMBX.corp.real.com>
<4B8EF686.7090406@real.com>
Message-ID: <4B8EF956.5010005@real.com>
For what it's worth, I also had issues with this change, which I simply
worked around for now by just not getting and passing the file size for
server builds (because http progressive download/pseudo-streaming
reception is not a concern at the server!)
The problem I was having as far as I chased it was that when the file
size was passed instead of ATOMIZE_ALL, the atomizer would not parse any
top level atoms after the moov (or possibly just anything after the
mdat).
On 3/3/2010 3:53 PM, Qiang Luo wrote:
> Hi Saleem,
>
> I made the change of passing ulFileSize to the Atomize() function. This
> was an attempt to fix a few mp4 http streaming issues. The basic idea
> was to limit the atomizer offset range to be within the actual file size
> if the filesystem supports IHXFileStat.
>
> In your parsing failure case, what is your DRM and the container format
> used? Is the m_ullFinalOffset the correct encrypted file size? What is
> the m_ullCurrentOffset value? Does the mp4 ff handles encrypted data or
> the filesystem decrypt the data first? In general, if there is no
> decryptor in or sit between the filesystem and the fileformat, then the
> mp4 ff logic for clear data should work for drm data.
>
> Qiang
>
>> ------------------------------------------------------------------------
>> *From:* saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
>> *Sent:* Wednesday, March 03, 2010 12:55 PM
>> *To:* Eric Hyche
>> *Subject:* FW: DRM protected MP4 file parsing failure with error code
>> HXR_CORRUPT_FILE due to recent change
>>
>> Any comment on this?
>>
>> ______________________________________________
>> *From: *Adookkattil Saleem (Nokia-D/Dallas)
>> *Sent: *Tuesday, March 02, 2010 6:04 PM
>> *To: *'nokia-private-dev@helixcommunity.org'
>> *Subject: *DRM protected MP4 file parsing failure with error
>> code HXR_CORRUPT_FILE due to recent change
>>
>> Hi,
>>
>> DRM protected MP4 file parsing is failing due to a change in MP4 file
>> format project (qtffplin.cpp) made recently. Please see the below
>> given diff.
>>
>> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>>
>>
>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
>>
>> When we pass the file size as the second parameter, DRM file parsing
>> is failing in the below given function of CAtomizer class
>> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
>>
>> /****************************************************************************
>> * CompleteAtomization
>> */
>> void CAtomizer::CompleteAtomization(HX_RESULT status)
>> {
>> CQTAtom* pRoot;
>>
>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
>> *(((INT32*)(&m_ullCurrentOffset)) + 1));
>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
>> *(((INT32*)(&m_ullFinalOffset)) + 1));
>>
>> if (!m_pRoot)
>> {
>> return;
>> }
>>
>> if (SUCCEEDED(status))
>> {
>> // Record the amount of data atomized
>> CQTAtom *pRoot = m_pCurrentRoot;
>>
>> HX_ASSERT(pRoot);
>>
>> // If we have the position of where next atom would be,
>> // compute unspecified atom sizes
>> if (m_ullNewAtomOffset != ATOMIZE_ALL)
>> {
>> while (pRoot)
>> {
>> if (pRoot->GetSize() == ATOMIZE_ALL)
>> {
>> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>> }
>>
>> // Move to the parent
>> pRoot = pRoot->GetParent();
>> }
>>
>> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>> }
>>
>> status = AdjustCurrentRoot();
>> }
>>
>> if (SUCCEEDED(status))
>> {
>> if (m_ullFinalOffset != ATOMIZE_ALL)
>> {
>> m_ullCurrentOffset = m_ullCurrentOffset > m_ullFinalOffset
>> ? m_ullFinalOffset : m_ullCurrentOffset;
>> }
>>
>> // See if parsing fully completed
>> if (((m_ullFinalOffset != ATOMIZE_ALL) &&
>> (m_ullFinalOffset != m_ullCurrentOffset)) ||
>> (m_pRoot != m_pCurrentRoot))
>> {
>> status = HXR_CORRUPT_FILE;
>> }
>> }
>> else
>> {
>> // Data compromizing failure occured during atomization
>> HX_RELEASE(m_pRoot);
>> }
>>
>> HX_RELEASE(m_pNewAtom);
>>
>> m_State = ATMZR_Ready;
>>
>> pRoot = m_pRoot;
>> m_pRoot = NULL;
>> m_pCurrentRoot = NULL;
>>
>> m_pResponse->AtomReady(status, pRoot);
>>
>> if (pRoot)
>> {
>> pRoot->Release();
>> }
>> }
>>
>> The reason for the failure is the value of ullCurrentOffset is less
>> than m_ullFinalOffset.
>>
>> If we keep the previous function call, there is no error (ie, retVal =
>> m_pAtomizer->Atomize(); )
>>
>> Whats the reason for this change? Any suggestion to fix this error?
>>
>> Thanks & regards
>> Saleem
>>
>
From sfu at real.com Wed Mar 3 17:41:10 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 4 00:53:17 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:Case ou1cimx1#259923
Helix Cannot play MPEG4 avi with 5.1ch AC3
In-Reply-To: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
References: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4B8F0FB6.3070603@real.com>
Change in mp4pyld looks good. For dd-depack.cpp:
1. Init function always return TRUE even if there is out of memory
error(s). If we don't think OOM could happen, then those detection logic
should be taken out, otherwise correct error coder returned.
2. dtor's "if (xxx) delete(xxx); xxx = 0;" could be replaced by
"HX_VECTOR_DELETE(xxx)"
3. In FindSyncWord, the outer 'if' doesn't seem to be needed if you just
make the for loop start at i=0, instead of i=1.
4. The depack logic in OnPacket and ProcessingStagingBuffer is quite
inefficient with extra memcpy ops that can be avoided, especially for
clips that don't have fragmented packets (or have only a small amount of
fragmented packets). For any incoming packet, if it doesn't start with
partial frame data (has sync word at beginning) then the data up to the
last whole frame in the packet buffer can be returned to the caller
directly without any memcpy. Only for incoming packet that starts at
partial frame offset that memcpy is needed and even for that case only
one memcpy is needed for any given byte of the incoming data. Having a
staging buffer and a final buffer to always do two memcpy ops for each
byte is not necessary.
Since this has some performance impact (memcpy stuff), It might be a
good idea to wrap the calling of depacktizer from mp4pyld in a
HELIX_FEATURE define.
fxd
Gang.Jia@nokia.com wrote:
> Any comment on this one?
>
> Thanks
> Gang
>
> ------------------------------------------------------------------------
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Jia Gang (Nokia-D/Dallas)
> *Sent:* Monday, March 01, 2010 3:22 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot
> play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: Gang.Jia@nokia.com
>
> Reviewed by:
>
> Date: 2/26/2010
>
> Project: SymbianMmf_wm
>
> ErrorId: ESLM-829J6K
>
> Synopsis: CR: Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> The current implementation of Dolby Digital doesn't consider the case
> that the audio frame could be fragmented
> during the encoding. The clip used in this error case is encoded with
> audio frame fragmented. To handle this we
> added de-packetizer for Dolby Digital/Dolby Digital plus to reassemble
> the fragmented frames. The de-packetizer
> tries to find the sync word of each frame. Based on the sync word it
> can get the frame length and then do the frame
> reassemble.
>
> Root Cause of the problem: Implementation.
>
> Files Added:
> /datatype/mp4/payload/dd_depack.cpp
> /datatype/mp4/payload/pub/dd_depack.h
>
> Files Modified:
> /datatype/mp4/payload/umakefil
> /datatype/mp4/payload/mp4apyld.cpp
> /datatype/mp4/payload/pub/mp4apyld.h
>
> Image Size and Heap Use impact:
> mp4pyldlib.lib size increased 2kB
> Heap size increased based on encoded AC3/EAC3 frame sizes, <20KB in
> normal cases.
>
>
> Module Release testing (STIF) : Passed selected test cases.
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, Head, 420Brizo
>
>
>
From ext-debashis.2.panigrahi at nokia.com Thu Mar 4 05:04:56 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Thu Mar 4 12:18:52 2010
Subject: [datatype-dev] CR: CKSS-833A8S: Audio is not played properly for
avi video file and lentgh info shown in not correct and len info sh
Message-ID: <20D73E2631F7914F868646E119DEC1CE22A4C27A28@NOK-EUMSG-02.mgdnok.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: ext-debashis.2.panigrahi@nokia.com
Reviewed by: rajesh.rathinasamy@nokia.com
TSW Id: CKSS-833A8S
Date: 03/04/2010
Project: SymbianMmf_wm
Synopsis: Audio is not played properly for avi video file and length info shown in not correct
Overview:
There are two issues here:
1) The audio stream length that is being read from header is zero, so audio duration calculation goes wrong. This CR fixes this problem
2) Audio doesn't play or plays intermittently. Here decoder is failing with KErrCorrupt as its not getting sync frame although when we dumped encoded audio data at helix we were able to play it properly. A separate Error has to be raised for this.
Fix:
Now calculating the audio stream length if its not set from the main header instead of setting it to 0xffffffff.
Files modified & changes:
datatype/avi/fileformat/avistrm.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS:
Index: avi/fileformat/avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.9.6.8
diff -u -w -r1.9.6.8 avistrm.cpp
--- avi/fileformat/avistrm.cpp 1 Mar 2010 22:03:28 -0000 1.9.6.8
+++ avi/fileformat/avistrm.cpp 3 Mar 2010 04:08:32 -0000
@@ -1151,7 +1155,7 @@
// Duration:
if(m_header.ulLength == 0)
{
- m_header.ulLength = 0xffffffff;
+ m_header.ulLength = m_mainHeader.ulMicroSecPerFrame *
+ m_mainHeader.ulTotalFrames * ((double)m_fSamplesPerSecond / 1000000);
}
pHeader->SetPropertyULONG32("Duration", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
HXLOGL4(HXLOG_AVIX,"\t\tDuration:\t%lu", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
From sfu at real.com Thu Mar 4 07:11:18 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 4 14:22:59 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: CKSS-833A8S: Audio is
not played properly
for avi video file and lentgh info shown in not correct and len info sh
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE22A4C27A28@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE22A4C27A28@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B8FCD96.6060107@real.com>
Looks ok, though this m_header.ulLength adjustment logic should probably
be moved to SetHeader, after ulLength is extract from raw header buffer
and detected to be zero. Reason being that there is another place
(GetDuration) that the ulLength is used to calculate duration and if we
do the adjustment in GetHeader, we will have to rely on the fact that
GetHeader is always called before GetDuration, which could be a problem
in the future.
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> TSW Id: CKSS-833A8S
>
> Date: 03/04/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Audio is not played properly for avi video file and length info shown in not correct
>
> Overview:
> There are two issues here:
> 1) The audio stream length that is being read from header is zero, so audio duration calculation goes wrong. This CR fixes this problem
> 2) Audio doesn't play or plays intermittently. Here decoder is failing with KErrCorrupt as its not getting sync frame although when we dumped encoded audio data at helix we were able to play it properly. A separate Error has to be raised for this.
>
> Fix:
> Now calculating the audio stream length if its not set from the main header instead of setting it to 0xffffffff.
>
> Files modified & changes:
> datatype/avi/fileformat/avistrm.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: avi/fileformat/avistrm.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
> retrieving revision 1.9.6.8
> diff -u -w -r1.9.6.8 avistrm.cpp
> --- avi/fileformat/avistrm.cpp 1 Mar 2010 22:03:28 -0000 1.9.6.8
> +++ avi/fileformat/avistrm.cpp 3 Mar 2010 04:08:32 -0000
> @@ -1151,7 +1155,7 @@
> // Duration:
> if(m_header.ulLength == 0)
> {
> - m_header.ulLength = 0xffffffff;
> + m_header.ulLength = m_mainHeader.ulMicroSecPerFrame *
> + m_mainHeader.ulTotalFrames * ((double)m_fSamplesPerSecond / 1000000);
> }
> pHeader->SetPropertyULONG32("Duration", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
> HXLOGL4(HXLOG_AVIX,"\t\tDuration:\t%lu", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
> .
>
>
From Gang.Jia at nokia.com Thu Mar 4 15:00:26 2010
From: Gang.Jia at nokia.com (Gang.Jia@nokia.com)
Date: Thu Mar 4 22:14:54 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR:Case ou1cimx1#259923
Helix Cannot play MPEG4 avi with 5.1ch AC3
In-Reply-To: <4B8F0FB6.3070603@real.com>
References: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
<4B8F0FB6.3070603@real.com>
Message-ID: <6F45DEE63C5BB542B6A7B0C4E41467D0152ED4CB7D@NOK-EUMSG-03.mgdnok.nokia.com>
Hi Sheldon
I have taken the comments 1,2,3. For comment 4, I have removed the extra copy. Now there is only one copy in the fragmented case, for none fragmented case there is no copy in DDDepack. Since the clip with fragmented frame is very rare I think this change should have little impact on the performance.
Thanks,
Gang
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Wednesday, March 03, 2010 7:41 PM
To: Jia Gang (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
Change in mp4pyld looks good. For dd-depack.cpp:
1. Init function always return TRUE even if there is out of memory error(s). If we don't think OOM could happen, then those detection logic should be taken out, otherwise correct error coder returned.
2. dtor's "if (xxx) delete(xxx); xxx = 0;" could be replaced by "HX_VECTOR_DELETE(xxx)"
3. In FindSyncWord, the outer 'if' doesn't seem to be needed if you just make the for loop start at i=0, instead of i=1.
4. The depack logic in OnPacket and ProcessingStagingBuffer is quite inefficient with extra memcpy ops that can be avoided, especially for clips that don't have fragmented packets (or have only a small amount of fragmented packets). For any incoming packet, if it doesn't start with partial frame data (has sync word at beginning) then the data up to the last whole frame in the packet buffer can be returned to the caller directly without any memcpy. Only for incoming packet that starts at partial frame offset that memcpy is needed and even for that case only one memcpy is needed for any given byte of the incoming data. Having a staging buffer and a final buffer to always do two memcpy ops for each byte is not necessary.
Since this has some performance impact (memcpy stuff), It might be a good idea to wrap the calling of depacktizer from mp4pyld in a HELIX_FEATURE define.
fxd
Gang.Jia@nokia.com wrote:
> Any comment on this one?
>
> Thanks
> Gang
>
> ----------------------------------------------------------------------
> --
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Jia Gang (Nokia-D/Dallas)
> *Sent:* Monday, March 01, 2010 3:22 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot
> play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: Gang.Jia@nokia.com
>
> Reviewed by:
>
> Date: 2/26/2010
>
> Project: SymbianMmf_wm
>
> ErrorId: ESLM-829J6K
>
> Synopsis: CR: Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> The current implementation of Dolby Digital doesn't consider the case
> that the audio frame could be fragmented during the encoding. The clip
> used in this error case is encoded with audio frame fragmented. To
> handle this we added de-packetizer for Dolby Digital/Dolby Digital
> plus to reassemble the fragmented frames. The de-packetizer tries to
> find the sync word of each frame. Based on the sync word it can get
> the frame length and then do the frame reassemble.
>
> Root Cause of the problem: Implementation.
>
> Files Added:
> /datatype/mp4/payload/dd_depack.cpp
> /datatype/mp4/payload/pub/dd_depack.h
>
> Files Modified:
> /datatype/mp4/payload/umakefil
> /datatype/mp4/payload/mp4apyld.cpp
> /datatype/mp4/payload/pub/mp4apyld.h
>
> Image Size and Heap Use impact:
> mp4pyldlib.lib size increased 2kB
> Heap size increased based on encoded AC3/EAC3 frame sizes, <20KB in
> normal cases.
>
>
> Module Release testing (STIF) : Passed selected test cases.
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, Head, 420Brizo
>
>
>
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 ***** */
#ifndef DD_DEPACK_H
#define DD_DEPACK_H
#include "hxtypes.h"
typedef void (*OnFrameCB)(void* pUserData, ULONG32 ulTime,
const UINT8* pData, ULONG32 ulSize,
HXBOOL bPreviousLoss);
class DDDepack
{
public:
DDDepack();
~DDDepack();
HXBOOL Init(OnFrameCB pFrameCB,
void* pUserData,
HXBOOL bIsDDPlus);
HXBOOL Reset(); // Completely reset the depacketizer state
HXBOOL Flush(); // Indicates end of stream
HXBOOL OnPacket(ULONG32 ulTime, const UINT8* pData,
ULONG32 ulSize);
HXBOOL OnLoss(ULONG32 ulNumPackets); // called to indicate lost packets
protected:
HXBOOL FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize);
HXBOOL ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize);
private:
void* m_pUserData;
OnFrameCB m_pCallback;
ULONG32 m_ulCurrentTime;
UINT8* m_pStagingBuf;
ULONG32 m_ulStagingBufSize;
ULONG32 m_ulBytesStaged;
HXBOOL m_bHadLoss;
HXBOOL m_bNeedNextPkt;
HXBOOL m_bIsDDPlus;
};
#endif // DD_DEPACK_H
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: $Id$
*
* Portions Copyright (c) 1995-2010 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 "dd-depack.h"
#define DEFAULT_STAGING_BUF_SIZE 5120
//Dolby Digital frame size table, the first column is framesizecode, it is the lower 6 bits
// of the 4th byte, the 2nd column is the norminal bit rate, the 3rd, 4th and 5th columns are
// the framesizes(in 16bit word) for sample rate at 32K, 44.1K and 48K respectively
/*
frmsizecode nominal bit rate 16-bit words per syncframe Fs=32K Fs=44.1K Fs=48K
000000 32Kbps 96 69 64
000001 32Kbps 96 70 64
000010 40Kbps 120 87 80
000011 40Kbps 120 88 80
000100 48Kbps 144 104 96
000101 48Kbps 144 105 96
000110 56Kbps 168 121 112
000111 56Kbps 168 122 112
001000 64Kbps 192 139 128
001001 64Kbps 192 140 128
001010 80Kbps 240 174 160
001011 80Kbps 240 175 160
001100 96Kbps 288 208 192
001101 96Kbps 288 209 192
001110 112Kbps 336 243 224
001111 112Kbps 336 244 224
010000 128Kbps 384 278 256
010001 128Kbps 384 279 256
010010 160Kbps 480 348 320
010011 160Kbps 480 349 320
010100 192Kbps 576 417 384
010101 192Kbps 576 418 384
010110 224Kbps 672 487 448
010111 224Kbps 672 488 448
011000 256Kbps 768 557 512
011001 256Kbps 768 558 512
011010 320Kbps 960 696 640
011011 320Kbps 960 697 640
011100 384Kbps 1152 835 768
011101 384Kbps 1152 836 768
011110 448Kbps 1344 975 896
011111 448Kbps 1344 976 896
100000 512Kbps 1536 1114 1024
100001 512Kbps 1536 1115 1024
100010 576Kbps 1728 1253 1152
100011 576Kbps 1728 1254 1152
100100 640Kbps 1920 1393 1280
100101 640Kbps 1920 1394 1280
100110 to 111111 reserved */
//Dolby Digital frame size (in bytes) table used to parse the frame header
const UINT32 uDDFrameSizetTbl [38][3] =
{
128, 138, 192,
128, 140, 192,
160, 174, 240,
160, 176, 240,
192, 208, 288,
192, 210, 288,
224, 242, 336,
224, 244, 336,
256, 278, 384,
256, 280, 384,
320, 348, 480,
320, 350, 480,
384, 416, 576,
384, 418, 576,
448, 486, 672,
448, 488, 672,
512, 556, 768,
512, 558, 768,
640, 696, 960,
640, 698, 960,
768, 834, 1152,
768, 836, 1152,
896, 974, 1344,
896, 976, 1344,
1024, 1114, 1536,
1024, 1116, 1536,
1280, 1392, 1920,
1280, 1394, 1920,
1536, 1670, 2304,
1536, 1672, 2304,
1792, 1950, 2688,
1792, 1952, 2688,
2048, 2228, 3072,
2048, 2230, 3072,
2304, 2506, 3456,
2304, 2508, 3456,
2560, 2786, 3840,
2560, 2788, 3840,
};
DDDepack::DDDepack() :
m_pUserData(0),
m_pCallback(0),
m_ulCurrentTime(0),
m_ulBytesStaged(0),
m_bHadLoss(FALSE),
m_bNeedNextPkt(FALSE)
{}
DDDepack::~DDDepack()
{
HX_VECTOR_DELETE(m_pStagingBuf);
}
HXBOOL DDDepack::Init(OnFrameCB pFrameCB, void* pUserData, HXBOOL bIsDDPlus)
{
HXBOOL ret = FALSE;
m_pCallback = pFrameCB;
m_pUserData = pUserData;
m_bIsDDPlus = bIsDDPlus;
m_pStagingBuf = new UINT8[DEFAULT_STAGING_BUF_SIZE];
if(m_pStagingBuf)
{
m_ulStagingBufSize = DEFAULT_STAGING_BUF_SIZE;
ret = TRUE;
}
return ret;
}
HXBOOL DDDepack::Reset() // Completely reset the depacketizer state
{
m_ulBytesStaged = 0;
m_bHadLoss = FALSE;
m_bNeedNextPkt = FALSE;
return FALSE;
}
HXBOOL DDDepack::Flush() // Indicates end of stream
{
return FALSE;
}
HXBOOL DDDepack::FindSyncWord(UINT8* pBuffer, ULONG32& ulOffset, ULONG32 ulSize)
{
HXBOOL ret = FALSE;
//Discard data until the first sync word
for(ULONG32 i=0; i m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[m_ulBytesStaged + ulSize];
if(!pNewBuf)
{
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
ret = FALSE;
}
else
{
memcpy(pNewBuf, m_pStagingBuf, m_ulBytesStaged);
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = m_ulBytesStaged + ulSize;
}
}
if(ret)
{
memcpy(m_pStagingBuf+m_ulBytesStaged, pData, ulSize);
m_ulBytesStaged += ulSize;
ret = ProcessStagingBuffer(m_pStagingBuf,m_ulBytesStaged);
}
}
return ret;
}
HXBOOL DDDepack::OnLoss(ULONG32 ulNumPackets) // called to indicate lost
// packets
{
m_bHadLoss = TRUE;
m_ulBytesStaged = 0;
return TRUE;
}
HXBOOL DDDepack::ProcessStagingBuffer(UINT8* pBuffer, ULONG32 ulSize)
{
HXBOOL ret = TRUE;
ULONG32 ulFrameTime = m_ulCurrentTime;
ULONG32 ulOffset = 0;
UINT32 uFrameLen = 0;
UINT8* pPayloadBuf;
ULONG32 ulPayloadLen = 0;
ULONG32 ulPayloadOffset = 0;
do
{
pPayloadBuf = pBuffer + ulOffset;
//Audio data need to start with a valid Dolby Digital frame, check Syncword 0x0b77
if( *pPayloadBuf == 0x0b && *(pPayloadBuf+1) == 0x77)
{
if(m_bIsDDPlus)
{
//Get Dolby Digital Plus frame length
/*First 2 byte of the PayloadData block contains the Syncword (0x0b77)
Word Size
bsi()
{
strmtyp 2
substreamid 3
frmsiz 11
...
..
}
To extract the framesize we need last 3 bits from the third byte of PayloadData block and the next byte
of PayloadData block.
'frmsiz' field indicates a value one less than the overall size of the coded frame in 16-bit words. That
is, this field may assume a value ranging from 0 to 2047, and these values correspond to frame
sizes ranging from 1 to 2048. */
uFrameLen = ((((*(pPayloadBuf+2)&0x07)<<8) | *(pPayloadBuf+3)) + 1) * 2;
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//Get Dolby Digital frame length
UINT8 uFrameInfoByte = *(pPayloadBuf+4);
UINT8 uFameSizeCode = uFrameInfoByte & 0x3f;
UINT8 uSampleRateCode = uFrameInfoByte >> 6;
if ( uFameSizeCode < 38 && uSampleRateCode < 3 )
{
uFrameLen = uDDFrameSizetTbl[uFameSizeCode][uSampleRateCode];
if( uFrameLen+ulOffset > ulSize )
{
//The frame is fragmented, need more data
break;
}
ulPayloadLen+=uFrameLen;
ulOffset+= uFrameLen;
}
else
{
//This is not a real sync word, try to find the next sync word
*pPayloadBuf = 0;
}
}
}
else
{
//Lost sync, try to find the next sync word in the buffer
ULONG32 ulNextSyncOffset = 0;
if((ulSize - ulOffset)>1 && FindSyncWord(pPayloadBuf, ulNextSyncOffset, ulSize - ulOffset))
{
ulOffset+= ulNextSyncOffset;
//resync to sync word, reset the payload offset and length
ulPayloadOffset = ulOffset;
ulPayloadLen = 0;
continue;
}
else
{
//can not find sync word in the buffer, discard the buffer
ulOffset = ulSize;
break;
}
}
}while(ulOffset < ulSize);
if(ulPayloadLen)
{
m_pCallback( m_pUserData, m_ulCurrentTime,
pBuffer+ulPayloadOffset,
ulPayloadLen,
m_bHadLoss);
m_bHadLoss = FALSE;
}
if(ulOffset < ulSize)
{
//Frame fragmented, need next pkt to reassemble the frame
m_ulBytesStaged = ulSize - ulOffset;
if (m_ulBytesStaged > m_ulStagingBufSize)
{
// We need to make the staging buffer larger
UINT8* pNewBuf = new UINT8[m_ulBytesStaged];
if (!pNewBuf)
{
m_ulBytesStaged = 0;
ret = FALSE;
}
else
{
delete [] m_pStagingBuf;
m_pStagingBuf = pNewBuf;
m_ulStagingBufSize = m_ulBytesStaged;
}
}
memcpy(m_pStagingBuf, pBuffer+ulOffset, m_ulBytesStaged);
m_bNeedNextPkt = TRUE;
}
else
{
//End of buffer reached
m_ulBytesStaged = 0;
m_bNeedNextPkt = FALSE;
}
return ret;
}
From sfu at real.com Thu Mar 4 15:10:19 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 4 22:22:05 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:Case ou1cimx1#259923
Helix Cannot play MPEG4 avi with 5.1ch AC3
In-Reply-To: <6F45DEE63C5BB542B6A7B0C4E41467D0152ED4CB7D@NOK-EUMSG-03.mgdnok.nokia.com>
References: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
<4B8F0FB6.3070603@real.com>
<6F45DEE63C5BB542B6A7B0C4E41467D0152ED4CB7D@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4B903DDB.7090707@real.com>
Looks good.
fxd
Gang.Jia@nokia.com wrote:
> Hi Sheldon
>
> I have taken the comments 1,2,3. For comment 4, I have removed the extra copy. Now there is only one copy in the fragmented case, for none fragmented case there is no copy in DDDepack. Since the clip with fragmented frame is very rare I think this change should have little impact on the performance.
>
> Thanks,
> Gang
>
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Wednesday, March 03, 2010 7:41 PM
> To: Jia Gang (Nokia-D/Dallas)
> Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> Change in mp4pyld looks good. For dd-depack.cpp:
>
> 1. Init function always return TRUE even if there is out of memory error(s). If we don't think OOM could happen, then those detection logic should be taken out, otherwise correct error coder returned.
>
> 2. dtor's "if (xxx) delete(xxx); xxx = 0;" could be replaced by "HX_VECTOR_DELETE(xxx)"
>
> 3. In FindSyncWord, the outer 'if' doesn't seem to be needed if you just make the for loop start at i=0, instead of i=1.
>
> 4. The depack logic in OnPacket and ProcessingStagingBuffer is quite inefficient with extra memcpy ops that can be avoided, especially for clips that don't have fragmented packets (or have only a small amount of fragmented packets). For any incoming packet, if it doesn't start with partial frame data (has sync word at beginning) then the data up to the last whole frame in the packet buffer can be returned to the caller directly without any memcpy. Only for incoming packet that starts at partial frame offset that memcpy is needed and even for that case only one memcpy is needed for any given byte of the incoming data. Having a staging buffer and a final buffer to always do two memcpy ops for each byte is not necessary.
>
> Since this has some performance impact (memcpy stuff), It might be a good idea to wrap the calling of depacktizer from mp4pyld in a HELIX_FEATURE define.
>
> fxd
>
> Gang.Jia@nokia.com wrote:
>
>> Any comment on this one?
>>
>> Thanks
>> Gang
>>
>> ----------------------------------------------------------------------
>> --
>> *From:* nokia-private-dev-bounces@helixcommunity.org
>> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
>> *Jia Gang (Nokia-D/Dallas)
>> *Sent:* Monday, March 01, 2010 3:22 PM
>> *To:* datatype-dev@helixcommunity.org
>> *Cc:* nokia-private-dev@helixcommunity.org
>> *Subject:* [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot
>> play MPEG4 avi with 5.1ch AC3
>>
>> "Nokia submits this code under the terms of a commercial contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: Gang.Jia@nokia.com
>>
>> Reviewed by:
>>
>> Date: 2/26/2010
>>
>> Project: SymbianMmf_wm
>>
>> ErrorId: ESLM-829J6K
>>
>> Synopsis: CR: Helix Cannot play MPEG4 avi with 5.1ch AC3
>>
>> The current implementation of Dolby Digital doesn't consider the case
>> that the audio frame could be fragmented during the encoding. The clip
>> used in this error case is encoded with audio frame fragmented. To
>> handle this we added de-packetizer for Dolby Digital/Dolby Digital
>> plus to reassemble the fragmented frames. The de-packetizer tries to
>> find the sync word of each frame. Based on the sync word it can get
>> the frame length and then do the frame reassemble.
>>
>> Root Cause of the problem: Implementation.
>>
>> Files Added:
>> /datatype/mp4/payload/dd_depack.cpp
>> /datatype/mp4/payload/pub/dd_depack.h
>>
>> Files Modified:
>> /datatype/mp4/payload/umakefil
>> /datatype/mp4/payload/mp4apyld.cpp
>> /datatype/mp4/payload/pub/mp4apyld.h
>>
>> Image Size and Heap Use impact:
>> mp4pyldlib.lib size increased 2kB
>> Heap size increased based on encoded AC3/EAC3 frame sizes, <20KB in
>> normal cases.
>>
>>
>> Module Release testing (STIF) : Passed selected test cases.
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes. No new leaks introduced
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch: 210CayS, Head, 420Brizo
>>
>>
>>
>>
>
>
From Gang.Jia at nokia.com Thu Mar 4 16:12:44 2010
From: Gang.Jia at nokia.com (Gang.Jia@nokia.com)
Date: Thu Mar 4 23:26:11 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR:Case ou1cimx1#259923
Helix Cannot play MPEG4 avi with 5.1ch AC3
In-Reply-To: <4B903DDB.7090707@real.com>
References: <6F45DEE63C5BB542B6A7B0C4E41467D0152ECC66B8@NOK-EUMSG-03.mgdnok.nokia.com>
<4B8F0FB6.3070603@real.com>
<6F45DEE63C5BB542B6A7B0C4E41467D0152ED4CB7D@NOK-EUMSG-03.mgdnok.nokia.com>
<4B903DDB.7090707@real.com>
Message-ID: <6F45DEE63C5BB542B6A7B0C4E41467D0152ED4CB9B@NOK-EUMSG-03.mgdnok.nokia.com>
Thanks Sheldon! Checked in to 210CayS, Head and 420Brizo
/Gang
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Thursday, March 04, 2010 5:10 PM
To: Jia Gang (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
Looks good.
fxd
Gang.Jia@nokia.com wrote:
> Hi Sheldon
>
> I have taken the comments 1,2,3. For comment 4, I have removed the extra copy. Now there is only one copy in the fragmented case, for none fragmented case there is no copy in DDDepack. Since the clip with fragmented frame is very rare I think this change should have little impact on the performance.
>
> Thanks,
> Gang
>
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Wednesday, March 03, 2010 7:41 PM
> To: Jia Gang (Nokia-D/Dallas)
> Cc: datatype-dev@helixcommunity.org;
> nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot
> play MPEG4 avi with 5.1ch AC3
>
> Change in mp4pyld looks good. For dd-depack.cpp:
>
> 1. Init function always return TRUE even if there is out of memory error(s). If we don't think OOM could happen, then those detection logic should be taken out, otherwise correct error coder returned.
>
> 2. dtor's "if (xxx) delete(xxx); xxx = 0;" could be replaced by "HX_VECTOR_DELETE(xxx)"
>
> 3. In FindSyncWord, the outer 'if' doesn't seem to be needed if you just make the for loop start at i=0, instead of i=1.
>
> 4. The depack logic in OnPacket and ProcessingStagingBuffer is quite inefficient with extra memcpy ops that can be avoided, especially for clips that don't have fragmented packets (or have only a small amount of fragmented packets). For any incoming packet, if it doesn't start with partial frame data (has sync word at beginning) then the data up to the last whole frame in the packet buffer can be returned to the caller directly without any memcpy. Only for incoming packet that starts at partial frame offset that memcpy is needed and even for that case only one memcpy is needed for any given byte of the incoming data. Having a staging buffer and a final buffer to always do two memcpy ops for each byte is not necessary.
>
> Since this has some performance impact (memcpy stuff), It might be a good idea to wrap the calling of depacktizer from mp4pyld in a HELIX_FEATURE define.
>
> fxd
>
> Gang.Jia@nokia.com wrote:
>
>> Any comment on this one?
>>
>> Thanks
>> Gang
>>
>> ---------------------------------------------------------------------
>> -
>> --
>> *From:* nokia-private-dev-bounces@helixcommunity.org
>> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
>> *Jia Gang (Nokia-D/Dallas)
>> *Sent:* Monday, March 01, 2010 3:22 PM
>> *To:* datatype-dev@helixcommunity.org
>> *Cc:* nokia-private-dev@helixcommunity.org
>> *Subject:* [Nokia-private-dev] CR:Case ou1cimx1#259923 Helix Cannot
>> play MPEG4 avi with 5.1ch AC3
>>
>> "Nokia submits this code under the terms of a commercial contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: Gang.Jia@nokia.com
>>
>> Reviewed by:
>>
>> Date: 2/26/2010
>>
>> Project: SymbianMmf_wm
>>
>> ErrorId: ESLM-829J6K
>>
>> Synopsis: CR: Helix Cannot play MPEG4 avi with 5.1ch AC3
>>
>> The current implementation of Dolby Digital doesn't consider the case
>> that the audio frame could be fragmented during the encoding. The
>> clip used in this error case is encoded with audio frame fragmented.
>> To handle this we added de-packetizer for Dolby Digital/Dolby Digital
>> plus to reassemble the fragmented frames. The de-packetizer tries to
>> find the sync word of each frame. Based on the sync word it can get
>> the frame length and then do the frame reassemble.
>>
>> Root Cause of the problem: Implementation.
>>
>> Files Added:
>> /datatype/mp4/payload/dd_depack.cpp
>> /datatype/mp4/payload/pub/dd_depack.h
>>
>> Files Modified:
>> /datatype/mp4/payload/umakefil
>> /datatype/mp4/payload/mp4apyld.cpp
>> /datatype/mp4/payload/pub/mp4apyld.h
>>
>> Image Size and Heap Use impact:
>> mp4pyldlib.lib size increased 2kB
>> Heap size increased based on encoded AC3/EAC3 frame sizes, <20KB in
>> normal cases.
>>
>>
>> Module Release testing (STIF) : Passed selected test cases.
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes. No new leaks introduced
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-52-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch: 210CayS, Head, 420Brizo
>>
>>
>>
>>
>
>
From ext-debashis.2.panigrahi at nokia.com Thu Mar 4 19:30:52 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Mar 5 02:43:27 2010
Subject: [datatype-dev] CR: SALM-835DF6: Codenomicon 3GP5: Kern Exec 3 panic
in bitstream.c fillUp()
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: ext-debashis.2.panigrahi@nokia.com
Reviewed by: Patrick.Amick@nokia.com
TSW Id: SALM-835DF6
Date: 03/05/2010
Project: SymbianMmf_wm
Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
Overview:
In this file the audio decoder specific desc data that is being read from header is not present and so when we pass this pointer to bit stream for read it fails as we try to access a NULL pointer.
Fix:
Checking if Audio config size is zero then returning HXR_FAIL, and thus going for partial (only video) playback.
Files modified & changes:
datatype/mp4/payload/mp4apyld.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS:
Index: mp4/payload/mp4apyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
retrieving revision 1.14.6.5
diff -u -w -r1.14.6.5 mp4apyld.cpp
--- mp4/payload/mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
+++ mp4/payload/mp4apyld.cpp 4 Mar 2010 05:47:05 -0000
@@ -450,6 +450,10 @@
retVal = HXR_OUTOFMEMORY;
}
}
+ else
+ {
+ retVal = HXR_FAIL;
+ }
}
if (SUCCEEDED(retVal))
From ext-debashis.2.panigrahi at nokia.com Thu Mar 4 22:12:21 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Mar 5 05:24:43 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: CKSS-833A8S: Audio is
not played
properly for avi video file and lentgh info shown in not correct and len
info sh
In-Reply-To: <4B8FCD96.6060107@real.com>
References: <20D73E2631F7914F868646E119DEC1CE22A4C27A28@NOK-EUMSG-02.mgdnok.nokia.com>
<4B8FCD96.6060107@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CD4AFC69@NOK-EUMSG-02.mgdnok.nokia.com>
Hi,
Thanks Sheldon!!
The changes has been modified as suggested and checked in to 210CayS, 420Bizo and HEAD
Here is the modified diff:
Index: avi/fileformat/avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.9.6.8
diff -u -w -r1.9.6.8 avistrm.cpp
--- avi/fileformat/avistrm.cpp 1 Mar 2010 22:03:28 -0000 1.9.6.8
+++ avi/fileformat/avistrm.cpp 5 Mar 2010 05:43:52 -0000
@@ -412,6 +412,13 @@
m_header.ulQuality = LE32_TO_HOST(*(UINT32*) &buf[40]);
m_header.ulSampleSize = LE32_TO_HOST(*(UINT32*) &buf[44]);
+ // For Duration calculation:
+ if(m_header.ulLength == 0 && m_header.ulScale)
+ {
+ m_header.ulLength = m_mainHeader.ulMicroSecPerFrame * m_mainHeader.ulTotalFrames *
+ ((double) m_header.ulRate / (m_header.ulScale * 1000000));
+ }
+
if(len >= sizeof(m_header))
{
m_header.sTop = (INT16) LE16_TO_HOST(*(UINT32*) &buf[48]);
@@ -1149,10 +1156,6 @@
HXLOGL4(HXLOG_AVIX,"\t\tStartTime:\t%lu", (ULONG32) (m_header.ulStart * m_fSamplesPerSecond * 1000));
// Duration:
- if(m_header.ulLength == 0)
- {
- m_header.ulLength = 0xffffffff;
- }
pHeader->SetPropertyULONG32("Duration", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
HXLOGL4(HXLOG_AVIX,"\t\tDuration:\t%lu", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
Best Regards,
Debashis.
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Thursday, March 04, 2010 8:41 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: CKSS-833A8S: Audio is not played properly for avi video file and lentgh info shown in not correct and len info sh
Looks ok, though this m_header.ulLength adjustment logic should probably be moved to SetHeader, after ulLength is extract from raw header buffer and detected to be zero. Reason being that there is another place
(GetDuration) that the ulLength is used to calculate duration and if we do the adjustment in GetHeader, we will have to rely on the fact that GetHeader is always called before GetDuration, which could be a problem in the future.
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> TSW Id: CKSS-833A8S
>
> Date: 03/04/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Audio is not played properly for avi video file and length
> info shown in not correct
>
> Overview:
> There are two issues here:
> 1) The audio stream length that is being read from header is zero, so
> audio duration calculation goes wrong. This CR fixes this problem
> 2) Audio doesn't play or plays intermittently. Here decoder is failing with KErrCorrupt as its not getting sync frame although when we dumped encoded audio data at helix we were able to play it properly. A separate Error has to be raised for this.
>
> Fix:
> Now calculating the audio stream length if its not set from the main header instead of setting it to 0xffffffff.
>
> Files modified & changes:
> datatype/avi/fileformat/avistrm.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: avi/fileformat/avistrm.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
> retrieving revision 1.9.6.8
> diff -u -w -r1.9.6.8 avistrm.cpp
> --- avi/fileformat/avistrm.cpp 1 Mar 2010 22:03:28 -0000 1.9.6.8
> +++ avi/fileformat/avistrm.cpp 3 Mar 2010 04:08:32 -0000
> @@ -1151,7 +1155,7 @@
> // Duration:
> if(m_header.ulLength == 0)
> {
> - m_header.ulLength = 0xffffffff;
> + m_header.ulLength = m_mainHeader.ulMicroSecPerFrame *
> + m_mainHeader.ulTotalFrames * ((double)m_fSamplesPerSecond /
> + 1000000);
> }
> pHeader->SetPropertyULONG32("Duration", (ULONG32) (((double) m_header.ulLength / m_fSamplesPerSecond) * 1000));
> HXLOGL4(HXLOG_AVIX,"\t\tDuration:\t%lu", (ULONG32) (((double)
> m_header.ulLength / m_fSamplesPerSecond) * 1000));
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
> .
>
>
From sfu at real.com Fri Mar 5 04:20:53 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Mar 5 11:32:32 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon
3GP5: Kern Exec 3 panic in bitstream.c fillUp()
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B90F725.7000904@real.com>
Not sure if there is a mp4a payload type that doesn't require audio
config data but since X-RN-MP4-RAWAU is a catch-all default mimetype in
mp4 file format (it's not just AAC), the detection of null config data
is probably best deferred to when we actually need to parse it (in
decoder's OpenDecoder function I assume).
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Patrick.Amick@nokia.com
>
> TSW Id: SALM-835DF6
>
> Date: 03/05/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
>
> Overview:
> In this file the audio decoder specific desc data that is being read from header is not present and so when we pass this pointer to bit stream for read it fails as we try to access a NULL pointer.
>
> Fix:
> Checking if Audio config size is zero then returning HXR_FAIL, and thus going for partial (only video) playback.
>
> Files modified & changes:
> datatype/mp4/payload/mp4apyld.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: mp4/payload/mp4apyld.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
> retrieving revision 1.14.6.5
> diff -u -w -r1.14.6.5 mp4apyld.cpp
> --- mp4/payload/mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
> +++ mp4/payload/mp4apyld.cpp 4 Mar 2010 05:47:05 -0000
> @@ -450,6 +450,10 @@
> retVal = HXR_OUTOFMEMORY;
> }
> }
> + else
> + {
> + retVal = HXR_FAIL;
> + }
> }
>
> if (SUCCEEDED(retVal))
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>
>
From ext-debashis.2.panigrahi at nokia.com Fri Mar 5 05:20:23 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Mar 5 12:32:17 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon
3GP5: Kern Exec 3 panic in bitstream.c fillUp()
In-Reply-To: <4B90F725.7000904@real.com>
References: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
<4B90F725.7000904@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CD4B00DA@NOK-EUMSG-02.mgdnok.nokia.com>
Hi Sheldon,
I have modified the change and transferred the check to OpenDecoder() as suggested. Here is the modified diff:
Index: symbianswdecoder.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/audio/mdf/platform/symbian/symbianswdecoder.cpp,v
retrieving revision 1.2.2.4
diff -u -w -r1.2.2.4 symbianswdecoder.cpp
--- symbianswdecoder.cpp 26 Mar 2008 20:09:33 -0000 1.2.2.4
+++ symbianswdecoder.cpp 5 Mar 2010 13:17:01 -0000
@@ -85,6 +85,15 @@
HX_RESULT result = HXR_OK;
HXAudioConfigurator* pAudConfig = NULL;
+ // make sure config is not NULL
+ if(!config)
+ {
+ HXLOGL2(HXLOG_MDFA,
+ "HXSymbianSwAudioDecoder::OpenDecoder() HXR_FAIL: Config not present");
+
+ result = HXR_FAIL;
+ }
+
// make sure fourCC has been set
if(m_pFourCC[0] == '\0')
{
Best Regards,
Debashis.
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, March 05, 2010 5:51 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
Not sure if there is a mp4a payload type that doesn't require audio config data but since X-RN-MP4-RAWAU is a catch-all default mimetype in
mp4 file format (it's not just AAC), the detection of null config data is probably best deferred to when we actually need to parse it (in decoder's OpenDecoder function I assume).
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Patrick.Amick@nokia.com
>
> TSW Id: SALM-835DF6
>
> Date: 03/05/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
>
> Overview:
> In this file the audio decoder specific desc data that is being read from header is not present and so when we pass this pointer to bit stream for read it fails as we try to access a NULL pointer.
>
> Fix:
> Checking if Audio config size is zero then returning HXR_FAIL, and thus going for partial (only video) playback.
>
> Files modified & changes:
> datatype/mp4/payload/mp4apyld.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: mp4/payload/mp4apyld.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
> retrieving revision 1.14.6.5
> diff -u -w -r1.14.6.5 mp4apyld.cpp
> --- mp4/payload/mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
> +++ mp4/payload/mp4apyld.cpp 4 Mar 2010 05:47:05 -0000
> @@ -450,6 +450,10 @@
> retVal = HXR_OUTOFMEMORY;
> }
> }
> + else
> + {
> + retVal = HXR_FAIL;
> + }
> }
>
> if (SUCCEEDED(retVal))
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>
>
From ext-anugrah.2.kashari at nokia.com Fri Mar 5 05:24:16 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Fri Mar 5 12:35:52 2010
Subject: [datatype-dev] CR : SALM-835FZC: Codenomicon 3GP5: Kern Exec 3
panic in CQTAtom::GetUI16()
Message-ID:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
Modified By: ext-anugrah.2.kashari@nokia.com
Review By: Rathinasamy Rajesh (Nokia-D/Dallas)
TSW-ID: SALM-835FZC
Date : 05/03/2010
Project: SymbianMmf_wm
Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
Overview: stsd atom for handle type video(vide) is corrupted. In this particular case, stsd atom has size of 182 (0xb6) bytes and number of entry_count for sample description is 256 . During initialization, in CQT_SampleDescription_Manager::Init() this description is read in loop. Each nextEntryOffset is equal to currentEntryOffset + SizeOf(currentEntryOffset) { computed in CQTAtom ::FindArrayEntry() in qtbatom.h}. Size of first entry is huge (0xa7bd bytes , actually cannot be greater than 166 bytes ) so next entry point returned is invalid, hence the panic.
Fix: In CQTAtom ::FindArrayEntry(), offset should be checked after pStartEntry has been updated to ensure that it is still a valid pointer.
Files modified & changes 210Cays , Brizo420 and Head :
/cvsroot/datatype/mp4/fileformat/pub/qtbatom.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5
Branch : 210Cays, Brizo420 & Head :
CVS diff: For 210 cays
Index: qtbatom.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h,v
retrieving revision 1.5.8.2
diff -u -w -r1.5.8.2 qtbatom.h
--- qtbatom.h 4 Nov 2009 14:41:21 -0000 1.5.8.2
+++ qtbatom.h 4 Mar 2010 11:46:51 -0000
@@ -214,13 +214,13 @@
{
while (ulArrayIdx != 0)
{
+ pStartEntry += GetUL32(pStartEntry);
+ ulArrayIdx--;
if (((UINT32)(pStartEntry - m_pData)) >= m_pBuffer->GetSize())
{
pStartEntry = NULL;
break;
}
- pStartEntry += GetUL32(pStartEntry);
- ulArrayIdx--;
}
return pStartEntry;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100305/ef0a53f4/attachment.html
From sfu at real.com Fri Mar 5 06:10:32 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Mar 5 13:21:44 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon
3GP5: Kern Exec 3 panic in bitstream.c fillUp()
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE22CD4B00DA@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
<4B90F725.7000904@real.com>
<20D73E2631F7914F868646E119DEC1CE22CD4B00DA@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B9110D8.6020700@real.com>
Looks good.
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> Hi Sheldon,
>
> I have modified the change and transferred the check to OpenDecoder() as suggested. Here is the modified diff:
> Index: symbianswdecoder.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/audio/mdf/platform/symbian/symbianswdecoder.cpp,v
> retrieving revision 1.2.2.4
> diff -u -w -r1.2.2.4 symbianswdecoder.cpp
> --- symbianswdecoder.cpp 26 Mar 2008 20:09:33 -0000 1.2.2.4
> +++ symbianswdecoder.cpp 5 Mar 2010 13:17:01 -0000
> @@ -85,6 +85,15 @@
> HX_RESULT result = HXR_OK;
> HXAudioConfigurator* pAudConfig = NULL;
>
> + // make sure config is not NULL
> + if(!config)
> + {
> + HXLOGL2(HXLOG_MDFA,
> + "HXSymbianSwAudioDecoder::OpenDecoder() HXR_FAIL: Config not present");
> +
> + result = HXR_FAIL;
> + }
> +
> // make sure fourCC has been set
> if(m_pFourCC[0] == '\0')
> {
>
> Best Regards,
> Debashis.
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Friday, March 05, 2010 5:51 PM
> To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
>
> Not sure if there is a mp4a payload type that doesn't require audio config data but since X-RN-MP4-RAWAU is a catch-all default mimetype in
> mp4 file format (it's not just AAC), the detection of null config data is probably best deferred to when we actually need to parse it (in decoder's OpenDecoder function I assume).
>
> fxd
>
> ext-debashis.2.panigrahi@nokia.com wrote:
>
>> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>>
>> Modified by: ext-debashis.2.panigrahi@nokia.com
>>
>> Reviewed by: Patrick.Amick@nokia.com
>>
>> TSW Id: SALM-835DF6
>>
>> Date: 03/05/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
>>
>> Overview:
>> In this file the audio decoder specific desc data that is being read from header is not present and so when we pass this pointer to bit stream for read it fails as we try to access a NULL pointer.
>>
>> Fix:
>> Checking if Audio config size is zero then returning HXR_FAIL, and thus going for partial (only video) playback.
>>
>> Files modified & changes:
>> datatype/mp4/payload/mp4apyld.cpp
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : Passed
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : Passed, No additional leaks introduced.
>>
>> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5, winscw
>>
>> Branch: 210CayS, 420Bizo and HEAD
>>
>> CVS Diff on 210CayS:
>> Index: mp4/payload/mp4apyld.cpp
>> ===================================================================
>> RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
>> retrieving revision 1.14.6.5
>> diff -u -w -r1.14.6.5 mp4apyld.cpp
>> --- mp4/payload/mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
>> +++ mp4/payload/mp4apyld.cpp 4 Mar 2010 05:47:05 -0000
>> @@ -450,6 +450,10 @@
>> retVal = HXR_OUTOFMEMORY;
>> }
>> }
>> + else
>> + {
>> + retVal = HXR_FAIL;
>> + }
>> }
>>
>> if (SUCCEEDED(retVal))
>> _______________________________________________
>> Nokia-private-dev mailing list
>> Nokia-private-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>>
>>
>>
>
> .
>
>
From ehyche at real.com Fri Mar 5 11:30:14 2010
From: ehyche at real.com (Eric Hyche)
Date: Fri Mar 5 18:41:40 2010
Subject: [datatype-dev] Fwd: [Build Farm]: Job #208582 on win32-i386-vc8
complete (build buster)
References: <201003051651.o25GpZjK001006@build02.dev.prognet.com>
Message-ID: <292E78F8-E8DE-4F62-9CE0-BEC8F83E1CAC@real.com>
This recent change to datatype/mp4/payload:
https://helixcommunity.org/viewcvs/datatype/mp4/payload/mp4apyld.cpp?r1=1.23&r2=1.22
CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
broke VC8 builds because of the mixed line endings. Here's the error from the broken build below:
mp4apyld.cpp
mp4apyld.cpp
c:\builds\src\datatype\mp4\payload\pub\dd-depack.h : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format
NMAKE : fatal error U1077: 'C:\vs2005\VC\BIN\cl.EXE' : return code '0x2'
Stop.
Please fix this and make sure that line endings are consistent on any future checkins.
Thanks,
Eric
Begin forwarded message:
> From: "build@build02.dev.prognet.com"
> Date: March 5, 2010 11:51:35 AM EST
> To: Eric Hyche
> Subject: [Build Farm]: Job #208582 on win32-i386-vc8 complete (build buster)
>
>
> Build ID : 208582
> URL : http://build.dev.prognet.com/~build/report.cgi?id=208582
> Platform : win32-i386-vc8
> Branch : helixinternal
> Target : clientapps_rn_ngvinstaller
> Type : release
> Code Sync : 2010-03-05 16:20:59 (UTC)
>
>
> These modules have been broken less than 50% of the time in
> the last 7 days. They are broken today.
> ------------------------------------------------------------
> Module : datatype/mp4/fileformat
> Error : WinCompile(datatype/mp4/fileformat) ERROR: Make failed.
> Broken[%]: 0%
>
> Module : datatype/mp4/audio/renderer
> Error : WinCompile(datatype/mp4/audio/renderer) ERROR: Make failed.
> Broken[%]: 0%
>
> Module : datatype/mp4/payload
> Error : WinCompile(datatype/mp4/payload) ERROR: Make failed.
> Broken[%]: 0%
>
>
> These modules failed to compile:
> ------------------------------------------------------------
> Module : datatype/mp4/fileformat
> Error : WinCompile(datatype/mp4/fileformat) ERROR: Make failed.
> Broken[%]: 0%
>
> Module : datatype/mp4/audio/renderer
> Error : WinCompile(datatype/mp4/audio/renderer) ERROR: Make failed.
> Broken[%]: 0%
>
> Module : datatype/mp4/payload
> Error : WinCompile(datatype/mp4/payload) ERROR: Make failed.
> Broken[%]: 0%
>
>
> Prior build : 208536
> Prior code sync : 2010-03-04 16:22:23 (UTC)
>
> Helix Commits:
>
> Time (UTC) | User | File
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 18:19 | jzeng | common/include/defslice.h
> https://helixcommunity.org/viewcvs/common/include/defslice.h?r1=1.29&r2=1.28
> Synopsis
> ============
> Bug 248588: RTP Live livensing is controlled by the QuickTime datatype licens
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 19:41 | dcollins | server/engine/core/pub/platform/unix/servcallback.h
> https://helixcommunity.org/viewcvs/server/engine/core/pub/platform/unix/servcallback.h?r1=1.17&r2=1.16
> Synopsis
> ========
> Fix related to PR 258373: RHEL5 edge has much higher CPU usage than other OSes
>
> Br
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 23:52 | gajia | datatype/mp4/payload/dd-depack.cpp
> https://helixcommunity.org/viewcvs/datatype/mp4/payload/dd-depack.cpp?r1=1.1&r2=1.0
> CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code und
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 23:55 | gajia | datatype/mp4/payload/mp4apyld.cpp
> https://helixcommunity.org/viewcvs/datatype/mp4/payload/mp4apyld.cpp?r1=1.23&r2=1.22
> CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code und
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 23:55 | gajia | datatype/mp4/payload/Umakefil
> https://helixcommunity.org/viewcvs/datatype/mp4/payload/Umakefil?r1=1.34&r2=1.33
> CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code und
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 23:56 | gajia | datatype/mp4/payload/pub/mp4apyld.h
> https://helixcommunity.org/viewcvs/datatype/mp4/payload/pub/mp4apyld.h?r1=1.11&r2=1.10
> CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code und
> ----------------------------------------------------------------------------------------------------
> 2010-03-04 23:57 | gajia | datatype/mp4/payload/pub/dd-depack.h
> https://helixcommunity.org/viewcvs/datatype/mp4/payload/pub/dd-depack.h?r1=1.1&r2=1.0
> CR: Case ou1cimx1#259923 Helix Cannot play MPEG4 avi with 5.1ch AC3
>
> "Nokia submits this code und
> ----------------------------------------------------------------------------------------------------
> 2010-03-05 01:07 | dcollins | server/protocol/http/httpprot.cpp
> https://helixcommunity.org/viewcvs/server/protocol/http/httpprot.cpp?r1=1.101&r2=1.100
> Synopsis
> ========
> Fixes PR 258858: Able to surpass ClientConnection license variable limit using HTT
> ----------------------------------------------------------------------------------------------------
> 2010-03-05 01:07 | dcollins | server/protocol/http/pub/httpprot.h
> https://helixcommunity.org/viewcvs/server/protocol/http/pub/httpprot.h?r1=1.43&r2=1.42
> Synopsis
> ========
> Fixes PR 258858: Able to surpass ClientConnection license variable limit using HTT
> ----------------------------------------------------------------------------------------------------
> 2010-03-05 13:11 | anugrahk | common/fileio/platform/symbian/hxdatasource_ccontent.cpp
> https://helixcommunity.org/viewcvs/common/fileio/platform/symbian/hxdatasource_ccontent.cpp?r1=1.10&r2=1.9
> Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, an
> ----------------------------------------------------------------------------------------------------
> 2010-03-05 13:20 | anugrahk | client/core/hxflsrc.cpp
> https://helixcommunity.org/viewcvs/client/core/hxflsrc.cpp?r1=1.141&r2=1.140
> Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, an
> ----------------------------------------------------------------------------------------------------
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
From Alvaro.Vaquero at nokia.com Fri Mar 5 15:51:41 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Fri Mar 5 23:07:29 2010
Subject: [datatype-dev] CR: PAMK-823V3J Harvester Crashes
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: aviindx.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/aviindx.cpp,v
retrieving revision 1.6.6.3
diff -w -u -b -r1.6.6.3 aviindx.cpp
--- aviindx.cpp 24 Feb 2010 06:53:32 -0000 1.6.6.3
+++ aviindx.cpp 5 Mar 2010 23:43:59 -0000
@@ -185,6 +185,8 @@
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::AddToIndex()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
+ {
// Do we have an index, or is this chunk already indexed?
if (m_pReader || ulChunk < pStream->ulSliceEndChunk)
{
@@ -207,6 +209,7 @@
pStream->ulTotalBytes += ulSize;
}
}
+}
void CAVIIndex::FileRead(BOOL bRead) // All chunks have been indexed; reset on seek
{
@@ -220,6 +223,9 @@
HX_ASSERT(usStream < m_usStreamCount);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+
+ if (pStream)
+ {
pStream->ulNextChunkRequired = ulChunk;
// Clip stale data:
@@ -232,12 +238,15 @@
}
}
}
+}
BOOL CAVIIndex::IsKeyChunk(UINT16 usStream, UINT32 ulChunk)
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::IsKeyChunk()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
+ {
// in bounds?
if (ulChunk >= pStream->ulSliceStartChunk && ulChunk < pStream->ulSliceEndChunk)
{
@@ -245,6 +254,7 @@
}
HX_ASSERT(!"Unindexed key chunk query.");
+ }
return TRUE;
}
@@ -267,6 +277,8 @@
SetMinimumChunkInterest(usStream, ulChunk);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
+ {
if (pStream->ulTotalChunks != 0)
{
if (ulChunk >= pStream->ulSliceEndChunk)
@@ -297,6 +309,7 @@
ulClosestOffset = m_ulFirstMOVIOffset + 4;
ulClosestStreamChunk = 0;
+ }
//HX_ASSERT(!"Unindexed chunk query.");
return HXR_NOT_INDEXABLE;
@@ -318,6 +331,8 @@
SetMinimumChunkInterest(usStream, ulChunk);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
+ {
if (pStream->ulTotalChunks != 0)
{
if (ulChunk >= pStream->ulLastKeyChunk)
@@ -347,6 +362,7 @@
ulClosestOffset = m_ulFirstMOVIOffset + 4;
ulClosestStreamChunk = 0;
+ }
return HXR_NOT_INDEXABLE;
}
@@ -357,7 +373,10 @@
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::GetMaxChunkSize()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
return pStream->ulMaxChunkSize;
+ else
+ return NULL;
}
// in bytes, not including header:
@@ -365,8 +384,10 @@
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::GetAverageChunkSize()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
-
+ if (pStream)
return pStream->ulTotalBytes / (double) pStream->ulTotalChunks;
+ else
+ return NULL;
}
// Returns zero if we have no index; assumes transmission at average rate
@@ -374,24 +395,30 @@
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::GetMaxByteDeflict()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
-
+ if (pStream)
return pStream->ulPrerollBytes;
+ else
+ return NULL;
}
UINT32 CAVIIndex::GetByteTotal(UINT16 usStream)
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::GetByteTotal()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
-
+ if (pStream)
return pStream->ulTotalBytes;
+ else
+ return NULL;
}
UINT32 CAVIIndex::GetChunkTotal(UINT16 usStream)
{
HXLOGL4(HXLOG_AVIX,"CAVIIndex[%p]::GetChunkTotal()", this);
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
-
+ if (pStream)
return pStream->ulTotalChunks;
+ else
+ return NULL;
}
BOOL CAVIIndex::CanLoadSlice()
@@ -404,6 +431,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[i];
+ if (pStream)
+ {
if (m_pReader &&
((pStream->ulNextChunkRequired >= pStream->ulSliceEndChunk &&
pStream->ulSliceEndOffset < m_ulIndexOffset + m_ulIndexLength - sizeof(idx1Entry)) ||
@@ -412,6 +441,7 @@
return TRUE;
}
}
+ }
return FALSE;
}
@@ -426,6 +456,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[i];
+ if (pStream)
+ {
if (m_pReader &&
pStream->ulSliceEndOffset < m_ulIndexOffset + m_ulIndexLength - sizeof(idx1Entry) &&
((pStream->ulNextChunkRequired >= pStream->ulSliceEndChunk ||
@@ -435,6 +467,7 @@
return TRUE;
}
}
+ }
return FALSE;
}
@@ -455,6 +488,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[i];
+ if (pStream)
+ {
if (pStream->ulNextChunkRequired >= pStream->ulSliceEndChunk)
{
UINT32 ulIndexRemaining = m_ulIndexOffset + m_ulIndexLength - pStream->ulSliceEndOffset;
@@ -516,11 +551,14 @@
ulLeastFullStream = i;
}
}
+ }
if (MAX_SLICE_SIZE - llMinFillLevel >= LOAD_GRANULARITY && ulLeastFullStream >= 0)
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[ulLeastFullStream];
+ if (pStream)
+ {
if (m_pReader->GetOffset() != pStream->ulSliceEndOffset)
{
m_state = eSeekToRecord;
@@ -542,9 +580,9 @@
m_pOuter->IOEvent();
}
}
-
return;
}
+ }
m_pOuter->IOEvent();
}
@@ -636,8 +674,11 @@
for (UINT16 i = 0; i < m_usStreamCount; ++i)
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[i];
+ if (pStream)
+ {
pStream->ulSliceEndOffset = m_ulIndexOffset;
}
+ }
// Scan index for preroll, bitrate values:
HX_ASSERT(m_scanState == eInitial);
@@ -754,6 +795,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[CAVIFileFormat::GetStream(pEntry->ulChunkId)];
+ if (pStream)
+ {
pStream->ulTotalBytes += LE32_TO_HOST(pEntry->ulChunkLength);
if (pEntry->ulChunkLength > pStream->ulMaxChunkSize)
{
@@ -761,6 +804,7 @@
}
pStream->ulTotalChunks++;
}
+ }
pEntry++;
}
@@ -795,6 +839,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[CAVIFileFormat::GetStream(pEntry->ulChunkId)];
+ if (pStream)
+ {
UINT32 ulAverageBytesPerChunk = (UINT32) (pStream->ulTotalBytes / (double) pStream->ulTotalChunks);
pStream->llByteDeflict -= ((INT64) ulAverageBytesPerChunk - LE32_TO_HOST(pEntry->ulChunkLength));
@@ -805,6 +851,7 @@
pStream->ulPrerollBytes = (UINT32) pStream->llByteDeflict;
}
}
+ }
pEntry++;
}
@@ -852,6 +899,8 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[CAVIFileFormat::GetStream(pEntry->ulChunkId)];
+ if (pStream)
+ {
if ((INT64) pStream->ulSliceEndChunk - pStream->ulNextChunkRequired < MAX_SLICE_SIZE)
{
pStream->bSliceOffsetCapped = FALSE;
@@ -897,16 +946,20 @@
pStream->bSliceOffsetCapped = TRUE;
pStream->ulSliceEndOffset = m_pReader->GetOffset() - i*sizeof(idx1Entry);
}
+ }
for (UINT16 j = 0; j < m_usStreamCount; j++)
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[j];
+ if (pStream)
+ {
if (!pStream->bSliceOffsetCapped)
{
pStream->ulSliceEndOffset = m_pReader->GetOffset() - (i-1)*sizeof(idx1Entry);
}
}
}
+ }
pEntry++;
}
@@ -1001,8 +1054,11 @@
{
StreamSlice* pStream = (StreamSlice*) m_sliceArray[usStream];
+ if (pStream)
+ {
if (ulChunkNumber < pStream->ulSliceEndChunk)
return pStream->entryArray [ulChunkNumber].ulLength;
else
return -1;
}
+}
-------------- next part --------------
Index: metadataeng.h
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/metadataeng.h,v
retrieving revision 1.1.2.2
diff -w -u -b -r1.1.2.2 metadataeng.h
--- metadataeng.h 24 Jan 2008 17:02:05 -0000 1.1.2.2
+++ metadataeng.h 5 Mar 2010 23:45:08 -0000
@@ -79,7 +79,7 @@
CHXMetaDataEng();
- STDMETHOD_(HX_RESULT, SetupGlobals)(THIS);
+ STDMETHOD_(HX_RESULT, SetupGlobals)(THIS_ HXBOOL bIsMetaData = FALSE); // Specifies whether the instance belongs to MetaData or Thumbnail
STDMETHOD_(HX_RESULT, SetupPreferences)(THIS);
STDMETHOD_(void, DoDestroy)(THIS);
STDMETHOD_(void, GetDefaultOptions)(THIS_ IHXValues* pOptions);
Index: metadataengbase.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/metadataengbase.cpp,v
retrieving revision 1.1.2.3
diff -w -u -b -r1.1.2.3 metadataengbase.cpp
--- metadataengbase.cpp 24 Jan 2008 17:02:05 -0000 1.1.2.3
+++ metadataengbase.cpp 5 Mar 2010 23:45:08 -0000
@@ -178,7 +178,7 @@
if (self)
{
- if( self->Initialize() != HXR_OK)
+ if( self->Initialize(TRUE) != HXR_OK) // TRUE = MetaData instance FALSE = thumbnail instance
{
HX_DELETE(self);
}
@@ -191,9 +191,9 @@
// setup preferences.
// Create DT Driver and initialize it.
-HX_RESULT CHXMetaDataEngBase::Initialize()
+HX_RESULT CHXMetaDataEngBase::Initialize(HXBOOL bIsMetaData)
{
- MD_LOG("CHXMetaDataEngBase::Initialize\n");
+ MD_LOG("CHXMetaDataEngBase::Initialize bIsMetaData %d\n", bIsMetaData);
HX_RESULT hxr;
@@ -211,7 +211,9 @@
if (SUCCEEDED(hxr))
{
- hxr = SetupGlobals();
+ hxr = SetupGlobals(bIsMetaData);
+ if (hxr == KErrNotReady)
+ return hxr;
}
if (SUCCEEDED(hxr))
Index: platform/symbian/symbian_metadataeng.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp,v
retrieving revision 1.1.2.7
diff -w -u -b -r1.1.2.7 symbian_metadataeng.cpp
--- platform/symbian/symbian_metadataeng.cpp 12 Feb 2010 16:27:33 -0000 1.1.2.7
+++ platform/symbian/symbian_metadataeng.cpp 5 Mar 2010 23:45:09 -0000
@@ -151,6 +151,7 @@
,m_bProtectedAndCantPlay(FALSE)
,m_bDCFHeadersNeeded(TRUE)
{
+ m_bGlMgrTaken = FALSE;
}
CHXSymbianMetaDataEng::~CHXSymbianMetaDataEng()
@@ -257,10 +258,25 @@
}
HX_RELEASE(m_pDataSource);
- m_pDataSource = CHXDataSourceFactory::Build(aMediaSource, TRUE /* bPeek */);
-
- MD_LOG("CHXSymbianMetaDataEng::OpenSource m_pDataSource=%p\n",
+ m_pDataSource = CHXDataSourceFactory::Build(aMediaSource, TRUE /* bPeek */, TRUE /* bForceSyncReading */);
+ if (aMediaSource.mType == CHXMediaSource::ERFile)
+ {
+ TBuf16<256> fileName;
+ RFile * testf = (RFile *)aMediaSource.m_pData;
+ testf->FullName(fileName);
+ MD_LOG("CHXSymbianMetaDataEng::OpenSource m_pDataSource=%x RFile = %S\n",
+ m_pDataSource, &fileName);
+ }
+ else if (aMediaSource.mType == CHXMediaSource::EFileName)
+ {
+ MD_LOG("CHXSymbianMetaDataEng::OpenSource m_pDataSource=%x Filename = %s\n",
+ m_pDataSource, aMediaSource.m_pData);
+ }
+ else
+ {
+ MD_LOG("CHXSymbianMetaDataEng::OpenSource m_pDataSource=%x\n",
m_pDataSource);
+ }
if (m_pDataSource)
{
@@ -394,11 +410,22 @@
// creates dll map.
// sets dllaccess paths.
-HX_RESULT CHXSymbianMetaDataEng::SetupGlobals()
+HX_RESULT CHXSymbianMetaDataEng::SetupGlobals(HXBOOL bIsMetaData)
{
HX_RESULT hxr;
+ if (bIsMetaData)
+ {
+ TInt err;
+ if (HXGlobalManInstance::GetInstance())
+ {
+ MD_LOG("SetupGlobals EXIT");
+ m_bGlMgrTaken = TRUE;
+ return KErrNotReady;
+ }
+ }
+
GetInstallDrive(m_strInstallDrive);
MD_LOG("CHXSymbianMetaDataEng::SetupGlobals InstallDrive=%s\n",
@@ -580,14 +607,13 @@
CHXMetaDataEngBase::DoDestroy();
-
HX_RELEASE(m_pPrefs);
HX_RELEASE(m_pDataSource);
HXGlobalManagerImp* pGM = static_cast
( HXGlobalManInstance::GetInstance() );
- if(pGM != NULL)
+ if(pGM != NULL && !m_bGlMgrTaken)
{
pGM->Shutdown();
HX_DELETE(pGM);
Index: pub/metadataengbase.h
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/pub/metadataengbase.h,v
retrieving revision 1.1.2.3
diff -w -u -b -r1.1.2.3 metadataengbase.h
--- pub/metadataengbase.h 24 Jan 2008 17:03:33 -0000 1.1.2.3
+++ pub/metadataengbase.h 5 Mar 2010 23:45:09 -0000
@@ -158,7 +158,7 @@
STDMETHOD_(void, DoDestroy)(THIS);
// functions must be implemented in the derived engines.
- STDMETHOD_(HX_RESULT, SetupGlobals)(THIS) PURE;
+ STDMETHOD_(HX_RESULT, SetupGlobals)(THIS_ HXBOOL bIsMetaData) PURE; // Specifies whether the instance belongs to MetaData or Thumbnail
STDMETHOD_(HX_RESULT, SetupPreferences)(THIS) PURE;
STDMETHOD_(void, GetDefaultOptions)(THIS_ IHXValues* pOptions) PURE;
STDMETHOD_(CHXMetaDataEntry*, CreateMetaDataEntry)
@@ -173,7 +173,7 @@
STDMETHOD_(void, DeleteMetaDataEntry)
(THIS_ CHXMetaDataEntry *pEntry) PURE;
- HX_RESULT Initialize();
+ HX_RESULT Initialize(HXBOOL bForceSyncReading = FALSE);
private:
Index: pub/platform/symbian/symbian_metadataeng.h
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h,v
retrieving revision 1.1.2.6
diff -w -u -b -r1.1.2.6 symbian_metadataeng.h
--- pub/platform/symbian/symbian_metadataeng.h 12 Feb 2010 16:27:33 -0000 1.1.2.6
+++ pub/platform/symbian/symbian_metadataeng.h 5 Mar 2010 23:45:09 -0000
@@ -151,7 +151,7 @@
public:
- STDMETHOD_(HX_RESULT, SetupGlobals)(THIS);
+ STDMETHOD_(HX_RESULT, SetupGlobals)(THIS_ HXBOOL bIsMetaData); // Specifies whether the instance belongs to MetaData or Thumbnail
STDMETHOD_(HX_RESULT, SetupPreferences)(THIS);
STDMETHOD_(void, DoDestroy)(THIS);
STDMETHOD_(void, GetDefaultOptions)(THIS_ IHXValues* pOptions);
@@ -189,6 +189,7 @@
IHXMMFDataSource* m_pDataSource;
HXBOOL m_bProtectedAndCantPlay;
HXBOOL m_bDCFHeadersNeeded;
+ HXBOOL m_bGlMgrTaken;
};
-------------- next part --------------
Index: minifileobj.cpp
===================================================================
RCS file: /cvsroot/filesystem/local/mini/minifileobj.cpp,v
retrieving revision 1.23.2.14
diff -w -u -b -r1.23.2.14 minifileobj.cpp
--- minifileobj.cpp 2 Dec 2009 18:38:54 -0000 1.23.2.14
+++ minifileobj.cpp 5 Mar 2010 23:45:35 -0000
@@ -849,7 +849,10 @@
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
if(m_pDataSource2)
{
+ if (m_bAsyncReadSupported)
actualCount = m_pDataSource2->Read(pBuffer, this); // ASync read on datasource
+ else
+ actualCount = m_pDataSource2->Read2(pBuffer, this); // Sync read on datasource
}
else
#endif
-------------- next part --------------
Index: platform/symbian/hxdatasource_ccontent.cpp
===================================================================
RCS file: /cvsroot/common/fileio/platform/symbian/hxdatasource_ccontent.cpp,v
retrieving revision 1.1.2.8
diff -w -u -b -r1.1.2.8 hxdatasource_ccontent.cpp
--- platform/symbian/hxdatasource_ccontent.cpp 5 Mar 2010 13:07:17 -0000 1.1.2.8
+++ platform/symbian/hxdatasource_ccontent.cpp 5 Mar 2010 23:43:12 -0000
@@ -64,6 +64,7 @@
#define MAX_DCF_HEADER_LENGTH 256
CHXDataSourceCContent::CHXDataSourceCContent(HXBOOL bPeek
+ ,HXBOOL bForceSyncReading
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
,TInt aPriority
#endif
@@ -99,16 +100,18 @@
{
m_intent = EPlay;
}
+ m_bForceSyncReading = bForceSyncReading;
}
CHXDataSourceCContent* CHXDataSourceCContent::Create(
char *pFileName,
- HXBOOL bPeek)
+ HXBOOL bPeek,
+ HXBOOL bForceSyncReading)
{
TInt err = KErrNone;
- CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek);
+ CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek, bForceSyncReading);
if (self)
{
@@ -124,14 +127,15 @@
CHXDataSourceCContent* CHXDataSourceCContent::Create(
RFile* pFileHandle,
- HXBOOL bPeek)
+ HXBOOL bPeek,
+ HXBOOL bForceSyncReading)
{
HX_RESULT hxr;
TInt err = KErrNone;
- CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek);
+ CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek, bForceSyncReading);
if (self)
{
@@ -363,11 +367,11 @@
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
// New Create function
-CHXDataSourceCContent* CHXDataSourceCContent::Create(CData* aData,HXBOOL bPeek)
+CHXDataSourceCContent* CHXDataSourceCContent::Create(CData* aData,HXBOOL bPeek, HXBOOL bForceSyncReading)
{
TInt err = KErrNone;
- CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek);
+ CHXDataSourceCContent *self = new CHXDataSourceCContent(bPeek, bForceSyncReading);
if(aData)
{
if (self)
@@ -443,7 +447,7 @@
HXBOOL CHXDataSourceCContent::AsyncReadSupported()
{
- return TRUE;
+ return !m_bForceSyncReading;
}
STDMETHODIMP CHXDataSourceCContent::Open(IHXRequest *pRequest,
Index: platform/symbian/hxdatasource_factory.cpp
===================================================================
RCS file: /cvsroot/common/fileio/platform/symbian/hxdatasource_factory.cpp,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource_factory.cpp
--- platform/symbian/hxdatasource_factory.cpp 19 Sep 2006 21:10:10 -0000 1.1.2.1
+++ platform/symbian/hxdatasource_factory.cpp 5 Mar 2010 23:43:12 -0000
@@ -49,7 +49,7 @@
#include "hxdatasource_factory.h"
-IHXMMFDataSource* CHXDataSourceFactory::Build(CHXMediaSource& aMediaSource, HXBOOL bPeek)
+IHXMMFDataSource* CHXDataSourceFactory::Build(CHXMediaSource& aMediaSource, HXBOOL bPeek, HXBOOL bForceSyncReading)
{
IHXMMFDataSource *pDataSource;
@@ -57,7 +57,7 @@
{
#ifdef HELIX_FEATURE_METADATAENG
case CHXMediaSource::ERFile:
- pDataSource = CHXDataSourceCContent::Create((RFile*)aMediaSource.m_pData, bPeek);
+ pDataSource = CHXDataSourceCContent::Create((RFile*)aMediaSource.m_pData, bPeek, bForceSyncReading);
break;
case CHXMediaSource::EDescriptor:
@@ -65,7 +65,7 @@
break;
case CHXMediaSource::EFileName:
- pDataSource = CHXDataSourceCContent::Create((char *)aMediaSource.m_pData, bPeek);
+ pDataSource = CHXDataSourceCContent::Create((char *)aMediaSource.m_pData, bPeek, bForceSyncReading);
break;
#else
Index: pub/platform/symbian/hxdatasource_ccontent.h
===================================================================
RCS file: /cvsroot/common/fileio/pub/platform/symbian/hxdatasource_ccontent.h,v
retrieving revision 1.1.2.4
diff -w -u -b -r1.1.2.4 hxdatasource_ccontent.h
--- pub/platform/symbian/hxdatasource_ccontent.h 3 Nov 2009 18:33:44 -0000 1.1.2.4
+++ pub/platform/symbian/hxdatasource_ccontent.h 5 Mar 2010 23:43:12 -0000
@@ -95,11 +95,11 @@
public:
static CHXDataSourceCContent* Create(char* pFileName,
- HXBOOL bPeek);
+ HXBOOL bPeek, HXBOOL bForceSyncReading = FALSE);
static CHXDataSourceCContent* Create(RFile *pFileHandle,
- HXBOOL bPeek);
+ HXBOOL bPeek, HXBOOL bForceSyncReading = FALSE);
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
- static CHXDataSourceCContent* Create(CData* aData,HXBOOL bPeek);
+ static CHXDataSourceCContent* Create(CData* aData,HXBOOL bPeek,HXBOOL bForceSyncReading = FALSE);
#endif
virtual ~CHXDataSourceCContent();
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
@@ -187,6 +187,7 @@
private:
CHXDataSourceCContent(HXBOOL bPeek
+ ,HXBOOL bForceSyncReading
#ifdef HELIX_FEATURE_64_BIT_FILE_SUPPORT
,TInt aPriority = EPriorityStandard
#endif
@@ -208,6 +209,7 @@
CContent* m_pContent;
CData* m_pCData;
TIntent m_intent;
+ HXBOOL m_bForceSyncReading;
Index: pub/platform/symbian/hxdatasource_factory.h
===================================================================
RCS file: /cvsroot/common/fileio/pub/platform/symbian/hxdatasource_factory.h,v
retrieving revision 1.1.2.1
diff -w -u -b -r1.1.2.1 hxdatasource_factory.h
--- pub/platform/symbian/hxdatasource_factory.h 19 Sep 2006 21:08:08 -0000 1.1.2.1
+++ pub/platform/symbian/hxdatasource_factory.h 5 Mar 2010 23:43:12 -0000
@@ -60,7 +60,7 @@
{
public:
static IHXMMFDataSource* CHXDataSourceFactory::Build(
- CHXMediaSource& aMediaSource, HXBOOL bPeek=FALSE);
+ CHXMediaSource& aMediaSource, HXBOOL bPeek=FALSE, HXBOOL bForceSyncReading=FALSE);
};
#endif // _HX_DATASOURCE_FACTORY_H_
From ext-debashis.2.panigrahi at nokia.com Sat Mar 6 06:06:57 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Sat Mar 6 13:18:25 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon
3GP5: Kern Exec 3 panic in bitstream.c fillUp()
In-Reply-To: <4B9110D8.6020700@real.com>
References: <20D73E2631F7914F868646E119DEC1CE22CD4AFBE4@NOK-EUMSG-02.mgdnok.nokia.com>
<4B90F725.7000904@real.com>
<20D73E2631F7914F868646E119DEC1CE22CD4B00DA@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9110D8.6020700@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CD4B04A8@NOK-EUMSG-02.mgdnok.nokia.com>
Hi,
This has been checked in to 210CayS, 420Bizo and HEAD
Thanks and Regards,
Debashis.
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, March 05, 2010 7:41 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
Looks good.
fxd
ext-debashis.2.panigrahi@nokia.com wrote:
> Hi Sheldon,
>
> I have modified the change and transferred the check to OpenDecoder() as suggested. Here is the modified diff:
> Index: symbianswdecoder.cpp
> ===================================================================
> RCS file:
> /cvsroot/datatype/mp4/audio/mdf/platform/symbian/symbianswdecoder.cpp,
> v
> retrieving revision 1.2.2.4
> diff -u -w -r1.2.2.4 symbianswdecoder.cpp
> --- symbianswdecoder.cpp 26 Mar 2008 20:09:33 -0000 1.2.2.4
> +++ symbianswdecoder.cpp 5 Mar 2010 13:17:01 -0000
> @@ -85,6 +85,15 @@
> HX_RESULT result = HXR_OK;
> HXAudioConfigurator* pAudConfig = NULL;
>
> + // make sure config is not NULL
> + if(!config)
> + {
> + HXLOGL2(HXLOG_MDFA,
> + "HXSymbianSwAudioDecoder::OpenDecoder() HXR_FAIL:
> + Config not present");
> +
> + result = HXR_FAIL;
> + }
> +
> // make sure fourCC has been set
> if(m_pFourCC[0] == '\0')
> {
>
> Best Regards,
> Debashis.
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Friday, March 05, 2010 5:51 PM
> To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org;
> nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: SALM-835DF6: Codenomicon 3GP5:
> Kern Exec 3 panic in bitstream.c fillUp()
>
> Not sure if there is a mp4a payload type that doesn't require audio
> config data but since X-RN-MP4-RAWAU is a catch-all default mimetype
> in
> mp4 file format (it's not just AAC), the detection of null config data is probably best deferred to when we actually need to parse it (in decoder's OpenDecoder function I assume).
>
> fxd
>
> ext-debashis.2.panigrahi@nokia.com wrote:
>
>> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>>
>> Modified by: ext-debashis.2.panigrahi@nokia.com
>>
>> Reviewed by: Patrick.Amick@nokia.com
>>
>> TSW Id: SALM-835DF6
>>
>> Date: 03/05/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in bitstream.c fillUp()
>>
>> Overview:
>> In this file the audio decoder specific desc data that is being read from header is not present and so when we pass this pointer to bit stream for read it fails as we try to access a NULL pointer.
>>
>> Fix:
>> Checking if Audio config size is zero then returning HXR_FAIL, and thus going for partial (only video) playback.
>>
>> Files modified & changes:
>> datatype/mp4/payload/mp4apyld.cpp
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : Passed
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : Passed, No additional leaks introduced.
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-50-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5, winscw
>>
>> Branch: 210CayS, 420Bizo and HEAD
>>
>> CVS Diff on 210CayS:
>> Index: mp4/payload/mp4apyld.cpp
>> ===================================================================
>> RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
>> retrieving revision 1.14.6.5
>> diff -u -w -r1.14.6.5 mp4apyld.cpp
>> --- mp4/payload/mp4apyld.cpp 26 Jan 2010 18:48:30 -0000 1.14.6.5
>> +++ mp4/payload/mp4apyld.cpp 4 Mar 2010 05:47:05 -0000
>> @@ -450,6 +450,10 @@
>> retVal = HXR_OUTOFMEMORY;
>> }
>> }
>> + else
>> + {
>> + retVal = HXR_FAIL;
>> + }
>> }
>>
>> if (SUCCEEDED(retVal))
>> _______________________________________________
>> Nokia-private-dev mailing list
>> Nokia-private-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>>
>>
>>
>
> .
>
>
From ext-anugrah.2.kashari at nokia.com Sun Mar 7 20:39:13 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Mon Mar 8 03:50:43 2010
Subject: [datatype-dev] RESEND: [Nokia-private-dev] CR : SALM-835FZC:
Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
In-Reply-To:
References:
Message-ID:
Any comments on this?
Thanks,
Anugrah K
From: nokia-private-dev-bounces@helixcommunity.org [mailto:nokia-private-dev-bounces@helixcommunity.org] On Behalf Of Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Sent: Friday, March 05, 2010 6:54 PM
To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [Nokia-private-dev] CR : SALM-835FZC: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
Modified By: ext-anugrah.2.kashari@nokia.com
Review By: Rathinasamy Rajesh (Nokia-D/Dallas)
TSW-ID: SALM-835FZC
Date : 05/03/2010
Project: SymbianMmf_wm
Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
Overview: stsd atom for handle type video(vide) is corrupted. In this particular case, stsd atom has size of 182 (0xb6) bytes and number of entry_count for sample description is 256 . During initialization, in CQT_SampleDescription_Manager::Init() this description is read in loop. Each nextEntryOffset is equal to currentEntryOffset + SizeOf(currentEntryOffset) { computed in CQTAtom ::FindArrayEntry() in qtbatom.h}. Size of first entry is huge (0xa7bd bytes , actually cannot be greater than 166 bytes ) so next entry point returned is invalid, hence the panic.
Fix: In CQTAtom ::FindArrayEntry(), offset should be checked after pStartEntry has been updated to ensure that it is still a valid pointer.
Files modified & changes 210Cays , Brizo420 and Head :
/cvsroot/datatype/mp4/fileformat/pub/qtbatom.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5
Branch : 210Cays, Brizo420 & Head :
CVS diff: For 210 cays
Index: qtbatom.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h,v
retrieving revision 1.5.8.2
diff -u -w -r1.5.8.2 qtbatom.h
--- qtbatom.h 4 Nov 2009 14:41:21 -0000 1.5.8.2
+++ qtbatom.h 4 Mar 2010 11:46:51 -0000
@@ -214,13 +214,13 @@
{
while (ulArrayIdx != 0)
{
+ pStartEntry += GetUL32(pStartEntry);
+ ulArrayIdx--;
if (((UINT32)(pStartEntry - m_pData)) >= m_pBuffer->GetSize())
{
pStartEntry = NULL;
break;
}
- pStartEntry += GetUL32(pStartEntry);
- ulArrayIdx--;
}
return pStartEntry;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100308/454e3ae0/attachment.html
From saleem.adookkattil at nokia.com Mon Mar 8 09:55:10 2010
From: saleem.adookkattil at nokia.com (saleem.adookkattil@nokia.com)
Date: Mon Mar 8 17:06:00 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <954B6835A0CD0544886FA9FDDB387E2B2D88036671@NOK-EUMSG-02.mgdnok.nokia.com>
References: <954B6835A0CD0544886FA9FDDB387E2B2D88036671@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <19113978AB61DA44AC317B211CF1C32A2901BD0D11@NOK-EUMSG-02.mgdnok.nokia.com>
Qiang,
Answer to your questions inline.
> I made the change of passing ulFileSize to the Atomize() function.
> This was an attempt to fix a few mp4 http streaming issues. The basic
> idea was to limit the atomizer offset range to be within the actual
> file size if the filesystem supports IHXFileStat.
>
> In your parsing failure case, what is your DRM and the container
Continer format of the DRM clip is 3GP
ullFinalOffset is actual file size
ullCurrentOffset is less than ullFinalOffset.
filesystem decrypt the datat first.
Here is the log that I generated using mp4 file format dll
CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
CAtomizer::Atomize offset 0, 0
CAtomizer::Atomize m_ullFinalOffset 136925, 0
CAtomizer::SeekData ullOffset 0, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 8, 0
CAtomizer::ReadData ulSize 16
CAtomizer::ReadData m_ullCurrentOffset 24, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 32, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 40, 0
CAtomizer::ReadData ulSize 100
CAtomizer::ReadData m_ullCurrentOffset 140, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 148, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 156, 0
CAtomizer::ReadData ulSize 84
CAtomizer::ReadData m_ullCurrentOffset 240, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 248, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 256, 0
CAtomizer::ReadData ulSize 24
CAtomizer::ReadData m_ullCurrentOffset 280, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 288, 0
CAtomizer::ReadData ulSize 25
CAtomizer::ReadData m_ullCurrentOffset 313, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 321, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 329, 0
CAtomizer::SeekData ullOffset 341, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 349, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 357, 0
CAtomizer::ReadData ulSize 20
CAtomizer::ReadData m_ullCurrentOffset 377, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 385, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 393, 0
CAtomizer::ReadData ulSize 109
CAtomizer::ReadData m_ullCurrentOffset 502, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 510, 0
CAtomizer::ReadData ulSize 32
CAtomizer::ReadData m_ullCurrentOffset 542, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 550, 0
CAtomizer::ReadData ulSize 20
CAtomizer::ReadData m_ullCurrentOffset 570, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 578, 0
CAtomizer::ReadData ulSize 820
CAtomizer::ReadData m_ullCurrentOffset 1398, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 1406, 0
CAtomizer::ReadData ulSize 816
CAtomizer::ReadData m_ullCurrentOffset 2222, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2230, 0
CAtomizer::ReadData ulSize 12
CAtomizer::ReadData m_ullCurrentOffset 2242, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2250, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2258, 0
CAtomizer::ReadData ulSize 84
CAtomizer::ReadData m_ullCurrentOffset 2342, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2350, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2358, 0
CAtomizer::ReadData ulSize 24
CAtomizer::ReadData m_ullCurrentOffset 2382, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2390, 0
CAtomizer::ReadData ulSize 25
CAtomizer::ReadData m_ullCurrentOffset 2415, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2423, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2431, 0
CAtomizer::SeekData ullOffset 2439, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2447, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2455, 0
CAtomizer::ReadData ulSize 20
CAtomizer::ReadData m_ullCurrentOffset 2475, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2483, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2491, 0
CAtomizer::ReadData ulSize 61
CAtomizer::ReadData m_ullCurrentOffset 2552, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2560, 0
CAtomizer::ReadData ulSize 24
CAtomizer::ReadData m_ullCurrentOffset 2584, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2592, 0
CAtomizer::ReadData ulSize 20
CAtomizer::ReadData m_ullCurrentOffset 2612, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2620, 0
CAtomizer::ReadData ulSize 284
CAtomizer::ReadData m_ullCurrentOffset 2904, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 2912, 0
CAtomizer::ReadData ulSize 280
CAtomizer::ReadData m_ullCurrentOffset 3192, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 3200, 0
CAtomizer::SeekData ullOffset 136651, 0
CAtomizer::ReadData ulSize 8
CAtomizer::ReadData m_ullCurrentOffset 136659, 0
CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
> format used? Is the m_ullFinalOffset the correct encrypted file size?
> What is the m_ullCurrentOffset value? Does the mp4 ff handles
> encrypted data or the filesystem decrypt the data first? In general,
> if there is no decryptor in or sit between the filesystem and the
> fileformat, then the
> mp4 ff logic for clear data should work for drm data.
>
> Qiang
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Jamie Gordon
Sent: Wednesday, March 03, 2010 6:06 PM
To: Qiang Luo
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
For what it's worth, I also had issues with this change, which I simply worked around for now by just not getting and passing the file size for server builds (because http progressive download/pseudo-streaming reception is not a concern at the server!)
The problem I was having as far as I chased it was that when the file size was passed instead of ATOMIZE_ALL, the atomizer would not parse any top level atoms after the moov (or possibly just anything after the mdat).
On 3/3/2010 3:53 PM, Qiang Luo wrote:
> Hi Saleem,
>
> I made the change of passing ulFileSize to the Atomize() function.
> This was an attempt to fix a few mp4 http streaming issues. The basic
> idea was to limit the atomizer offset range to be within the actual
> file size if the filesystem supports IHXFileStat.
>
> In your parsing failure case, what is your DRM and the container
> format used? Is the m_ullFinalOffset the correct encrypted file size?
> What is the m_ullCurrentOffset value? Does the mp4 ff handles
> encrypted data or the filesystem decrypt the data first? In general,
> if there is no decryptor in or sit between the filesystem and the
> fileformat, then the
> mp4 ff logic for clear data should work for drm data.
>
> Qiang
>
>> ---------------------------------------------------------------------
>> ---
>> *From:* saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
>> *Sent:* Wednesday, March 03, 2010 12:55 PM
>> *To:* Eric Hyche
>> *Subject:* FW: DRM protected MP4 file parsing failure with error code
>> HXR_CORRUPT_FILE due to recent change
>>
>> Any comment on this?
>>
>> ______________________________________________
>> *From: *Adookkattil Saleem (Nokia-D/Dallas)
>> *Sent: *Tuesday, March 02, 2010 6:04 PM
>> *To: *'nokia-private-dev@helixcommunity.org'
>> *Subject: *DRM protected MP4 file parsing failure with error
>> code HXR_CORRUPT_FILE due to recent change
>>
>> Hi,
>>
>> DRM protected MP4 file parsing is failing due to a change in MP4 file
>> format project (qtffplin.cpp) made recently. Please see the below
>> given diff.
>>
>> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.
>> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>> > cpp?r1=1.60.2.8&r2=1.60.2.3.14.1>
>>
>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
>>
>> When we pass the file size as the second parameter, DRM file parsing
>> is failing in the below given function of CAtomizer class
>> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
>>
>> /********************************************************************
>> ********
>> * CompleteAtomization
>> */
>> void CAtomizer::CompleteAtomization(HX_RESULT status) {
>> CQTAtom* pRoot;
>>
>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
>> *(((INT32*)(&m_ullCurrentOffset)) + 1));
>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
>> *(((INT32*)(&m_ullFinalOffset)) + 1));
>>
>> if (!m_pRoot)
>> {
>> return;
>> }
>>
>> if (SUCCEEDED(status))
>> {
>> // Record the amount of data atomized
>> CQTAtom *pRoot = m_pCurrentRoot;
>>
>> HX_ASSERT(pRoot);
>>
>> // If we have the position of where next atom would be,
>> // compute unspecified atom sizes
>> if (m_ullNewAtomOffset != ATOMIZE_ALL)
>> {
>> while (pRoot)
>> {
>> if (pRoot->GetSize() == ATOMIZE_ALL)
>> {
>> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>> }
>>
>> // Move to the parent
>> pRoot = pRoot->GetParent();
>> }
>>
>> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>> }
>>
>> status = AdjustCurrentRoot();
>> }
>>
>> if (SUCCEEDED(status))
>> {
>> if (m_ullFinalOffset != ATOMIZE_ALL)
>> {
>> m_ullCurrentOffset = m_ullCurrentOffset >
>> m_ullFinalOffset ? m_ullFinalOffset : m_ullCurrentOffset;
>> }
>>
>> // See if parsing fully completed
>> if (((m_ullFinalOffset != ATOMIZE_ALL) &&
>> (m_ullFinalOffset != m_ullCurrentOffset)) ||
>> (m_pRoot != m_pCurrentRoot))
>> {
>> status = HXR_CORRUPT_FILE;
>> }
>> }
>> else
>> {
>> // Data compromizing failure occured during atomization
>> HX_RELEASE(m_pRoot);
>> }
>>
>> HX_RELEASE(m_pNewAtom);
>>
>> m_State = ATMZR_Ready;
>>
>> pRoot = m_pRoot;
>> m_pRoot = NULL;
>> m_pCurrentRoot = NULL;
>>
>> m_pResponse->AtomReady(status, pRoot);
>>
>> if (pRoot)
>> {
>> pRoot->Release();
>> }
>> }
>>
>> The reason for the failure is the value of ullCurrentOffset is less
>> than m_ullFinalOffset.
>>
>> If we keep the previous function call, there is no error (ie, retVal
>> = m_pAtomizer->Atomize(); )
>>
>> Whats the reason for this change? Any suggestion to fix this error?
>>
>> Thanks & regards
>> Saleem
>>
>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From jgordon at real.com Mon Mar 8 10:16:53 2010
From: jgordon at real.com (Jamie Gordon)
Date: Mon Mar 8 17:27:48 2010
Subject: [datatype-dev] Re: RESEND: [Nokia-private-dev] CR : SALM-835FZC:
Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
In-Reply-To:
References:
Message-ID: <4B953F15.7030206@real.com>
Looks good
On 3/7/2010 8:39 PM, ext-anugrah.2.kashari@nokia.com wrote:
> Any comments on this?
>
>
>
> Thanks,
>
> Anugrah K
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> *Sent:* Friday, March 05, 2010 6:54 PM
> *To:* datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR : SALM-835FZC: Codenomicon 3GP5: Kern
> Exec 3 panic in CQTAtom::GetUI16()
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement?
>
>
>
> Modified By: ext-anugrah.2.kashari@nokia.com
>
>
>
> Review By: Rathinasamy Rajesh (Nokia-D/Dallas)
>
>
>
> TSW-ID: SALM-835FZC
>
>
>
> Date : 05/03/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
>
>
>
> Overview: stsd atom for handle type video(vide) is corrupted. In this
> particular case, stsd atom has size of 182 (0xb6) bytes and number of
> entry_count for sample description is 256 . During initialization, in
> CQT_SampleDescription_Manager::Init() this description is read in
> loop. Each nextEntryOffset is equal to currentEntryOffset +
> SizeOf(currentEntryOffset) { computed in CQTAtom ::FindArrayEntry() in
> qtbatom.h}. Size of first entry is huge (0xa7bd bytes , actually cannot
> be greater than 166 bytes ) so next entry point returned is invalid,
> hence the panic.
>
>
>
> Fix: In CQTAtom ::FindArrayEntry(), offset should be checked after
> pStartEntry has been updated to ensure that it is still a valid pointer.
>
>
>
> Files modified & changes 210Cays , Brizo420 and Head :
>
> /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h
>
>
>
> Image Size and Heap Use impact: No major impact
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
>
>
> Platforms and Profiles Build Verified:
> helix-client-s60-52-mmf-mdf-dsp
>
>
>
>
> Platforms and Profiles Functionality verified: armv5
>
>
>
> Branch : 210Cays, Brizo420 & Head :
>
>
>
> CVS diff: For 210 cays
>
>
>
> Index: qtbatom.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h,v
>
> retrieving revision 1.5.8.2
>
> diff -u -w -r1.5.8.2 qtbatom.h
>
> --- qtbatom.h 4 Nov 2009 14:41:21 -0000 1.5.8.2
>
> +++ qtbatom.h 4 Mar 2010 11:46:51 -0000
>
> @@ -214,13 +214,13 @@
>
> {
>
> while (ulArrayIdx != 0)
>
> {
>
> + pStartEntry += GetUL32(pStartEntry);
>
> + ulArrayIdx--;
>
> if (((UINT32)(pStartEntry - m_pData)) >= m_pBuffer->GetSize())
>
> {
>
> pStartEntry = NULL;
>
> break;
>
> }
>
> - pStartEntry += GetUL32(pStartEntry);
>
> - ulArrayIdx--;
>
> }
>
>
>
> return pStartEntry;
>
>
>
From Alvaro.Vaquero at nokia.com Mon Mar 8 12:02:01 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Mon Mar 8 19:13:01 2010
Subject: [datatype-dev] RESEND [urgent]: PAMK-823V3J Harvester Crashes
In-Reply-To:
References:
Message-ID:
Hi,
Any comments on this? We'd like to have it checked in tomorrow the latest. Thanks.
BR,
/Alvaro
From: Vaquero Alvaro (Nokia-D/Dallas)
Sent: Friday, March 05, 2010 2:59 PM
To: I_EXT_HELIX_GMS DG
Subject: CR: PAMK-823V3J Harvester Crashes
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: alvaro.vaquero@nokia.com
Reviewed by:
Date: 02/22/2010
Project: SymbianMmf_wm
ErrorId: PAMK-823V3J
Synopsis: Harvester Crashes
Overview:
The Harvester crash has been triggered by the asynchronous reading mode. It happens when multiple metadata parser instances run simultaneously and shared objects are still used after being destroyed by another instance. We've tried using SymbianEventHandler and ActiveSchedulerWait classes to ensure only one instance runs at a time, however both cases have been unsuccessful. It seems the only proper way to approach this problem is using a client/server architecture.
Due to time constrains and the negative impact of this error, this CR only focuses on fixing the crash. A new property (m_bForceSyncReading) has been added to control sync/async reading modes. For metadata utility this has been set to true by default. However, HarvesterServer does run a second instance when parsing RM clips, so in this case we simply return an error to avoid the crash. >From the harvester point of view this might cause Real Audio clips to be incorrectly identified as video. Also, the AVI index class was using an object without checking its validity. This has been addressed as it caused the harvester to crash with AVI clips.
Another CR will be submitted later on addressing the client/server approach to ensure only one instance run at a time.
Files Added: None.
Files Modified:
/common/fileio/platform/symbian/hxdatasource_ccontent.cpp
/common/fileio/platform/symbian/hxdatasource_factory.cpp
/common/fileio/pub/platform/symbian/hxdatasource_ccontent.cpp
/common/fileio/pub/platform/symbian/hxdatasource_factory.cpp
/datatype/avi/fileformat/aviindx.cpp
/datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp
/datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h
/datatype/tools/metadataeng/engine/pub/metadataengbase.h
/datatype/tools/metadataeng/engine/metadataeng.h
/datatype/tools/metadataeng/engine/metadataengbasex.cpp
/filesystem/local/mini/minifileobj.cpp
Image Size and Heap Use impact: minor
Module Release testing (STIF) : Passed
Test case(s) Added : No.
Memory leak check performed : Yes. No new leaks introduced
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Cays210, Brizo420
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100308/2d3ab4df/attachment.html
From qluo at real.com Mon Mar 8 12:24:08 2010
From: qluo at real.com (Qiang Luo)
Date: Mon Mar 8 19:34:34 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901BD0D11@NOK-EUMSG-02.mgdnok.nokia.com>
References: <954B6835A0CD0544886FA9FDDB387E2B2D88036671@NOK-EUMSG-02.mgdnok.nokia.com>
<19113978AB61DA44AC317B211CF1C32A2901BD0D11@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B955CE8.6050602@real.com>
I initially thought that this bug could be DRM specific issue due to the
encryption padding. Based on Jamie's feedback, there might be issue
related to my change even for non-drm contents. Limiting the seek/read
range within the filesize seems to be the right thing to do. I would
prefer not to rollback the http streaming fix if we can figure out a
proper fix.
With the old code where m_ulFinalOffset was always ATOMIZE_ALL, the
checking in function CAtomizer::CompleteAtomization() for "if parsing
fully completed" would never kick in. With m_ulFinalOffset now to be
the filesize, the checking logic maybe too strict, marking false detection.
If you take out the checking code in CompleteAtomization(), will the
change fix your drm playback issue, Saleem? Jamie, will the same change
address the parsing issues you observed?
Thanks,
Qiang
On 3/8/2010 9:55 AM, saleem.adookkattil@nokia.com wrote:
> Qiang,
>
> Answer to your questions inline.
>
>
>> I made the change of passing ulFileSize to the Atomize() function.
>> This was an attempt to fix a few mp4 http streaming issues. The basic
>> idea was to limit the atomizer offset range to be within the actual
>> file size if the filesystem supports IHXFileStat.
>>
>> In your parsing failure case, what is your DRM and the container
>>
> Continer format of the DRM clip is 3GP
> ullFinalOffset is actual file size
> ullCurrentOffset is less than ullFinalOffset.
> filesystem decrypt the datat first.
>
> Here is the log that I generated using mp4 file format dll
>
> CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
> CAtomizer::Atomize offset 0, 0
> CAtomizer::Atomize m_ullFinalOffset 136925, 0
> CAtomizer::SeekData ullOffset 0, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 8, 0
> CAtomizer::ReadData ulSize 16
> CAtomizer::ReadData m_ullCurrentOffset 24, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 32, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 40, 0
> CAtomizer::ReadData ulSize 100
> CAtomizer::ReadData m_ullCurrentOffset 140, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 148, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 156, 0
> CAtomizer::ReadData ulSize 84
> CAtomizer::ReadData m_ullCurrentOffset 240, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 248, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 256, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 280, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 288, 0
> CAtomizer::ReadData ulSize 25
> CAtomizer::ReadData m_ullCurrentOffset 313, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 321, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 329, 0
> CAtomizer::SeekData ullOffset 341, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 349, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 357, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 377, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 385, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 393, 0
> CAtomizer::ReadData ulSize 109
> CAtomizer::ReadData m_ullCurrentOffset 502, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 510, 0
> CAtomizer::ReadData ulSize 32
> CAtomizer::ReadData m_ullCurrentOffset 542, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 550, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 570, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 578, 0
> CAtomizer::ReadData ulSize 820
> CAtomizer::ReadData m_ullCurrentOffset 1398, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 1406, 0
> CAtomizer::ReadData ulSize 816
> CAtomizer::ReadData m_ullCurrentOffset 2222, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2230, 0
> CAtomizer::ReadData ulSize 12
> CAtomizer::ReadData m_ullCurrentOffset 2242, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2250, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2258, 0
> CAtomizer::ReadData ulSize 84
> CAtomizer::ReadData m_ullCurrentOffset 2342, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2350, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2358, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 2382, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2390, 0
> CAtomizer::ReadData ulSize 25
> CAtomizer::ReadData m_ullCurrentOffset 2415, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2423, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2431, 0
> CAtomizer::SeekData ullOffset 2439, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2447, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2455, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 2475, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2483, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2491, 0
> CAtomizer::ReadData ulSize 61
> CAtomizer::ReadData m_ullCurrentOffset 2552, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2560, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 2584, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2592, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 2612, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2620, 0
> CAtomizer::ReadData ulSize 284
> CAtomizer::ReadData m_ullCurrentOffset 2904, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2912, 0
> CAtomizer::ReadData ulSize 280
> CAtomizer::ReadData m_ullCurrentOffset 3192, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 3200, 0
> CAtomizer::SeekData ullOffset 136651, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 136659, 0
> CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
> CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
>
>
>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>> encrypted data or the filesystem decrypt the data first? In general,
>> if there is no decryptor in or sit between the filesystem and the
>> fileformat, then the
>> mp4 ff logic for clear data should work for drm data.
>>
>> Qiang
>>
> -----Original Message-----
> From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Jamie Gordon
> Sent: Wednesday, March 03, 2010 6:06 PM
> To: Qiang Luo
> Cc: datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
>
> For what it's worth, I also had issues with this change, which I simply worked around for now by just not getting and passing the file size for server builds (because http progressive download/pseudo-streaming reception is not a concern at the server!)
>
> The problem I was having as far as I chased it was that when the file size was passed instead of ATOMIZE_ALL, the atomizer would not parse any top level atoms after the moov (or possibly just anything after the mdat).
>
> On 3/3/2010 3:53 PM, Qiang Luo wrote:
>
>> Hi Saleem,
>>
>> I made the change of passing ulFileSize to the Atomize() function.
>> This was an attempt to fix a few mp4 http streaming issues. The basic
>> idea was to limit the atomizer offset range to be within the actual
>> file size if the filesystem supports IHXFileStat.
>>
>> In your parsing failure case, what is your DRM and the container
>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>> encrypted data or the filesystem decrypt the data first? In general,
>> if there is no decryptor in or sit between the filesystem and the
>> fileformat, then the
>> mp4 ff logic for clear data should work for drm data.
>>
>> Qiang
>>
>>
>>> ---------------------------------------------------------------------
>>> ---
>>> *From:* saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
>>> *Sent:* Wednesday, March 03, 2010 12:55 PM
>>> *To:* Eric Hyche
>>> *Subject:* FW: DRM protected MP4 file parsing failure with error code
>>> HXR_CORRUPT_FILE due to recent change
>>>
>>> Any comment on this?
>>>
>>> ______________________________________________
>>> *From: *Adookkattil Saleem (Nokia-D/Dallas)
>>> *Sent: *Tuesday, March 02, 2010 6:04 PM
>>> *To: *'nokia-private-dev@helixcommunity.org'
>>> *Subject: *DRM protected MP4 file parsing failure with error
>>> code HXR_CORRUPT_FILE due to recent change
>>>
>>> Hi,
>>>
>>> DRM protected MP4 file parsing is failing due to a change in MP4 file
>>> format project (qtffplin.cpp) made recently. Please see the below
>>> given diff.
>>>
>>> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.
>>> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>>> >> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1>
>>>
>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
>>>
>>> When we pass the file size as the second parameter, DRM file parsing
>>> is failing in the below given function of CAtomizer class
>>> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
>>>
>>> /********************************************************************
>>> ********
>>> * CompleteAtomization
>>> */
>>> void CAtomizer::CompleteAtomization(HX_RESULT status) {
>>> CQTAtom* pRoot;
>>>
>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
>>> *(((INT32*)(&m_ullCurrentOffset)) + 1));
>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
>>> *(((INT32*)(&m_ullFinalOffset)) + 1));
>>>
>>> if (!m_pRoot)
>>> {
>>> return;
>>> }
>>>
>>> if (SUCCEEDED(status))
>>> {
>>> // Record the amount of data atomized
>>> CQTAtom *pRoot = m_pCurrentRoot;
>>>
>>> HX_ASSERT(pRoot);
>>>
>>> // If we have the position of where next atom would be,
>>> // compute unspecified atom sizes
>>> if (m_ullNewAtomOffset != ATOMIZE_ALL)
>>> {
>>> while (pRoot)
>>> {
>>> if (pRoot->GetSize() == ATOMIZE_ALL)
>>> {
>>> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>> }
>>>
>>> // Move to the parent
>>> pRoot = pRoot->GetParent();
>>> }
>>>
>>> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>> }
>>>
>>> status = AdjustCurrentRoot();
>>> }
>>>
>>> if (SUCCEEDED(status))
>>> {
>>> if (m_ullFinalOffset != ATOMIZE_ALL)
>>> {
>>> m_ullCurrentOffset = m_ullCurrentOffset>
>>> m_ullFinalOffset ? m_ullFinalOffset : m_ullCurrentOffset;
>>> }
>>>
>>> // See if parsing fully completed
>>> if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>> (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>> (m_pRoot != m_pCurrentRoot))
>>> {
>>> status = HXR_CORRUPT_FILE;
>>> }
>>> }
>>> else
>>> {
>>> // Data compromizing failure occured during atomization
>>> HX_RELEASE(m_pRoot);
>>> }
>>>
>>> HX_RELEASE(m_pNewAtom);
>>>
>>> m_State = ATMZR_Ready;
>>>
>>> pRoot = m_pRoot;
>>> m_pRoot = NULL;
>>> m_pCurrentRoot = NULL;
>>>
>>> m_pResponse->AtomReady(status, pRoot);
>>>
>>> if (pRoot)
>>> {
>>> pRoot->Release();
>>> }
>>> }
>>>
>>> The reason for the failure is the value of ullCurrentOffset is less
>>> than m_ullFinalOffset.
>>>
>>> If we keep the previous function call, there is no error (ie, retVal
>>> = m_pAtomizer->Atomize(); )
>>>
>>> Whats the reason for this change? Any suggestion to fix this error?
>>>
>>> Thanks& regards
>>> Saleem
>>>
>>>
>>
> _______________________________________________
> 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
> .
>
>
From saleem.adookkattil at nokia.com Mon Mar 8 13:05:53 2010
From: saleem.adookkattil at nokia.com (saleem.adookkattil@nokia.com)
Date: Mon Mar 8 20:16:42 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <4B955CE8.6050602@real.com>
References: <954B6835A0CD0544886FA9FDDB387E2B2D88036671@NOK-EUMSG-02.mgdnok.nokia.com>
<19113978AB61DA44AC317B211CF1C32A2901BD0D11@NOK-EUMSG-02.mgdnok.nokia.com>
<4B955CE8.6050602@real.com>
Message-ID: <19113978AB61DA44AC317B211CF1C32A2901BD0E1C@NOK-EUMSG-02.mgdnok.nokia.com>
Qiang,
Removing the check in CompleteAtomization() fixes DRM issue.
Thanks
Saleem
-----Original Message-----
From: ext Qiang Luo [mailto:qluo@real.com]
Sent: Monday, March 08, 2010 2:24 PM
To: Adookkattil Saleem (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
I initially thought that this bug could be DRM specific issue due to the encryption padding. Based on Jamie's feedback, there might be issue related to my change even for non-drm contents. Limiting the seek/read range within the filesize seems to be the right thing to do. I would prefer not to rollback the http streaming fix if we can figure out a proper fix.
With the old code where m_ulFinalOffset was always ATOMIZE_ALL, the checking in function CAtomizer::CompleteAtomization() for "if parsing fully completed" would never kick in. With m_ulFinalOffset now to be the filesize, the checking logic maybe too strict, marking false detection.
If you take out the checking code in CompleteAtomization(), will the change fix your drm playback issue, Saleem? Jamie, will the same change address the parsing issues you observed?
Thanks,
Qiang
On 3/8/2010 9:55 AM, saleem.adookkattil@nokia.com wrote:
> Qiang,
>
> Answer to your questions inline.
>
>
>> I made the change of passing ulFileSize to the Atomize() function.
>> This was an attempt to fix a few mp4 http streaming issues. The
>> basic idea was to limit the atomizer offset range to be within the
>> actual file size if the filesystem supports IHXFileStat.
>>
>> In your parsing failure case, what is your DRM and the container
>>
> Continer format of the DRM clip is 3GP ullFinalOffset is actual file
> size ullCurrentOffset is less than ullFinalOffset.
> filesystem decrypt the datat first.
>
> Here is the log that I generated using mp4 file format dll
>
> CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
> CAtomizer::Atomize offset 0, 0
> CAtomizer::Atomize m_ullFinalOffset 136925, 0
> CAtomizer::SeekData ullOffset 0, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 8, 0
> CAtomizer::ReadData ulSize 16
> CAtomizer::ReadData m_ullCurrentOffset 24, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 32, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 40, 0
> CAtomizer::ReadData ulSize 100
> CAtomizer::ReadData m_ullCurrentOffset 140, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 148, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 156, 0
> CAtomizer::ReadData ulSize 84
> CAtomizer::ReadData m_ullCurrentOffset 240, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 248, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 256, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 280, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 288, 0
> CAtomizer::ReadData ulSize 25
> CAtomizer::ReadData m_ullCurrentOffset 313, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 321, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 329, 0
> CAtomizer::SeekData ullOffset 341, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 349, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 357, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 377, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 385, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 393, 0
> CAtomizer::ReadData ulSize 109
> CAtomizer::ReadData m_ullCurrentOffset 502, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 510, 0
> CAtomizer::ReadData ulSize 32
> CAtomizer::ReadData m_ullCurrentOffset 542, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 550, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 570, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 578, 0
> CAtomizer::ReadData ulSize 820
> CAtomizer::ReadData m_ullCurrentOffset 1398, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 1406, 0
> CAtomizer::ReadData ulSize 816
> CAtomizer::ReadData m_ullCurrentOffset 2222, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2230, 0
> CAtomizer::ReadData ulSize 12
> CAtomizer::ReadData m_ullCurrentOffset 2242, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2250, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2258, 0
> CAtomizer::ReadData ulSize 84
> CAtomizer::ReadData m_ullCurrentOffset 2342, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2350, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2358, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 2382, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2390, 0
> CAtomizer::ReadData ulSize 25
> CAtomizer::ReadData m_ullCurrentOffset 2415, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2423, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2431, 0
> CAtomizer::SeekData ullOffset 2439, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2447, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2455, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 2475, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2483, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2491, 0
> CAtomizer::ReadData ulSize 61
> CAtomizer::ReadData m_ullCurrentOffset 2552, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2560, 0
> CAtomizer::ReadData ulSize 24
> CAtomizer::ReadData m_ullCurrentOffset 2584, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2592, 0
> CAtomizer::ReadData ulSize 20
> CAtomizer::ReadData m_ullCurrentOffset 2612, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2620, 0
> CAtomizer::ReadData ulSize 284
> CAtomizer::ReadData m_ullCurrentOffset 2904, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 2912, 0
> CAtomizer::ReadData ulSize 280
> CAtomizer::ReadData m_ullCurrentOffset 3192, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 3200, 0
> CAtomizer::SeekData ullOffset 136651, 0
> CAtomizer::ReadData ulSize 8
> CAtomizer::ReadData m_ullCurrentOffset 136659, 0
> CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
> CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
>
>
>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>> encrypted data or the filesystem decrypt the data first? In general,
>> if there is no decryptor in or sit between the filesystem and the
>> fileformat, then the
>> mp4 ff logic for clear data should work for drm data.
>>
>> Qiang
>>
> -----Original Message-----
> From: datatype-dev-bounces@helixcommunity.org
> [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext
> Jamie Gordon
> Sent: Wednesday, March 03, 2010 6:06 PM
> To: Qiang Luo
> Cc: datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing failure
> with error code HXR_CORRUPT_FILE due to recent change
>
> For what it's worth, I also had issues with this change, which I
> simply worked around for now by just not getting and passing the file
> size for server builds (because http progressive
> download/pseudo-streaming reception is not a concern at the server!)
>
> The problem I was having as far as I chased it was that when the file size was passed instead of ATOMIZE_ALL, the atomizer would not parse any top level atoms after the moov (or possibly just anything after the mdat).
>
> On 3/3/2010 3:53 PM, Qiang Luo wrote:
>
>> Hi Saleem,
>>
>> I made the change of passing ulFileSize to the Atomize() function.
>> This was an attempt to fix a few mp4 http streaming issues. The
>> basic idea was to limit the atomizer offset range to be within the
>> actual file size if the filesystem supports IHXFileStat.
>>
>> In your parsing failure case, what is your DRM and the container
>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>> encrypted data or the filesystem decrypt the data first? In general,
>> if there is no decryptor in or sit between the filesystem and the
>> fileformat, then the
>> mp4 ff logic for clear data should work for drm data.
>>
>> Qiang
>>
>>
>>> --------------------------------------------------------------------
>>> -
>>> ---
>>> *From:* saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
>>> *Sent:* Wednesday, March 03, 2010 12:55 PM
>>> *To:* Eric Hyche
>>> *Subject:* FW: DRM protected MP4 file parsing failure with error
>>> code HXR_CORRUPT_FILE due to recent change
>>>
>>> Any comment on this?
>>>
>>> ______________________________________________
>>> *From: *Adookkattil Saleem (Nokia-D/Dallas)
>>> *Sent: *Tuesday, March 02, 2010 6:04 PM
>>> *To: *'nokia-private-dev@helixcommunity.org'
>>> *Subject: *DRM protected MP4 file parsing failure with error
>>> code HXR_CORRUPT_FILE due to recent change
>>>
>>> Hi,
>>>
>>> DRM protected MP4 file parsing is failing due to a change in MP4
>>> file format project (qtffplin.cpp) made recently. Please see the
>>> below given diff.
>>>
>>> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.
>>> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>>> >> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1>
>>>
>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
>>>
>>> When we pass the file size as the second parameter, DRM file parsing
>>> is failing in the below given function of CAtomizer class
>>> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
>>>
>>> /*******************************************************************
>>> *
>>> ********
>>> * CompleteAtomization
>>> */
>>> void CAtomizer::CompleteAtomization(HX_RESULT status) {
>>> CQTAtom* pRoot;
>>>
>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
>>> *(((INT32*)(&m_ullCurrentOffset)) + 1));
>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
>>> *(((INT32*)(&m_ullFinalOffset)) + 1));
>>>
>>> if (!m_pRoot)
>>> {
>>> return;
>>> }
>>>
>>> if (SUCCEEDED(status))
>>> {
>>> // Record the amount of data atomized
>>> CQTAtom *pRoot = m_pCurrentRoot;
>>>
>>> HX_ASSERT(pRoot);
>>>
>>> // If we have the position of where next atom would be,
>>> // compute unspecified atom sizes
>>> if (m_ullNewAtomOffset != ATOMIZE_ALL)
>>> {
>>> while (pRoot)
>>> {
>>> if (pRoot->GetSize() == ATOMIZE_ALL)
>>> {
>>> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>> }
>>>
>>> // Move to the parent
>>> pRoot = pRoot->GetParent();
>>> }
>>>
>>> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>> }
>>>
>>> status = AdjustCurrentRoot();
>>> }
>>>
>>> if (SUCCEEDED(status))
>>> {
>>> if (m_ullFinalOffset != ATOMIZE_ALL)
>>> {
>>> m_ullCurrentOffset = m_ullCurrentOffset>
>>> m_ullFinalOffset ? m_ullFinalOffset : m_ullCurrentOffset;
>>> }
>>>
>>> // See if parsing fully completed
>>> if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>> (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>> (m_pRoot != m_pCurrentRoot))
>>> {
>>> status = HXR_CORRUPT_FILE;
>>> }
>>> }
>>> else
>>> {
>>> // Data compromizing failure occured during atomization
>>> HX_RELEASE(m_pRoot);
>>> }
>>>
>>> HX_RELEASE(m_pNewAtom);
>>>
>>> m_State = ATMZR_Ready;
>>>
>>> pRoot = m_pRoot;
>>> m_pRoot = NULL;
>>> m_pCurrentRoot = NULL;
>>>
>>> m_pResponse->AtomReady(status, pRoot);
>>>
>>> if (pRoot)
>>> {
>>> pRoot->Release();
>>> }
>>> }
>>>
>>> The reason for the failure is the value of ullCurrentOffset is less
>>> than m_ullFinalOffset.
>>>
>>> If we keep the previous function call, there is no error (ie, retVal
>>> = m_pAtomizer->Atomize(); )
>>>
>>> Whats the reason for this change? Any suggestion to fix this error?
>>>
>>> Thanks& regards
>>> Saleem
>>>
>>>
>>
> _______________________________________________
> 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
> .
>
>
From sfu at real.com Mon Mar 8 15:48:47 2010
From: sfu at real.com (Sheldon Fu)
Date: Mon Mar 8 22:59:05 2010
Subject: [datatype-dev] RESEND [urgent]: PAMK-823V3J Harvester Crashes
In-Reply-To:
References:
Message-ID: <4B958CDF.2080807@real.com>
Looks good to me.
fxd
Alvaro.Vaquero@nokia.com wrote:
>
> *Hi,** *
>
> * *
>
> *Any comments on this? We?d like to have it checked in tomorrow the
> latest. Thanks. *
>
> * *
>
> *BR, *
>
> */Alvaro *
>
>
>
> *From:* Vaquero Alvaro (Nokia-D/Dallas)
> *Sent:* Friday, March 05, 2010 2:59 PM
> *To:* I_EXT_HELIX_GMS DG
> *Subject:* CR: PAMK-823V3J Harvester Crashes
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: alvaro.vaquero@nokia.com
>
>
>
> Reviewed by:
>
>
>
> Date: 02/22/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> ErrorId: PAMK-823V3J
>
>
>
> Synopsis: Harvester Crashes
>
>
>
> Overview:
>
> The Harvester crash has been triggered by the asynchronous reading
> mode. It happens when multiple metadata parser instances run
> simultaneously and shared objects are still used after being destroyed
> by another instance. We?ve tried using SymbianEventHandler and
> ActiveSchedulerWait classes to ensure only one instance runs at a
> time, however both cases have been unsuccessful. It seems the only
> proper way to approach this problem is using a client/server
> architecture.
>
>
>
> Due to time constrains and the negative impact of this error, this CR
> only focuses on fixing the crash. A new property (m_bForceSyncReading)
> has been added to control sync/async reading modes. For metadata
> utility this has been set to true by default. However, HarvesterServer
> does run a second instance when parsing RM clips, so in this case we
> simply return an error to avoid the crash. >From the harvester point
> of view this might cause Real Audio clips to be incorrectly identified
> as video. Also, the AVI index class was using an object without
> checking its validity. This has been addressed as it caused the
> harvester to crash with AVI clips.
>
>
>
> Another CR will be submitted later on addressing the client/server
> approach to ensure only one instance run at a time.
>
>
>
> Files Added: None.
>
>
>
> Files Modified:
>
> /common/fileio/platform/symbian/hxdatasource_ccontent.cpp
>
> /common/fileio/platform/symbian/hxdatasource_factory.cpp
>
> /common/fileio/pub/platform/symbian/hxdatasource_ccontent.cpp
>
> /common/fileio/pub/platform/symbian/hxdatasource_factory.cpp
>
> /datatype/avi/fileformat/aviindx.cpp
>
> /datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp
>
>
> /datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h
>
>
> /datatype/tools/metadataeng/engine/pub/metadataengbase.h
>
> /datatype/tools/metadataeng/engine/metadataeng.h
>
> /datatype/tools/metadataeng/engine/metadataengbasex.cpp
>
> /filesystem/local/mini/minifileobj.cpp
>
>
>
> Image Size and Heap Use impact: minor
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No.
>
>
>
> Memory leak check performed : Yes. No new leaks introduced
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: Cays210, Brizo420
>
>
>
>
>
From ext-anugrah.2.kashari at nokia.com Mon Mar 8 23:03:06 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Tue Mar 9 06:14:04 2010
Subject: [datatype-dev] RE: RESEND: [Nokia-private-dev] CR : SALM-835FZC:
Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
In-Reply-To: <4B953F15.7030206@real.com>
References:
<4B953F15.7030206@real.com>
Message-ID:
Thanks Jamie,
Checked in 210Cays, Brizo420 and head.
-----Original Message-----
From: ext Jamie Gordon [mailto:jgordon@real.com]
Sent: Monday, March 08, 2010 11:47 PM
To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: RESEND: [Nokia-private-dev] CR : SALM-835FZC: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
Looks good
On 3/7/2010 8:39 PM, ext-anugrah.2.kashari@nokia.com wrote:
> Any comments on this?
>
>
>
> Thanks,
>
> Anugrah K
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> *Sent:* Friday, March 05, 2010 6:54 PM
> *To:* datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR : SALM-835FZC: Codenomicon 3GP5: Kern
> Exec 3 panic in CQTAtom::GetUI16()
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this code
> under said agreement"
>
>
>
> Modified By: ext-anugrah.2.kashari@nokia.com
>
>
>
> Review By: Rathinasamy Rajesh (Nokia-D/Dallas)
>
>
>
> TSW-ID: SALM-835FZC
>
>
>
> Date : 05/03/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Synopsis: Codenomicon 3GP5: Kern Exec 3 panic in CQTAtom::GetUI16()
>
>
>
> Overview: stsd atom for handle type video(vide) is corrupted. In this
> particular case, stsd atom has size of 182 (0xb6) bytes and number of
> entry_count for sample description is 256 . During initialization, in
> CQT_SampleDescription_Manager::Init() this description is read in
> loop. Each nextEntryOffset is equal to currentEntryOffset +
> SizeOf(currentEntryOffset) { computed in CQTAtom ::FindArrayEntry() in
> qtbatom.h}. Size of first entry is huge (0xa7bd bytes , actually cannot
> be greater than 166 bytes ) so next entry point returned is invalid,
> hence the panic.
>
>
>
> Fix: In CQTAtom ::FindArrayEntry(), offset should be checked after
> pStartEntry has been updated to ensure that it is still a valid pointer.
>
>
>
> Files modified & changes 210Cays , Brizo420 and Head :
>
> /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h
>
>
>
> Image Size and Heap Use impact: No major impact
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
>
>
> Platforms and Profiles Build Verified:
> helix-client-s60-52-mmf-mdf-dsp
>
>
>
>
> Platforms and Profiles Functionality verified: armv5
>
>
>
> Branch : 210Cays, Brizo420 & Head :
>
>
>
> CVS diff: For 210 cays
>
>
>
> Index: qtbatom.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtbatom.h,v
>
> retrieving revision 1.5.8.2
>
> diff -u -w -r1.5.8.2 qtbatom.h
>
> --- qtbatom.h 4 Nov 2009 14:41:21 -0000 1.5.8.2
>
> +++ qtbatom.h 4 Mar 2010 11:46:51 -0000
>
> @@ -214,13 +214,13 @@
>
> {
>
> while (ulArrayIdx != 0)
>
> {
>
> + pStartEntry += GetUL32(pStartEntry);
>
> + ulArrayIdx--;
>
> if (((UINT32)(pStartEntry - m_pData)) >= m_pBuffer->GetSize())
>
> {
>
> pStartEntry = NULL;
>
> break;
>
> }
>
> - pStartEntry += GetUL32(pStartEntry);
>
> - ulArrayIdx--;
>
> }
>
>
>
> return pStartEntry;
>
>
>
From Alvaro.Vaquero at nokia.com Tue Mar 9 10:05:10 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Tue Mar 9 17:15:39 2010
Subject: [datatype-dev] RESEND [urgent]: PAMK-823V3J Harvester Crashes
In-Reply-To: <4B958CDF.2080807@real.com>
References:
<4B958CDF.2080807@real.com>
Message-ID:
Thanks. Checked in to Cay210, Brizo420 and HEAD.
BR,
/Alvaro
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Monday, March 08, 2010 5:49 PM
To: Vaquero Alvaro (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] RESEND [urgent]: PAMK-823V3J Harvester Crashes
Looks good to me.
fxd
Alvaro.Vaquero@nokia.com wrote:
>
> *Hi,** *
>
> * *
>
> *Any comments on this? We'd like to have it checked in tomorrow the
> latest. Thanks. *
>
> * *
>
> *BR, *
>
> */Alvaro *
>
>
>
> *From:* Vaquero Alvaro (Nokia-D/Dallas)
> *Sent:* Friday, March 05, 2010 2:59 PM
> *To:* I_EXT_HELIX_GMS DG
> *Subject:* CR: PAMK-823V3J Harvester Crashes
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: alvaro.vaquero@nokia.com
>
>
>
> Reviewed by:
>
>
>
> Date: 02/22/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> ErrorId: PAMK-823V3J
>
>
>
> Synopsis: Harvester Crashes
>
>
>
> Overview:
>
> The Harvester crash has been triggered by the asynchronous reading
> mode. It happens when multiple metadata parser instances run
> simultaneously and shared objects are still used after being destroyed
> by another instance. We've tried using SymbianEventHandler and
> ActiveSchedulerWait classes to ensure only one instance runs at a
> time, however both cases have been unsuccessful. It seems the only
> proper way to approach this problem is using a client/server
> architecture.
>
>
>
> Due to time constrains and the negative impact of this error, this CR
> only focuses on fixing the crash. A new property (m_bForceSyncReading)
> has been added to control sync/async reading modes. For metadata
> utility this has been set to true by default. However, HarvesterServer
> does run a second instance when parsing RM clips, so in this case we
> simply return an error to avoid the crash. >From the harvester point
> of view this might cause Real Audio clips to be incorrectly identified
> as video. Also, the AVI index class was using an object without
> checking its validity. This has been addressed as it caused the
> harvester to crash with AVI clips.
>
>
>
> Another CR will be submitted later on addressing the client/server
> approach to ensure only one instance run at a time.
>
>
>
> Files Added: None.
>
>
>
> Files Modified:
>
> /common/fileio/platform/symbian/hxdatasource_ccontent.cpp
>
> /common/fileio/platform/symbian/hxdatasource_factory.cpp
>
> /common/fileio/pub/platform/symbian/hxdatasource_ccontent.cpp
>
> /common/fileio/pub/platform/symbian/hxdatasource_factory.cpp
>
> /datatype/avi/fileformat/aviindx.cpp
>
> /datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp
>
>
> /datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h
>
>
> /datatype/tools/metadataeng/engine/pub/metadataengbase.h
>
> /datatype/tools/metadataeng/engine/metadataeng.h
>
> /datatype/tools/metadataeng/engine/metadataengbasex.cpp
>
> /filesystem/local/mini/minifileobj.cpp
>
>
>
> Image Size and Heap Use impact: minor
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No.
>
>
>
> Memory leak check performed : Yes. No new leaks introduced
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: Cays210, Brizo420
>
>
>
>
>
From jrathore at real.com Tue Mar 9 22:48:52 2010
From: jrathore at real.com (Jyotsana Rathore)
Date: Wed Mar 10 05:59:02 2010
Subject: [datatype-dev] CR: Bug fix for 10084: Can't do mp3 http streaming
but other android devices can
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: http.diff
Type: application/octet-stream
Size: 1172 bytes
Desc: http.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100309/853e9bb2/http.obj
From sfu at real.com Wed Mar 10 04:52:46 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Mar 10 12:03:08 2010
Subject: [datatype-dev] Re: [Porting-android] CR: Bug fix for 10084: Can't
do mp3 http streaming but other android devices can
In-Reply-To:
References:
Message-ID: <4B97961E.1060503@real.com>
Looks ok.
We apparently will loss the ability to put id3 tags in the file headers.
Whether this is acceptable, at least on Android, I think depends what
other media engines are doing. Can these 'other android devices' do http
streaming while showing id3 values?
fxd
Jyotsana Rathore wrote:
>
> Project: Real Player for Android
>
>
>
> Synopsis: Bug fix for 10084: Can't do mp3 http streaming but other
> android devices can
>
>
>
> Overview: In mp3ff GetFileHeader function, there is a seek to the end
> of file to look for ID3 v1 tags. Since the BYTE_RANGE_SEEK_THRESHHOLD
> was bumped up in httpfsys.cpp, this seek is usually huge resulting in
> downloading of all the data to the seek point and thus, increasing the
> startup delay. The attached fix allows this initial seek for local
> file system only.
>
>
>
> Files Added: none
>
>
>
> Files Modified:
>
> Datatype/mp3/fileformat/mp3ff.cpp
>
>
>
> Image Size and Heap Use impact (Client -Only): None
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
>
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
> Copyright assignment: I am a RealNetworks employee.
>
>
>
> Files Attached: http.diff
>
>
>
From jrathore at real.com Wed Mar 10 08:28:13 2010
From: jrathore at real.com (Jyotsana Rathore)
Date: Wed Mar 10 15:38:40 2010
Subject: [datatype-dev] RE: [Porting-android] CR: Bug fix for 10084: Can't
do mp3 http streaming but other android devices can
In-Reply-To: <4B97961E.1060503@real.com>
References:
<4B97961E.1060503@real.com>
Message-ID:
Hi Sheldon,
Thanks for the review. I have checked in this fix to 361 Atlas.
We would still be able to check for ID3 v2 tags but not ID3 v1. We will check with Lenovo if other devices/other players can show id3v1 values for files that contain them.
Thanks,
Jyotsana
-----Original Message-----
From: Xiaodong (Sheldon) Fu
Sent: Wednesday, March 10, 2010 4:53 AM
To: Jyotsana Rathore
Cc: porting-android@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Porting-android] CR: Bug fix for 10084: Can't do mp3 http streaming but other android devices can
Looks ok.
We apparently will loss the ability to put id3 tags in the file headers.
Whether this is acceptable, at least on Android, I think depends what
other media engines are doing. Can these 'other android devices' do http
streaming while showing id3 values?
fxd
Jyotsana Rathore wrote:
>
> Project: Real Player for Android
>
>
>
> Synopsis: Bug fix for 10084: Can't do mp3 http streaming but other
> android devices can
>
>
>
> Overview: In mp3ff GetFileHeader function, there is a seek to the end
> of file to look for ID3 v1 tags. Since the BYTE_RANGE_SEEK_THRESHHOLD
> was bumped up in httpfsys.cpp, this seek is usually huge resulting in
> downloading of all the data to the seek point and thus, increasing the
> startup delay. The attached fix allows this initial seek for local
> file system only.
>
>
>
> Files Added: none
>
>
>
> Files Modified:
>
> Datatype/mp3/fileformat/mp3ff.cpp
>
>
>
> Image Size and Heap Use impact (Client -Only): None
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
>
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
> Copyright assignment: I am a RealNetworks employee.
>
>
>
> Files Attached: http.diff
>
>
>
From jgordon at real.com Wed Mar 10 09:58:22 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Mar 10 17:08:54 2010
Subject: [datatype-dev] CR: Bug fix for 10084: Can't do mp3 http streaming
but other android devices can
In-Reply-To:
References:
Message-ID: <4B97DDBE.4020507@real.com>
Looks fine to me, though I am surprised it is necessary - shouldn't
httpfsys always return PREFER_LINEAR?
On 3/9/2010 10:48 PM, Jyotsana Rathore wrote:
> Project: Real Player for Android
>
>
>
> Synopsis: Bug fix for 10084: Can't do mp3 http streaming but other
> android devices can
>
>
>
> Overview: In mp3ff GetFileHeader function, there is a seek to the end of
> file to look for ID3 v1 tags. Since the BYTE_RANGE_SEEK_THRESHHOLD was
> bumped up in httpfsys.cpp, this seek is usually huge resulting in
> downloading of all the data to the seek point and thus, increasing the
> startup delay. The attached fix allows this initial seek for local file
> system only.
>
>
>
> Files Added: none
>
>
>
> Files Modified:
>
> Datatype/mp3/fileformat/mp3ff.cpp
>
>
>
> Image Size and Heap Use impact (Client -Only): None
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
>
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
> Copyright assignment: I am a RealNetworks employee.
>
>
>
> Files Attached: http.diff
>
>
>
From jrathore at real.com Wed Mar 10 11:16:20 2010
From: jrathore at real.com (Jyotsana Rathore)
Date: Wed Mar 10 18:26:52 2010
Subject: [datatype-dev] CR: Bug fix for 10084: Can't do mp3 http
streaming but other android devices can
In-Reply-To: <4B97DDBE.4020507@real.com>
References:
<4B97DDBE.4020507@real.com>
Message-ID:
Hi Jamie,
It returns PREFER_LINEAR if the server does not support byte range seeking or if the stream is a live stream.
I have checked in this change to 361 atlas.
Thanks,
Jyotsana
-----Original Message-----
From: Jamie Gordon
Sent: Wednesday, March 10, 2010 9:58 AM
To: Jyotsana Rathore
Cc: porting-android@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: Bug fix for 10084: Can't do mp3 http streaming but other android devices can
Looks fine to me, though I am surprised it is necessary - shouldn't
httpfsys always return PREFER_LINEAR?
On 3/9/2010 10:48 PM, Jyotsana Rathore wrote:
> Project: Real Player for Android
>
>
>
> Synopsis: Bug fix for 10084: Can't do mp3 http streaming but other
> android devices can
>
>
>
> Overview: In mp3ff GetFileHeader function, there is a seek to the end of
> file to look for ID3 v1 tags. Since the BYTE_RANGE_SEEK_THRESHHOLD was
> bumped up in httpfsys.cpp, this seek is usually huge resulting in
> downloading of all the data to the seek point and thus, increasing the
> startup delay. The attached fix allows this initial seek for local file
> system only.
>
>
>
> Files Added: none
>
>
>
> Files Modified:
>
> Datatype/mp3/fileformat/mp3ff.cpp
>
>
>
> Image Size and Heap Use impact (Client -Only): None
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
>
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
> Copyright assignment: I am a RealNetworks employee.
>
>
>
> Files Attached: http.diff
>
>
>
From sfu at real.com Wed Mar 10 11:27:30 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Mar 10 18:38:05 2010
Subject: [Porting-android] RE: [datatype-dev] CR: Bug fix for 10084: Can't
do mp3 http streaming but other android devices can
In-Reply-To:
References: <4B97DDBE.4020507@real.com>
Message-ID: <4B97F2A2.6000406@real.com>
This should also go to Head I think, unless we plan to make improvement
soon (e.g. ask http filesystem to do quick byte-range-seek to the end of
file, bypassing the byte range seek threshold ).
fxd
Jyotsana Rathore wrote:
> Hi Jamie,
>
> It returns PREFER_LINEAR if the server does not support byte range seeking or if the stream is a live stream.
>
> I have checked in this change to 361 atlas.
>
> Thanks,
> Jyotsana
>
> -----Original Message-----
> From: Jamie Gordon
> Sent: Wednesday, March 10, 2010 9:58 AM
> To: Jyotsana Rathore
> Cc: porting-android@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] CR: Bug fix for 10084: Can't do mp3 http streaming but other android devices can
>
> Looks fine to me, though I am surprised it is necessary - shouldn't
> httpfsys always return PREFER_LINEAR?
>
> On 3/9/2010 10:48 PM, Jyotsana Rathore wrote:
>
>> Project: Real Player for Android
>>
>>
>>
>> Synopsis: Bug fix for 10084: Can't do mp3 http streaming but other
>> android devices can
>>
>>
>>
>> Overview: In mp3ff GetFileHeader function, there is a seek to the end of
>> file to look for ID3 v1 tags. Since the BYTE_RANGE_SEEK_THRESHHOLD was
>> bumped up in httpfsys.cpp, this seek is usually huge resulting in
>> downloading of all the data to the seek point and thus, increasing the
>> startup delay. The attached fix allows this initial seek for local file
>> system only.
>>
>>
>>
>> Files Added: none
>>
>>
>>
>> Files Modified:
>>
>> Datatype/mp3/fileformat/mp3ff.cpp
>>
>>
>>
>> Image Size and Heap Use impact (Client -Only): None
>>
>>
>>
>> Platforms and Profiles Build and Functionality Verified:
>>
>> Platform: android-donut-arm-qsd_8x50
>>
>> Profile: helix-client-android-full
>>
>> target(s): android_omx
>>
>>
>>
>> Branch: hxclient_3_6_1_atlas_restricted
>>
>>
>>
>> Copyright assignment: I am a RealNetworks employee.
>>
>>
>>
>> Files Attached: http.diff
>>
>>
>>
>>
>
> _______________________________________________
> Porting-android mailing list
> Porting-android@lists.helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/porting-android
> .
>
>
From qluo at real.com Thu Mar 11 11:57:43 2010
From: qluo at real.com (Qiang Luo)
Date: Thu Mar 11 19:07:05 2010
Subject: [datatype-dev] FW: DRM protected MP4 file parsing failure with
error code HXR_CORRUPT_FILE due to recent change
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901D6CBF5@NOK-EUMSG-02.mgdnok.nokia.com>
References: <954B6835A0CD0544886FA9FDDB387E2B2D88036671@NOK-EUMSG-02.mgdnok.nokia.com>
<19113978AB61DA44AC317B211CF1C32A2901BD0D11@NOK-EUMSG-02.mgdnok.nokia.com>
<4B955CE8.6050602@real.com>
<19113978AB61DA44AC317B211CF1C32A2901BD0E1C@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9590C5.4080401@real.com> <4B9596EE.1040601@real.com>
<19113978AB61DA44AC317B211CF1C32A2901D6CBF5@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B994B37.4030903@real.com>
Hi Saleem,
I think removing the "size check" in function CompleteAtomization() is a
reasonable fix. Please make the change and send a CR diff to the list
to see if there is any objection.
Thanks,
Qiang
On 3/11/2010 10:11 AM, saleem.adookkattil@nokia.com wrote:
> Qiang,
>
> Are you going to make the change to remove CompleteAtomization()?
>
> Thanks
> Saleem
>
> -----Original Message-----
> From: ext Jamie Gordon [mailto:jgordon@real.com]
> Sent: Monday, March 08, 2010 6:32 PM
> To: Qiang Luo
> Cc: Adookkattil Saleem (Nokia-D/Dallas)
> Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing failure with error code HXR_CORRUPT_FILE due to recent change
>
> Yeah I will try it, but I probably won't get a chance to do it until tomorrow.
>
> The repro I had was with fragmented content, specifically everything created by Adobe's Flash Media Live Encoder. I suspect someone on client is going to have more related work to do for fragmented content with HTTP progressive download and pseudo-streaming (like 3GPP Rel9 and MS Silverlight), in order to handle parsing the new moof atoms as they arrive - right now mp4ff will only do one up-front atomization, which of course is the problem with HTTP that this change deals with!
>
> On 3/8/2010 4:05 PM, Qiang Luo wrote:
>
>> Hi Jamie, I was wondering if you still have the repro content for the
>> atomizer parsing issue. If it is easy to setup, could you try
>> skipping the size checking in CompleteAtomization() to see if the
>> change fixes the parsing issue?
>>
>> It seems to me that removing the check might be a valid fix. Although
>> my previous change altered the atomizer code path in a few palaces,
>> here we are just trying to skip a particular check that has never been
>> used in CompleteAtomization() before. Please comment with your
>> thought/better fixes.
>>
>> Thanks,
>> Qiang
>>
>> On 3/8/2010 1:05 PM, saleem.adookkattil@nokia.com wrote:
>>
>>> Qiang,
>>>
>>> Removing the check in CompleteAtomization() fixes DRM issue.
>>>
>>> Thanks
>>> Saleem
>>>
>>> -----Original Message-----
>>> From: ext Qiang Luo [mailto:qluo@real.com]
>>> Sent: Monday, March 08, 2010 2:24 PM
>>> To: Adookkattil Saleem (Nokia-D/Dallas)
>>> Cc: datatype-dev@helixcommunity.org
>>> Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing
>>> failure with error code HXR_CORRUPT_FILE due to recent change
>>>
>>> I initially thought that this bug could be DRM specific issue due to the encryption padding. Based on Jamie's feedback, there might be issue related to my change even for non-drm contents. Limiting the seek/read range within the filesize seems to be the right thing to do. I would prefer not to rollback the http streaming fix if we can figure out a proper fix.
>>>
>>> With the old code where m_ulFinalOffset was always ATOMIZE_ALL, the checking in function CAtomizer::CompleteAtomization() for "if parsing fully completed" would never kick in. With m_ulFinalOffset now to be the filesize, the checking logic maybe too strict, marking false detection.
>>>
>>> If you take out the checking code in CompleteAtomization(), will the change fix your drm playback issue, Saleem? Jamie, will the same change address the parsing issues you observed?
>>>
>>> Thanks,
>>> Qiang
>>>
>>> On 3/8/2010 9:55 AM, saleem.adookkattil@nokia.com wrote:
>>>
>>>
>>>> Qiang,
>>>>
>>>> Answer to your questions inline.
>>>>
>>>>
>>>>
>>>>
>>>>> I made the change of passing ulFileSize to the Atomize() function.
>>>>> This was an attempt to fix a few mp4 http streaming issues. The
>>>>> basic idea was to limit the atomizer offset range to be within the
>>>>> actual file size if the filesystem supports IHXFileStat.
>>>>>
>>>>> In your parsing failure case, what is your DRM and the container
>>>>>
>>>>>
>>>>>
>>>> Continer format of the DRM clip is 3GP ullFinalOffset is actual file
>>>> size ullCurrentOffset is less than ullFinalOffset.
>>>> filesystem decrypt the datat first.
>>>>
>>>> Here is the log that I generated using mp4 file format dll
>>>>
>>>> CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
>>>> CAtomizer::Atomize offset 0, 0
>>>> CAtomizer::Atomize m_ullFinalOffset 136925, 0
>>>> CAtomizer::SeekData ullOffset 0, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 8, 0
>>>> CAtomizer::ReadData ulSize 16
>>>> CAtomizer::ReadData m_ullCurrentOffset 24, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 32, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 40, 0
>>>> CAtomizer::ReadData ulSize 100
>>>> CAtomizer::ReadData m_ullCurrentOffset 140, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 148, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 156, 0
>>>> CAtomizer::ReadData ulSize 84
>>>> CAtomizer::ReadData m_ullCurrentOffset 240, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 248, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 256, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 280, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 288, 0
>>>> CAtomizer::ReadData ulSize 25
>>>> CAtomizer::ReadData m_ullCurrentOffset 313, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 321, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 329, 0
>>>> CAtomizer::SeekData ullOffset 341, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 349, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 357, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 377, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 385, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 393, 0
>>>> CAtomizer::ReadData ulSize 109
>>>> CAtomizer::ReadData m_ullCurrentOffset 502, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 510, 0
>>>> CAtomizer::ReadData ulSize 32
>>>> CAtomizer::ReadData m_ullCurrentOffset 542, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 550, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 570, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 578, 0
>>>> CAtomizer::ReadData ulSize 820
>>>> CAtomizer::ReadData m_ullCurrentOffset 1398, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 1406, 0
>>>> CAtomizer::ReadData ulSize 816
>>>> CAtomizer::ReadData m_ullCurrentOffset 2222, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2230, 0
>>>> CAtomizer::ReadData ulSize 12
>>>> CAtomizer::ReadData m_ullCurrentOffset 2242, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2250, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2258, 0
>>>> CAtomizer::ReadData ulSize 84
>>>> CAtomizer::ReadData m_ullCurrentOffset 2342, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2350, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2358, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 2382, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2390, 0
>>>> CAtomizer::ReadData ulSize 25
>>>> CAtomizer::ReadData m_ullCurrentOffset 2415, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2423, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2431, 0
>>>> CAtomizer::SeekData ullOffset 2439, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2447, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2455, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 2475, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2483, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2491, 0
>>>> CAtomizer::ReadData ulSize 61
>>>> CAtomizer::ReadData m_ullCurrentOffset 2552, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2560, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 2584, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2592, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 2612, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2620, 0
>>>> CAtomizer::ReadData ulSize 284
>>>> CAtomizer::ReadData m_ullCurrentOffset 2904, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2912, 0
>>>> CAtomizer::ReadData ulSize 280
>>>> CAtomizer::ReadData m_ullCurrentOffset 3192, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 3200, 0
>>>> CAtomizer::SeekData ullOffset 136651, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 136659, 0
>>>> CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
>>>> CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
>>>>
>>>>
>>>>
>>>>
>>>>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>>>>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>>>>> encrypted data or the filesystem decrypt the data first? In
>>>>> general, if there is no decryptor in or sit between the filesystem
>>>>> and the fileformat, then the
>>>>> mp4 ff logic for clear data should work for drm data.
>>>>>
>>>>> Qiang
>>>>>
>>>>>
>>>>>
>>>> -----Original Message-----
>>>> From: datatype-dev-bounces@helixcommunity.org
>>>> [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext
>>>> Jamie Gordon
>>>> Sent: Wednesday, March 03, 2010 6:06 PM
>>>> To: Qiang Luo
>>>> Cc: datatype-dev@helixcommunity.org
>>>> Subject: Re: [datatype-dev] FW: DRM protected MP4 file parsing
>>>> failure with error code HXR_CORRUPT_FILE due to recent change
>>>>
>>>> For what it's worth, I also had issues with this change, which I
>>>> simply worked around for now by just not getting and passing the
>>>> file size for server builds (because http progressive
>>>> download/pseudo-streaming reception is not a concern at the server!)
>>>>
>>>> The problem I was having as far as I chased it was that when the file size was passed instead of ATOMIZE_ALL, the atomizer would not parse any top level atoms after the moov (or possibly just anything after the mdat).
>>>>
>>>> On 3/3/2010 3:53 PM, Qiang Luo wrote:
>>>>
>>>>
>>>>
>>>>> Hi Saleem,
>>>>>
>>>>> I made the change of passing ulFileSize to the Atomize() function.
>>>>> This was an attempt to fix a few mp4 http streaming issues. The
>>>>> basic idea was to limit the atomizer offset range to be within the
>>>>> actual file size if the filesystem supports IHXFileStat.
>>>>>
>>>>> In your parsing failure case, what is your DRM and the container
>>>>> format used? Is the m_ullFinalOffset the correct encrypted file size?
>>>>> What is the m_ullCurrentOffset value? Does the mp4 ff handles
>>>>> encrypted data or the filesystem decrypt the data first? In
>>>>> general, if there is no decryptor in or sit between the filesystem
>>>>> and the fileformat, then the
>>>>> mp4 ff logic for clear data should work for drm data.
>>>>>
>>>>> Qiang
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --
>>>>>> -
>>>>>> ---
>>>>>> *From:* saleem.adookkattil@nokia.com
>>>>>> [saleem.adookkattil@nokia.com]
>>>>>> *Sent:* Wednesday, March 03, 2010 12:55 PM
>>>>>> *To:* Eric Hyche
>>>>>> *Subject:* FW: DRM protected MP4 file parsing failure with error
>>>>>> code HXR_CORRUPT_FILE due to recent change
>>>>>>
>>>>>> Any comment on this?
>>>>>>
>>>>>> ______________________________________________
>>>>>> *From: *Adookkattil Saleem (Nokia-D/Dallas)
>>>>>> *Sent: *Tuesday, March 02, 2010 6:04 PM
>>>>>> *To: *'nokia-private-dev@helixcommunity.org'
>>>>>> *Subject: *DRM protected MP4 file parsing failure with error
>>>>>> code HXR_CORRUPT_FILE due to recent change
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> DRM protected MP4 file parsing is failing due to a change in MP4
>>>>>> file format project (qtffplin.cpp) made recently. Please see the
>>>>>> below given diff.
>>>>>>
>>>>>> _https://helixcommunity.org/viewcvs/datatype/mp4/fileformat/qtffplin.
>>>>>> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1_
>>>>>> >>>>> cpp?r1=1.60.2.8&r2=1.60.2.3.14.1>
>>>>>>
>>>>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>>>>> m_pAtomizer->Atomize(0, m_ulFileSize); as given in the diff.
>>>>>>
>>>>>> When we pass the file size as the second parameter, DRM file
>>>>>> parsing is failing in the below given function of CAtomizer class
>>>>>> (atomizer.cpp) with error code HXR_CORRUPT_FILE.
>>>>>>
>>>>>> /*****************************************************************
>>>>>> **
>>>>>> *
>>>>>> ********
>>>>>> * CompleteAtomization
>>>>>> */
>>>>>> void CAtomizer::CompleteAtomization(HX_RESULT status) {
>>>>>> CQTAtom* pRoot;
>>>>>>
>>>>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>>>>> m_ullCurrentOffset %d, %d\n", m_ullCurrentOffset,
>>>>>> *(((INT32*)(&m_ullCurrentOffset)) + 1));
>>>>>> fprintf((FILE*)m_file, " CAtomizer::CompleteAtomization
>>>>>> m_ullFinalOffset %d, %d\n", m_ullFinalOffset,
>>>>>> *(((INT32*)(&m_ullFinalOffset)) + 1));
>>>>>>
>>>>>> if (!m_pRoot)
>>>>>> {
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> if (SUCCEEDED(status))
>>>>>> {
>>>>>> // Record the amount of data atomized
>>>>>> CQTAtom *pRoot = m_pCurrentRoot;
>>>>>>
>>>>>> HX_ASSERT(pRoot);
>>>>>>
>>>>>> // If we have the position of where next atom would be,
>>>>>> // compute unspecified atom sizes
>>>>>> if (m_ullNewAtomOffset != ATOMIZE_ALL)
>>>>>> {
>>>>>> while (pRoot)
>>>>>> {
>>>>>> if (pRoot->GetSize() == ATOMIZE_ALL)
>>>>>> {
>>>>>> pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>>>>> }
>>>>>>
>>>>>> // Move to the parent
>>>>>> pRoot = pRoot->GetParent();
>>>>>> }
>>>>>>
>>>>>> m_pRoot->SetSize(m_ullNewAtomOffset - m_ullStartOffset);
>>>>>> }
>>>>>>
>>>>>> status = AdjustCurrentRoot();
>>>>>> }
>>>>>>
>>>>>> if (SUCCEEDED(status))
>>>>>> {
>>>>>> if (m_ullFinalOffset != ATOMIZE_ALL)
>>>>>> {
>>>>>> m_ullCurrentOffset = m_ullCurrentOffset>
>>>>>> m_ullFinalOffset ? m_ullFinalOffset : m_ullCurrentOffset;
>>>>>> }
>>>>>>
>>>>>> // See if parsing fully completed
>>>>>> if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>>>>> (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>>>>> (m_pRoot != m_pCurrentRoot))
>>>>>> {
>>>>>> status = HXR_CORRUPT_FILE;
>>>>>> }
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> // Data compromizing failure occured during atomization
>>>>>> HX_RELEASE(m_pRoot);
>>>>>> }
>>>>>>
>>>>>> HX_RELEASE(m_pNewAtom);
>>>>>>
>>>>>> m_State = ATMZR_Ready;
>>>>>>
>>>>>> pRoot = m_pRoot;
>>>>>> m_pRoot = NULL;
>>>>>> m_pCurrentRoot = NULL;
>>>>>>
>>>>>> m_pResponse->AtomReady(status, pRoot);
>>>>>>
>>>>>> if (pRoot)
>>>>>> {
>>>>>> pRoot->Release();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The reason for the failure is the value of ullCurrentOffset is
>>>>>> less than m_ullFinalOffset.
>>>>>>
>>>>>> If we keep the previous function call, there is no error (ie,
>>>>>> retVal = m_pAtomizer->Atomize(); )
>>>>>>
>>>>>> Whats the reason for this change? Any suggestion to fix this error?
>>>>>>
>>>>>> Thanks& regards
>>>>>> Saleem
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> 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
>>>> .
>>>>
>>>>
>>>>
>>>>
>>> .
>>>
>>>
>>>
>>
> .
>
>
From ext-debashis.2.panigrahi at nokia.com Thu Mar 11 19:50:32 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Mar 12 03:01:02 2010
Subject: [datatype-dev] CR: EELI-838CX2: Fusion: System error occurs after
rejecting query ?Create WLAN connection in offline mode?? when try
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CDA72062@NOK-EUMSG-02.mgdnok.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: ext-debashis.2.panigrahi@nokia.com
Reviewed by: Yury.Ramanovich@nokia.com
TSW Id: EELI-838CX2
Date: 03/12/2010
Project: SymbianMmf_wm
Synopsis: Fusion: System error occurs after rejecting query ?Create WLAN connection in offline mode?? when try
Overview:
When user cancels the query to connect to the access point, AP Connect() fails with HXR_CANCELLED but this error code is not being handled properly at CPlatform::GetAddrInfoDone() @ helix_platform.cpp. It falls into the default case where we set return value to E_FAIL. Which again gets mapped to HXR_FAIL at CASFFileFormatNet::MapWMToHelixErrorCode() @asf_file_format_net.cpp and hence we get that "General: System error" note.
Fix:
Now mapping HXR_CANCELLED to WM error NS_E_WMPCORE_USER_CANCEL (Open was aborted by user). Then mapping this WM error code to HXR_CANCELLED at MapWMToHelixErrorCode().
Files modified & changes:
wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp
wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS:
Index: wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp
===================================================================
RCS file: /cvsroot/wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp,v
retrieving revision 1.5.10.5
diff -u -w -r1.5.10.5 helix_platform.cpp
--- wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 7 Aug 2009 17:01:02 -0000 1.5.10.5
+++ wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 10 Mar 2010 11:34:01 -0000
@@ -673,6 +673,7 @@
case HXR_NET_RESOURCES_IN_USE: hr = HXR_NET_RESOURCES_IN_USE; break;
case HXR_NET_CONNECT: hr = NS_E_CONNECT_TIMEOUT; break;
case HXR_DNR: hr = NS_E_SERVER_DNS_TIMEOUT; break;
+ case HXR_CANCELLED: hr = NS_E_WMPCORE_USER_CANCEL; break;
default: hr = (SUCCEEDED(status) ? S_OK : E_FAIL); break;
}
// Invoke the callback
Index: wm/rtsp/fileformat/asf_file_format_net.cpp
===================================================================
RCS file: /cvsroot/wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp,v
retrieving revision 1.15.10.21
diff -u -w -r1.15.10.21 asf_file_format_net.cpp
--- wm/rtsp/fileformat/asf_file_format_net.cpp 13 Nov 2009 13:43:46 -0000 1.15.10.21
+++ wm/rtsp/fileformat/asf_file_format_net.cpp 10 Mar 2010 11:27:43
+++ -0000
@@ -192,6 +192,7 @@
{NS_E_TIMEOUT, HXR_PE_REQUEST_TIMEOUT },
{HXR_NET_RESOURCES_IN_USE, HXR_NET_CONNECT },
{HXR_INVALID_PARAMETER, HXR_NET_CONNECT },
+ {NS_E_WMPCORE_USER_CANCEL, HXR_CANCELLED },
{NSNET_E_BADREQUEST, HXR_PE_BAD_REQUEST },
{NSNET_E_UNAUTHORIZED, HXR_PE_UNAUTHORIZED },
{NSNET_E_PAYMENTREQD, HXR_PE_PAYMENT_REQUIRED },
From tseaward at real.com Fri Mar 12 14:33:14 2010
From: tseaward at real.com (Tony Seaward)
Date: Fri Mar 12 21:43:29 2010
Subject: [datatype-dev] Re: [wmcode-protocol-dev] CR: EELI-838CX2: Fusion:
System error occurs
after rejecting query ?Create WLAN connection in offline mode?? when try
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE22CDA72062@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE22CDA72062@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B9AC12A.4060706@real.com>
Looks Good (on behalf of Cbailey).
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/11/10 7:50 PM, ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Yury.Ramanovich@nokia.com
>
> TSW Id: EELI-838CX2
>
> Date: 03/12/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Fusion: System error occurs after rejecting query ?Create WLAN connection in offline mode?? when try
>
> Overview:
> When user cancels the query to connect to the access point, AP Connect() fails with HXR_CANCELLED but this error code is not being handled properly at CPlatform::GetAddrInfoDone() @ helix_platform.cpp. It falls into the default case where we set return value to E_FAIL. Which again gets mapped to HXR_FAIL at CASFFileFormatNet::MapWMToHelixErrorCode() @asf_file_format_net.cpp and hence we get that "General: System error" note.
>
> Fix:
> Now mapping HXR_CANCELLED to WM error NS_E_WMPCORE_USER_CANCEL (Open was aborted by user). Then mapping this WM error code to HXR_CANCELLED at MapWMToHelixErrorCode().
>
> Files modified & changes:
> wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp
> wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp
> ===================================================================
> RCS file: /cvsroot/wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp,v
> retrieving revision 1.5.10.5
> diff -u -w -r1.5.10.5 helix_platform.cpp
> --- wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 7 Aug 2009 17:01:02 -0000 1.5.10.5
> +++ wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 10 Mar 2010 11:34:01 -0000
> @@ -673,6 +673,7 @@
> case HXR_NET_RESOURCES_IN_USE: hr = HXR_NET_RESOURCES_IN_USE; break;
> case HXR_NET_CONNECT: hr = NS_E_CONNECT_TIMEOUT; break;
> case HXR_DNR: hr = NS_E_SERVER_DNS_TIMEOUT; break;
> + case HXR_CANCELLED: hr = NS_E_WMPCORE_USER_CANCEL; break;
> default: hr = (SUCCEEDED(status) ? S_OK : E_FAIL); break;
> }
> // Invoke the callback
>
> Index: wm/rtsp/fileformat/asf_file_format_net.cpp
> ===================================================================
> RCS file: /cvsroot/wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp,v
> retrieving revision 1.15.10.21
> diff -u -w -r1.15.10.21 asf_file_format_net.cpp
> --- wm/rtsp/fileformat/asf_file_format_net.cpp 13 Nov 2009 13:43:46 -0000 1.15.10.21
> +++ wm/rtsp/fileformat/asf_file_format_net.cpp 10 Mar 2010 11:27:43
> +++ -0000
> @@ -192,6 +192,7 @@
> {NS_E_TIMEOUT, HXR_PE_REQUEST_TIMEOUT },
> {HXR_NET_RESOURCES_IN_USE, HXR_NET_CONNECT },
> {HXR_INVALID_PARAMETER, HXR_NET_CONNECT },
> + {NS_E_WMPCORE_USER_CANCEL, HXR_CANCELLED },
> {NSNET_E_BADREQUEST, HXR_PE_BAD_REQUEST },
> {NSNET_E_UNAUTHORIZED, HXR_PE_UNAUTHORIZED },
> {NSNET_E_PAYMENTREQD, HXR_PE_PAYMENT_REQUIRED },
>
>
> _______________________________________________
> wmcode-protocol-dev mailing list
> wmcode-protocol-dev@lists.helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/wmcode-protocol-dev
>
From ext-debashis.2.panigrahi at nokia.com Sat Mar 13 01:57:01 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Sat Mar 13 09:07:46 2010
Subject: [datatype-dev] RE: [wmcode-protocol-dev] CR: EELI-838CX2: Fusion:
System error
occurs after rejecting query ?Create WLAN connection in offline mode?? when
try
In-Reply-To: <4B9AC12A.4060706@real.com>
References: <20D73E2631F7914F868646E119DEC1CE22CDA72062@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9AC12A.4060706@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE22CDA72909@NOK-EUMSG-02.mgdnok.nokia.com>
Hi,
This has been checked in to 210CayS, 420Bizo and HEAD
Thanks and Regards,
Debashis.
-----Original Message-----
From: ext Tony Seaward [mailto:tseaward@real.com]
Sent: Saturday, March 13, 2010 4:03 AM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: wmcode-protocol-dev@helixcommunity.org; datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org; Christina Bailey
Subject: Re: [wmcode-protocol-dev] CR: EELI-838CX2: Fusion: System error occurs after rejecting query ?Create WLAN connection in offline mode?? when try
Looks Good (on behalf of Cbailey).
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/11/10 7:50 PM, ext-debashis.2.panigrahi@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Yury.Ramanovich@nokia.com
>
> TSW Id: EELI-838CX2
>
> Date: 03/12/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Fusion: System error occurs after rejecting query ?Create
> WLAN connection in offline mode?? when try
>
> Overview:
> When user cancels the query to connect to the access point, AP Connect() fails with HXR_CANCELLED but this error code is not being handled properly at CPlatform::GetAddrInfoDone() @ helix_platform.cpp. It falls into the default case where we set return value to E_FAIL. Which again gets mapped to HXR_FAIL at CASFFileFormatNet::MapWMToHelixErrorCode() @asf_file_format_net.cpp and hence we get that "General: System error" note.
>
> Fix:
> Now mapping HXR_CANCELLED to WM error NS_E_WMPCORE_USER_CANCEL (Open was aborted by user). Then mapping this WM error code to HXR_CANCELLED at MapWMToHelixErrorCode().
>
> Files modified & changes:
> wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/helix/he
> lix_platform.cpp
> wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index:
> wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.
> cpp
> ===================================================================
> RCS file:
> /cvsroot/wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client
> /helix/helix_platform.cpp,v
> retrieving revision 1.5.10.5
> diff -u -w -r1.5.10.5 helix_platform.cpp
> --- wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 7 Aug 2009 17:01:02 -0000 1.5.10.5
> +++ wm/rtsp/import/wmrtsp-porting-kit/network/client/helix/helix_platform.cpp 10 Mar 2010 11:34:01 -0000
> @@ -673,6 +673,7 @@
> case HXR_NET_RESOURCES_IN_USE: hr = HXR_NET_RESOURCES_IN_USE; break;
> case HXR_NET_CONNECT: hr = NS_E_CONNECT_TIMEOUT; break;
> case HXR_DNR: hr = NS_E_SERVER_DNS_TIMEOUT; break;
> + case HXR_CANCELLED: hr = NS_E_WMPCORE_USER_CANCEL; break;
> default: hr = (SUCCEEDED(status) ? S_OK : E_FAIL); break;
> }
> // Invoke the callback
>
> Index: wm/rtsp/fileformat/asf_file_format_net.cpp
> ===================================================================
> RCS file:
> /cvsroot/wmcode-protocol/rtsp/fileformat/asf_file_format_net.cpp,v
> retrieving revision 1.15.10.21
> diff -u -w -r1.15.10.21 asf_file_format_net.cpp
> --- wm/rtsp/fileformat/asf_file_format_net.cpp 13 Nov 2009 13:43:46 -0000 1.15.10.21
> +++ wm/rtsp/fileformat/asf_file_format_net.cpp 10 Mar 2010 11:27:43
> +++ -0000
> @@ -192,6 +192,7 @@
> {NS_E_TIMEOUT, HXR_PE_REQUEST_TIMEOUT },
> {HXR_NET_RESOURCES_IN_USE, HXR_NET_CONNECT },
> {HXR_INVALID_PARAMETER, HXR_NET_CONNECT },
> + {NS_E_WMPCORE_USER_CANCEL, HXR_CANCELLED },
> {NSNET_E_BADREQUEST, HXR_PE_BAD_REQUEST },
> {NSNET_E_UNAUTHORIZED, HXR_PE_UNAUTHORIZED },
> {NSNET_E_PAYMENTREQD, HXR_PE_PAYMENT_REQUIRED },
>
>
> _______________________________________________
> wmcode-protocol-dev mailing list
> wmcode-protocol-dev@lists.helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/wmcode-protocol-dev
>
From saleem.adookkattil at nokia.com Mon Mar 15 13:05:11 2010
From: saleem.adookkattil at nokia.com (saleem.adookkattil@nokia.com)
Date: Mon Mar 15 20:16:36 2010
Subject: [datatype-dev] CR:-DRM protected 3gp file parsing failure.
Message-ID: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with Real Networks, and I am authorized to contribute this code under said agreement."
Modified by: saleem.adookkattil@nokia.com
Reviewed by:
Date: 03/15/2010
Project: symbian_client_apps
ErrorId: JLIU-83KSEU
Synopsis: DRM protected 3gp file parsing failure.
Overview:
DRM protected 3gp file parsing is failing due to a change in MP4 file format project (qtffplin.cpp) made recently.
Function call retVal = m_pAtomizer->Atomize(); changed to retVal = m_pAtomizer->Atomize(0, m_ulFileSize);
When we pass the file size as the second parameter, DRM file parsing is failing in void CompleteAtomization(HX_RESULT status) method of CAtomizer with error code HXR_CORRUPT_FILE.
Removed the condition (m_ullFinalOffset != ATOMIZE_ALL) && (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in the diff to fix the error.
Files modified:
cvsroot\datatype\mp4\fileformat\atomizer.cpp
Files added:
Image Size and Heap Use impact: None.
Module Release testing (STIF) : Yes
Test case(s) Added : No
Memory leak check performed : Yes
Platforms and Profiles Build Verified: helix-client-symbian-4
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 4_2_0_brizo, HEAD
Index: atomizer.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
retrieving revision 1.23.4.2
diff -u -w -r1.23.4.2 atomizer.cpp
--- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
+++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
@@ -574,9 +574,7 @@
}
// See if parsing fully completed
- if (((m_ullFinalOffset != ATOMIZE_ALL) &&
- (m_ullFinalOffset != m_ullCurrentOffset)) ||
- (m_pRoot != m_pCurrentRoot))
+ if (m_pRoot != m_pCurrentRoot)
{
status = HXR_CORRUPT_FILE;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100315/ae77b896/attachment.html
From sfu at real.com Mon Mar 15 15:58:13 2010
From: sfu at real.com (Sheldon Fu)
Date: Mon Mar 15 23:07:16 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp file
parsing failure.
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B9EC995.1090306@real.com>
This nullifies the last change right above this code block (on Head,
revision 1.25 made in 10/2009), if we are going to go with this, we need
to take out the change r1.25 too.
It seems that both 1.25 and this is not fixing the root problem(s). Do
you have details why in the DRM file case, CurrentOffset ends up smaller
than FinalOffset after the parsing finishes? And for the issue that
r1.25 tries to fix, why CurrentOffset can end up bigger than
FinalOffset(which is the file size)? If our parsing logic can advance
the CurrentOffset beyond the file size for a well-formed mp4 file,
likely somewhere some logic is not right and may cause other problems.
fxd
saleem.adookkattil@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with Real Networks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: saleem.adookkattil@nokia.com
>
> Reviewed by:
>
> Date: 03/15/2010
>
> Project: symbian_client_apps
>
> ErrorId: JLIU-83KSEU
>
> Synopsis: DRM protected 3gp file parsing failure.
>
> Overview:
>
> DRM protected 3gp file parsing is failing due to a change in MP4 file
> format project (qtffplin.cpp) made recently.
> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
> m_pAtomizer->Atomize(0, m_ulFileSize);
> When we pass the file size as the second parameter, DRM file parsing
> is failing in void CompleteAtomization(HX_RESULT status) method of
> CAtomizer with error code HXR_CORRUPT_FILE.
> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL) &&
> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in
> the diff to fix the error.
>
> Files modified:
>
> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>
> Files added:
>
> Image Size and Heap Use impact: None.
>
> Module Release testing (STIF) : Yes
>
> Test case(s) Added : No
>
> Memory leak check performed : Yes
>
> Platforms and Profiles Build Verified: helix-client-symbian-4
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 4_2_0_brizo, HEAD
>
> Index: atomizer.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
> retrieving revision 1.23.4.2
> diff -u -w -r1.23.4.2 atomizer.cpp
> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
> @@ -574,9 +574,7 @@
> }
>
> // See if parsing fully completed
> - if (((m_ullFinalOffset != ATOMIZE_ALL) &&
> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
> - (m_pRoot != m_pCurrentRoot))
> + if (m_pRoot != m_pCurrentRoot)
> {
> status = HXR_CORRUPT_FILE;
> }
>
From qluo at real.com Mon Mar 15 21:27:27 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Mar 16 04:36:19 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <4B9EC995.1090306@real.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com>
Message-ID: <4B9F16BF.5000803@real.com>
Sheldon,
Here is some background info. Both this fix and the change in r1.25 was
related to my previous change of passing ulFileSize to the Atomize()
function.
The mp4 header parsing code, the CAtomizer, walks through all atoms
until certain conditions are met: the offset for the next atom is out
of range or the next atom read returns an error. In the initial
implementation, we did not set the atom offset range limit. In the
attempt to get to the next atom, we ended up seeking over the last
atom(usually the "mdat" atom) to the end of file. While this may not be
an issue for local playback, for http streaming, it forces byte-range
seek with network re-connect, disrupting normal downloading data flow,
or even worse, making the client wait long time to download the entire
track if the seek size is under byte-range-seek threshold.
My Atomize() change was an attempt to fix the mp4 http streaming slow
start issue. The basic idea was to limit the atomizer offset range to
be within the actual file size if the filesystem supports IHXFileStat.
We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
checks in the code for m_ullCurrentOffset that will never get hit
because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
end of atom parsing, the m_ullCurrentOffset could be arbitrary, without
triggering the checks. My change of passing file size to the
m_pAtomizer->Atomize() activated those "dead" checks. Some of the
checks appeared to be too strict, triggering false detection.
As you implied, the better fix might be figuring out what value
m_ullCurrentOffset should be after atom parsing in normal situation, and
fixing the m_ullCurrentOffset advancing logic. I agree that if we make
this change in Saleem's diff , we should also take out my change in r1.25.
Qiang
On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
> This nullifies the last change right above this code block (on Head,
> revision 1.25 made in 10/2009), if we are going to go with this, we need
> to take out the change r1.25 too.
>
> It seems that both 1.25 and this is not fixing the root problem(s). Do
> you have details why in the DRM file case, CurrentOffset ends up smaller
> than FinalOffset after the parsing finishes? And for the issue that
> r1.25 tries to fix, why CurrentOffset can end up bigger than
> FinalOffset(which is the file size)? If our parsing logic can advance
> the CurrentOffset beyond the file size for a well-formed mp4 file,
> likely somewhere some logic is not right and may cause other problems.
>
> fxd
>
> saleem.adookkattil@nokia.com wrote:
>
>> "Nokia submits this code under the terms of a commercial contribution
>> agreement with Real Networks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: saleem.adookkattil@nokia.com
>>
>> Reviewed by:
>>
>> Date: 03/15/2010
>>
>> Project: symbian_client_apps
>>
>> ErrorId: JLIU-83KSEU
>>
>> Synopsis: DRM protected 3gp file parsing failure.
>>
>> Overview:
>>
>> DRM protected 3gp file parsing is failing due to a change in MP4 file
>> format project (qtffplin.cpp) made recently.
>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>> m_pAtomizer->Atomize(0, m_ulFileSize);
>> When we pass the file size as the second parameter, DRM file parsing
>> is failing in void CompleteAtomization(HX_RESULT status) method of
>> CAtomizer with error code HXR_CORRUPT_FILE.
>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in
>> the diff to fix the error.
>>
>> Files modified:
>>
>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>
>> Files added:
>>
>> Image Size and Heap Use impact: None.
>>
>> Module Release testing (STIF) : Yes
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : Yes
>>
>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>
>> Platforms and Profiles Functionality verified: armv5, winscw
>>
>> Branch: 4_2_0_brizo, HEAD
>>
>> Index: atomizer.cpp
>> ===================================================================
>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>> retrieving revision 1.23.4.2
>> diff -u -w -r1.23.4.2 atomizer.cpp
>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>> @@ -574,9 +574,7 @@
>> }
>>
>> // See if parsing fully completed
>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>> - (m_pRoot != m_pCurrentRoot))
>> + if (m_pRoot != m_pCurrentRoot)
>> {
>> status = HXR_CORRUPT_FILE;
>> }
>>
>>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> .
>
>
From sfu at real.com Tue Mar 16 04:06:13 2010
From: sfu at real.com (Sheldon Fu)
Date: Tue Mar 16 11:15:04 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <4B9F16BF.5000803@real.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com> <4B9F16BF.5000803@real.com>
Message-ID: <4B9F7435.2070507@real.com>
Right. I remember your CR. What I don't understand is why "In the
attempt to get to the next atom, we ended up seeking over the last
atom(usually the "mdat" atom) to the end of file. ". Each atom has a
size field (unless for the special case of 'spanning to the end' atom).
Did you actually see for some clip that at some point we actually issue
a SEEK beyond the file size (not a SEEK_END, but a SEEK_SET with an
offset beyond file size)? If so, that seems to be wrong.
fxd
Qiang Luo wrote:
> Sheldon,
>
> Here is some background info. Both this fix and the change in r1.25 was
> related to my previous change of passing ulFileSize to the Atomize()
> function.
>
> The mp4 header parsing code, the CAtomizer, walks through all atoms
> until certain conditions are met: the offset for the next atom is out
> of range or the next atom read returns an error. In the initial
> implementation, we did not set the atom offset range limit. In the
> attempt to get to the next atom, we ended up seeking over the last
> atom(usually the "mdat" atom) to the end of file. While this may not be
> an issue for local playback, for http streaming, it forces byte-range
> seek with network re-connect, disrupting normal downloading data flow,
> or even worse, making the client wait long time to download the entire
> track if the seek size is under byte-range-seek threshold.
>
> My Atomize() change was an attempt to fix the mp4 http streaming slow
> start issue. The basic idea was to limit the atomizer offset range to
> be within the actual file size if the filesystem supports IHXFileStat.
>
> We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
> checks in the code for m_ullCurrentOffset that will never get hit
> because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
> end of atom parsing, the m_ullCurrentOffset could be arbitrary, without
> triggering the checks. My change of passing file size to the
> m_pAtomizer->Atomize() activated those "dead" checks. Some of the
> checks appeared to be too strict, triggering false detection.
>
> As you implied, the better fix might be figuring out what value
> m_ullCurrentOffset should be after atom parsing in normal situation, and
> fixing the m_ullCurrentOffset advancing logic. I agree that if we make
> this change in Saleem's diff , we should also take out my change in r1.25.
>
> Qiang
>
> On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
>
>> This nullifies the last change right above this code block (on Head,
>> revision 1.25 made in 10/2009), if we are going to go with this, we need
>> to take out the change r1.25 too.
>>
>> It seems that both 1.25 and this is not fixing the root problem(s). Do
>> you have details why in the DRM file case, CurrentOffset ends up smaller
>> than FinalOffset after the parsing finishes? And for the issue that
>> r1.25 tries to fix, why CurrentOffset can end up bigger than
>> FinalOffset(which is the file size)? If our parsing logic can advance
>> the CurrentOffset beyond the file size for a well-formed mp4 file,
>> likely somewhere some logic is not right and may cause other problems.
>>
>> fxd
>>
>> saleem.adookkattil@nokia.com wrote:
>>
>>
>>> "Nokia submits this code under the terms of a commercial contribution
>>> agreement with Real Networks, and I am authorized to contribute this
>>> code under said agreement."
>>>
>>> Modified by: saleem.adookkattil@nokia.com
>>>
>>> Reviewed by:
>>>
>>> Date: 03/15/2010
>>>
>>> Project: symbian_client_apps
>>>
>>> ErrorId: JLIU-83KSEU
>>>
>>> Synopsis: DRM protected 3gp file parsing failure.
>>>
>>> Overview:
>>>
>>> DRM protected 3gp file parsing is failing due to a change in MP4 file
>>> format project (qtffplin.cpp) made recently.
>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>> m_pAtomizer->Atomize(0, m_ulFileSize);
>>> When we pass the file size as the second parameter, DRM file parsing
>>> is failing in void CompleteAtomization(HX_RESULT status) method of
>>> CAtomizer with error code HXR_CORRUPT_FILE.
>>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in
>>> the diff to fix the error.
>>>
>>> Files modified:
>>>
>>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>>
>>> Files added:
>>>
>>> Image Size and Heap Use impact: None.
>>>
>>> Module Release testing (STIF) : Yes
>>>
>>> Test case(s) Added : No
>>>
>>> Memory leak check performed : Yes
>>>
>>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>>
>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>
>>> Branch: 4_2_0_brizo, HEAD
>>>
>>> Index: atomizer.cpp
>>> ===================================================================
>>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>>> retrieving revision 1.23.4.2
>>> diff -u -w -r1.23.4.2 atomizer.cpp
>>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>>> @@ -574,9 +574,7 @@
>>> }
>>>
>>> // See if parsing fully completed
>>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>> - (m_pRoot != m_pCurrentRoot))
>>> + if (m_pRoot != m_pCurrentRoot)
>>> {
>>> status = HXR_CORRUPT_FILE;
>>> }
>>>
>>>
>>>
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>> .
>>
>>
>>
>
> .
>
>
From saleem.adookkattil at nokia.com Tue Mar 16 05:46:24 2010
From: saleem.adookkattil at nokia.com (saleem.adookkattil@nokia.com)
Date: Tue Mar 16 12:58:40 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <4B9F7435.2070507@real.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com> <4B9F16BF.5000803@real.com>
<4B9F7435.2070507@real.com>
Message-ID: <19113978AB61DA44AC317B211CF1C32A2901E1136B@NOK-EUMSG-02.mgdnok.nokia.com>
There is no seeking beyond file size. Last current offset value is 136659 and file size is 136925. Here is the log.
>>> CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
>>> CAtomizer::Atomize offset 0, 0
>>> CAtomizer::Atomize m_ullFinalOffset 136925, 0
>>> CAtomizer::SeekData ullOffset 0, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 8, 0
>>> CAtomizer::ReadData ulSize 16
>>> CAtomizer::ReadData m_ullCurrentOffset 24, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 32, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 40, 0
>>> CAtomizer::ReadData ulSize 100
>>> CAtomizer::ReadData m_ullCurrentOffset 140, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 148, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 156, 0
>>> CAtomizer::ReadData ulSize 84
>>> CAtomizer::ReadData m_ullCurrentOffset 240, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 248, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 256, 0
>>> CAtomizer::ReadData ulSize 24
>>> CAtomizer::ReadData m_ullCurrentOffset 280, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 288, 0
>>> CAtomizer::ReadData ulSize 25
>>> CAtomizer::ReadData m_ullCurrentOffset 313, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 321, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 329, 0
>>> CAtomizer::SeekData ullOffset 341, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 349, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 357, 0
>>> CAtomizer::ReadData ulSize 20
>>> CAtomizer::ReadData m_ullCurrentOffset 377, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 385, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 393, 0
>>> CAtomizer::ReadData ulSize 109
>>> CAtomizer::ReadData m_ullCurrentOffset 502, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 510, 0
>>> CAtomizer::ReadData ulSize 32
>>> CAtomizer::ReadData m_ullCurrentOffset 542, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 550, 0
>>> CAtomizer::ReadData ulSize 20
>>> CAtomizer::ReadData m_ullCurrentOffset 570, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 578, 0
>>> CAtomizer::ReadData ulSize 820
>>> CAtomizer::ReadData m_ullCurrentOffset 1398, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 1406, 0
>>> CAtomizer::ReadData ulSize 816
>>> CAtomizer::ReadData m_ullCurrentOffset 2222, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2230, 0
>>> CAtomizer::ReadData ulSize 12
>>> CAtomizer::ReadData m_ullCurrentOffset 2242, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2250, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2258, 0
>>> CAtomizer::ReadData ulSize 84
>>> CAtomizer::ReadData m_ullCurrentOffset 2342, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2350, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2358, 0
>>> CAtomizer::ReadData ulSize 24
>>> CAtomizer::ReadData m_ullCurrentOffset 2382, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2390, 0
>>> CAtomizer::ReadData ulSize 25
>>> CAtomizer::ReadData m_ullCurrentOffset 2415, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2423, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2431, 0
>>> CAtomizer::SeekData ullOffset 2439, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2447, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2455, 0
>>> CAtomizer::ReadData ulSize 20
>>> CAtomizer::ReadData m_ullCurrentOffset 2475, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2483, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2491, 0
>>> CAtomizer::ReadData ulSize 61
>>> CAtomizer::ReadData m_ullCurrentOffset 2552, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2560, 0
>>> CAtomizer::ReadData ulSize 24
>>> CAtomizer::ReadData m_ullCurrentOffset 2584, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2592, 0
>>> CAtomizer::ReadData ulSize 20
>>> CAtomizer::ReadData m_ullCurrentOffset 2612, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2620, 0
>>> CAtomizer::ReadData ulSize 284
>>> CAtomizer::ReadData m_ullCurrentOffset 2904, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 2912, 0
>>> CAtomizer::ReadData ulSize 280
>>> CAtomizer::ReadData m_ullCurrentOffset 3192, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 3200, 0
>>> CAtomizer::SeekData ullOffset 136651, 0
>>> CAtomizer::ReadData ulSize 8
>>> CAtomizer::ReadData m_ullCurrentOffset 136659, 0
>>> CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
>>> CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
-Saleem
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Tuesday, March 16, 2010 7:06 AM
To: Qiang Luo
Cc: Adookkattil Saleem (Nokia-D/Dallas); nokia-private-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp file parsing failure.
Right. I remember your CR. What I don't understand is why "In the attempt to get to the next atom, we ended up seeking over the last atom(usually the "mdat" atom) to the end of file. ". Each atom has a size field (unless for the special case of 'spanning to the end' atom).
Did you actually see for some clip that at some point we actually issue a SEEK beyond the file size (not a SEEK_END, but a SEEK_SET with an offset beyond file size)? If so, that seems to be wrong.
fxd
Qiang Luo wrote:
> Sheldon,
>
> Here is some background info. Both this fix and the change in r1.25
> was related to my previous change of passing ulFileSize to the
> Atomize() function.
>
> The mp4 header parsing code, the CAtomizer, walks through all atoms
> until certain conditions are met: the offset for the next atom is out
> of range or the next atom read returns an error. In the initial
> implementation, we did not set the atom offset range limit. In the
> attempt to get to the next atom, we ended up seeking over the last
> atom(usually the "mdat" atom) to the end of file. While this may not
> be an issue for local playback, for http streaming, it forces
> byte-range seek with network re-connect, disrupting normal downloading
> data flow, or even worse, making the client wait long time to download
> the entire track if the seek size is under byte-range-seek threshold.
>
> My Atomize() change was an attempt to fix the mp4 http streaming slow
> start issue. The basic idea was to limit the atomizer offset range to
> be within the actual file size if the filesystem supports IHXFileStat.
>
> We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
> checks in the code for m_ullCurrentOffset that will never get hit
> because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
> end of atom parsing, the m_ullCurrentOffset could be arbitrary,
> without triggering the checks. My change of passing file size to the
> m_pAtomizer->Atomize() activated those "dead" checks. Some of the
> checks appeared to be too strict, triggering false detection.
>
> As you implied, the better fix might be figuring out what value
> m_ullCurrentOffset should be after atom parsing in normal situation,
> and fixing the m_ullCurrentOffset advancing logic. I agree that if we
> make this change in Saleem's diff , we should also take out my change in r1.25.
>
> Qiang
>
> On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
>
>> This nullifies the last change right above this code block (on Head,
>> revision 1.25 made in 10/2009), if we are going to go with this, we
>> need to take out the change r1.25 too.
>>
>> It seems that both 1.25 and this is not fixing the root problem(s).
>> Do you have details why in the DRM file case, CurrentOffset ends up
>> smaller than FinalOffset after the parsing finishes? And for the
>> issue that
>> r1.25 tries to fix, why CurrentOffset can end up bigger than
>> FinalOffset(which is the file size)? If our parsing logic can advance
>> the CurrentOffset beyond the file size for a well-formed mp4 file,
>> likely somewhere some logic is not right and may cause other problems.
>>
>> fxd
>>
>> saleem.adookkattil@nokia.com wrote:
>>
>>
>>> "Nokia submits this code under the terms of a commercial
>>> contribution agreement with Real Networks, and I am authorized to
>>> contribute this code under said agreement."
>>>
>>> Modified by: saleem.adookkattil@nokia.com
>>>
>>> Reviewed by:
>>>
>>> Date: 03/15/2010
>>>
>>> Project: symbian_client_apps
>>>
>>> ErrorId: JLIU-83KSEU
>>>
>>> Synopsis: DRM protected 3gp file parsing failure.
>>>
>>> Overview:
>>>
>>> DRM protected 3gp file parsing is failing due to a change in MP4
>>> file format project (qtffplin.cpp) made recently.
>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>> m_pAtomizer->Atomize(0, m_ulFileSize); When we pass the file size as
>>> the second parameter, DRM file parsing is failing in void
>>> CompleteAtomization(HX_RESULT status) method of CAtomizer with error
>>> code HXR_CORRUPT_FILE.
>>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given
>>> in the diff to fix the error.
>>>
>>> Files modified:
>>>
>>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>>
>>> Files added:
>>>
>>> Image Size and Heap Use impact: None.
>>>
>>> Module Release testing (STIF) : Yes
>>>
>>> Test case(s) Added : No
>>>
>>> Memory leak check performed : Yes
>>>
>>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>>
>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>
>>> Branch: 4_2_0_brizo, HEAD
>>>
>>> Index: atomizer.cpp
>>> ===================================================================
>>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>>> retrieving revision 1.23.4.2
>>> diff -u -w -r1.23.4.2 atomizer.cpp
>>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>>> @@ -574,9 +574,7 @@
>>> }
>>>
>>> // See if parsing fully completed
>>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>> - (m_pRoot != m_pCurrentRoot))
>>> + if (m_pRoot != m_pCurrentRoot)
>>> {
>>> status = HXR_CORRUPT_FILE;
>>> }
>>>
>>>
>>>
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>> .
>>
>>
>>
>
> .
>
>
From qluo at real.com Tue Mar 16 06:17:27 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Mar 16 13:25:44 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <4B9F7435.2070507@real.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com> <4B9F16BF.5000803@real.com>
<4B9F7435.2070507@real.com>
Message-ID: <4B9F92F7.4@real.com>
Sheldon,
The point is that before my change, the atomizer didn't know the file
size. The parsing advancing logic was:
read 4-byte to get atom size
seek to the end of current atom for next atom
read 4-byte to get current atom size
....
We always ended up doing a Seek(SEEK_SET, filesize) followed by Read(4)
that would fails.
Qiang
On 3/16/2010 5:06 AM, Xiaodong (Sheldon) Fu wrote:
> Right. I remember your CR. What I don't understand is why "In the
> attempt to get to the next atom, we ended up seeking over the last
> atom(usually the "mdat" atom) to the end of file. ". Each atom has a
> size field (unless for the special case of 'spanning to the end' atom).
> Did you actually see for some clip that at some point we actually issue
> a SEEK beyond the file size (not a SEEK_END, but a SEEK_SET with an
> offset beyond file size)? If so, that seems to be wrong.
>
> fxd
>
> Qiang Luo wrote:
>
>> Sheldon,
>>
>> Here is some background info. Both this fix and the change in r1.25 was
>> related to my previous change of passing ulFileSize to the Atomize()
>> function.
>>
>> The mp4 header parsing code, the CAtomizer, walks through all atoms
>> until certain conditions are met: the offset for the next atom is out
>> of range or the next atom read returns an error. In the initial
>> implementation, we did not set the atom offset range limit. In the
>> attempt to get to the next atom, we ended up seeking over the last
>> atom(usually the "mdat" atom) to the end of file. While this may not be
>> an issue for local playback, for http streaming, it forces byte-range
>> seek with network re-connect, disrupting normal downloading data flow,
>> or even worse, making the client wait long time to download the entire
>> track if the seek size is under byte-range-seek threshold.
>>
>> My Atomize() change was an attempt to fix the mp4 http streaming slow
>> start issue. The basic idea was to limit the atomizer offset range to
>> be within the actual file size if the filesystem supports IHXFileStat.
>>
>> We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
>> checks in the code for m_ullCurrentOffset that will never get hit
>> because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
>> end of atom parsing, the m_ullCurrentOffset could be arbitrary, without
>> triggering the checks. My change of passing file size to the
>> m_pAtomizer->Atomize() activated those "dead" checks. Some of the
>> checks appeared to be too strict, triggering false detection.
>>
>> As you implied, the better fix might be figuring out what value
>> m_ullCurrentOffset should be after atom parsing in normal situation, and
>> fixing the m_ullCurrentOffset advancing logic. I agree that if we make
>> this change in Saleem's diff , we should also take out my change in r1.25.
>>
>> Qiang
>>
>> On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
>>
>>
>>> This nullifies the last change right above this code block (on Head,
>>> revision 1.25 made in 10/2009), if we are going to go with this, we need
>>> to take out the change r1.25 too.
>>>
>>> It seems that both 1.25 and this is not fixing the root problem(s). Do
>>> you have details why in the DRM file case, CurrentOffset ends up smaller
>>> than FinalOffset after the parsing finishes? And for the issue that
>>> r1.25 tries to fix, why CurrentOffset can end up bigger than
>>> FinalOffset(which is the file size)? If our parsing logic can advance
>>> the CurrentOffset beyond the file size for a well-formed mp4 file,
>>> likely somewhere some logic is not right and may cause other problems.
>>>
>>> fxd
>>>
>>> saleem.adookkattil@nokia.com wrote:
>>>
>>>
>>>
>>>> "Nokia submits this code under the terms of a commercial contribution
>>>> agreement with Real Networks, and I am authorized to contribute this
>>>> code under said agreement."
>>>>
>>>> Modified by: saleem.adookkattil@nokia.com
>>>>
>>>> Reviewed by:
>>>>
>>>> Date: 03/15/2010
>>>>
>>>> Project: symbian_client_apps
>>>>
>>>> ErrorId: JLIU-83KSEU
>>>>
>>>> Synopsis: DRM protected 3gp file parsing failure.
>>>>
>>>> Overview:
>>>>
>>>> DRM protected 3gp file parsing is failing due to a change in MP4 file
>>>> format project (qtffplin.cpp) made recently.
>>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>>> m_pAtomizer->Atomize(0, m_ulFileSize);
>>>> When we pass the file size as the second parameter, DRM file parsing
>>>> is failing in void CompleteAtomization(HX_RESULT status) method of
>>>> CAtomizer with error code HXR_CORRUPT_FILE.
>>>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>>>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in
>>>> the diff to fix the error.
>>>>
>>>> Files modified:
>>>>
>>>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>>>
>>>> Files added:
>>>>
>>>> Image Size and Heap Use impact: None.
>>>>
>>>> Module Release testing (STIF) : Yes
>>>>
>>>> Test case(s) Added : No
>>>>
>>>> Memory leak check performed : Yes
>>>>
>>>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>>>
>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>
>>>> Branch: 4_2_0_brizo, HEAD
>>>>
>>>> Index: atomizer.cpp
>>>> ===================================================================
>>>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>>>> retrieving revision 1.23.4.2
>>>> diff -u -w -r1.23.4.2 atomizer.cpp
>>>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>>>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>>>> @@ -574,9 +574,7 @@
>>>> }
>>>>
>>>> // See if parsing fully completed
>>>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>>> - (m_pRoot != m_pCurrentRoot))
>>>> + if (m_pRoot != m_pCurrentRoot)
>>>> {
>>>> status = HXR_CORRUPT_FILE;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>> .
>>>
>>>
>>>
>>>
>> .
>>
>>
>>
> .
>
>
From sfu at real.com Tue Mar 16 06:18:14 2010
From: sfu at real.com (Sheldon Fu)
Date: Tue Mar 16 13:27:09 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901E1136B@NOK-EUMSG-02.mgdnok.nokia.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com> <4B9F16BF.5000803@real.com>
<4B9F7435.2070507@real.com>
<19113978AB61DA44AC317B211CF1C32A2901E1136B@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4B9F9326.1050203@real.com>
Sorry Saleem, Qiang and I was talking about the issue the last change
related to this (r.25 on head) tries to fix.
In your case, what is between 136659 and 136925 in the file then? ISO
base file format doesn't allow arbitrary (non-boxed) data in the file,
so that portion at the end of the file must be another box, if this is a
conforming file.
It may be a type that the current mp4 file format doesn't understand and
if so, we should have logic to parse it as a default/unknown box (this
is required by ISO file format spec) and still advance the current
offset to the end of the file, thus avoid triggering the CORRUPT_FILE
error condition.
fxd
saleem.adookkattil@nokia.com wrote:
> There is no seeking beyond file size. Last current offset value is 136659 and file size is 136925. Here is the log.
>
>
>>>> CAtomizer::CAtomizer successfully created m_file CAtomizer::Atomize size 136925, 0
>>>> CAtomizer::Atomize offset 0, 0
>>>> CAtomizer::Atomize m_ullFinalOffset 136925, 0
>>>> CAtomizer::SeekData ullOffset 0, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 8, 0
>>>> CAtomizer::ReadData ulSize 16
>>>> CAtomizer::ReadData m_ullCurrentOffset 24, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 32, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 40, 0
>>>> CAtomizer::ReadData ulSize 100
>>>> CAtomizer::ReadData m_ullCurrentOffset 140, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 148, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 156, 0
>>>> CAtomizer::ReadData ulSize 84
>>>> CAtomizer::ReadData m_ullCurrentOffset 240, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 248, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 256, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 280, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 288, 0
>>>> CAtomizer::ReadData ulSize 25
>>>> CAtomizer::ReadData m_ullCurrentOffset 313, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 321, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 329, 0
>>>> CAtomizer::SeekData ullOffset 341, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 349, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 357, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 377, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 385, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 393, 0
>>>> CAtomizer::ReadData ulSize 109
>>>> CAtomizer::ReadData m_ullCurrentOffset 502, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 510, 0
>>>> CAtomizer::ReadData ulSize 32
>>>> CAtomizer::ReadData m_ullCurrentOffset 542, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 550, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 570, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 578, 0
>>>> CAtomizer::ReadData ulSize 820
>>>> CAtomizer::ReadData m_ullCurrentOffset 1398, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 1406, 0
>>>> CAtomizer::ReadData ulSize 816
>>>> CAtomizer::ReadData m_ullCurrentOffset 2222, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2230, 0
>>>> CAtomizer::ReadData ulSize 12
>>>> CAtomizer::ReadData m_ullCurrentOffset 2242, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2250, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2258, 0
>>>> CAtomizer::ReadData ulSize 84
>>>> CAtomizer::ReadData m_ullCurrentOffset 2342, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2350, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2358, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 2382, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2390, 0
>>>> CAtomizer::ReadData ulSize 25
>>>> CAtomizer::ReadData m_ullCurrentOffset 2415, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2423, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2431, 0
>>>> CAtomizer::SeekData ullOffset 2439, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2447, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2455, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 2475, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2483, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2491, 0
>>>> CAtomizer::ReadData ulSize 61
>>>> CAtomizer::ReadData m_ullCurrentOffset 2552, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2560, 0
>>>> CAtomizer::ReadData ulSize 24
>>>> CAtomizer::ReadData m_ullCurrentOffset 2584, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2592, 0
>>>> CAtomizer::ReadData ulSize 20
>>>> CAtomizer::ReadData m_ullCurrentOffset 2612, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2620, 0
>>>> CAtomizer::ReadData ulSize 284
>>>> CAtomizer::ReadData m_ullCurrentOffset 2904, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 2912, 0
>>>> CAtomizer::ReadData ulSize 280
>>>> CAtomizer::ReadData m_ullCurrentOffset 3192, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 3200, 0
>>>> CAtomizer::SeekData ullOffset 136651, 0
>>>> CAtomizer::ReadData ulSize 8
>>>> CAtomizer::ReadData m_ullCurrentOffset 136659, 0
>>>> CAtomizer::CompleteAtomization m_ullCurrentOffset 136659, 0
>>>> CAtomizer::CompleteAtomization m_ullFinalOffset 136925, 0
>>>>
>
> -Saleem
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Tuesday, March 16, 2010 7:06 AM
> To: Qiang Luo
> Cc: Adookkattil Saleem (Nokia-D/Dallas); nokia-private-dev@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp file parsing failure.
>
> Right. I remember your CR. What I don't understand is why "In the attempt to get to the next atom, we ended up seeking over the last atom(usually the "mdat" atom) to the end of file. ". Each atom has a size field (unless for the special case of 'spanning to the end' atom).
> Did you actually see for some clip that at some point we actually issue a SEEK beyond the file size (not a SEEK_END, but a SEEK_SET with an offset beyond file size)? If so, that seems to be wrong.
>
> fxd
>
> Qiang Luo wrote:
>
>> Sheldon,
>>
>> Here is some background info. Both this fix and the change in r1.25
>> was related to my previous change of passing ulFileSize to the
>> Atomize() function.
>>
>> The mp4 header parsing code, the CAtomizer, walks through all atoms
>> until certain conditions are met: the offset for the next atom is out
>> of range or the next atom read returns an error. In the initial
>> implementation, we did not set the atom offset range limit. In the
>> attempt to get to the next atom, we ended up seeking over the last
>> atom(usually the "mdat" atom) to the end of file. While this may not
>> be an issue for local playback, for http streaming, it forces
>> byte-range seek with network re-connect, disrupting normal downloading
>> data flow, or even worse, making the client wait long time to download
>> the entire track if the seek size is under byte-range-seek threshold.
>>
>> My Atomize() change was an attempt to fix the mp4 http streaming slow
>> start issue. The basic idea was to limit the atomizer offset range to
>> be within the actual file size if the filesystem supports IHXFileStat.
>>
>> We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
>> checks in the code for m_ullCurrentOffset that will never get hit
>> because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
>> end of atom parsing, the m_ullCurrentOffset could be arbitrary,
>> without triggering the checks. My change of passing file size to the
>> m_pAtomizer->Atomize() activated those "dead" checks. Some of the
>> checks appeared to be too strict, triggering false detection.
>>
>> As you implied, the better fix might be figuring out what value
>> m_ullCurrentOffset should be after atom parsing in normal situation,
>> and fixing the m_ullCurrentOffset advancing logic. I agree that if we
>> make this change in Saleem's diff , we should also take out my change in r1.25.
>>
>> Qiang
>>
>> On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
>>
>>
>>> This nullifies the last change right above this code block (on Head,
>>> revision 1.25 made in 10/2009), if we are going to go with this, we
>>> need to take out the change r1.25 too.
>>>
>>> It seems that both 1.25 and this is not fixing the root problem(s).
>>> Do you have details why in the DRM file case, CurrentOffset ends up
>>> smaller than FinalOffset after the parsing finishes? And for the
>>> issue that
>>> r1.25 tries to fix, why CurrentOffset can end up bigger than
>>> FinalOffset(which is the file size)? If our parsing logic can advance
>>> the CurrentOffset beyond the file size for a well-formed mp4 file,
>>> likely somewhere some logic is not right and may cause other problems.
>>>
>>> fxd
>>>
>>> saleem.adookkattil@nokia.com wrote:
>>>
>>>
>>>
>>>> "Nokia submits this code under the terms of a commercial
>>>> contribution agreement with Real Networks, and I am authorized to
>>>> contribute this code under said agreement."
>>>>
>>>> Modified by: saleem.adookkattil@nokia.com
>>>>
>>>> Reviewed by:
>>>>
>>>> Date: 03/15/2010
>>>>
>>>> Project: symbian_client_apps
>>>>
>>>> ErrorId: JLIU-83KSEU
>>>>
>>>> Synopsis: DRM protected 3gp file parsing failure.
>>>>
>>>> Overview:
>>>>
>>>> DRM protected 3gp file parsing is failing due to a change in MP4
>>>> file format project (qtffplin.cpp) made recently.
>>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>>> m_pAtomizer->Atomize(0, m_ulFileSize); When we pass the file size as
>>>> the second parameter, DRM file parsing is failing in void
>>>> CompleteAtomization(HX_RESULT status) method of CAtomizer with error
>>>> code HXR_CORRUPT_FILE.
>>>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>>>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given
>>>> in the diff to fix the error.
>>>>
>>>> Files modified:
>>>>
>>>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>>>
>>>> Files added:
>>>>
>>>> Image Size and Heap Use impact: None.
>>>>
>>>> Module Release testing (STIF) : Yes
>>>>
>>>> Test case(s) Added : No
>>>>
>>>> Memory leak check performed : Yes
>>>>
>>>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>>>
>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>
>>>> Branch: 4_2_0_brizo, HEAD
>>>>
>>>> Index: atomizer.cpp
>>>> ===================================================================
>>>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>>>> retrieving revision 1.23.4.2
>>>> diff -u -w -r1.23.4.2 atomizer.cpp
>>>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>>>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>>>> @@ -574,9 +574,7 @@
>>>> }
>>>>
>>>> // See if parsing fully completed
>>>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>>> - (m_pRoot != m_pCurrentRoot))
>>>> + if (m_pRoot != m_pCurrentRoot)
>>>> {
>>>> status = HXR_CORRUPT_FILE;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>> .
>>>
>>>
>>>
>>>
>> .
>>
>>
>>
>
> .
>
>
From sfu at real.com Tue Mar 16 06:23:50 2010
From: sfu at real.com (Sheldon Fu)
Date: Tue Mar 16 13:32:51 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR:-DRM protected 3gp
file parsing failure.
In-Reply-To: <4B9F92F7.4@real.com>
References: <19113978AB61DA44AC317B211CF1C32A2901E10E26@NOK-EUMSG-02.mgdnok.nokia.com>
<4B9EC995.1090306@real.com> <4B9F16BF.5000803@real.com>
<4B9F7435.2070507@real.com> <4B9F92F7.4@real.com>
Message-ID: <4B9F9476.1060000@real.com>
That's a normal operation. It can not justify your r.1.25 change though:
+ if (m_ulFinalOffset != ATOMIZE_ALL)
+ {
+ m_ulCurrentOffset = m_ulCurrentOffset > m_ulFinalOffset ?
m_ulFinalOffset : m_ulCurrentOffset;
+ }
+
That logic is apparently trying to detect the condition that current
offset is strictly bigger than file size.
fxd
Qiang Luo wrote:
> Sheldon,
>
> The point is that before my change, the atomizer didn't know the file
> size. The parsing advancing logic was:
>
> read 4-byte to get atom size
> seek to the end of current atom for next atom
> read 4-byte to get current atom size
> ....
>
> We always ended up doing a Seek(SEEK_SET, filesize) followed by Read(4)
> that would fails.
>
> Qiang
>
> On 3/16/2010 5:06 AM, Xiaodong (Sheldon) Fu wrote:
>
>> Right. I remember your CR. What I don't understand is why "In the
>> attempt to get to the next atom, we ended up seeking over the last
>> atom(usually the "mdat" atom) to the end of file. ". Each atom has a
>> size field (unless for the special case of 'spanning to the end' atom).
>> Did you actually see for some clip that at some point we actually issue
>> a SEEK beyond the file size (not a SEEK_END, but a SEEK_SET with an
>> offset beyond file size)? If so, that seems to be wrong.
>>
>> fxd
>>
>> Qiang Luo wrote:
>>
>>
>>> Sheldon,
>>>
>>> Here is some background info. Both this fix and the change in r1.25 was
>>> related to my previous change of passing ulFileSize to the Atomize()
>>> function.
>>>
>>> The mp4 header parsing code, the CAtomizer, walks through all atoms
>>> until certain conditions are met: the offset for the next atom is out
>>> of range or the next atom read returns an error. In the initial
>>> implementation, we did not set the atom offset range limit. In the
>>> attempt to get to the next atom, we ended up seeking over the last
>>> atom(usually the "mdat" atom) to the end of file. While this may not be
>>> an issue for local playback, for http streaming, it forces byte-range
>>> seek with network re-connect, disrupting normal downloading data flow,
>>> or even worse, making the client wait long time to download the entire
>>> track if the seek size is under byte-range-seek threshold.
>>>
>>> My Atomize() change was an attempt to fix the mp4 http streaming slow
>>> start issue. The basic idea was to limit the atomizer offset range to
>>> be within the actual file size if the filesystem supports IHXFileStat.
>>>
>>> We used to use ATOMIZE_ALL, 0, as m_ullFinalOffset. There were "dead"
>>> checks in the code for m_ullCurrentOffset that will never get hit
>>> because m_ullFinalOffset was always ATOMIZE_ALL. Effectively, at the
>>> end of atom parsing, the m_ullCurrentOffset could be arbitrary, without
>>> triggering the checks. My change of passing file size to the
>>> m_pAtomizer->Atomize() activated those "dead" checks. Some of the
>>> checks appeared to be too strict, triggering false detection.
>>>
>>> As you implied, the better fix might be figuring out what value
>>> m_ullCurrentOffset should be after atom parsing in normal situation, and
>>> fixing the m_ullCurrentOffset advancing logic. I agree that if we make
>>> this change in Saleem's diff , we should also take out my change in r1.25.
>>>
>>> Qiang
>>>
>>> On 3/15/2010 4:58 PM, Xiaodong (Sheldon) Fu wrote:
>>>
>>>
>>>
>>>> This nullifies the last change right above this code block (on Head,
>>>> revision 1.25 made in 10/2009), if we are going to go with this, we need
>>>> to take out the change r1.25 too.
>>>>
>>>> It seems that both 1.25 and this is not fixing the root problem(s). Do
>>>> you have details why in the DRM file case, CurrentOffset ends up smaller
>>>> than FinalOffset after the parsing finishes? And for the issue that
>>>> r1.25 tries to fix, why CurrentOffset can end up bigger than
>>>> FinalOffset(which is the file size)? If our parsing logic can advance
>>>> the CurrentOffset beyond the file size for a well-formed mp4 file,
>>>> likely somewhere some logic is not right and may cause other problems.
>>>>
>>>> fxd
>>>>
>>>> saleem.adookkattil@nokia.com wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> "Nokia submits this code under the terms of a commercial contribution
>>>>> agreement with Real Networks, and I am authorized to contribute this
>>>>> code under said agreement."
>>>>>
>>>>> Modified by: saleem.adookkattil@nokia.com
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Date: 03/15/2010
>>>>>
>>>>> Project: symbian_client_apps
>>>>>
>>>>> ErrorId: JLIU-83KSEU
>>>>>
>>>>> Synopsis: DRM protected 3gp file parsing failure.
>>>>>
>>>>> Overview:
>>>>>
>>>>> DRM protected 3gp file parsing is failing due to a change in MP4 file
>>>>> format project (qtffplin.cpp) made recently.
>>>>> Function call retVal = m_pAtomizer->Atomize(); changed to retVal =
>>>>> m_pAtomizer->Atomize(0, m_ulFileSize);
>>>>> When we pass the file size as the second parameter, DRM file parsing
>>>>> is failing in void CompleteAtomization(HX_RESULT status) method of
>>>>> CAtomizer with error code HXR_CORRUPT_FILE.
>>>>> Removed the condition (m_ullFinalOffset != ATOMIZE_ALL)&&
>>>>> (m_ullFinalOffset != m_ullCurrentOffset) from IF statement as given in
>>>>> the diff to fix the error.
>>>>>
>>>>> Files modified:
>>>>>
>>>>> cvsroot\datatype\mp4\fileformat\atomizer.cpp
>>>>>
>>>>> Files added:
>>>>>
>>>>> Image Size and Heap Use impact: None.
>>>>>
>>>>> Module Release testing (STIF) : Yes
>>>>>
>>>>> Test case(s) Added : No
>>>>>
>>>>> Memory leak check performed : Yes
>>>>>
>>>>> Platforms and Profiles Build Verified: helix-client-symbian-4
>>>>>
>>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>>
>>>>> Branch: 4_2_0_brizo, HEAD
>>>>>
>>>>> Index: atomizer.cpp
>>>>> ===================================================================
>>>>> RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
>>>>> retrieving revision 1.23.4.2
>>>>> diff -u -w -r1.23.4.2 atomizer.cpp
>>>>> --- atomizer.cpp 23 Dec 2009 22:41:02 -0000 1.23.4.2
>>>>> +++ atomizer.cpp 15 Mar 2010 00:57:06 -0000
>>>>> @@ -574,9 +574,7 @@
>>>>> }
>>>>>
>>>>> // See if parsing fully completed
>>>>> - if (((m_ullFinalOffset != ATOMIZE_ALL)&&
>>>>> - (m_ullFinalOffset != m_ullCurrentOffset)) ||
>>>>> - (m_pRoot != m_pCurrentRoot))
>>>>> + if (m_pRoot != m_pCurrentRoot)
>>>>> {
>>>>> status = HXR_CORRUPT_FILE;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Datatype-dev mailing list
>>>> Datatype-dev@helixcommunity.org
>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>> .
>>>>
>>>>
>>>>
>>>>
>>>>
>>> .
>>>
>>>
>>>
>>>
>> .
>>
>>
>>
>
> .
>
>
From saleem.adookkattil at nokia.com Wed Mar 17 07:21:32 2010
From: saleem.adookkattil at nokia.com (saleem.adookkattil@nokia.com)
Date: Wed Mar 17 14:33:48 2010
Subject: [datatype-dev] CR:- Thumbnail/Metadata engine cleanup and crash fix.
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901A079CE@NOK-EUMSG-02.mgdnok.nokia.com>
References: <19113978AB61DA44AC317B211CF1C32A2901A079CE@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <19113978AB61DA44AC317B211CF1C32A2901E92774@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: metadataengbase.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/metadataengbase.cpp,v
retrieving revision 1.6.14.1
diff -u -w -r1.6.14.1 metadataengbase.cpp
--- metadataengbase.cpp 9 Mar 2010 16:43:09 -0000 1.6.14.1
+++ metadataengbase.cpp 17 Mar 2010 15:08:33 -0000
@@ -180,7 +180,7 @@
if (self)
{
- if( self->Initialize(TRUE) != HXR_OK) // TRUE = MetaData instance FALSE = thumbnail instance
+ if( self->Initialize() != HXR_OK)
{
HX_DELETE(self);
}
@@ -193,21 +193,12 @@
// setup preferences.
// Create DT Driver and initialize it.
-HX_RESULT CHXMetaDataEngBase::Initialize(HXBOOL bIsMetaData)
+HX_RESULT CHXMetaDataEngBase::Initialize()
{
- MD_LOG("CHXMetaDataEngBase::Initialize bIsMetaData %d\n", bIsMetaData);
+ MD_LOG("CHXMetaDataEngBase::Initialize\n");
HX_RESULT hxr;
-
- hxr = SetupGlobals(bIsMetaData);
- if (hxr == KErrNotReady)
- return hxr;
-
- if (SUCCEEDED(hxr))
- {
hxr = SetupPreferences();
- }
-
// create the DTDriver.
if (SUCCEEDED(hxr))
{
-------------- next part --------------
Index: metadataengbase.h
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/pub/metadataengbase.h,v
retrieving revision 1.6.14.1
diff -u -w -r1.6.14.1 metadataengbase.h
--- metadataengbase.h 9 Mar 2010 16:42:50 -0000 1.6.14.1
+++ metadataengbase.h 17 Mar 2010 15:08:20 -0000
@@ -159,7 +159,7 @@
STDMETHOD_(void, DoDestroy)(THIS);
// functions must be implemented in the derived engines.
- STDMETHOD_(HX_RESULT, SetupGlobals)(THIS_ HXBOOL bIsMetaData) PURE; // Specifies whether the instance belongs to MetaData or Thumbnail
+ STDMETHOD_(HX_RESULT, SetupGlobals)(THIS) PURE;
STDMETHOD_(HX_RESULT, SetupPreferences)(THIS) PURE;
STDMETHOD_(void, GetDefaultOptions)(THIS_ IHXValues* pOptions) PURE;
STDMETHOD_(CHXMetaDataEntry*, CreateMetaDataEntry)
@@ -174,7 +174,7 @@
STDMETHOD_(void, DeleteMetaDataEntry)
(THIS_ CHXMetaDataEntry *pEntry) PURE;
- HX_RESULT Initialize(HXBOOL bForceSyncReading = FALSE);
+ HX_RESULT Initialize();
private:
-------------- next part --------------
Index: symbian_metadataeng.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp,v
retrieving revision 1.12.4.6
diff -u -w -r1.12.4.6 symbian_metadataeng.cpp
--- symbian_metadataeng.cpp 9 Mar 2010 17:12:10 -0000 1.12.4.6
+++ symbian_metadataeng.cpp 17 Mar 2010 15:09:03 -0000
@@ -63,7 +63,10 @@
#include "hxmetadatalog.h"
#include "hxmedpltfmloader.h"
#include "hxtlogutil.h"
-#include "symbian_tlc_context.h"
+
+#include "symbian_dll_map_inst.h"
+#include "symbian_dll_map.h"
+
#include "hxprefutil.h" // ReadPrefCSTRING( )
static const int KMinMetaDataStartupMemory = 512*1024;
@@ -71,15 +74,11 @@
_LIT(KFileScheme, "file://");
const char * const METADATA_DUMMYFILE_NAME = "c:\\dummy.3gp";
-#include "symbian_dll_map_inst.h"
-#include "symbian_dll_map.h"
-
#define DESTOSTR(x) (CHXSymbianString::DescToString(x))
#define CHXAV_MMFControllerVersion "MMFControllerVersion" // key preference in config file
void GetInstallDrive(CHXString &strDrive)
{
-
// Default value
strDrive = DESTOSTR(KHXDefaultInstallDrive);
@@ -89,26 +88,26 @@
strDrive = DESTOSTR(ff.Left(1));
strDrive = strDrive + ":\\";
#endif
-
}
void destroyDLLMap(void* pObj)
{
SymbianDLLMapImp* pDLLMap = reinterpret_cast(pObj);
- delete pDLLMap;
+ HX_DELETE(pDLLMap);
}
-
static HXBOOL IsProtected(IHXMMFDataSource &aMediaSource)
{
INT32 value = 0;
HX_RESULT hxr = aMediaSource.GetAttribute(ContentAccess::EIsProtected, value);
if (hxr == HXR_OK && value == 1)
{
+ MD_LOG("CHXSymbianMetaDataEng::IsProtected : Yes \n");
return TRUE;
}
else
{
+ MD_LOG("CHXSymbianMetaDataEng::IsProtected : No \n");
return FALSE;
}
}
@@ -119,10 +118,12 @@
HX_RESULT hxr = aMediaSource.GetAttribute(ContentAccess::ECanPlay, value);
if (hxr == HXR_OK && value == 1)
{
+ MD_LOG("CHXSymbianMetaDataEng::CanPlay : Yes \n");
return TRUE;
}
else
{
+ MD_LOG("CHXSymbianMetaDataEng::CanPlay : No \n");
return FALSE;
}
}
@@ -145,7 +146,6 @@
// Symbian MetaData Engine
UINT32 CHXSymbianMetaDataEng::GetCurrentFreeRAM()
{
-
TMemoryInfoV1Buf info;
UserHal::MemoryInfo(info);
return info().iFreeRamInBytes;
@@ -157,6 +157,13 @@
if (GetCurrentFreeRAM() > KMinMetaDataStartupMemory)
{
self = new CHXSymbianMetaDataEng();
+ if (self)
+ {
+ if( FAILED(self->SetupGlobals()))
+ {
+ HX_DELETE(self);
+ }
+ }
}
return self;
}
@@ -166,9 +173,8 @@
,m_pDataSource(NULL)
,m_bProtectedAndCantPlay(FALSE)
,m_bDCFHeadersNeeded(TRUE)
- ,m_pSymTLCContext(NULL)
{
- m_bGlMgrTaken = FALSE;
+ m_bDestroyed = TRUE;
}
CHXSymbianMetaDataEng::~CHXSymbianMetaDataEng()
@@ -286,10 +292,7 @@
if (aMediaSource.m_pData)
{
HX_RELEASE(m_pDataSource);
- m_pDataSource = CHXDataSourceFactory::Build(aMediaSource, TRUE /* bPeek */, TRUE /* bForceSyncReading */);
-
- MD_LOG("CHXSymbianMetaDataEng::OpenSource m_pDataSource=%p\n", m_pDataSource);
-
+ m_pDataSource = CHXDataSourceFactory::Build(aMediaSource, TRUE /* bPeek */);
if (m_pDataSource)
{
HX_ADDREF(m_pDataSource);
@@ -312,10 +315,13 @@
{
hxr = DoOpenSource(METADATA_DUMMYFILE_NAME);
}
+ HX_RELEASE(m_pDataSource);
}
}
}
+ MD_LOG("CHXSymbianMetaDataEng::OpenSource hxr=%d\n", hxr);
+
return hxr;
}
@@ -330,7 +336,6 @@
m_LastError = HXR_OK;
m_bProtectedAndCantPlay = IsProtected(*m_pDataSource) && (!CanPlay(*m_pDataSource));
-
if (m_bProtectedAndCantPlay)
{
// Media data is protected and it can't be played.
@@ -372,25 +377,17 @@
// Creates the root configuration file if doesn't exits.
HX_RESULT CHXSymbianMetaDataEng::CheckRootConfigFile()
-
{
- TInt err = KErrNone;
HX_RESULT hxr = HXR_FAIL;
- RFs fsSession;
- RFile rfile;
CHXString strConfigFilePath, sProductName;
-
hxr = GetProperty(MHXEngineProperties::EConfigFilePath, strConfigFilePath);
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
- hxr = GetProperty(MHXEngineProperties::EProductName,
- sProductName);
+ hxr = GetProperty(MHXEngineProperties::EProductName, sProductName);
}
-
-
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
CHXString sPath;
sPath.Format("%s\\%s_%u_%u.cfg", (const char *)strConfigFilePath,
@@ -398,17 +395,22 @@
CONFIGFILE_MAJOR_VERSION,
CONFIGFILE_MINOR_VERSION);
- TBuf<256> filePath;
+ hxr = HXR_FAIL;
+ TInt err = KErrNone;
+ RFs fsSession;
+ err = fsSession.Connect();
+ if (err == KErrNone)
+ {
+ TBuf<256> filePath;
CHXSymbianString::StringToDes(sPath, filePath);
- fsSession.Connect();
-
- err = rfile.Open(fsSession, filePath, EFileStreamText
- |EFileRead);
+ RFile rfile;
+ err = rfile.Open(fsSession, filePath, EFileStreamText|EFileRead);
if ( err == KErrNone)
{
rfile.Close();
+ hxr = HXR_OK;
}
else
{
@@ -417,24 +419,25 @@
// Dir does not exits, create it
// File name omiitted, so its ok to pass
// complete filepath
- fsSession.MkDirAll(filePath);
- err = KErrNotFound;
+ err = fsSession.MkDirAll(filePath);
}
- if (err == KErrNotFound)
+ if (err == KErrNone || err == KErrNotFound)
{
- err = rfile.Create(fsSession, filePath, EFileStreamText
- |EFileWrite);
- }
- }
-
+ err = rfile.Create(fsSession, filePath, EFileStreamText|EFileWrite);
if (err == KErrNone)
{
+ rfile.Close();
hxr = HXR_OK;
}
}
-
+ }
fsSession.Close();
+ }
+ }
+
+ MD_LOG("CHXSymbianMetaDataEng::CheckRootConfigFile hxr=%d\n", hxr);
+
return hxr;
}
@@ -445,29 +448,10 @@
// creates dll map.
// sets dllaccess paths.
-HX_RESULT CHXSymbianMetaDataEng::SetupGlobals(HXBOOL bIsMetaData)
-{
-
- HX_RESULT hxr;
-
- if (bIsMetaData)
- {
- if (HXGlobalManInstance::GetInstance())
+HX_RESULT CHXSymbianMetaDataEng::SetupGlobals()
{
- MD_LOG("SetupGlobals EXIT");
- m_bGlMgrTaken = TRUE;
- return KErrNotReady;
- }
- }
-
- GetInstallDrive(m_strInstallDrive);
-
- MD_LOG("CHXSymbianMetaDataEng::SetupGlobals InstallDrive=%s\n",
- ((const char*) m_strInstallDrive));
-
- hxr = CheckRootConfigFile();
-
- if (SUCCEEDED(hxr))
+ HX_RESULT hxr = HXR_OUTOFMEMORY;
+ if (!HXGlobalManInstance::GetInstance())
{
HXGlobalManager* pGM = new HXGlobalManagerImp();
if (pGM)
@@ -475,84 +459,80 @@
HXGlobalManInstance::SetInstance(pGM);
// create the global dll map for symbian.
-
SymbianDLLMapImp *pDLLMap = new SymbianDLLMapImp;
if (pDLLMap)
{
HXSymbianDLLMapInstance::SetInstance(pDLLMap, &destroyDLLMap);
+ m_bDestroyed = FALSE;
+ hxr = HXR_OK;
}
else
{
- hxr = HXR_OUTOFMEMORY;
+ HX_DELETE(pGM);
+ HXGlobalManInstance::SetInstance(0);
}
}
- else
- {
- hxr = HXR_OUTOFMEMORY;
+ }
+ return hxr;
}
- // enable Helix DNA access paths at global scope.
+// creates a pref object and opens it.
+// plugin dll file name and plugin archive file names are set
+// initailizes mediaplatform.
+
+HX_RESULT CHXSymbianMetaDataEng::SetupPreferences()
+{
+ HX_RESULT hxr = CheckRootConfigFile();
+ if (SUCCEEDED(hxr))
+ {
CHXString strDllPath;
hxr = GetProperty(MHXEngineProperties::EDllDir, strDllPath);
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
GetDLLAccessPath()->SetPath(DLLTYPE_PLUGIN, strDllPath);
GetDLLAccessPath()->SetPath(DLLTYPE_CODEC, strDllPath);
}
-
- }
-
- MD_LOG("CHXSymbianMetaDataEng::SetupGlobals hxr=%d\n", hxr);
- return hxr;
}
-// creates a pref object and opens it.
-// plugin dll file name and plugin archive file names are set.
-
-HX_RESULT CHXSymbianMetaDataEng::SetupPreferences()
-{
- HX_RESULT hxr = HXR_OK;
-
+ CHXString temp;
CHXString strRootFilePath;
CHXString strShadowFilePath;
-
-
- hxr = GetProperty(MHXEngineProperties::EConfigFilePath, strRootFilePath);
-
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
- CHXString temp;
- hxr = GetProperty(MHXEngineProperties::EShadowFilePath, temp);
- if (hxr == HXR_OK)
+ HX_RESULT hxr = GetProperty(MHXEngineProperties::EConfigFilePath, strRootFilePath);
+ if (SUCCEEDED(hxr))
{
- strShadowFilePath = m_strInstallDrive + temp;
+ hxr = GetProperty(MHXEngineProperties::EShadowFilePath, temp);
}
}
if (SUCCEEDED(hxr))
{
+ CHXString strInstallDrive;
+ GetInstallDrive(strInstallDrive);
+ strShadowFilePath = strInstallDrive + temp;
+
+ MD_LOG("CHXSymbianMetaDataEng::SetupGlobals InstallDrive=%s\n", ((const char*) strInstallDrive));
+
m_pPrefs = new CHXLitePrefs(strRootFilePath, strShadowFilePath);
if (m_pPrefs)
{
HX_ADDREF(m_pPrefs);
CHXString sCompanyName, sProductName;
-
hxr = GetProperty(MHXEngineProperties::ECompanyName, sCompanyName);
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
hxr = GetProperty(MHXEngineProperties::EProductName, sProductName);
}
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
- hxr = m_pPrefs->Open(sCompanyName, sProductName,
- CONFIGFILE_MAJOR_VERSION, CONFIGFILE_MINOR_VERSION);
+ hxr = m_pPrefs->Open(sCompanyName, sProductName, CONFIGFILE_MAJOR_VERSION, CONFIGFILE_MINOR_VERSION);
}
- MD_LOG("CHXSymbianMetaDataEng::SetupPreferences Opening Pref "
- "hxr=%d\n", hxr);
+ MD_LOG("CHXSymbianMetaDataEng::SetupPreferences Opening Pref hxr=%d\n", hxr);
}
else
{
@@ -563,88 +543,55 @@
if (SUCCEEDED(hxr))
{
hxr = CreateMediaPlatform();
+ }
if (SUCCEEDED(hxr))
{
- m_pPrefs->RegisterContext(m_pMediaPlatform);
- m_pMediaPlatform->QueryInterface(IID_IHXCommonClassFactory, (void**) &m_pCCF);
-
- // once open the config file, verify if the MMFControllerVersion has changed
- //get MMFControllerVersion from platform.h
- CHXString strMmfControllerVerCur = TARVER_STR_PLATFORM;
-
- // get MMFControllerVersion from cfg file
- //cfg file could be HXMDEngine_3_2.cfg or HXTNEngine_3_2.cfg, It depends on which file we are working on
- CHXString strMmfControllerVerOld;
- hxr = ReadPrefCSTRING( m_pPrefs, CHXAV_MMFControllerVersion, strMmfControllerVerOld );
+ hxr = m_pPrefs->RegisterContext(m_pMediaPlatform);
+ }
- if( !SUCCEEDED(hxr) )
+ if (SUCCEEDED(hxr))
{
- // MMFControllerVersion does not exist in cfg file ... add MMFControllerVersion and delete files
- CreatePrefIfNoExist( CHXAV_MMFControllerVersion,strMmfControllerVerCur );
- TRAPD( err, DeleteFilesL() );
+ hxr = m_pMediaPlatform->QueryInterface(IID_IHXCommonClassFactory, (void**) &m_pCCF);
}
- else
- {
- //MMFControllerVersion exists in cfg file ..... compare MMFControllerVersion from cfg VS MMFControllerVersion from platform.h
- if ( strMmfControllerVerCur != strMmfControllerVerOld )
- {
- // MMFControllerVersions are diferent then delete files and replace in cfg the value of MMFControllerVersion with the new value
- TRAPD( err, DeleteFilesL() );
- IHXBuffer* pBuffer = NULL;
- if( m_pCCF->CreateInstance(CLSID_IHXBuffer, (void**)&pBuffer) == HXR_OK )
+ if (SUCCEEDED(hxr))
{
- pBuffer->Set( (const unsigned char*)(const char*)strMmfControllerVerCur, strlen(strMmfControllerVerCur) + 1 );
- m_pPrefs->WritePref( CHXAV_MMFControllerVersion, pBuffer );
- }
- HX_RELEASE( pBuffer );
- }
- }
+ //UpdateConfigVersion();
+
// set plugin archieve file name
CHXString strPluginArchiveFileName;
-
hxr = GetProperty(MHXEngineProperties::EPluginArchiveName, strPluginArchiveFileName);
-
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
CHXString preference("PluginArchiveFileName");
CHXSymbianString::PrefixNameSpace(preference);
CreatePrefIfNoExist(preference, strPluginArchiveFileName);
}
+ }
// set the dll name file path. Plugin Manager needs it to load the dlls.
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
CHXString strPluginDLLFileName;
hxr = GetProperty(MHXEngineProperties::EDLLNamePath, strPluginDLLFileName);
- if (hxr == HXR_OK)
+ if (SUCCEEDED(hxr))
{
CHXString preference("PluginDLLFileName");
CHXSymbianString::PrefixNameSpace(preference);
CreatePrefIfNoExist(preference, strPluginDLLFileName);
- }
- }
// metadata engine shouldn't use the system recognizer.
CreatePrefIfNoExist("DisableSystemRecognizer", "1");
- m_pSymTLCContext = new SymbianTLCContext();
+ // Default logging flag
+ CreatePrefIfNoExist("Logging\\File\\Enabled", "0");
- if (m_pSymTLCContext)
- {
- HX_ADDREF(m_pSymTLCContext);
-
- // pass pref and external context
- // external context is used for initializing log system and observer.
- // External context becomes ready only after Media platform init
- m_pSymTLCContext->Init(m_pPrefs, (IUnknown*) m_pMediaPlatform);
- m_pSymTLCContext->InitializeLogging();
- hxr = m_pMediaPlatform->Init(m_pSymTLCContext);
- }
- else
+ // Initialize mediaplatform with created preference as external context
+ hxr = m_pMediaPlatform->Init((IUnknown*)(IHXPreferences*)m_pPrefs);
+ if (SUCCEEDED(hxr))
{
- hxr = HXR_OUTOFMEMORY;
+ HX_ENABLE_LOGGING(m_pMediaPlatform);
}
}
}
@@ -653,38 +600,26 @@
return hxr;
}
-
// cleanup routine.
// calls base class cleanup routine.
void CHXSymbianMetaDataEng::DoDestroy()
{
- if (m_bDestroyed)
+ if (!m_bDestroyed)
{
- return;
- }
-
MD_LOG("CHXSymbianMetaDataEng::DoDestroy\n");
CHXMetaDataEngBase::DoDestroy();
-
HX_RELEASE(m_pPrefs);
- HX_RELEASE(m_pDataSource);
HX_RELEASE(m_pCCF);
-
+ HX_DISABLE_LOGGING();
HX_RELEASE(m_pMediaPlatform);
- m_pSymTLCContext->CloseExternalContext();
-
HXMediaPlatformClose();
HXUnloadMediaPlatform();
- HX_RELEASE(m_pSymTLCContext);
-
- HXGlobalManagerImp* pGM = static_cast
- ( HXGlobalManInstance::GetInstance() );
-
- if(pGM != NULL && !m_bGlMgrTaken)
+ HXGlobalManagerImp* pGM = static_cast( HXGlobalManInstance::GetInstance() );
+ if(pGM != NULL)
{
pGM->Shutdown();
HX_DELETE(pGM);
@@ -696,43 +631,45 @@
#endif
m_bDestroyed = TRUE;
}
+}
-STDMETHODIMP CHXSymbianMetaDataEng::GetUserContext(
- REF(IUnknown*) pIUnknownCurrentContext)
+STDMETHODIMP CHXSymbianMetaDataEng::GetUserContext(REF(IUnknown*) pIUnknownCurrentContext)
{
-
+ MD_LOG("CHXSymbianMetaDataEng::GetUserContext hxr=%d\n", HXR_FAIL);
return HXR_FAIL;
}
-STDMETHODIMP CHXSymbianMetaDataEng::SetUserContext(
- IUnknown* pIUnknownCurrentContext)
+STDMETHODIMP CHXSymbianMetaDataEng::SetUserContext(IUnknown* pIUnknownCurrentContext)
{
-
+ MD_LOG("CHXSymbianMetaDataEng::SetUserContext hxr=%d\n", HXR_FAIL);
return HXR_FAIL;
}
// data source is returned as the requester.
-STDMETHODIMP CHXSymbianMetaDataEng::GetRequester(
- REF(IUnknown*) pIUnknownNewRequester)
+STDMETHODIMP CHXSymbianMetaDataEng::GetRequester( REF(IUnknown*) pIUnknownNewRequester)
{
+ HX_RESULT hxr = HXR_FAIL;
pIUnknownNewRequester = (IUnknown*) (IHXMMFDataSource*) m_pDataSource;
if (pIUnknownNewRequester)
{
HX_ADDREF(pIUnknownNewRequester);
- return HXR_OK;
+ hxr = HXR_OK;
}
- return HXR_FAIL;
+
+ MD_LOG("CHXSymbianMetaDataEng::GetRequester hxr=%d\n", hxr);
+
+ return hxr;
}
-STDMETHODIMP CHXSymbianMetaDataEng::SetRequester(
- IUnknown* pIUnknownNewRequester)
+STDMETHODIMP CHXSymbianMetaDataEng::SetRequester(IUnknown* pIUnknownNewRequester)
{
// request object is created internally.
// don't allow the request object to be changed
// from outside.
+ MD_LOG("CHXSymbianMetaDataEng::SetRequester hxr=%d\n", HXR_FAIL);
return HXR_FAIL;
}
@@ -776,7 +713,6 @@
HX_RESULT CHXSymbianMetaDataEng::GetDCFHeaders()
{
-
MD_LOG("CHXSymbianMetaDataEng::GetDCFHeaders\n");
m_MetaDataList.SetSize(0, 8); // current number of elements 0, growsize 8
@@ -840,12 +776,12 @@
void CHXSymbianMetaDataEng::DeleteMetaDataEntry(CHXMetaDataEntry *pEntry)
{
- delete pEntry->m_pVal;
- delete pEntry;
+ if (pEntry)
+ {
+ HX_DELETE(pEntry->m_pVal);
+ HX_DELETE(pEntry);
+ }
}
-
-
-// default options. These are passed to FFDriver.
void CHXSymbianMetaDataEng::GetDefaultOptions(IHXValues* pOptions)
{
@@ -913,25 +849,28 @@
//setup and create media platform
HX_RESULT CHXSymbianMetaDataEng::CreateMediaPlatform()
{
- HX_RESULT rv;
+ HX_RESULT hxr;
CHXString strLibPath;
- //_LIT(KHXMMFDllDir, "\\sys\\bin");
- //GetPropertyL(MHXControllerProperties::EMMFDllDir, strLibPath);
strLibPath = "\\sys\\bin";
-
- rv = HXLoadMediaPlatform(strLibPath);
-
- if(SUCCEEDED(rv))
+ hxr = HXLoadMediaPlatform(strLibPath);
+ if(SUCCEEDED(hxr))
{
- rv = HXMediaPlatformOpen();
+ hxr = HXMediaPlatformOpen();
+ }
- rv = HXCreateMediaPlatform((IHXMediaPlatform**)&m_pMediaPlatform);
+ if(SUCCEEDED(hxr))
+ {
+ hxr = HXCreateMediaPlatform((IHXMediaPlatform**)&m_pMediaPlatform);
+ }
- if(m_pMediaPlatform != NULL)
+ if(SUCCEEDED(hxr))
{
- rv = m_pMediaPlatform->AddPluginPath("HelixSDK", (const char*) strLibPath);
+ hxr= m_pMediaPlatform->AddPluginPath("HelixSDK", (const char*) strLibPath);
+ }
+ if(SUCCEEDED(hxr))
+ {
// set dll search path
CHXString strAccessPath;
AddAccessPath(strAccessPath, "DT_Common", strLibPath);
@@ -947,15 +886,49 @@
strAccessPath.SetAt(idx, '\0');
}
}
-
SetDLLAccessPath(strAccessPath);
-
} // End of if(m_pMediaPlatform != NULL)
+ MD_LOG("CHXSymbianMetaDataEng::CreateMediaPlatform hxr=%d\n", hxr);
+ return hxr;
}
+/*
+HX_RESULT CHXSymbianMetaDataEng::UpdateConfigVersion()
+{
+ // once open the config file, verify if the MMFControllerVersion has changed
+ //get MMFControllerVersion from platform.h
+ CHXString strMmfControllerVerCur = TARVER_STR_PLATFORM;
- return rv;
+ // get MMFControllerVersion from cfg file
+ //cfg file could be HXMDEngine_3_2.cfg or HXTNEngine_3_2.cfg, It depends on which file we are working on
+ CHXString strMmfControllerVerOld;
+ HX_RESULT hxr = ReadPrefCSTRING( m_pPrefs, CHXAV_MMFControllerVersion, strMmfControllerVerOld );
+ if( SUCCEEDED(hxr) )
+ {
+ //MMFControllerVersion exists in cfg file ..... compare MMFControllerVersion from cfg VS MMFControllerVersion from platform.h
+ if ( strMmfControllerVerCur != strMmfControllerVerOld )
+ {
+ // MMFControllerVersions are diferent then delete files and replace in cfg the value of MMFControllerVersion with the new value
+ TRAPD( err, DeleteFilesL() );
+
+ IHXBuffer* pBuffer = NULL;
+ hxr = m_pCCF->CreateInstance(CLSID_IHXBuffer, (void**)&pBuffer);
+ if( SUCCEEDED(hxr) )
+ {
+ pBuffer->Set( (const unsigned char*)(const char*)strMmfControllerVerCur, strlen(strMmfControllerVerCur) + 1 );
+ hxr = m_pPrefs->WritePref( CHXAV_MMFControllerVersion, pBuffer );
+ HX_RELEASE( pBuffer );
+ }
+ }
+ }
+ else
+ {
+ // MMFControllerVersion does not exist in cfg file ... add MMFControllerVersion and delete files
+ CreatePrefIfNoExist( CHXAV_MMFControllerVersion,strMmfControllerVerCur );
+ TRAPD( err, DeleteFilesL() );
+ }
+ return hxr;
}
//------------------------------------------------------------------------------
@@ -985,4 +958,4 @@
fsrv.Delete(KHxthumbnailArchiveAndPath);
CleanupStack::PopAndDestroy( 1 );
-}
+}*/
-------------- next part --------------
Index: symbian_thumbnaileng.cpp
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/platform/symbian/symbian_thumbnaileng.cpp,v
retrieving revision 1.4.14.2
diff -u -w -r1.4.14.2 symbian_thumbnaileng.cpp
--- symbian_thumbnaileng.cpp 23 Jan 2010 21:28:55 -0000 1.4.14.2
+++ symbian_thumbnaileng.cpp 17 Mar 2010 15:09:33 -0000
@@ -75,6 +75,13 @@
if (GetCurrentFreeRAM() > KMinThumbnailStartupMemory)
{
*ppEngine = new CHXTNEngine();
+ if (*ppEngine)
+ {
+ if( FAILED((*ppEngine)->SetupGlobals()))
+ {
+ HX_DELETE(*ppEngine);
+ }
+ }
}
return;
}
@@ -89,6 +96,7 @@
STDMETHODIMP_(void)CHXTNEngine::SetStartTime(UINT32 uStartTimeMS)
{
+ MD_LOG("CHXTNEngine::SetStartTime %d\n", uStartTimeMS);
m_uStartTimeMS = uStartTimeMS;
}
@@ -96,11 +104,10 @@
STDMETHODIMP_(void)CHXTNEngine::Done()
{
// stop the driver from further sending the packets.
+ MD_LOG("CHXTNEngine::Done\n");
CloseFile();
}
-
-
CHXTNEngine::~CHXTNEngine()
{
DoDestroy();
@@ -108,20 +115,14 @@
// cleanup routine.
// calls base class cleanup routine.
-
void CHXTNEngine::DoDestroy()
{
- if (m_bDestroyed)
+ if (!m_bDestroyed)
{
- return;
- }
-
- Done();
-
MD_LOG("CHXTNEngine::DoDestroy\n");
-
+ Done();
CHXSymbianMetaDataEng::DoDestroy();
-
+ }
}
void CHXTNEngine::GetDefaultOptions(IHXValues* pOptions)
@@ -174,7 +175,7 @@
pValue = ((TDesC &) KHXTEShadowFilePath).AllocLC();
break;
case EPluginArchiveName:
- pValue = ((TDesC &) KHXTEPluginArchiveName).AllocLC();
+ pValue = CHXSymbianString::PrefixNameSpaceLC(KHXTEPluginArchiveName);
break;
case EDLLNamePath:
pValue = CHXSymbianString::PrefixNameSpaceLC(KHXTEDLLNamePath);
@@ -195,6 +196,8 @@
STDMETHODIMP CHXTNEngine::OnStreamHeader(HX_RESULT status,
IHXValues* pValues)
{
+ MD_LOG("CHXTNEngine::OnStreamHeader status=%d\n", status);
+
CHXSymbianMetaDataEng::OnStreamHeader(status, pValues);
if(m_ulStreamCount == m_ulStreamsReceived)
{
@@ -204,32 +207,29 @@
}
}
-STDMETHODIMP CHXTNEngine::OnPacket(HX_RESULT status,
- IHXPacket* pPacket)
+STDMETHODIMP CHXTNEngine::OnPacket(HX_RESULT status, IHXPacket* pPacket)
{
+ MD_LOG("CHXTNEngine::OnPacket status=%d\n", status);
+
if (status == HXR_OK && pPacket && m_LastError == HXR_OK)
{
-
IHXBuffer *pBuffer = pPacket->GetBuffer();
- m_pObserver->PacketReady(HXR_OK, pBuffer->GetBuffer(),
- pBuffer->GetSize());
-
+ m_pObserver->PacketReady(HXR_OK, pBuffer->GetBuffer(), pBuffer->GetSize());
HX_RELEASE(pBuffer);
}
-
CHXSymbianMetaDataEng::OnPacket(status, pPacket);
-
-
}
STDMETHODIMP CHXTNEngine::OnTermination(HX_RESULT status)
-
{
+ MD_LOG("CHXTNEngine::OnTermination status=%d\n", status);
+
m_pFFDriver->OnTermination(status);
if (status != HXR_OK && status != HXR_CLOSED)
{
m_LastError = status;
}
m_pObserver->EndOfPackets();
+
return HXR_OK;
}
-------------- next part --------------
Index: symbian_metadataeng.h
===================================================================
RCS file: /cvsroot/datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h,v
retrieving revision 1.9.14.2
diff -u -w -r1.9.14.2 symbian_metadataeng.h
--- symbian_metadataeng.h 9 Mar 2010 16:42:29 -0000 1.9.14.2
+++ symbian_metadataeng.h 17 Mar 2010 15:10:54 -0000
@@ -66,8 +66,6 @@
// needed for the pref.
#include "chxminiccf.h"
-class SymbianTLCContext;
-
UINT32 GetCurrentFreeRAM();
class CHXSymbianMetaDataEng : public IHXRequestContext,
public IHXErrorMessages,
@@ -152,7 +150,7 @@
public:
- STDMETHOD_(HX_RESULT, SetupGlobals)(THIS_ HXBOOL bIsMetaData); // Specifies whether the instance belongs to MetaData or Thumbnail
+ STDMETHOD_(HX_RESULT, SetupGlobals)(THIS);
STDMETHOD_(HX_RESULT, SetupPreferences)(THIS);
STDMETHOD_(void, DoDestroy)(THIS);
STDMETHOD_(void, GetDefaultOptions)(THIS_ IHXValues* pOptions);
@@ -168,6 +166,7 @@
private:
+ //HX_RESULT UpdateConfigVersion();
void CreatePrefIfNoExist(const char* pName, const char* pValue);
HX_RESULT DoOpenSource(const char *pName);
HX_RESULT GetDCFHeaders();
@@ -187,13 +186,9 @@
HX_RESULT CreateMediaPlatform();
CHXLitePrefs* m_pPrefs;
- CHXString m_strInstallDrive;
IHXMMFDataSource* m_pDataSource;
HXBOOL m_bProtectedAndCantPlay;
HXBOOL m_bDCFHeadersNeeded;
- HXBOOL m_bGlMgrTaken;
- SymbianTLCContext* m_pSymTLCContext;
-
};
#endif // _HX_SYMBIAN_METADATA_ENGINE_H_
From Alvaro.Vaquero at nokia.com Wed Mar 17 11:28:31 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Wed Mar 17 18:37:18 2010
Subject: [datatype-dev] CR: EGRS-83FRVP Long duration MKV clips take 20-25
seconds to start playing
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? matroska_diff.txt
Index: Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.6
diff -w -u -b -r1.1.1.1.2.6 Matroska.cpp
--- Matroska.cpp 2 Mar 2010 22:03:17 -0000 1.1.1.1.2.6
+++ Matroska.cpp 17 Mar 2010 19:24:45 -0000
@@ -1298,6 +1298,12 @@
int UpperElementLevel = 0;
uint64 TimecodeScale = 1000000;
+ HXBOOL bTracksParsed = FALSE;
+ HXBOOL bTagsParsed = FALSE;
+ HXBOOL bInfoParsed = FALSE;
+ HXBOOL bCuesParsed = FALSE;
+ HXBOOL bSeekHeadFound = FALSE;
+
ElementLevel1 = m_pES->FindNextElement( *(ElementLevel0->Generic().Context), UpperElementLevel, 0xFFFFFFFFL, false, 1 );
while (ElementLevel1 != NULL)
{
@@ -1310,13 +1316,116 @@
UpperElementLevel = 0;
}
- if (EbmlId(*ElementLevel1) == KaxTracks::ClassInfos->GlobalId)
+ if (EbmlId(*ElementLevel1) == KaxSeekHead::ClassInfos->GlobalId)
+ {
+ bSeekHeadFound = TRUE;
+
+ KaxSeekHead* metaSeek = static_cast(ElementLevel1);
+
+ //temp element pointers needed for parsing seek head
+ EbmlElement *el1 = NULL;
+ EbmlElement *el2 = NULL;
+
+ // read it in memory
+ metaSeek->Read( *m_pES, *(KaxSeekHead::ClassInfos->Context), UpperElementLevel, el1, true ); //el1 is never used
+
+ //store current position
+ uint64 savedPos = (uint64)m_pES->I_O().getFilePointer();
+ uint64 pos = 0;
+
+ for (int index = 0; index < metaSeek->ListSize(); index++)
+ {
+ if ((*metaSeek)[index]->Generic().GlobalId == KaxSeek::ClassInfos->GlobalId)
+ {
+ KaxSeek & seekPoint = *static_cast((*metaSeek)[index]);
+ KaxSeekID * seekID = NULL;
+ KaxSeekPosition *seekPos = NULL;
+
+ for (int index1 = 0; index1 < seekPoint.ListSize(); index1++)
+ {
+ if (seekPoint[index1]->Generic().GlobalId == KaxSeekID::ClassInfos->GlobalId)
+ {
+ seekID = static_cast(seekPoint[index1]);
+ }
+ else if (seekPoint[index1]->Generic().GlobalId == KaxSeekPosition::ClassInfos->GlobalId)
+ {
+ seekPos = static_cast(seekPoint[index1]);
+ pos = (uint64)this->m_pSegment->GetGlobalPosition( uint64( *seekPos ) );
+ }
+ }
+
+ //so now we have both seek position and id
+ //go and parse the relevant id
+ EbmlId id = EbmlId( seekID->GetBuffer(), seekID->GetSize() );
+
+ m_pES->I_O().setFilePointer( pos, seek_beginning );
+
+ EbmlCallbacks *cb = NULL;
+ EbmlElement *el = NULL;
+ if(id == KaxCues::ClassInfos->GlobalId)
+ {
+ cb = KaxCues::ClassInfos;
+ }
+ else if(id == KaxInfo::ClassInfos->GlobalId)
+ {
+ cb = KaxInfo::ClassInfos;
+ }
+ else if(id == KaxTags::ClassInfos->GlobalId)
+ {
+ cb = KaxTags::ClassInfos;
+ }
+ else if(id == KaxTracks::ClassInfos->GlobalId)
+ {
+ cb = KaxTracks::ClassInfos;
+ }
+
+ if(cb)
+ {
+ el = m_pES->FindNextID( *cb, 0xFFFFFFFFL);
+ }
+
+ if( el != NULL )
+ {
+ if(!bCuesParsed && (EbmlId(*el) == KaxCues::ClassInfos->GlobalId) )
+ {
+ int elementLevel = 0;
+ ParseCues( static_cast( el ), el2, elementLevel); //el2 is not used on return
+ bCuesParsed = TRUE;
+ }
+ else if(!bInfoParsed && (EbmlId(*el) == KaxInfo::ClassInfos->GlobalId) )
+ {
+ ParseSegmentInfo(static_cast(el));
+ bInfoParsed = TRUE;
+ }
+ else if(!bTagsParsed && (id == KaxTags::ClassInfos->GlobalId) )
+ {
+ ParseTags( static_cast( el));
+ bTagsParsed = TRUE;
+ }
+ else if( !bTracksParsed && (id == KaxTracks::ClassInfos->GlobalId) )
+ {
+ ParseStreams(static_cast( el ));
+ bTracksParsed = TRUE;
+ }
+ else
+ {
+ //Do Nothing
+ }
+ }
+ }
+ }
+ //reset to where we started
+ m_pES->I_O().setFilePointer( savedPos, seek_beginning );
+ }
+ else if (!bTracksParsed && (EbmlId(*ElementLevel1) == KaxTracks::ClassInfos->GlobalId) )
{
ParseStreams(static_cast( ElementLevel1 ));
+ bTracksParsed = TRUE;
}
- else if (EbmlId(*ElementLevel1) == KaxInfo::ClassInfos->GlobalId)
+ else if (!bInfoParsed && (EbmlId(*ElementLevel1) == KaxInfo::ClassInfos->GlobalId) )
{
ParseSegmentInfo(static_cast(ElementLevel1));
+ bInfoParsed = TRUE;
}
else if (EbmlId(*ElementLevel1) == KaxCluster::ClassInfos->GlobalId)
{
@@ -1325,14 +1434,22 @@
m_uStartPos = ElementLevel1->GetElementPosition();
ParseCluster(static_cast(ElementLevel1), ElementLevel2, UpperElementLevel);
}
+ else if(bSeekHeadFound)
+ {
+ ElementLevel1->SkipData( *m_pES, *ElementLevel1->Generic().Context );
+ delete ElementLevel1;
+ break;
+ }
}
- else if(EbmlId(*ElementLevel1) == KaxCues::ClassInfos->GlobalId)
+ else if(!bCuesParsed && (EbmlId(*ElementLevel1) == KaxCues::ClassInfos->GlobalId))
{
ParseCues( static_cast( ElementLevel1 ), ElementLevel2, UpperElementLevel);
+ bCuesParsed = TRUE;
}
- else if(EbmlId(*ElementLevel1) == KaxTags::ClassInfos->GlobalId)
+ else if(!bTagsParsed && (EbmlId(*ElementLevel1) == KaxTags::ClassInfos->GlobalId))
{
ParseTags( static_cast( ElementLevel1));
+ bTagsParsed = TRUE;
}
if (UpperElementLevel > 0)
@@ -1352,7 +1469,6 @@
ElementLevel1 = m_pES->FindNextElement( *(ElementLevel0->Generic().Context), UpperElementLevel, 0xFFFFFFFFL, false, 1 );
}
}
-
}
}
Index: libebml/ebml/EbmlCrc32.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlCrc32.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlCrc32.h
--- libebml/ebml/EbmlCrc32.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libebml/ebml/EbmlCrc32.h 17 Mar 2010 19:24:45 -0000
@@ -63,7 +63,7 @@
uint64 ReadData(IOCallback & input, ScopeMode ReadFully = SCOPE_ALL_DATA);
// uint64 UpdateSize(bool bKeepIntact = false);
- static EbmlCallbacks *ClassInfos; //ANUJ_MKV - remove const
+ static EbmlCallbacks *ClassInfos;
bool IsDefaultValue() const {
Index: libebml/ebml/EbmlDummy.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlDummy.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlDummy.h
--- libebml/ebml/EbmlDummy.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libebml/ebml/EbmlDummy.h 17 Mar 2010 19:24:45 -0000
@@ -47,7 +47,7 @@
EbmlDummy(const EbmlDummy & ElementToClone):EbmlBinary(ElementToClone), DummyId(ElementToClone.DummyId) {}
static EbmlElement & Create() {return *(new EbmlDummy);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos;//ANUJ - commented const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return DummyId;}
bool ValidateSize() const {return true;}
@@ -56,11 +56,10 @@
EbmlElement * Clone() const {return new EbmlDummy(*this);}
- //protected: //ANUJ commented
const EbmlId DummyId;
static EbmlId* DummyRawId;
- static void InitCallback(); //ANUJ
+ static void InitCallback();
static void DeleteCallback();
};
Index: libebml/ebml/EbmlElement.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlElement.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlElement.h
--- libebml/ebml/EbmlElement.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libebml/ebml/EbmlElement.h 17 Mar 2010 19:24:45 -0000
@@ -93,8 +93,6 @@
,DebugName(aDebugName)
,Context(aContext)
{
-// {FILE* f1 = ::fopen("f:\\anuj_ebml.txt", "a+"); ::fprintf(f1, "EbmlCallbacks \n");::fclose(f1);}
-
}
void DeleteData()
@@ -102,7 +100,7 @@
}
- const char* GetName() { return "ANUJ";/*DebugName;*/ }
+ const char* GetName() { return "DebugName"; }
EbmlElement& (*Create)();
const EbmlId& GlobalId;
Index: libebml/ebml/EbmlHead.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlHead.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlHead.h
--- libebml/ebml/EbmlHead.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libebml/ebml/EbmlHead.h 17 Mar 2010 19:24:45 -0000
@@ -47,13 +47,13 @@
EbmlHead(const EbmlHead & ElementToClone) : EbmlMaster(ElementToClone) {}
static EbmlElement & Create() {return *(new EbmlHead);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
bool IsYourId(const EbmlId & TestId) const;
EbmlElement * Clone() const {return new EbmlHead(*this);}
- static void InitCallback(); //ANUJ
+ static void InitCallback();
static void DeleteCallback();
};
Index: libebml/ebml/EbmlSubHead.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlSubHead.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlSubHead.h
--- libebml/ebml/EbmlSubHead.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libebml/ebml/EbmlSubHead.h 17 Mar 2010 19:24:45 -0000
@@ -49,11 +49,11 @@
EVersion(const EVersion & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EVersion);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EVersion(*this);}
- static void InitCallback(); //ANUJ
+ static void InitCallback();
static void DeleteCallback();
};
@@ -63,7 +63,7 @@
EReadVersion(const EReadVersion & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EReadVersion);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EReadVersion(*this);}
@@ -75,7 +75,7 @@
EMaxIdLength(const EMaxIdLength & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EMaxIdLength);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EMaxIdLength(*this);}
@@ -88,7 +88,7 @@
EMaxSizeLength(const EMaxSizeLength & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EMaxSizeLength);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EMaxSizeLength(*this);}
@@ -100,7 +100,7 @@
EDocType(const EDocType & ElementToClone) : EbmlString(ElementToClone) {}
static EbmlElement & Create() {return *(new EDocType);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EDocType(*this);}
@@ -112,7 +112,7 @@
EDocTypeVersion(const EDocTypeVersion & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EDocTypeVersion);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EDocTypeVersion(*this);}
@@ -124,7 +124,7 @@
EDocTypeReadVersion(const EDocTypeReadVersion & ElementToClone) : EbmlUInteger(ElementToClone) {}
static EbmlElement & Create() {return *(new EDocTypeReadVersion);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
EbmlElement * Clone() const {return new EDocTypeReadVersion(*this);}
Index: libebml/ebml/EbmlVoid.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/ebml/EbmlVoid.h,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlVoid.h
--- libebml/ebml/EbmlVoid.h 19 Oct 2009 14:53:48 -0000 1.1.1.1
+++ libebml/ebml/EbmlVoid.h 17 Mar 2010 19:24:45 -0000
@@ -48,7 +48,7 @@
static EbmlElement & Create() {return *(new EbmlVoid);}
const EbmlCallbacks & Generic() const {return *ClassInfos;}
bool ValidateSize() const {return true;} // any void element is accepted
- static /*const*/ EbmlCallbacks* ClassInfos; //ANUJ removed const
+ static EbmlCallbacks* ClassInfos;
operator const EbmlId &() const {return ClassInfos->GlobalId;}
bool IsYourId(const EbmlId & TestId) const;
@@ -75,7 +75,7 @@
EbmlElement * Clone() const {return new EbmlVoid(*this);}
- static void InitCallback(); //ANUJ
+ static void InitCallback();
static void DeleteCallback();
};
Index: libebml/src/EbmlElement.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/src/EbmlElement.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlElement.cpp
--- libebml/src/EbmlElement.cpp 19 Oct 2009 14:53:48 -0000 1.1.1.1
+++ libebml/src/EbmlElement.cpp 17 Mar 2010 19:24:46 -0000
@@ -472,7 +472,7 @@
for (EltIndex = 0; EltIndex < Context.Size; EltIndex++) {
if (EbmlId(*Result) == Context.MyTable[EltIndex].GetCallbacks->GlobalId) {
// skip the data with its own context
- Result = Result->SkipData(DataStream, *(Context.MyTable[EltIndex].GetCallbacks->Context), NULL); //ANUJ - use *
+ Result = Result->SkipData(DataStream, *(Context.MyTable[EltIndex].GetCallbacks->Context), NULL);
break; // let's go to the next ID
}
}
Index: libebml/src/EbmlMaster.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/src/EbmlMaster.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlMaster.cpp
--- libebml/src/EbmlMaster.cpp 19 Oct 2009 14:53:48 -0000 1.1.1.1
+++ libebml/src/EbmlMaster.cpp 17 Mar 2010 19:24:46 -0000
@@ -253,13 +253,6 @@
for (EltIdx = 0; EltIdx < Context.Size; EltIdx++) {
if (Context.MyTable[EltIdx].Mandatory) {
if (FindElt(*(Context.MyTable[EltIdx].GetCallbacks)) == NULL) {
-/*ANUJ std::string missingElement;
- missingElement = "Missing element \"";
- missingElement.append(Context.MyTable[EltIdx].GetCallbacks->DebugName);
- missingElement.append("\" in EbmlMaster \"");
- missingElement.append(Context.MasterElt->DebugName);
- missingElement.append("\"");
- missingElements.push_back(missingElement);*/
CHXString missingElement;
missingElement = "Missing element \"";
missingElement += Context.MyTable[EltIdx].GetCallbacks->DebugName;
@@ -441,10 +434,10 @@
// more logical to do it afterward
ElementList.push_back(ElementLevelA);
- ElementLevelA->Read(inDataStream, *(ElementLevelA->Generic().Context), UpperEltFound, FoundElt, AllowDummyElt, ReadFully); //ANUJ - use *
+ ElementLevelA->Read(inDataStream, *(ElementLevelA->Generic().Context), UpperEltFound, FoundElt, AllowDummyElt, ReadFully);
// just in case
- ElementLevelA->SkipData(inDataStream, *(ElementLevelA->Generic().Context)); //ANUJ - use *
+ ElementLevelA->SkipData(inDataStream, *(ElementLevelA->Generic().Context));
}
if (UpperEltFound > 0) {
From ugundeli at real.com Wed Mar 17 13:08:34 2010
From: ugundeli at real.com (Umakant Gundeli)
Date: Wed Mar 17 20:18:06 2010
Subject: [datatype-dev] RE: - Thumbnail/Metadata engine cleanup and crash
fix.
In-Reply-To: <19113978AB61DA44AC317B211CF1C32A2901E92774@NOK-EUMSG-02.mgdnok.nokia.com>
References: <19113978AB61DA44AC317B211CF1C32A2901A079CE@NOK-EUMSG-02.mgdnok.nokia.com>,
<19113978AB61DA44AC317B211CF1C32A2901E92774@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507DF56E75E@SEAMBX.corp.real.com>
it looks good to me.
- Umakant.
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of saleem.adookkattil@nokia.com [saleem.adookkattil@nokia.com]
Sent: Wednesday, March 17, 2010 8:21 AM
To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [datatype-dev] CR:- Thumbnail/Metadata engine cleanup and crash fix.
"Nokia submits this code under the terms of a commercial contribution agreement with Real Networks, and I am authorized to contribute this code under said agreement."
Modified by: saleem.adookkattil@nokia.com
Reviewed by:
Date: 03/16/2010
Project: symbian_client_apps
ErrorId: JLIU_83KSM1
Synopsis: Thumbnail/Metadata engine cleanup and crash fix.
Overview:
Made the following changes.
1) Added code to create one instance of Thumnail/Metadata engine inside one thread.
CHXSymbianMetaDataEng::Create() and void CHXTNEngine::CreateTNE(CHXTNEngine** ppEngine) returns NULL on SetupGlobals method call failure.
SetupGlobals checks whether an instance of HXGlobalManager already created and avialble before creating a new instance.
If there is one already created returns failure.
2) Added code to add prefix to thumbnail engine plugin archive name.
This change is needed when we use 'ng' name space
3) Removed symbian tlc context from Thumbnail/Metadata engine.
As mediaplatform create instance of log manager, there is no need to use symbian tlc context in Thumbnail/Metadata engine.
4) Added code to disable configuration file version updation.
As the code to update configuration file version is not tested, created a separate function for it and disabled.
5) Added code to disable logging by setting default value of "Logging\\File\\Enabled"
6) Cleanup and added logs
Files modified:
cvsroot\datatype\tools\metadataeng\engine\platform\symbian\symbian_thumbnaileng.cpp
cvsroot\datatype\tools\metadataeng\engine\platform\symbian\symbian_metadataeng.cpp
cvsroot\datatype\tools\metadataeng\engine\pub\platform\symbian\symbian_metadataeng.h
cvsroot\datatype\tools\metadataeng\engine\metadataengbase.cpp
cvsroot\datatype\tools\metadataeng\engine\pub\metadataengbase.h
Files added:
Image Size and Heap Use impact: None.
Module Release testing (STIF) : Yes
Test case(s) Added : No
Memory leak check performed : Yes
Platforms and Profiles Build Verified: helix-client-symbian-4
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 4_2_0_brizo, HEAD
From Joeli at real.com Thu Mar 18 02:51:53 2010
From: Joeli at real.com (Qiang (Joe) Li)
Date: Thu Mar 18 09:59:50 2010
Subject: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for
capturing thumbnail of a broken rmvb file
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: UnsavedYY
Type: application/octet-stream
Size: 64037 bytes
Desc: UnsavedYY
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100318/7a848aef/UnsavedYY-0001.obj
From qluo at real.com Thu Mar 18 06:13:51 2010
From: qluo at real.com (Qiang Luo)
Date: Thu Mar 18 13:21:23 2010
Subject: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for
capturing thumbnail of a broken rmvb file
In-Reply-To:
References:
Message-ID: <4BA2351F.5030709@real.com>
Hi Joe,
Your fix looks reasonable. However, it doesn't explain why it take 30s
to get SeekDone() callback from the file system. The old code do limit
the seek to be within the file size, making out-of-range seek to be seek
to the end. It would be better to track down and fix the real issue.
If the local file system doesn't call the file response with SeekDone()
within reasonable time, the bug then is in the local file system or its
components. For android, we use FDBufferedDataFile object (in
common/fileio/fdbufdataf) to handle actual file io operations.
Thanks,
Luo Qiang
On 3/18/2010 3:51 AM, Qiang (Joe) Li wrote:
>
> Project: Real Player for Android
>
> Synopsis: Fix for Bug 9974: It costs 24 seconds for capturing
> thumbnail of a broken rmvb file.
>
> Overview:
>
> This issue was conflict with Bug10036 (Bug 10036:"force close" when
> capturing thumbnail).
>
> So the Bug9974 was re-opened in RC14 due to bug 10036?s fixing.
>
> In Bug10036:
>
> When trying to capture thumbnail for this avi file.
>
> Thumbnail generation start time for android is 30sec and since we have
> 6 sec playback in this file, the ideal behavior for the player is to
> exit gracefully by returning an error.
>
> While In Bug9974:
>
> It was due to capturing thumbnail of a corrupted/broken RMVB file. In
> this given broken/corrupted RMVB file, The duration given in file
> header is around 111 minutes, whereas the actual clip is only around
> 7minutes. At some point in execution, the riff reader tries to seek to
> an offset (to around 111 minutes) which is way outside the file size
> limits and after this ->Seek() call, it takes about 24 seconds to
> return the control back to ::RIFFSeekDone() method.
>
> So in order not to affect these two test cases,
>
> I think added a check to make sure that desired seek offset falls
> within the file size limits. if desired seek offset is outside file
> size limits, we simply call RIFFSeekDone(HXR_FAILED).
>
> Files Added: None
>
> Files Modified:
>
> datatype/common/util/riff.cpp
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut3230-arm.eabi
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
> Branch: hxclient_3_6_1_atlas_restricted
>
> DIFF:
>
> HX_RESULT
>
> CRIFFReader::FileSeek(UINT32 offset)
>
> {
>
> m_ulSeekOffset = offset;
>
> m_state = RS_UserSeekPending;
>
> - if(m_ulSeekOffset >= m_TotalFileSize && m_TotalFileSize != 0)
>
> - {
>
> - m_ulSeekOffset = m_TotalFileSize;
>
> - }
>
> - return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + if(m_ulSeekOffset <= m_TotalFileSize)
>
> + {
>
> + return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + }
>
> + else
>
> + {
>
> + return m_pResponse->RIFFSeekDone(HXR_FAILED);
>
> + }
>
> }
>
> Umakant and Manjunatha please help to check this modification;
>
> Thanks.
>
> Test Result:
>
> Test files:
>
> crank2-tlr1b_mjpeg_wvga.avi
>
> conan.rmvb
>
> 01-30 01:36:03.879: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:36:03.889: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:04.009: DEBUG/HelixPlayer(1141):
> m_pMediaPlatform->AddPluginPath() path=/system/lib/helix.
>
> 01-30 01:36:04.229: INFO/ActivityManager(1191): Stopping service:
> com.android.camera/.ThumbnailScannerService
>
> 01-30 01:36:04.329: DEBUG/ddm-heap(1387): Got feature list request
>
> 01-30 01:36:05.279: DEBUG/KeyguardViewMediator(1191): pokeWakelock(5000)
>
> 01-30 01:36:05.339: INFO/ActivityManager(1191): Start proc
> com.android.inputmethod.latin for service
> com.android.inputmethod.latin/.LatinIME: pid=1409 uid=10008
> gids={3003, 3002, 3001, 1015}
>
> 01-30 01:36:05.389: DEBUG/ddm-heap(1409): Got feature list request
>
> 01-30 01:36:06.299: VERBOSE/HelixPlayer(1141): Helix Media platform
> created, thread_id = 86024.
>
> 01-30 01:36:07.189: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.259: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3343 ms
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.279: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:07.279: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3362 ms
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.836: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.836: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:07.836: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:07.839: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.839: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:08.029: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.029: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 197 ms
>
> 01-30 01:36:08.049: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.099: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.099: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:08.099: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 267 ms
>
> 01-30 01:36:08.109: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.554: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.554: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:08.554: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:08.609: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.609: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:10.439: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.real.RealPlayer/.Home }
>
> 01-30 01:36:10.509: DEBUG/RP-HOME(1322): onCreate
>
> 01-30 01:36:11.019: VERBOSE/RP-HOME(1322): onCreate(): scanner already
> registered, no need to send the broadcast
>
> 01-30 01:36:11.069: VERBOSE/RP-MediaService(1322): onCreate
>
> 01-30 01:36:11.129: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:11.339: INFO/ActivityManager(1191): Displayed activity
> com.real.RealPlayer/.Home: 851 ms (total 851 ms)
>
> 01-30 01:36:19.789: WARN/IInputConnectionWrapper(1322): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:19.899: DEBUG/RP-HOME(1322): onDestroy
>
> 01-30 01:36:19.949: INFO/ActivityManager(1191): Stopping service:
> com.real.RealPlayer/.MediaPlaybackService
>
> 01-30 01:36:19.949: INFO/RP-HOME(1322): Skipping
> cleanup:isMediaScannerScanning():true, isRealDataScanning():true
>
> 01-30 01:36:19.959: VERBOSE/RP-MediaService(1322): onDestroy
>
> 01-30 01:36:23.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.239: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 14632 ms
>
> 01-30 01:36:23.309: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.669: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.709: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:23.709: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 15159 ms
>
> 01-30 01:36:23.719: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.909: INFO/RP-MediaScannerService(1308): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:true and
> isRealDataScanning:false
>
> 01-30 01:36:23.909: VERBOSE/RP-MediaScannerService(1308):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:24.279: INFO/RP-MediaScannerService(1322): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:trueand
> isRealDataScanning:false
>
> 01-30 01:36:24.279: VERBOSE/RP-MediaScannerService(1322):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:25.659: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.android.camera/.GalleryPicker }
>
> 01-30 01:36:26.029: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:26.089: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.GalleryPicker: 399 ms (total 399 ms)
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.259: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:26.259: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.579: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.609: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.609: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 351 ms
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.809: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:26.809: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.919: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.929: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.929: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 121 ms
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.999: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:26.999: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:28.139: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.VIEW
> dat=content://media/internal/images/media
> cmp=com.android.camera/.ImageGallery (has extras) }
>
> 01-30 01:36:28.479: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.ImageGallery: 338 ms (total 338 ms)
>
> 01-30 01:36:34.419: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:34.449: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:34.449: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7456 ms
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:34.589: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:34.589: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:34.709: ERROR/Database(1267): Leak found
>
> 01-30 01:36:34.709: ERROR/Database(1267):
> java.lang.IllegalStateException:
> /data/data/com.android.providers.media/databases/external-1e3b66a5.db
> SQLiteDatabase created and never closed
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.(SQLiteDatabase.java:1581)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:638)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:659)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:652)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.app.ApplicationContext.openOrCreateDatabase(ApplicationContext.java:482)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:193)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:98)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:158)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.query(MediaProvider.java:874)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.attachVolume(MediaProvider.java:2244)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insertInternal(MediaProvider.java:1420)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insert(MediaProvider.java:1200)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentProvider$Transport.insert(ContentProvider.java:140)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentResolver.insert(ContentResolver.java:479)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.openDatabase(MediaScannerService.java:61)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.scan(MediaScannerService.java:108)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.access$200(MediaScannerService.java:49)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService$ServiceHandler.handleMessage(MediaScannerService.java:280)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Handler.dispatchMessage(Handler.java:99)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Looper.loop(Looper.java:123)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.run(MediaScannerService.java:180)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> java.lang.Thread.run(Thread.java:1060)
>
> 01-30 01:36:42.049: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:42.079: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:42.079: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7494 ms
>
> 01-30 01:37:01.169: DEBUG/RP-MediaScannerService(1308): Scanning SD Card
>
> 01-30 01:37:01.169: DEBUG/RP-MediaStore(1308): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.179: DEBUG/RP-MediaStore(1308): ScanSDCard start
>
> 01-30 01:37:01.379: DEBUG/RP-MediaStore(1308): ScanSDCard end
>
> 01-30 01:37:01.379: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.399: DEBUG/RP-DataStore(1308): verifyVideoThumbnails start
>
> 01-30 01:37:01.602: DEBUG/RP-MediaScannerService(1322): Scanning SD Card
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): ScanSDCard start
>
> 01-30 01:37:01.689: DEBUG/RP-MediaStore(1322): ScanSDCard end
>
> 01-30 01:37:01.689: VERBOSE/RP-DataStore(1322): checkVideoMiniThumbails()
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.709: DEBUG/RP-DataStore(1322): verifyVideoThumbnails start
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): verifyVideoThumbnails
> complete
>
> 01-30 01:37:02.929: VERBOSE/RP-MediaScannerService(1308): Closing DB
> as appOpen:false and mIsMediaScanning:false and isRealDataScanning:false
>
> 01-30 01:37:02.929: VERBOSE/RP-DataStore(1308): cleanUp()
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): resetAllScannerFlags
>
> 01-30 01:37:02.939: VERBOSE/RP-DataStore(1308): cleanUp(): finished
> normally
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): verifyVideoThumbnails
> complete
>
> 01-30 01:37:03.231: VERBOSE/RP-MediaScannerService(1322): Closing DB
> as appOpen:false and mIsMediaScanning:falseand isRealDataScanning:false
>
> 01-30 01:37:03.231: VERBOSE/RP-DataStore(1322): cleanUp()
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): resetAllScannerFlags
>
> 01-30 01:37:03.309: VERBOSE/RP-DataStore(1322): cleanUp(): finished
> normally
>
> 01-30 01:37:06.309: INFO/HelixPlayer(1141): Helix Media platform
> finial release: done.
>
> more details please check the attached log file.
>
> Regards,
> LiQiang(Joe)
> RealNetworks, China
> T: +86(10)59542795
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100318/4f05ae2e/attachment-0001.html
From sfu at real.com Thu Mar 18 06:42:26 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 13:50:35 2010
Subject: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for
capturing thumbnail of a broken rmvb file
In-Reply-To:
References:
Message-ID: <4BA23BD2.7030300@real.com>
In some cases, m_TotalFileSize may be unknown and it will be zero. The
'if' statement needs to account for this condition, just like the old
code does.
This is at least the 3rd time a CR is sent for these kind of out of
range seek delay problems in different data types I think. The fix
really should be in the file system itself -- i.e. if file format
requires a seek and it is out of range, file system/object should fail
the seek right way and file format just need to handle that error
condition in a timely manner. Otherwise, we'll have to fix the file
format plugins one by one.
fxd
Qiang (Joe) Li wrote:
>
> Project: Real Player for Android
>
>
>
> Synopsis: Fix for Bug 9974: It costs 24 seconds for capturing
> thumbnail of a broken rmvb file.
>
>
>
> Overview:
>
> This issue was conflict with Bug10036 (Bug 10036:"force close" when
> capturing thumbnail).
>
> So the Bug9974 was re-opened in RC14 due to bug 10036?s fixing.
>
>
>
>
>
> In Bug10036:
>
> When trying to capture thumbnail for this avi file.
>
> Thumbnail generation start time for android is 30sec and since we have
> 6 sec playback in this file, the ideal behavior for the player is to
> exit gracefully by returning an error.
>
>
>
> While In Bug9974:
>
> It was due to capturing thumbnail of a corrupted/broken RMVB file. In
> this given broken/corrupted RMVB file, The duration given in file
> header is around 111 minutes, whereas the actual clip is only around
> 7minutes. At some point in execution, the riff reader tries to seek to
> an offset (to around 111 minutes) which is way outside the file size
> limits and after this ->Seek() call, it takes about 24 seconds to
> return the control back to ::RIFFSeekDone() method.
>
>
>
> So in order not to affect these two test cases,
>
> I think added a check to make sure that desired seek offset falls
> within the file size limits. if desired seek offset is outside file
> size limits, we simply call RIFFSeekDone(HXR_FAILED).
>
>
>
>
>
> Files Added: None
>
>
>
> Files Modified:
>
> datatype/common/util/riff.cpp
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut3230-arm.eabi
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
>
>
> DIFF:
>
>
>
> HX_RESULT
>
> CRIFFReader::FileSeek(UINT32 offset)
>
> {
>
> m_ulSeekOffset = offset;
>
> m_state = RS_UserSeekPending;
>
> - if(m_ulSeekOffset >= m_TotalFileSize && m_TotalFileSize != 0)
>
> - {
>
> - m_ulSeekOffset = m_TotalFileSize;
>
> - }
>
> - return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + if(m_ulSeekOffset <= m_TotalFileSize)
>
> + {
>
> + return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + }
>
> + else
>
> + {
>
> + return m_pResponse->RIFFSeekDone(HXR_FAILED);
>
> + }
>
>
>
> }
>
>
>
> Umakant and Manjunatha please help to check this modification;
>
> Thanks.
>
>
>
>
>
> Test Result:
>
> Test files:
>
> crank2-tlr1b_mjpeg_wvga.avi
>
> conan.rmvb
>
>
>
> 01-30 01:36:03.879: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:36:03.889: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:04.009: DEBUG/HelixPlayer(1141):
> m_pMediaPlatform->AddPluginPath() path=/system/lib/helix.
>
> 01-30 01:36:04.229: INFO/ActivityManager(1191): Stopping service:
> com.android.camera/.ThumbnailScannerService
>
> 01-30 01:36:04.329: DEBUG/ddm-heap(1387): Got feature list request
>
> 01-30 01:36:05.279: DEBUG/KeyguardViewMediator(1191): pokeWakelock(5000)
>
> 01-30 01:36:05.339: INFO/ActivityManager(1191): Start proc
> com.android.inputmethod.latin for service
> com.android.inputmethod.latin/.LatinIME: pid=1409 uid=10008
> gids={3003, 3002, 3001, 1015}
>
> 01-30 01:36:05.389: DEBUG/ddm-heap(1409): Got feature list request
>
> 01-30 01:36:06.299: VERBOSE/HelixPlayer(1141): Helix Media platform
> created, thread_id = 86024.
>
> 01-30 01:36:07.189: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.259: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3343 ms
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.279: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:07.279: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3362 ms
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.836: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.836: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:07.836: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:07.839: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.839: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:08.029: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.029: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 197 ms
>
> 01-30 01:36:08.049: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.099: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.099: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:08.099: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 267 ms
>
> 01-30 01:36:08.109: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.554: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.554: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:08.554: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:08.609: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.609: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:10.439: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.real.RealPlayer/.Home }
>
> 01-30 01:36:10.509: DEBUG/RP-HOME(1322): onCreate
>
> 01-30 01:36:11.019: VERBOSE/RP-HOME(1322): onCreate(): scanner already
> registered, no need to send the broadcast
>
> 01-30 01:36:11.069: VERBOSE/RP-MediaService(1322): onCreate
>
> 01-30 01:36:11.129: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:11.339: INFO/ActivityManager(1191): Displayed activity
> com.real.RealPlayer/.Home: 851 ms (total 851 ms)
>
> 01-30 01:36:19.789: WARN/IInputConnectionWrapper(1322): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:19.899: DEBUG/RP-HOME(1322): onDestroy
>
> 01-30 01:36:19.949: INFO/ActivityManager(1191): Stopping service:
> com.real.RealPlayer/.MediaPlaybackService
>
> 01-30 01:36:19.949: INFO/RP-HOME(1322): Skipping
> cleanup:isMediaScannerScanning():true, isRealDataScanning():true
>
> 01-30 01:36:19.959: VERBOSE/RP-MediaService(1322): onDestroy
>
> 01-30 01:36:23.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.239: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 14632 ms
>
> 01-30 01:36:23.309: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.669: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.709: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:23.709: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 15159 ms
>
> 01-30 01:36:23.719: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.909: INFO/RP-MediaScannerService(1308): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:true and
> isRealDataScanning:false
>
> 01-30 01:36:23.909: VERBOSE/RP-MediaScannerService(1308):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:24.279: INFO/RP-MediaScannerService(1322): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:trueand
> isRealDataScanning:false
>
> 01-30 01:36:24.279: VERBOSE/RP-MediaScannerService(1322):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:25.659: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.android.camera/.GalleryPicker }
>
> 01-30 01:36:26.029: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:26.089: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.GalleryPicker: 399 ms (total 399 ms)
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.259: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:26.259: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.579: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.609: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.609: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 351 ms
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.809: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:26.809: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.919: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.929: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.929: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 121 ms
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.999: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:26.999: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:28.139: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.VIEW
> dat=content://media/internal/images/media
> cmp=com.android.camera/.ImageGallery (has extras) }
>
> 01-30 01:36:28.479: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.ImageGallery: 338 ms (total 338 ms)
>
> 01-30 01:36:34.419: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:34.449: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:34.449: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7456 ms
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:34.589: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:34.589: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:34.709: ERROR/Database(1267): Leak found
>
> 01-30 01:36:34.709: ERROR/Database(1267):
> java.lang.IllegalStateException:
> /data/data/com.android.providers.media/databases/external-1e3b66a5.db
> SQLiteDatabase created and never closed
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.(SQLiteDatabase.java:1581)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:638)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:659)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:652)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.app.ApplicationContext.openOrCreateDatabase(ApplicationContext.java:482)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:193)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:98)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:158)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.query(MediaProvider.java:874)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.attachVolume(MediaProvider.java:2244)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insertInternal(MediaProvider.java:1420)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insert(MediaProvider.java:1200)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentProvider$Transport.insert(ContentProvider.java:140)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentResolver.insert(ContentResolver.java:479)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.openDatabase(MediaScannerService.java:61)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.scan(MediaScannerService.java:108)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.access$200(MediaScannerService.java:49)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService$ServiceHandler.handleMessage(MediaScannerService.java:280)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Handler.dispatchMessage(Handler.java:99)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Looper.loop(Looper.java:123)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.run(MediaScannerService.java:180)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> java.lang.Thread.run(Thread.java:1060)
>
> 01-30 01:36:42.049: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:42.079: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:42.079: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7494 ms
>
> 01-30 01:37:01.169: DEBUG/RP-MediaScannerService(1308): Scanning SD Card
>
> 01-30 01:37:01.169: DEBUG/RP-MediaStore(1308): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.179: DEBUG/RP-MediaStore(1308): ScanSDCard start
>
> 01-30 01:37:01.379: DEBUG/RP-MediaStore(1308): ScanSDCard end
>
> 01-30 01:37:01.379: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.399: DEBUG/RP-DataStore(1308): verifyVideoThumbnails start
>
> 01-30 01:37:01.602: DEBUG/RP-MediaScannerService(1322): Scanning SD Card
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): ScanSDCard start
>
> 01-30 01:37:01.689: DEBUG/RP-MediaStore(1322): ScanSDCard end
>
> 01-30 01:37:01.689: VERBOSE/RP-DataStore(1322): checkVideoMiniThumbails()
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.709: DEBUG/RP-DataStore(1322): verifyVideoThumbnails start
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): verifyVideoThumbnails
> complete
>
> 01-30 01:37:02.929: VERBOSE/RP-MediaScannerService(1308): Closing DB
> as appOpen:false and mIsMediaScanning:false and isRealDataScanning:false
>
> 01-30 01:37:02.929: VERBOSE/RP-DataStore(1308): cleanUp()
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): resetAllScannerFlags
>
> 01-30 01:37:02.939: VERBOSE/RP-DataStore(1308): cleanUp(): finished
> normally
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): verifyVideoThumbnails
> complete
>
> 01-30 01:37:03.231: VERBOSE/RP-MediaScannerService(1322): Closing DB
> as appOpen:false and mIsMediaScanning:falseand isRealDataScanning:false
>
> 01-30 01:37:03.231: VERBOSE/RP-DataStore(1322): cleanUp()
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): resetAllScannerFlags
>
> 01-30 01:37:03.309: VERBOSE/RP-DataStore(1322): cleanUp(): finished
> normally
>
> 01-30 01:37:06.309: INFO/HelixPlayer(1141): Helix Media platform
> finial release: done.
>
>
>
>
>
> more details please check the attached log file.
>
>
>
> Regards,
> LiQiang(Joe)
> RealNetworks, China
> T: +86(10)59542795
>
>
>
From Yury.Ramanovich at nokia.com Thu Mar 18 08:11:02 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Mar 18 15:19:39 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix support
for 'CreationTime" and "ModificationTime" content metadata
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
?
Index: clientapps/symbiancommon/hxsymmetadata.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbiancommon/hxsymmetadata.cpp,v
retrieving revision 1.1.10.1
diff -u -w -r1.1.10.1 hxsymmetadata.cpp
--- clientapps/symbiancommon/hxsymmetadata.cpp 11 Jan 2010 16:19:41 -0000 1.1.10.1
+++ clientapps/symbiancommon/hxsymmetadata.cpp 15 Mar 2010 19:35:07 -0000
@@ -236,6 +236,54 @@
++iter;
}
+ // ISO time base midnight 01/01/1904 UTC
+ const TTime mp4timebase = TDateTime(1904, EJanuary, 0, 0, 0, 0, 0);
+ const TTime posixtimebase = TDateTime(1970, EJanuary, 0, 0, 0, 0, 0);
+ TTimeIntervalMicroSeconds intervalMicroSec = posixtimebase.MicroSecondsFrom(mp4timebase);
+ UINT32 intervalSec = INT64_TO_UINT32(intervalMicroSec.Int64()/TInt64(1000000));
+
+ // content creation_time in seconds since 01/01/1904 UTC
+ // from mvhd box ISO/IEC 14496-12:2004 section 8.3
+ UINT32 clipCreationTimeInSec = 0;
+ if(val::GetUINT32( header, "CreationTime", clipCreationTimeInSec))
+ {
+ // convert to seconds in POSIX time base 01/01/1970
+ TInt posixCreationTime = clipCreationTimeInSec - intervalSec;
+ AddToClipInfoL("CreationTime", posixCreationTime);
+ }
+
+ // content modification_time in seconds since 01/01/1904
+ // from mvhd box ISO/IEC 14496-12:2004 section 8.3
+ UINT32 clipModTimeInSec = 0;
+ if(val::GetUINT32( header, "ModificationTime", clipModTimeInSec))
+ {
+ //convert to seconds in POSIX time base 01/01/1970
+ TInt posixModTime = clipModTimeInSec - intervalSec;
+ AddToClipInfoL("ModificationTime", posixModTime);
+ }
+
+ UINT32 wmCreationTimeLow = 0;
+ UINT32 wmCreationTimeHigh = 0;
+ if(val::GetUINT32( header, "CreationDateWMLow", wmCreationTimeLow) &&
+ val::GetUINT32( header, "CreationDateWMHigh", wmCreationTimeHigh))
+ {
+ // WM content creation time in microseconds since 01/01/1601
+ UINT64 wmCreationTime = (((UINT64) wmCreationTimeHigh) << 32) | ((UINT64) wmCreationTimeLow);
+ const TTime wmtimebase = TDateTime(1601, EJanuary, 0, 0, 0, 0, 0);
+ TTimeIntervalMicroSeconds wminterval = posixtimebase.MicroSecondsFrom(wmtimebase);
+ // convert to seconds in POSIX time base 01/01/1970
+ TInt wmposixCreationTime = (TInt) (((TInt64)wmCreationTime - wminterval.Int64()) / TInt64(1000000));
+ AddToClipInfoL("CreationTime",wmposixCreationTime);
+ }
+
+ // matroska content creation time in seconds in POSIX time base 01/01/1970
+ UINT32 mkvClipCreationTimeInSec = 0;
+ if(val::GetUINT32( header, "CreationTimeMKV", mkvClipCreationTimeInSec) &&
+ ( mkvClipCreationTimeInSec > 0) )
+ {
+ AddToClipInfoL("CreationTime", mkvClipCreationTimeInSec);
+ }
+
TInt isLive = m_clipHeader.IsLive();
if ( isLive )
Index: datatype/mkv/fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.1.2.3
diff -u -w -r1.1.1.1.2.1.2.3 mkv_file_format.cpp
--- datatype/mkv/fileformat/mkv_file_format.cpp 23 Dec 2009 22:31:05 -0000 1.1.1.1.2.1.2.3
+++ datatype/mkv/fileformat/mkv_file_format.cpp 15 Mar 2010 19:35:43 -0000
@@ -653,6 +653,8 @@
// Set the stream count
pHdr->SetPropertyULONG32("StreamCount", m_pMKVHandle->NumTracks());
pHdr->SetPropertyULONG32("Duration", m_pMKVHandle->DurationMS());
+ // set creation date/time in seconds measured relatively to Jan 01, 2001
+ pHdr->SetPropertyULONG32("CreationTimeMKV", m_pMKVHandle->EpochDate());
retVal = SetTags(pHdr);
Index: datatype/mp4/fileformat/qtatmmgs.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtatmmgs.cpp,v
retrieving revision 1.56.2.1.2.3
diff -u -w -r1.56.2.1.2.3 qtatmmgs.cpp
--- datatype/mp4/fileformat/qtatmmgs.cpp 23 Dec 2009 22:50:29 -0000 1.56.2.1.2.3
+++ datatype/mp4/fileformat/qtatmmgs.cpp 15 Mar 2010 19:35:43 -0000
@@ -2633,6 +2633,8 @@
CQT_MovieInfo_Manager::CQT_MovieInfo_Manager(void)
: m_ulMovieTimeScale(0)
, m_ulMovieDuration(0)
+ , m_ulMovieCreationTime(0)
+ , m_ulMovieModificationTime(0)
, m_pNameAtom(NULL)
#ifdef QTCONFIG_3GPP_TAC
@@ -2697,6 +2699,8 @@
m_ulMovieTimeScale = 0;
m_ulMovieDuration = 0;
+ m_ulMovieCreationTime = 0;
+ m_ulMovieModificationTime = 0;
HX_RELEASE(m_pNameAtom);
#ifdef QTCONFIG_3GPP_TAC
@@ -2737,6 +2741,8 @@
{
m_ulMovieTimeScale = pMovieHeaderAtom->Get_TimeScale();
m_ulMovieDuration = pMovieHeaderAtom->Get_Duration();
+ m_ulMovieCreationTime = pMovieHeaderAtom->Get_CreationTime();
+ m_ulMovieModificationTime = pMovieHeaderAtom->Get_ModificationTime();
}
else if(pRmraHeaderAtom)
{
Index: datatype/mp4/fileformat/qtffplin.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
retrieving revision 1.77.4.1
diff -u -w -r1.77.4.1 qtffplin.cpp
--- datatype/mp4/fileformat/qtffplin.cpp 23 Dec 2009 22:51:43 -0000 1.77.4.1
+++ datatype/mp4/fileformat/qtffplin.cpp 15 Mar 2010 19:35:44 -0000
@@ -1047,6 +1047,8 @@
m_ulFileDuration = (ULONG32) ((1000.0 * ((double) m_MovieInfo.GetMovieDuration())) /
m_MovieInfo.GetMovieTimeScale());
pHeader->SetPropertyULONG32("Duration", m_ulFileDuration);
+ pHeader->SetPropertyULONG32("CreationTime", m_MovieInfo.GetMovieCreationTime());
+ pHeader->SetPropertyULONG32("ModificationTime", m_MovieInfo.GetMovieModificationTime());
}
if (SUCCEEDED(status) && m_TrackManager.AreStreamGroupsPresent())
Index: datatype/mp4/fileformat/pub/qtatmmgs.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatmmgs.h,v
retrieving revision 1.28.4.3
diff -u -w -r1.28.4.3 qtatmmgs.h
--- datatype/mp4/fileformat/pub/qtatmmgs.h 7 Jan 2010 07:52:19 -0000 1.28.4.3
+++ datatype/mp4/fileformat/pub/qtatmmgs.h 15 Mar 2010 19:35:44 -0000
@@ -726,6 +726,8 @@
ULONG32 GetMovieTimeScale(void) { return m_ulMovieTimeScale; }
ULONG32 GetMovieDuration(void) { return m_ulMovieDuration; }
+ ULONG32 GetMovieCreationTime(void) { return m_ulMovieCreationTime; }
+ ULONG32 GetMovieModificationTime(void) { return m_ulMovieModificationTime; }
//*** Name Atom **********************************************
@@ -1028,6 +1030,8 @@
char *m_pRefURL;
ULONG32 m_ulMovieTimeScale;
ULONG32 m_ulMovieDuration;
+ ULONG32 m_ulMovieCreationTime;
+ ULONG32 m_ulMovieModificationTime;
CQT_name_Atom* m_pNameAtom;
Index: datatype/mp4/fileformat/pub/qtatoms.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatoms.h,v
retrieving revision 1.35.4.1
diff -u -w -r1.35.4.1 qtatoms.h
--- datatype/mp4/fileformat/pub/qtatoms.h 23 Dec 2009 22:38:29 -0000 1.35.4.1
+++ datatype/mp4/fileformat/pub/qtatoms.h 15 Mar 2010 19:35:44 -0000
@@ -364,6 +364,28 @@
return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pDuration));
}
+
+ ULONG32 Get_CreationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pCreatTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pCreatTime));
+ }
+
+ ULONG32 Get_ModificationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pModifTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pModifTime));
+ }
};
/****************************************************************************
Index: datatype/wm/fileformat/asf_file_format_file.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
retrieving revision 1.22.4.3
diff -u -w -r1.22.4.3 asf_file_format_file.cpp
--- datatype/wm/fileformat/asf_file_format_file.cpp 3 Mar 2010 23:14:52 -0000 1.22.4.3
+++ datatype/wm/fileformat/asf_file_format_file.cpp 15 Mar 2010 19:35:45 -0000
@@ -1520,6 +1520,22 @@
ullDuration -= m_pFilePropertiesObject->m_ullPreroll;
// Convert from UINT64 to UINT32
ulDuration = INT64_TO_UINT32(ullDuration);
+
+ if( !m_pFilePropertiesObject->IsFlagSet(HXASFFilePropertiesFlags_Broadcast))
+ {
+ // Creation Date: Specifies the date and time of the initial creation of the file.
+ // The value is given as the number of 100-nanosecond intervals since January 1, 1601,
+ // according to Coordinated Universal Time (Greenwich Mean Time).
+ // The value of this field is invalid if the Broadcast Flag bit (Bit 0 LSB) in the Flags field is set.
+
+ // convert to microseconds
+ UINT64 ullCreationDate = m_pFilePropertiesObject->m_ullCreationDate/((UINT64) 10);
+ UINT32 ulCreationDateLow = INT64_TO_UINT32(ullCreationDate & 0xFFFFFFFF);
+ UINT32 ulCreationDateHigh = INT64_TO_UINT32((ullCreationDate & 0xFFFFFFFF00000000) >> 32);
+
+ pHdr->SetPropertyULONG32("CreationDateWMLow", ulCreationDateLow);
+ pHdr->SetPropertyULONG32("CreationDateWMHigh",ulCreationDateHigh);
+ }
}
// Set the duration property
pHdr->SetPropertyULONG32("Duration", ulDuration);
? datatype/mkv/libmatroska/Makefile
? datatype/mkv/libmatroska/Umakefil.upp
? datatype/mkv/libmatroska/armv5-rel32
Index: datatype/mkv/libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.1.2.5
diff -u -w -r1.1.1.1.2.1.2.5 Matroska.cpp
--- datatype/mkv/libmatroska/Matroska.cpp 2 Mar 2010 22:12:16 -0000 1.1.1.1.2.1.2.5
+++ datatype/mkv/libmatroska/Matroska.cpp 15 Mar 2010 19:36:52 -0000
@@ -46,6 +46,7 @@
,m_uTimescale(TIMECODESCALE)
,m_uDuration(0)
,m_uStartPos(0)
+ ,m_uEpochDate(0)
,m_bCues(FALSE)
,m_pES(estream)
,m_pSegTitle(NULL)
@@ -600,6 +601,11 @@
UTFstring uStr(title);
m_pSegTitle = strdup( uStr.GetUTF8() );
}
+ else if( EbmlId(*el) == KaxDateUTC::ClassInfos->GlobalId )
+ {
+ KaxDateUTC &date = *(KaxDateUTC*)el;
+ m_uEpochDate = date.GetEpochDate();
+ }
}
m_uDuration = UINT64(double(m_uDuration) * double(m_uTimescale) / 1000000.0);
Index: datatype/mkv/libmatroska/Matroska.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 Matroska.h
--- datatype/mkv/libmatroska/Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/Matroska.h 15 Mar 2010 19:36:52 -0000
@@ -43,6 +43,7 @@
UINT64 m_uTimescale;
UINT64 m_uDuration;
UINT64 m_uStartPos;
+ UINT32 m_uEpochDate;
char *m_pSegTitle;
char *m_pTagTitle;
Index: datatype/mkv/libmatroska/MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.cpp
--- datatype/mkv/libmatroska/MatroskaExports.cpp 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.cpp 15 Mar 2010 19:36:52 -0000
@@ -60,6 +60,17 @@
return -1;
}
+int32 MatroskaExports::EpochDate()
+{
+ if(m_pSeg)
+ {
+ return m_pSeg->m_uEpochDate;
+ }
+
+ return -1;
+}
+
+
int MatroskaExports::NumTracks()
{
if(m_pSeg)
Index: datatype/mkv/libmatroska/MatroskaExports.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.h
--- datatype/mkv/libmatroska/MatroskaExports.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.h 15 Mar 2010 19:36:52 -0000
@@ -21,6 +21,7 @@
static MatroskaExports* Init(libebml::IOCallback &);
int64 DurationMS();
+ int32 EpochDate();
int NumTracks();
char* TagAuthor();
From sfu at real.com Thu Mar 18 08:30:53 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 15:39:17 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To:
References:
Message-ID: <4BA2553D.2060100@real.com>
It might be better for re-usability if we let each file format plugin
convert the time/date values into a standard format (e.g. POSIX 1/1/1970
based) , rather than letting them set the values with the native format
and let TLC converts them.
fxd
Yury.Ramanovich@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: _yury.ramanovich@nokia.com_
>
>
> Reviewed by:
>
> Date: 03/18/2010
>
> Project: symbian_client_apps
>
> ErrorId: req. 417-59758
>
> Synopsis: added helix support for extraction of ?CreationTime? and
> ?ModificationTime? content metadata for .3gp, .mp4, .mkv, .wmv file
> formats
>
> Overview: in order to allow user to see creation date/time and
> modification date/time of recorded video clips, helix needs to extract
> corresponding metadata from content and make it available to UI. The
> support of content creation date/time and modification date/time
> metadata by different file formats is not consistent. Some formats
> have both time values, some formats have only "CreationTime" and other
> formats don't provide any such info at all. Moreover, time base
> conversion is needed, since each format stores these time/date values
> in different time units and relative to different time bases and UI
> needs those values in seconds relative to POSIX time base 01/01/1970
> 0:0:0 UTC. If a particular file format doesn't provide "CreationTime"
> and/or "ModificationTime" values to UI or it is missing in the file?s
> metadata, then UI will substitute with values obtained via QT APIs
> from filesystem.
>
> Solution:
> Added support for retrieving "CreationTime" and "ModificationTime"
> metadata from .3gp and .mp4 files; "CreationTime" only is retrieved
> for WindowsMedia (.wm) and Matroska (.mkv) files. The ?CreationTime?
> and ?ModificationTIme? values, if any, will be converted to seconds
> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to UI.
> Note that not all tools that create Matroska (.mkv) files, write out
> this info in the Segment. RealMedia and AVI file formats do not seem
> to have any creation/modification time info.
>
> Files Added:
> None.
>
> Files Modified:
>
> /clientapps/symbiancommon/hxsymmetadata.cpp
> /datatype/mkv/fileformat/mkv_file_format.cpp
> /datatype/mp4/fileformat/qtatmmgs.cpp
> /datatype/mp4/fileformat/qtffplin.cpp
> /datatype/mp4/fileformat/pub/qtatmmgs.h
> /datatype/mp4/fileformat/pub/qtatoms.h
> /datatype/wm/fileformat/asf_file_format_file.cpp
> /xiph/matroskalib/Matroska.cpp
> /xiph/matroskalib/Matroska.h
> /xiph/matroskalib/MatroskaExports.cpp
> /xiph/matroskalib/MatroskaExports.h
>
>
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : Ongoing
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced
>
> Platforms and Profiles Build Verified:
> helix-client-symbian-4
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 420Brizo, HEAD
>
>
>
From Yury.Ramanovich at Nokia.com Thu Mar 18 09:54:45 2010
From: Yury.Ramanovich at Nokia.com (Yury.Ramanovich@Nokia.com)
Date: Thu Mar 18 17:03:26 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To: <4BA2553D.2060100@real.com>
References:
<4BA2553D.2060100@real.com>
Message-ID:
Hi
I just wanted to minimize impact on all the formats and preserve the original values as much as I can; plus I don't see any convenient apis in fileformats to deal with timebase conversions apart from some ad-hoc calculations and magic numbers.
BR
Yury
>-----Original Message-----
>From: ext Sheldon Fu [mailto:sfu@real.com]
>Sent: Thursday, March 18, 2010 11:31 AM
>To: Ramanovich Yury (Nokia-D/Dallas)
>Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>support for 'CreationTime" and "ModificationTime" content metadata
>
>It might be better for re-usability if we let each file format plugin
>convert the time/date values into a standard format (e.g. POSIX 1/1/1970
>based) , rather than letting them set the values with the native format
>and let TLC converts them.
>
>fxd
>
>Yury.Ramanovich@nokia.com wrote:
>> "Nokia submits this code under the terms of a commercial contribution
>> agreement with RealNetworks, and I am authorized to contribute this
>> code under said agreement."
>>
>> Modified by: _yury.ramanovich@nokia.com_
>>
>>
>> Reviewed by:
>>
>> Date: 03/18/2010
>>
>> Project: symbian_client_apps
>>
>> ErrorId: req. 417-59758
>>
>> Synopsis: added helix support for extraction of "CreationTime" and
>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv file
>> formats
>>
>> Overview: in order to allow user to see creation date/time and
>> modification date/time of recorded video clips, helix needs to extract
>> corresponding metadata from content and make it available to UI. The
>> support of content creation date/time and modification date/time
>> metadata by different file formats is not consistent. Some formats
>> have both time values, some formats have only "CreationTime" and other
>> formats don't provide any such info at all. Moreover, time base
>> conversion is needed, since each format stores these time/date values
>> in different time units and relative to different time bases and UI
>> needs those values in seconds relative to POSIX time base 01/01/1970
>> 0:0:0 UTC. If a particular file format doesn't provide "CreationTime"
>> and/or "ModificationTime" values to UI or it is missing in the file's
>> metadata, then UI will substitute with values obtained via QT APIs
>> from filesystem.
>>
>> Solution:
>> Added support for retrieving "CreationTime" and "ModificationTime"
>> metadata from .3gp and .mp4 files; "CreationTime" only is retrieved
>> for WindowsMedia (.wm) and Matroska (.mkv) files. The 'CreationTime"
>> and "ModificationTIme" values, if any, will be converted to seconds
>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to UI.
>> Note that not all tools that create Matroska (.mkv) files, write out
>> this info in the Segment. RealMedia and AVI file formats do not seem
>> to have any creation/modification time info.
>>
>> Files Added:
>> None.
>>
>> Files Modified:
>>
>> /clientapps/symbiancommon/hxsymmetadata.cpp
>> /datatype/mkv/fileformat/mkv_file_format.cpp
>> /datatype/mp4/fileformat/qtatmmgs.cpp
>> /datatype/mp4/fileformat/qtffplin.cpp
>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>> /datatype/mp4/fileformat/pub/qtatoms.h
>> /datatype/wm/fileformat/asf_file_format_file.cpp
>> /xiph/matroskalib/Matroska.cpp
>> /xiph/matroskalib/Matroska.h
>> /xiph/matroskalib/MatroskaExports.cpp
>> /xiph/matroskalib/MatroskaExports.h
>>
>>
>>
>> Image Size and Heap Use impact: minor
>>
>> Module Release testing (STIF) : Ongoing
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes. No new leaks introduced
>>
>> Platforms and Profiles Build Verified:
>> helix-client-symbian-4
>>
>> Platforms and Profiles Functionality verified: armv5, winscw
>>
>> Branch: 420Brizo, HEAD
>>
>>
>>
From sfu at real.com Thu Mar 18 10:15:53 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 17:24:13 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To:
References:
<4BA2553D.2060100@real.com>
Message-ID: <4BA26DD9.5050503@real.com>
The time base conversion logic certainly is not platform dependent.
Helix may not have a handy class/function for that yet but you can add
it. For this to be useful for Helix community as a whole, these time
values really should come in with a standard format (doesn't matter
which format). These are one time calculation per clip. I don't' think
they have any impact on file format's performance or logic.
You can check you change into Nokia's 420brizo branch now, but for Head,
it would be nice if the values are in a unified format.
fxd
Yury.Ramanovich@Nokia.com wrote:
> Hi
> I just wanted to minimize impact on all the formats and preserve the original values as much as I can; plus I don't see any convenient apis in fileformats to deal with timebase conversions apart from some ad-hoc calculations and magic numbers.
>
> BR
> Yury
>
>> -----Original Message-----
>> From: ext Sheldon Fu [mailto:sfu@real.com]
>> Sent: Thursday, March 18, 2010 11:31 AM
>> To: Ramanovich Yury (Nokia-D/Dallas)
>> Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>> support for 'CreationTime" and "ModificationTime" content metadata
>>
>> It might be better for re-usability if we let each file format plugin
>> convert the time/date values into a standard format (e.g. POSIX 1/1/1970
>> based) , rather than letting them set the values with the native format
>> and let TLC converts them.
>>
>> fxd
>>
>> Yury.Ramanovich@nokia.com wrote:
>>
>>> "Nokia submits this code under the terms of a commercial contribution
>>> agreement with RealNetworks, and I am authorized to contribute this
>>> code under said agreement."
>>>
>>> Modified by: _yury.ramanovich@nokia.com_
>>>
>>>
>>> Reviewed by:
>>>
>>> Date: 03/18/2010
>>>
>>> Project: symbian_client_apps
>>>
>>> ErrorId: req. 417-59758
>>>
>>> Synopsis: added helix support for extraction of "CreationTime" and
>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv file
>>> formats
>>>
>>> Overview: in order to allow user to see creation date/time and
>>> modification date/time of recorded video clips, helix needs to extract
>>> corresponding metadata from content and make it available to UI. The
>>> support of content creation date/time and modification date/time
>>> metadata by different file formats is not consistent. Some formats
>>> have both time values, some formats have only "CreationTime" and other
>>> formats don't provide any such info at all. Moreover, time base
>>> conversion is needed, since each format stores these time/date values
>>> in different time units and relative to different time bases and UI
>>> needs those values in seconds relative to POSIX time base 01/01/1970
>>> 0:0:0 UTC. If a particular file format doesn't provide "CreationTime"
>>> and/or "ModificationTime" values to UI or it is missing in the file's
>>> metadata, then UI will substitute with values obtained via QT APIs
>>> from filesystem.
>>>
>>> Solution:
>>> Added support for retrieving "CreationTime" and "ModificationTime"
>>> metadata from .3gp and .mp4 files; "CreationTime" only is retrieved
>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The 'CreationTime"
>>> and "ModificationTIme" values, if any, will be converted to seconds
>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to UI.
>>> Note that not all tools that create Matroska (.mkv) files, write out
>>> this info in the Segment. RealMedia and AVI file formats do not seem
>>> to have any creation/modification time info.
>>>
>>> Files Added:
>>> None.
>>>
>>> Files Modified:
>>>
>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>> /datatype/mp4/fileformat/qtffplin.cpp
>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>> /xiph/matroskalib/Matroska.cpp
>>> /xiph/matroskalib/Matroska.h
>>> /xiph/matroskalib/MatroskaExports.cpp
>>> /xiph/matroskalib/MatroskaExports.h
>>>
>>>
>>>
>>> Image Size and Heap Use impact: minor
>>>
>>> Module Release testing (STIF) : Ongoing
>>>
>>> Test case(s) Added : No.
>>>
>>> Memory leak check performed : Yes. No new leaks introduced
>>>
>>> Platforms and Profiles Build Verified:
>>> helix-client-symbian-4
>>>
>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>
>>> Branch: 420Brizo, HEAD
>>>
>>>
>>>
>>>
>
> .
>
>
From Alvaro.Vaquero at nokia.com Thu Mar 18 10:55:51 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Thu Mar 18 18:04:11 2010
Subject: [datatype-dev] RESEND: CR: EGRS-83FRVP Long duration MKV clips take
20-25 seconds to start playing
Message-ID:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: alvaro.vaquero@nokia.com
Reviewed by:
Date: 03/17/2010
Project: SymbianMmf_wm
ErrorId: EGRS-83FRVP
Synopsis: Long duration MKV clips take 20-25 seconds to start playing
Overview:
Due to the nature of Mkv container the fileformat currently parses the complete file looking for the different elements. It seems skipping through the clusters is not very efficient and it's taking the most time. In this CR the SeekHead element is used to only parse one cluster and skip directly to the different locations of interest in the file. However, this optimization should have no effect if the seekhead is not present in the file. I've also cleaned up a few comments from the ebml files.
>From the two tested clips this are the results:
File A:
Pre Optimization Parsing Headers Time: 136.885
Post Optimization Parsing Headers Time: 1.333
File B:
Pre Optimization Parsing Headers Time: 31.140
Post Optimization Parsing Headers Time: 4.328
Files Added: None.
Files Modified:
/datatype/mkv/libmatroska/Matroska.cpp
/datatype/mkv/libmatroska/libebml/ebml/EbmlCrc32.h
/datatype/mkv/libmatroska/libebml/ebml/EbmlDummy.h
/datatype/mkv/libmatroska/libebml/ebml/EbmlElement.h
/datatype/mkv/libmatroska/libebml/ebml/EbmlHead.h
/datatype/mkv/libmatroska/libebml/ebml/EbmlSubHead.h
/datatype/mkv/libmatroska/libebml/ebml/EbmlVoid.h
/datatype/mkv/libmatroska/libebml/src/EbmlElement.cpp
/datatype/mkv/libmatroska/libebml/src/EbmlMaster.cpp
Image Size and Heap Use impact: minor
Module Release testing (STIF) : Passed
Test case(s) Added : No.
Memory leak check performed : Yes. No new leaks introduced
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Cays210, Brizo420, HEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100318/1fcdc90a/attachment-0001.html
From Yury.Ramanovich at nokia.com Thu Mar 18 12:39:20 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Mar 18 19:48:04 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To: <4BA26DD9.5050503@real.com>
References:
<4BA2553D.2060100@real.com>
<4BA26DD9.5050503@real.com>
Message-ID:
Sheldon, please see the new diff, where creation time and modification time metadata converted to seconds relative to POSIX time base 01/01/1970 UTC before setting them in file header values map. This is for mp4, wm, mkv file formats.
BR
Yury
>-----Original Message-----
>From: ext Sheldon Fu [mailto:sfu@real.com]
>Sent: Thursday, March 18, 2010 1:16 PM
>To: Ramanovich Yury (Nokia-D/Dallas)
>Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>support for 'CreationTime" and "ModificationTime" content metadata
>
>The time base conversion logic certainly is not platform dependent.
>Helix may not have a handy class/function for that yet but you can add
>it. For this to be useful for Helix community as a whole, these time
>values really should come in with a standard format (doesn't matter
>which format). These are one time calculation per clip. I don't' think
>they have any impact on file format's performance or logic.
>
>You can check you change into Nokia's 420brizo branch now, but for Head,
>it would be nice if the values are in a unified format.
>
>fxd
>
>
>Yury.Ramanovich@Nokia.com wrote:
>> Hi
>> I just wanted to minimize impact on all the formats and preserve the
>original values as much as I can; plus I don't see any convenient apis
>in fileformats to deal with timebase conversions apart from some ad-hoc
>calculations and magic numbers.
>>
>> BR
>> Yury
>>
>>> -----Original Message-----
>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>> Sent: Thursday, March 18, 2010 11:31 AM
>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>dev@helixcommunity.org
>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>helix
>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>
>>> It might be better for re-usability if we let each file format plugin
>>> convert the time/date values into a standard format (e.g. POSIX
>1/1/1970
>>> based) , rather than letting them set the values with the native
>format
>>> and let TLC converts them.
>>>
>>> fxd
>>>
>>> Yury.Ramanovich@nokia.com wrote:
>>>
>>>> "Nokia submits this code under the terms of a commercial
>contribution
>>>> agreement with RealNetworks, and I am authorized to contribute this
>>>> code under said agreement."
>>>>
>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>
>>>>
>>>> Reviewed by:
>>>>
>>>> Date: 03/18/2010
>>>>
>>>> Project: symbian_client_apps
>>>>
>>>> ErrorId: req. 417-59758
>>>>
>>>> Synopsis: added helix support for extraction of "CreationTime" and
>>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv file
>>>> formats
>>>>
>>>> Overview: in order to allow user to see creation date/time and
>>>> modification date/time of recorded video clips, helix needs to
>extract
>>>> corresponding metadata from content and make it available to UI. The
>>>> support of content creation date/time and modification date/time
>>>> metadata by different file formats is not consistent. Some formats
>>>> have both time values, some formats have only "CreationTime" and
>other
>>>> formats don't provide any such info at all. Moreover, time base
>>>> conversion is needed, since each format stores these time/date
>values
>>>> in different time units and relative to different time bases and UI
>>>> needs those values in seconds relative to POSIX time base 01/01/1970
>>>> 0:0:0 UTC. If a particular file format doesn't provide
>"CreationTime"
>>>> and/or "ModificationTime" values to UI or it is missing in the
>file's
>>>> metadata, then UI will substitute with values obtained via QT APIs
>>>> from filesystem.
>>>>
>>>> Solution:
>>>> Added support for retrieving "CreationTime" and "ModificationTime"
>>>> metadata from .3gp and .mp4 files; "CreationTime" only is
>retrieved
>>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The
>'CreationTime"
>>>> and "ModificationTIme" values, if any, will be converted to seconds
>>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to
>UI.
>>>> Note that not all tools that create Matroska (.mkv) files, write out
>>>> this info in the Segment. RealMedia and AVI file formats do not seem
>>>> to have any creation/modification time info.
>>>>
>>>> Files Added:
>>>> None.
>>>>
>>>> Files Modified:
>>>>
>>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>>> /datatype/mp4/fileformat/qtffplin.cpp
>>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>>> /xiph/matroskalib/Matroska.cpp
>>>> /xiph/matroskalib/Matroska.h
>>>> /xiph/matroskalib/MatroskaExports.cpp
>>>> /xiph/matroskalib/MatroskaExports.h
>>>>
>>>>
>>>>
>>>> Image Size and Heap Use impact: minor
>>>>
>>>> Module Release testing (STIF) : Ongoing
>>>>
>>>> Test case(s) Added : No.
>>>>
>>>> Memory leak check performed : Yes. No new leaks introduced
>>>>
>>>> Platforms and Profiles Build Verified:
>>>> helix-client-symbian-4
>>>>
>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>
>>>> Branch: 420Brizo, HEAD
>>>>
>>>>
>>>>
>>>>
>>
>> .
>>
>>
-------------- next part --------------
Index: clientapps/symbiancommon/hxsymmetadata.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbiancommon/hxsymmetadata.cpp,v
retrieving revision 1.1.10.1
diff -u -w -r1.1.10.1 hxsymmetadata.cpp
--- clientapps/symbiancommon/hxsymmetadata.cpp 11 Jan 2010 16:19:41 -0000 1.1.10.1
+++ clientapps/symbiancommon/hxsymmetadata.cpp 18 Mar 2010 20:30:33 -0000
@@ -236,6 +236,43 @@
++iter;
}
+
+ // content creation_time in seconds since 01/01/1904 UTC
+ // from mvhd box ISO/IEC 14496-12:2004 section 8.3
+ // converted to seconds in POSIX time base 01/01/1970
+ UINT32 clipPosixCreationTimeSec = 0;
+ if(val::GetUINT32( header, "CreationTime", clipPosixCreationTimeSec) &&
+ ( clipPosixCreationTimeSec > 0 ) )
+ {
+ AddToClipInfoL("CreationTime", clipPosixCreationTimeSec);
+ }
+
+ // content modification_time in seconds since 01/01/1904 UTC
+ // from mvhd box ISO/IEC 14496-12:2004 section 8.3
+ // converted to seconds in POSIX time base 01/01/1970
+ UINT32 clipPosixModTimeSec = 0;
+ if(val::GetUINT32( header, "ModificationTime", clipPosixModTimeSec) &&
+ ( clipPosixModTimeSec > 0) )
+ {
+ AddToClipInfoL("ModificationTime", clipPosixModTimeSec);
+ }
+
+ // WM content creation time in seconds in POSIX time base 01/01/1970
+ UINT32 wmPosixCreationTimeSec = 0;
+ if(val::GetUINT32( header, "CreationDateWM", wmPosixCreationTimeSec) &&
+ ( wmPosixCreationTimeSec > 0) )
+ {
+ AddToClipInfoL("CreationTime",wmPosixCreationTimeSec);
+ }
+
+ // matroska content creation time in seconds in POSIX time base 01/01/1970
+ UINT32 mkvClipCreationTimeSec = 0;
+ if(val::GetUINT32( header, "CreationTimeMKV", mkvClipCreationTimeSec) &&
+ ( mkvClipCreationTimeSec > 0) )
+ {
+ AddToClipInfoL("CreationTime", mkvClipCreationTimeSec);
+ }
+
TInt isLive = m_clipHeader.IsLive();
if ( isLive )
Index: datatype/mkv/fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.1.2.3
diff -u -w -r1.1.1.1.2.1.2.3 mkv_file_format.cpp
--- datatype/mkv/fileformat/mkv_file_format.cpp 23 Dec 2009 22:31:05 -0000 1.1.1.1.2.1.2.3
+++ datatype/mkv/fileformat/mkv_file_format.cpp 18 Mar 2010 20:31:27 -0000
@@ -653,6 +653,8 @@
// Set the stream count
pHdr->SetPropertyULONG32("StreamCount", m_pMKVHandle->NumTracks());
pHdr->SetPropertyULONG32("Duration", m_pMKVHandle->DurationMS());
+ // set creation date/time in seconds measured relatively POSIX time base 01/01/1970 UTC
+ pHdr->SetPropertyULONG32("CreationTimeMKV", m_pMKVHandle->EpochDate());
retVal = SetTags(pHdr);
Index: datatype/mp4/fileformat/qtatmmgs.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtatmmgs.cpp,v
retrieving revision 1.56.2.1.2.3
diff -u -w -r1.56.2.1.2.3 qtatmmgs.cpp
--- datatype/mp4/fileformat/qtatmmgs.cpp 23 Dec 2009 22:50:29 -0000 1.56.2.1.2.3
+++ datatype/mp4/fileformat/qtatmmgs.cpp 18 Mar 2010 20:31:28 -0000
@@ -2633,6 +2633,8 @@
CQT_MovieInfo_Manager::CQT_MovieInfo_Manager(void)
: m_ulMovieTimeScale(0)
, m_ulMovieDuration(0)
+ , m_ulMovieCreationTime(0)
+ , m_ulMovieModificationTime(0)
, m_pNameAtom(NULL)
#ifdef QTCONFIG_3GPP_TAC
@@ -2697,6 +2699,8 @@
m_ulMovieTimeScale = 0;
m_ulMovieDuration = 0;
+ m_ulMovieCreationTime = 0;
+ m_ulMovieModificationTime = 0;
HX_RELEASE(m_pNameAtom);
#ifdef QTCONFIG_3GPP_TAC
@@ -2737,6 +2741,8 @@
{
m_ulMovieTimeScale = pMovieHeaderAtom->Get_TimeScale();
m_ulMovieDuration = pMovieHeaderAtom->Get_Duration();
+ m_ulMovieCreationTime = pMovieHeaderAtom->Get_CreationTime();
+ m_ulMovieModificationTime = pMovieHeaderAtom->Get_ModificationTime();
}
else if(pRmraHeaderAtom)
{
Index: datatype/mp4/fileformat/qtffplin.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
retrieving revision 1.77.4.1
diff -u -w -r1.77.4.1 qtffplin.cpp
--- datatype/mp4/fileformat/qtffplin.cpp 23 Dec 2009 22:51:43 -0000 1.77.4.1
+++ datatype/mp4/fileformat/qtffplin.cpp 18 Mar 2010 20:31:35 -0000
@@ -127,6 +127,7 @@
const char* const CQTFileFormat::zm_pPacketFormats[] = {"rtp", "rdt", NULL};
+const ULONG32 CQTFileFormat::m_ulMp4PosixTimeDiffSec = 2082844800;
/****************************************************************************
* Globals
@@ -1047,6 +1048,9 @@
m_ulFileDuration = (ULONG32) ((1000.0 * ((double) m_MovieInfo.GetMovieDuration())) /
m_MovieInfo.GetMovieTimeScale());
pHeader->SetPropertyULONG32("Duration", m_ulFileDuration);
+ // set CreationTime and ModificationTime in seconds in POSIX time 01/01/1970 UTC
+ pHeader->SetPropertyULONG32("CreationTime", m_MovieInfo.GetMovieCreationTime() - m_ulMp4PosixTimeDiffSec);
+ pHeader->SetPropertyULONG32("ModificationTime", m_MovieInfo.GetMovieModificationTime() - m_ulMp4PosixTimeDiffSec);
}
if (SUCCEEDED(status) && m_TrackManager.AreStreamGroupsPresent())
Index: datatype/mp4/fileformat/pub/qtatmmgs.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatmmgs.h,v
retrieving revision 1.28.4.3
diff -u -w -r1.28.4.3 qtatmmgs.h
--- datatype/mp4/fileformat/pub/qtatmmgs.h 7 Jan 2010 07:52:19 -0000 1.28.4.3
+++ datatype/mp4/fileformat/pub/qtatmmgs.h 18 Mar 2010 20:31:35 -0000
@@ -726,6 +726,8 @@
ULONG32 GetMovieTimeScale(void) { return m_ulMovieTimeScale; }
ULONG32 GetMovieDuration(void) { return m_ulMovieDuration; }
+ ULONG32 GetMovieCreationTime(void) { return m_ulMovieCreationTime; }
+ ULONG32 GetMovieModificationTime(void) { return m_ulMovieModificationTime; }
//*** Name Atom **********************************************
@@ -1028,6 +1030,8 @@
char *m_pRefURL;
ULONG32 m_ulMovieTimeScale;
ULONG32 m_ulMovieDuration;
+ ULONG32 m_ulMovieCreationTime;
+ ULONG32 m_ulMovieModificationTime;
CQT_name_Atom* m_pNameAtom;
Index: datatype/mp4/fileformat/pub/qtatoms.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatoms.h,v
retrieving revision 1.35.4.1
diff -u -w -r1.35.4.1 qtatoms.h
--- datatype/mp4/fileformat/pub/qtatoms.h 23 Dec 2009 22:38:29 -0000 1.35.4.1
+++ datatype/mp4/fileformat/pub/qtatoms.h 18 Mar 2010 20:31:38 -0000
@@ -364,6 +364,28 @@
return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pDuration));
}
+
+ ULONG32 Get_CreationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pCreatTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pCreatTime));
+ }
+
+ ULONG32 Get_ModificationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pModifTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pModifTime));
+ }
};
/****************************************************************************
Index: datatype/mp4/fileformat/pub/qtffplin.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtffplin.h,v
retrieving revision 1.23.4.1
diff -u -w -r1.23.4.1 qtffplin.h
--- datatype/mp4/fileformat/pub/qtffplin.h 23 Dec 2009 22:39:10 -0000 1.23.4.1
+++ datatype/mp4/fileformat/pub/qtffplin.h 18 Mar 2010 20:31:38 -0000
@@ -374,6 +374,7 @@
static const char* const zm_pFileExtensions[];
static const char* const zm_pFileOpenNames[];
static const char* const zm_pPacketFormats[];
+ static const ULONG32 m_ulMp4PosixTimeDiffSec;
#ifdef QTCONFIG_FSWITCHER
IHXFileSwitcher2* m_pFileSwitcher;
Index: datatype/wm/fileformat/asf_file_format_file.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
retrieving revision 1.22.4.3
diff -u -w -r1.22.4.3 asf_file_format_file.cpp
--- datatype/wm/fileformat/asf_file_format_file.cpp 3 Mar 2010 23:14:52 -0000 1.22.4.3
+++ datatype/wm/fileformat/asf_file_format_file.cpp 18 Mar 2010 20:31:40 -0000
@@ -95,6 +95,8 @@
"application/vnd.rn-wm-binary-encrypted"};
#endif
+const UINT64 CASFFileFormatFile::m_ullAsfPosixTimeDiffSec = 11644473600;
+
CASFFileFormatFile::CASFFileFormatFile()
{
HXLOGL3(HXLOG_ASFF, "Construct CASFFileFormatFile this=%p", this);
@@ -1520,6 +1522,19 @@
ullDuration -= m_pFilePropertiesObject->m_ullPreroll;
// Convert from UINT64 to UINT32
ulDuration = INT64_TO_UINT32(ullDuration);
+
+ if( !m_pFilePropertiesObject->IsFlagSet(HXASFFilePropertiesFlags_Broadcast))
+ {
+ // Creation Date: Specifies the date and time of the initial creation of the file.
+ // The value is given as the number of 100-nanosecond intervals since January 1, 1601,
+ // according to Coordinated Universal Time (Greenwich Mean Time).
+ // The value of this field is invalid if the Broadcast Flag bit (Bit 0 LSB) in the Flags field is set.
+
+ // convert to seconds in POSIX time base 01/01/1970 UTC
+ UINT64 ullCreationDate = m_pFilePropertiesObject->m_ullCreationDate/((UINT64) 10000000) - m_ullAsfPosixTimeDiffSec;
+ UINT32 ulCreationDateWmPosix = INT64_TO_UINT32(ullCreationDate);
+ pHdr->SetPropertyULONG32("CreationDateWM", ulCreationDateWmPosix);
+ }
}
// Set the duration property
pHdr->SetPropertyULONG32("Duration", ulDuration);
Index: datatype/wm/fileformat/pub/asf_file_format_file.h
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
retrieving revision 1.9.10.1
diff -u -w -r1.9.10.1 asf_file_format_file.h
--- datatype/wm/fileformat/pub/asf_file_format_file.h 15 Oct 2009 21:38:19 -0000 1.9.10.1
+++ datatype/wm/fileformat/pub/asf_file_format_file.h 18 Mar 2010 20:31:40 -0000
@@ -265,6 +265,7 @@
#if defined(HELIX_FEATURE_DRM)
static const char* const m_ppszEncryptedStreamMimeType[HX_ASF_Num_Stream_Types - 1];
#endif
+ static const UINT64 m_ullAsfPosixTimeDiffSec;
};
#define HX_SWAP_XOR(x, y) \
Index: datatype/mkv/libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.1.2.5
diff -u -w -r1.1.1.1.2.1.2.5 Matroska.cpp
--- datatype/mkv/libmatroska/Matroska.cpp 2 Mar 2010 22:12:16 -0000 1.1.1.1.2.1.2.5
+++ datatype/mkv/libmatroska/Matroska.cpp 18 Mar 2010 20:32:58 -0000
@@ -46,6 +46,7 @@
,m_uTimescale(TIMECODESCALE)
,m_uDuration(0)
,m_uStartPos(0)
+ ,m_uEpochDate(0)
,m_bCues(FALSE)
,m_pES(estream)
,m_pSegTitle(NULL)
@@ -600,6 +601,11 @@
UTFstring uStr(title);
m_pSegTitle = strdup( uStr.GetUTF8() );
}
+ else if( EbmlId(*el) == KaxDateUTC::ClassInfos->GlobalId )
+ {
+ KaxDateUTC &date = *(KaxDateUTC*)el;
+ m_uEpochDate = date.GetEpochDate();
+ }
}
m_uDuration = UINT64(double(m_uDuration) * double(m_uTimescale) / 1000000.0);
Index: datatype/mkv/libmatroska/Matroska.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 Matroska.h
--- datatype/mkv/libmatroska/Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/Matroska.h 18 Mar 2010 20:32:58 -0000
@@ -43,6 +43,7 @@
UINT64 m_uTimescale;
UINT64 m_uDuration;
UINT64 m_uStartPos;
+ UINT32 m_uEpochDate;
char *m_pSegTitle;
char *m_pTagTitle;
Index: datatype/mkv/libmatroska/MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.cpp
--- datatype/mkv/libmatroska/MatroskaExports.cpp 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.cpp 18 Mar 2010 20:33:00 -0000
@@ -60,6 +60,17 @@
return -1;
}
+int32 MatroskaExports::EpochDate()
+{
+ if(m_pSeg)
+ {
+ return m_pSeg->m_uEpochDate;
+ }
+
+ return -1;
+}
+
+
int MatroskaExports::NumTracks()
{
if(m_pSeg)
Index: datatype/mkv/libmatroska/MatroskaExports.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.h
--- datatype/mkv/libmatroska/MatroskaExports.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.h 18 Mar 2010 20:33:00 -0000
@@ -21,6 +21,7 @@
static MatroskaExports* Init(libebml::IOCallback &);
int64 DurationMS();
+ int32 EpochDate();
int NumTracks();
char* TagAuthor();
From sfu at real.com Thu Mar 18 13:26:28 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 20:34:58 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To:
References:
<4BA2553D.2060100@real.com>
<4BA26DD9.5050503@real.com>
Message-ID: <4BA29A84.6060008@real.com>
Now that they are all in the same format, we should name them the same I
think to save the TLC from the trouble of getting them separately.
Thanks for the effort. I know this is beyond what Nokia needs.
fxd
Yury.Ramanovich@nokia.com wrote:
> Sheldon, please see the new diff, where creation time and modification time metadata converted to seconds relative to POSIX time base 01/01/1970 UTC before setting them in file header values map. This is for mp4, wm, mkv file formats.
>
> BR
> Yury
>
>
>> -----Original Message-----
>> From: ext Sheldon Fu [mailto:sfu@real.com]
>> Sent: Thursday, March 18, 2010 1:16 PM
>> To: Ramanovich Yury (Nokia-D/Dallas)
>> Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>> support for 'CreationTime" and "ModificationTime" content metadata
>>
>> The time base conversion logic certainly is not platform dependent.
>> Helix may not have a handy class/function for that yet but you can add
>> it. For this to be useful for Helix community as a whole, these time
>> values really should come in with a standard format (doesn't matter
>> which format). These are one time calculation per clip. I don't' think
>> they have any impact on file format's performance or logic.
>>
>> You can check you change into Nokia's 420brizo branch now, but for Head,
>> it would be nice if the values are in a unified format.
>>
>> fxd
>>
>>
>> Yury.Ramanovich@Nokia.com wrote:
>>
>>> Hi
>>> I just wanted to minimize impact on all the formats and preserve the
>>>
>> original values as much as I can; plus I don't see any convenient apis
>> in fileformats to deal with timebase conversions apart from some ad-hoc
>> calculations and magic numbers.
>>
>>> BR
>>> Yury
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>> Sent: Thursday, March 18, 2010 11:31 AM
>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>
>> dev@helixcommunity.org
>>
>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>>>>
>> helix
>>
>>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>>
>>>> It might be better for re-usability if we let each file format plugin
>>>> convert the time/date values into a standard format (e.g. POSIX
>>>>
>> 1/1/1970
>>
>>>> based) , rather than letting them set the values with the native
>>>>
>> format
>>
>>>> and let TLC converts them.
>>>>
>>>> fxd
>>>>
>>>> Yury.Ramanovich@nokia.com wrote:
>>>>
>>>>
>>>>> "Nokia submits this code under the terms of a commercial
>>>>>
>> contribution
>>
>>>>> agreement with RealNetworks, and I am authorized to contribute this
>>>>> code under said agreement."
>>>>>
>>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>>
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Date: 03/18/2010
>>>>>
>>>>> Project: symbian_client_apps
>>>>>
>>>>> ErrorId: req. 417-59758
>>>>>
>>>>> Synopsis: added helix support for extraction of "CreationTime" and
>>>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv file
>>>>> formats
>>>>>
>>>>> Overview: in order to allow user to see creation date/time and
>>>>> modification date/time of recorded video clips, helix needs to
>>>>>
>> extract
>>
>>>>> corresponding metadata from content and make it available to UI. The
>>>>> support of content creation date/time and modification date/time
>>>>> metadata by different file formats is not consistent. Some formats
>>>>> have both time values, some formats have only "CreationTime" and
>>>>>
>> other
>>
>>>>> formats don't provide any such info at all. Moreover, time base
>>>>> conversion is needed, since each format stores these time/date
>>>>>
>> values
>>
>>>>> in different time units and relative to different time bases and UI
>>>>> needs those values in seconds relative to POSIX time base 01/01/1970
>>>>> 0:0:0 UTC. If a particular file format doesn't provide
>>>>>
>> "CreationTime"
>>
>>>>> and/or "ModificationTime" values to UI or it is missing in the
>>>>>
>> file's
>>
>>>>> metadata, then UI will substitute with values obtained via QT APIs
>>>>> from filesystem.
>>>>>
>>>>> Solution:
>>>>> Added support for retrieving "CreationTime" and "ModificationTime"
>>>>> metadata from .3gp and .mp4 files; "CreationTime" only is
>>>>>
>> retrieved
>>
>>>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The
>>>>>
>> 'CreationTime"
>>
>>>>> and "ModificationTIme" values, if any, will be converted to seconds
>>>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to
>>>>>
>> UI.
>>
>>>>> Note that not all tools that create Matroska (.mkv) files, write out
>>>>> this info in the Segment. RealMedia and AVI file formats do not seem
>>>>> to have any creation/modification time info.
>>>>>
>>>>> Files Added:
>>>>> None.
>>>>>
>>>>> Files Modified:
>>>>>
>>>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>>>> /datatype/mp4/fileformat/qtffplin.cpp
>>>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>>>> /xiph/matroskalib/Matroska.cpp
>>>>> /xiph/matroskalib/Matroska.h
>>>>> /xiph/matroskalib/MatroskaExports.cpp
>>>>> /xiph/matroskalib/MatroskaExports.h
>>>>>
>>>>>
>>>>>
>>>>> Image Size and Heap Use impact: minor
>>>>>
>>>>> Module Release testing (STIF) : Ongoing
>>>>>
>>>>> Test case(s) Added : No.
>>>>>
>>>>> Memory leak check performed : Yes. No new leaks introduced
>>>>>
>>>>> Platforms and Profiles Build Verified:
>>>>> helix-client-symbian-4
>>>>>
>>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>>
>>>>> Branch: 420Brizo, HEAD
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>> .
>>>
>>>
>>>
>
>
From Yury.Ramanovich at nokia.com Thu Mar 18 14:08:48 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Mar 18 21:17:08 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To: <4BA29A84.6060008@real.com>
References:
<4BA2553D.2060100@real.com>
<4BA26DD9.5050503@real.com>
<4BA29A84.6060008@real.com>
Message-ID:
Good catch! Same time format simplifies TLC code. Here's new diff
BR
Yury
>-----Original Message-----
>From: ext Sheldon Fu [mailto:sfu@real.com]
>Sent: Thursday, March 18, 2010 4:26 PM
>To: Ramanovich Yury (Nokia-D/Dallas)
>Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>support for 'CreationTime" and "ModificationTime" content metadata
>
>Now that they are all in the same format, we should name them the same I
>think to save the TLC from the trouble of getting them separately.
>
>Thanks for the effort. I know this is beyond what Nokia needs.
>
>fxd
>
>Yury.Ramanovich@nokia.com wrote:
>> Sheldon, please see the new diff, where creation time and modification
>time metadata converted to seconds relative to POSIX time base
>01/01/1970 UTC before setting them in file header values map. This is
>for mp4, wm, mkv file formats.
>>
>> BR
>> Yury
>>
>>
>>> -----Original Message-----
>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>> Sent: Thursday, March 18, 2010 1:16 PM
>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>dev@helixcommunity.org
>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>helix
>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>
>>> The time base conversion logic certainly is not platform dependent.
>>> Helix may not have a handy class/function for that yet but you can
>add
>>> it. For this to be useful for Helix community as a whole, these time
>>> values really should come in with a standard format (doesn't matter
>>> which format). These are one time calculation per clip. I don't'
>think
>>> they have any impact on file format's performance or logic.
>>>
>>> You can check you change into Nokia's 420brizo branch now, but for
>Head,
>>> it would be nice if the values are in a unified format.
>>>
>>> fxd
>>>
>>>
>>> Yury.Ramanovich@Nokia.com wrote:
>>>
>>>> Hi
>>>> I just wanted to minimize impact on all the formats and preserve the
>>>>
>>> original values as much as I can; plus I don't see any convenient
>apis
>>> in fileformats to deal with timebase conversions apart from some ad-
>hoc
>>> calculations and magic numbers.
>>>
>>>> BR
>>>> Yury
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>>> Sent: Thursday, March 18, 2010 11:31 AM
>>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>>
>>> dev@helixcommunity.org
>>>
>>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>>>>>
>>> helix
>>>
>>>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>>>
>>>>> It might be better for re-usability if we let each file format
>plugin
>>>>> convert the time/date values into a standard format (e.g. POSIX
>>>>>
>>> 1/1/1970
>>>
>>>>> based) , rather than letting them set the values with the native
>>>>>
>>> format
>>>
>>>>> and let TLC converts them.
>>>>>
>>>>> fxd
>>>>>
>>>>> Yury.Ramanovich@nokia.com wrote:
>>>>>
>>>>>
>>>>>> "Nokia submits this code under the terms of a commercial
>>>>>>
>>> contribution
>>>
>>>>>> agreement with RealNetworks, and I am authorized to contribute
>this
>>>>>> code under said agreement."
>>>>>>
>>>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>>>
>>>>>>
>>>>>> Reviewed by:
>>>>>>
>>>>>> Date: 03/18/2010
>>>>>>
>>>>>> Project: symbian_client_apps
>>>>>>
>>>>>> ErrorId: req. 417-59758
>>>>>>
>>>>>> Synopsis: added helix support for extraction of "CreationTime" and
>>>>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv
>file
>>>>>> formats
>>>>>>
>>>>>> Overview: in order to allow user to see creation date/time and
>>>>>> modification date/time of recorded video clips, helix needs to
>>>>>>
>>> extract
>>>
>>>>>> corresponding metadata from content and make it available to UI.
>The
>>>>>> support of content creation date/time and modification date/time
>>>>>> metadata by different file formats is not consistent. Some
>formats
>>>>>> have both time values, some formats have only "CreationTime" and
>>>>>>
>>> other
>>>
>>>>>> formats don't provide any such info at all. Moreover, time base
>>>>>> conversion is needed, since each format stores these time/date
>>>>>>
>>> values
>>>
>>>>>> in different time units and relative to different time bases and
>UI
>>>>>> needs those values in seconds relative to POSIX time base
>01/01/1970
>>>>>> 0:0:0 UTC. If a particular file format doesn't provide
>>>>>>
>>> "CreationTime"
>>>
>>>>>> and/or "ModificationTime" values to UI or it is missing in the
>>>>>>
>>> file's
>>>
>>>>>> metadata, then UI will substitute with values obtained via QT APIs
>>>>>> from filesystem.
>>>>>>
>>>>>> Solution:
>>>>>> Added support for retrieving "CreationTime" and "ModificationTime"
>>>>>> metadata from .3gp and .mp4 files; "CreationTime" only is
>>>>>>
>>> retrieved
>>>
>>>>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The
>>>>>>
>>> 'CreationTime"
>>>
>>>>>> and "ModificationTIme" values, if any, will be converted to
>seconds
>>>>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to
>>>>>>
>>> UI.
>>>
>>>>>> Note that not all tools that create Matroska (.mkv) files, write
>out
>>>>>> this info in the Segment. RealMedia and AVI file formats do not
>seem
>>>>>> to have any creation/modification time info.
>>>>>>
>>>>>> Files Added:
>>>>>> None.
>>>>>>
>>>>>> Files Modified:
>>>>>>
>>>>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>>>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>>>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>>>>> /datatype/mp4/fileformat/qtffplin.cpp
>>>>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>>>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>>>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>>>>> /xiph/matroskalib/Matroska.cpp
>>>>>> /xiph/matroskalib/Matroska.h
>>>>>> /xiph/matroskalib/MatroskaExports.cpp
>>>>>> /xiph/matroskalib/MatroskaExports.h
>>>>>>
>>>>>>
>>>>>>
>>>>>> Image Size and Heap Use impact: minor
>>>>>>
>>>>>> Module Release testing (STIF) : Ongoing
>>>>>>
>>>>>> Test case(s) Added : No.
>>>>>>
>>>>>> Memory leak check performed : Yes. No new leaks introduced
>>>>>>
>>>>>> Platforms and Profiles Build Verified:
>>>>>> helix-client-symbian-4
>>>>>>
>>>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>>>
>>>>>> Branch: 420Brizo, HEAD
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> .
>>>>
>>>>
>>>>
>>
>>
-------------- next part --------------
Index: clientapps/symbiancommon/hxsymmetadata.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbiancommon/hxsymmetadata.cpp,v
retrieving revision 1.1.10.1
diff -u -w -r1.1.10.1 hxsymmetadata.cpp
--- clientapps/symbiancommon/hxsymmetadata.cpp 11 Jan 2010 16:19:41 -0000 1.1.10.1
+++ clientapps/symbiancommon/hxsymmetadata.cpp 18 Mar 2010 22:02:15 -0000
@@ -236,6 +236,22 @@
++iter;
}
+ // content creation time in seconds in POSIX time base 01/01/1970
+ UINT32 clipPosixCreationTimeSec = 0;
+ if(val::GetUINT32( header, "CreationTime", clipPosixCreationTimeSec) &&
+ ( clipPosixCreationTimeSec > 0 ) )
+ {
+ AddToClipInfoL("CreationTime", clipPosixCreationTimeSec);
+ }
+
+ // content modification time in seconds in POSIX time base 01/01/1970
+ UINT32 clipPosixModTimeSec = 0;
+ if(val::GetUINT32( header, "ModificationTime", clipPosixModTimeSec) &&
+ ( clipPosixModTimeSec > 0) )
+ {
+ AddToClipInfoL("ModificationTime", clipPosixModTimeSec);
+ }
+
TInt isLive = m_clipHeader.IsLive();
if ( isLive )
Index: datatype/mkv/fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.1.2.3
diff -u -w -r1.1.1.1.2.1.2.3 mkv_file_format.cpp
--- datatype/mkv/fileformat/mkv_file_format.cpp 23 Dec 2009 22:31:05 -0000 1.1.1.1.2.1.2.3
+++ datatype/mkv/fileformat/mkv_file_format.cpp 18 Mar 2010 22:02:52 -0000
@@ -653,6 +653,8 @@
// Set the stream count
pHdr->SetPropertyULONG32("StreamCount", m_pMKVHandle->NumTracks());
pHdr->SetPropertyULONG32("Duration", m_pMKVHandle->DurationMS());
+ // set creation date/time in seconds measured relatively to POSIX time base 01/01/1970 UTC
+ pHdr->SetPropertyULONG32("CreationTime", m_pMKVHandle->EpochDate());
retVal = SetTags(pHdr);
Index: datatype/mp4/fileformat/qtatmmgs.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtatmmgs.cpp,v
retrieving revision 1.56.2.1.2.3
diff -u -w -r1.56.2.1.2.3 qtatmmgs.cpp
--- datatype/mp4/fileformat/qtatmmgs.cpp 23 Dec 2009 22:50:29 -0000 1.56.2.1.2.3
+++ datatype/mp4/fileformat/qtatmmgs.cpp 18 Mar 2010 22:02:55 -0000
@@ -2633,6 +2633,8 @@
CQT_MovieInfo_Manager::CQT_MovieInfo_Manager(void)
: m_ulMovieTimeScale(0)
, m_ulMovieDuration(0)
+ , m_ulMovieCreationTime(0)
+ , m_ulMovieModificationTime(0)
, m_pNameAtom(NULL)
#ifdef QTCONFIG_3GPP_TAC
@@ -2697,6 +2699,8 @@
m_ulMovieTimeScale = 0;
m_ulMovieDuration = 0;
+ m_ulMovieCreationTime = 0;
+ m_ulMovieModificationTime = 0;
HX_RELEASE(m_pNameAtom);
#ifdef QTCONFIG_3GPP_TAC
@@ -2737,6 +2741,8 @@
{
m_ulMovieTimeScale = pMovieHeaderAtom->Get_TimeScale();
m_ulMovieDuration = pMovieHeaderAtom->Get_Duration();
+ m_ulMovieCreationTime = pMovieHeaderAtom->Get_CreationTime();
+ m_ulMovieModificationTime = pMovieHeaderAtom->Get_ModificationTime();
}
else if(pRmraHeaderAtom)
{
Index: datatype/mp4/fileformat/qtffplin.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
retrieving revision 1.77.4.1
diff -u -w -r1.77.4.1 qtffplin.cpp
--- datatype/mp4/fileformat/qtffplin.cpp 23 Dec 2009 22:51:43 -0000 1.77.4.1
+++ datatype/mp4/fileformat/qtffplin.cpp 18 Mar 2010 22:02:57 -0000
@@ -127,6 +127,7 @@
const char* const CQTFileFormat::zm_pPacketFormats[] = {"rtp", "rdt", NULL};
+const ULONG32 CQTFileFormat::m_ulMp4PosixTimeDiffSec = 2082844800;
/****************************************************************************
* Globals
@@ -1047,6 +1048,9 @@
m_ulFileDuration = (ULONG32) ((1000.0 * ((double) m_MovieInfo.GetMovieDuration())) /
m_MovieInfo.GetMovieTimeScale());
pHeader->SetPropertyULONG32("Duration", m_ulFileDuration);
+ // set CreationTime and ModificationTime in seconds in POSIX time 01/01/1970 UTC
+ pHeader->SetPropertyULONG32("CreationTime", m_MovieInfo.GetMovieCreationTime() - m_ulMp4PosixTimeDiffSec);
+ pHeader->SetPropertyULONG32("ModificationTime", m_MovieInfo.GetMovieModificationTime() - m_ulMp4PosixTimeDiffSec);
}
if (SUCCEEDED(status) && m_TrackManager.AreStreamGroupsPresent())
Index: datatype/mp4/fileformat/pub/qtatmmgs.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatmmgs.h,v
retrieving revision 1.28.4.3
diff -u -w -r1.28.4.3 qtatmmgs.h
--- datatype/mp4/fileformat/pub/qtatmmgs.h 7 Jan 2010 07:52:19 -0000 1.28.4.3
+++ datatype/mp4/fileformat/pub/qtatmmgs.h 18 Mar 2010 22:02:58 -0000
@@ -726,6 +726,8 @@
ULONG32 GetMovieTimeScale(void) { return m_ulMovieTimeScale; }
ULONG32 GetMovieDuration(void) { return m_ulMovieDuration; }
+ ULONG32 GetMovieCreationTime(void) { return m_ulMovieCreationTime; }
+ ULONG32 GetMovieModificationTime(void) { return m_ulMovieModificationTime; }
//*** Name Atom **********************************************
@@ -1028,6 +1030,8 @@
char *m_pRefURL;
ULONG32 m_ulMovieTimeScale;
ULONG32 m_ulMovieDuration;
+ ULONG32 m_ulMovieCreationTime;
+ ULONG32 m_ulMovieModificationTime;
CQT_name_Atom* m_pNameAtom;
Index: datatype/mp4/fileformat/pub/qtatoms.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtatoms.h,v
retrieving revision 1.35.4.1
diff -u -w -r1.35.4.1 qtatoms.h
--- datatype/mp4/fileformat/pub/qtatoms.h 23 Dec 2009 22:38:29 -0000 1.35.4.1
+++ datatype/mp4/fileformat/pub/qtatoms.h 18 Mar 2010 22:02:59 -0000
@@ -364,6 +364,28 @@
return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pDuration));
}
+
+ ULONG32 Get_CreationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pCreatTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pCreatTime));
+ }
+
+ ULONG32 Get_ModificationTime(void)
+ {
+ HX_ASSERT(m_pData);
+ if ((*(((Data*) m_pData)->pVersion)) == 0)
+ {
+ return GetUL32(((Data*) m_pData)->pModifTime);
+ }
+
+ return INT64_TO_UINT32(GetUL64(((Data64*) m_pData)->pModifTime));
+ }
};
/****************************************************************************
Index: datatype/mp4/fileformat/pub/qtffplin.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtffplin.h,v
retrieving revision 1.23.4.1
diff -u -w -r1.23.4.1 qtffplin.h
--- datatype/mp4/fileformat/pub/qtffplin.h 23 Dec 2009 22:39:10 -0000 1.23.4.1
+++ datatype/mp4/fileformat/pub/qtffplin.h 18 Mar 2010 22:02:59 -0000
@@ -374,6 +374,7 @@
static const char* const zm_pFileExtensions[];
static const char* const zm_pFileOpenNames[];
static const char* const zm_pPacketFormats[];
+ static const ULONG32 m_ulMp4PosixTimeDiffSec;
#ifdef QTCONFIG_FSWITCHER
IHXFileSwitcher2* m_pFileSwitcher;
Index: datatype/wm/fileformat/asf_file_format_file.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
retrieving revision 1.22.4.3
diff -u -w -r1.22.4.3 asf_file_format_file.cpp
--- datatype/wm/fileformat/asf_file_format_file.cpp 3 Mar 2010 23:14:52 -0000 1.22.4.3
+++ datatype/wm/fileformat/asf_file_format_file.cpp 18 Mar 2010 22:03:02 -0000
@@ -95,6 +95,8 @@
"application/vnd.rn-wm-binary-encrypted"};
#endif
+const UINT64 CASFFileFormatFile::m_ullAsfPosixTimeDiffSec = 11644473600;
+
CASFFileFormatFile::CASFFileFormatFile()
{
HXLOGL3(HXLOG_ASFF, "Construct CASFFileFormatFile this=%p", this);
@@ -1520,6 +1522,19 @@
ullDuration -= m_pFilePropertiesObject->m_ullPreroll;
// Convert from UINT64 to UINT32
ulDuration = INT64_TO_UINT32(ullDuration);
+
+ if( !m_pFilePropertiesObject->IsFlagSet(HXASFFilePropertiesFlags_Broadcast))
+ {
+ // Creation Date: Specifies the date and time of the initial creation of the file.
+ // The value is given as the number of 100-nanosecond intervals since January 1, 1601,
+ // according to Coordinated Universal Time (Greenwich Mean Time).
+ // The value of this field is invalid if the Broadcast Flag bit (Bit 0 LSB) in the Flags field is set.
+
+ // convert to seconds in POSIX time base 01/01/1970 UTC
+ UINT64 ullCreationDate = m_pFilePropertiesObject->m_ullCreationDate/((UINT64) 10000000) - m_ullAsfPosixTimeDiffSec;
+ UINT32 ulCreationDateWmPosix = INT64_TO_UINT32(ullCreationDate);
+ pHdr->SetPropertyULONG32("CreationTime", ulCreationDateWmPosix);
+ }
}
// Set the duration property
pHdr->SetPropertyULONG32("Duration", ulDuration);
Index: datatype/wm/fileformat/pub/asf_file_format_file.h
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
retrieving revision 1.9.10.1
diff -u -w -r1.9.10.1 asf_file_format_file.h
--- datatype/wm/fileformat/pub/asf_file_format_file.h 15 Oct 2009 21:38:19 -0000 1.9.10.1
+++ datatype/wm/fileformat/pub/asf_file_format_file.h 18 Mar 2010 22:03:02 -0000
@@ -265,6 +265,7 @@
#if defined(HELIX_FEATURE_DRM)
static const char* const m_ppszEncryptedStreamMimeType[HX_ASF_Num_Stream_Types - 1];
#endif
+ static const UINT64 m_ullAsfPosixTimeDiffSec;
};
#define HX_SWAP_XOR(x, y) \
? datatype/mkv/libmatroska/Makefile
? datatype/mkv/libmatroska/Umakefil.upp
? datatype/mkv/libmatroska/armv5-rel32
Index: datatype/mkv/libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.1.2.5
diff -u -w -r1.1.1.1.2.1.2.5 Matroska.cpp
--- datatype/mkv/libmatroska/Matroska.cpp 2 Mar 2010 22:12:16 -0000 1.1.1.1.2.1.2.5
+++ datatype/mkv/libmatroska/Matroska.cpp 18 Mar 2010 22:04:14 -0000
@@ -46,6 +46,7 @@
,m_uTimescale(TIMECODESCALE)
,m_uDuration(0)
,m_uStartPos(0)
+ ,m_uEpochDate(0)
,m_bCues(FALSE)
,m_pES(estream)
,m_pSegTitle(NULL)
@@ -600,6 +601,11 @@
UTFstring uStr(title);
m_pSegTitle = strdup( uStr.GetUTF8() );
}
+ else if( EbmlId(*el) == KaxDateUTC::ClassInfos->GlobalId )
+ {
+ KaxDateUTC &date = *(KaxDateUTC*)el;
+ m_uEpochDate = date.GetEpochDate();
+ }
}
m_uDuration = UINT64(double(m_uDuration) * double(m_uTimescale) / 1000000.0);
Index: datatype/mkv/libmatroska/Matroska.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 Matroska.h
--- datatype/mkv/libmatroska/Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/Matroska.h 18 Mar 2010 22:04:14 -0000
@@ -43,6 +43,7 @@
UINT64 m_uTimescale;
UINT64 m_uDuration;
UINT64 m_uStartPos;
+ UINT32 m_uEpochDate;
char *m_pSegTitle;
char *m_pTagTitle;
Index: datatype/mkv/libmatroska/MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.cpp
--- datatype/mkv/libmatroska/MatroskaExports.cpp 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.cpp 18 Mar 2010 22:04:15 -0000
@@ -60,6 +60,17 @@
return -1;
}
+int32 MatroskaExports::EpochDate()
+{
+ if(m_pSeg)
+ {
+ return m_pSeg->m_uEpochDate;
+ }
+
+ return -1;
+}
+
+
int MatroskaExports::NumTracks()
{
if(m_pSeg)
Index: datatype/mkv/libmatroska/MatroskaExports.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.h,v
retrieving revision 1.1.1.1.2.1
diff -u -w -r1.1.1.1.2.1 MatroskaExports.h
--- datatype/mkv/libmatroska/MatroskaExports.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ datatype/mkv/libmatroska/MatroskaExports.h 18 Mar 2010 22:04:15 -0000
@@ -21,6 +21,7 @@
static MatroskaExports* Init(libebml::IOCallback &);
int64 DurationMS();
+ int32 EpochDate();
int NumTracks();
char* TagAuthor();
From sfu at real.com Thu Mar 18 14:24:15 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 21:32:33 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To:
References:
<4BA2553D.2060100@real.com>
<4BA26DD9.5050503@real.com>
<4BA29A84.6060008@real.com>
Message-ID: <4BA2A80F.4070907@real.com>
Looks good.
fxd
Yury.Ramanovich@nokia.com wrote:
> Good catch! Same time format simplifies TLC code. Here's new diff
>
>
>
> BR
> Yury
>
>
>> -----Original Message-----
>> From: ext Sheldon Fu [mailto:sfu@real.com]
>> Sent: Thursday, March 18, 2010 4:26 PM
>> To: Ramanovich Yury (Nokia-D/Dallas)
>> Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>> support for 'CreationTime" and "ModificationTime" content metadata
>>
>> Now that they are all in the same format, we should name them the same I
>> think to save the TLC from the trouble of getting them separately.
>>
>> Thanks for the effort. I know this is beyond what Nokia needs.
>>
>> fxd
>>
>> Yury.Ramanovich@nokia.com wrote:
>>
>>> Sheldon, please see the new diff, where creation time and modification
>>>
>> time metadata converted to seconds relative to POSIX time base
>> 01/01/1970 UTC before setting them in file header values map. This is
>> for mp4, wm, mkv file formats.
>>
>>> BR
>>> Yury
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>> Sent: Thursday, March 18, 2010 1:16 PM
>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>
>> dev@helixcommunity.org
>>
>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>>>>
>> helix
>>
>>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>>
>>>> The time base conversion logic certainly is not platform dependent.
>>>> Helix may not have a handy class/function for that yet but you can
>>>>
>> add
>>
>>>> it. For this to be useful for Helix community as a whole, these time
>>>> values really should come in with a standard format (doesn't matter
>>>> which format). These are one time calculation per clip. I don't'
>>>>
>> think
>>
>>>> they have any impact on file format's performance or logic.
>>>>
>>>> You can check you change into Nokia's 420brizo branch now, but for
>>>>
>> Head,
>>
>>>> it would be nice if the values are in a unified format.
>>>>
>>>> fxd
>>>>
>>>>
>>>> Yury.Ramanovich@Nokia.com wrote:
>>>>
>>>>
>>>>> Hi
>>>>> I just wanted to minimize impact on all the formats and preserve the
>>>>>
>>>>>
>>>> original values as much as I can; plus I don't see any convenient
>>>>
>> apis
>>
>>>> in fileformats to deal with timebase conversions apart from some ad-
>>>>
>> hoc
>>
>>>> calculations and magic numbers.
>>>>
>>>>
>>>>> BR
>>>>> Yury
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>>>> Sent: Thursday, March 18, 2010 11:31 AM
>>>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>>>
>>>>>>
>>>> dev@helixcommunity.org
>>>>
>>>>
>>>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>>>>>>
>>>>>>
>>>> helix
>>>>
>>>>
>>>>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>>>>
>>>>>> It might be better for re-usability if we let each file format
>>>>>>
>> plugin
>>
>>>>>> convert the time/date values into a standard format (e.g. POSIX
>>>>>>
>>>>>>
>>>> 1/1/1970
>>>>
>>>>
>>>>>> based) , rather than letting them set the values with the native
>>>>>>
>>>>>>
>>>> format
>>>>
>>>>
>>>>>> and let TLC converts them.
>>>>>>
>>>>>> fxd
>>>>>>
>>>>>> Yury.Ramanovich@nokia.com wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> "Nokia submits this code under the terms of a commercial
>>>>>>>
>>>>>>>
>>>> contribution
>>>>
>>>>
>>>>>>> agreement with RealNetworks, and I am authorized to contribute
>>>>>>>
>> this
>>
>>>>>>> code under said agreement."
>>>>>>>
>>>>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>>>>
>>>>>>>
>>>>>>> Reviewed by:
>>>>>>>
>>>>>>> Date: 03/18/2010
>>>>>>>
>>>>>>> Project: symbian_client_apps
>>>>>>>
>>>>>>> ErrorId: req. 417-59758
>>>>>>>
>>>>>>> Synopsis: added helix support for extraction of "CreationTime" and
>>>>>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv
>>>>>>>
>> file
>>
>>>>>>> formats
>>>>>>>
>>>>>>> Overview: in order to allow user to see creation date/time and
>>>>>>> modification date/time of recorded video clips, helix needs to
>>>>>>>
>>>>>>>
>>>> extract
>>>>
>>>>
>>>>>>> corresponding metadata from content and make it available to UI.
>>>>>>>
>> The
>>
>>>>>>> support of content creation date/time and modification date/time
>>>>>>> metadata by different file formats is not consistent. Some
>>>>>>>
>> formats
>>
>>>>>>> have both time values, some formats have only "CreationTime" and
>>>>>>>
>>>>>>>
>>>> other
>>>>
>>>>
>>>>>>> formats don't provide any such info at all. Moreover, time base
>>>>>>> conversion is needed, since each format stores these time/date
>>>>>>>
>>>>>>>
>>>> values
>>>>
>>>>
>>>>>>> in different time units and relative to different time bases and
>>>>>>>
>> UI
>>
>>>>>>> needs those values in seconds relative to POSIX time base
>>>>>>>
>> 01/01/1970
>>
>>>>>>> 0:0:0 UTC. If a particular file format doesn't provide
>>>>>>>
>>>>>>>
>>>> "CreationTime"
>>>>
>>>>
>>>>>>> and/or "ModificationTime" values to UI or it is missing in the
>>>>>>>
>>>>>>>
>>>> file's
>>>>
>>>>
>>>>>>> metadata, then UI will substitute with values obtained via QT APIs
>>>>>>> from filesystem.
>>>>>>>
>>>>>>> Solution:
>>>>>>> Added support for retrieving "CreationTime" and "ModificationTime"
>>>>>>> metadata from .3gp and .mp4 files; "CreationTime" only is
>>>>>>>
>>>>>>>
>>>> retrieved
>>>>
>>>>
>>>>>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The
>>>>>>>
>>>>>>>
>>>> 'CreationTime"
>>>>
>>>>
>>>>>>> and "ModificationTIme" values, if any, will be converted to
>>>>>>>
>> seconds
>>
>>>>>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided to
>>>>>>>
>>>>>>>
>>>> UI.
>>>>
>>>>
>>>>>>> Note that not all tools that create Matroska (.mkv) files, write
>>>>>>>
>> out
>>
>>>>>>> this info in the Segment. RealMedia and AVI file formats do not
>>>>>>>
>> seem
>>
>>>>>>> to have any creation/modification time info.
>>>>>>>
>>>>>>> Files Added:
>>>>>>> None.
>>>>>>>
>>>>>>> Files Modified:
>>>>>>>
>>>>>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>>>>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>>>>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>>>>>> /datatype/mp4/fileformat/qtffplin.cpp
>>>>>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>>>>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>>>>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>>>>>> /xiph/matroskalib/Matroska.cpp
>>>>>>> /xiph/matroskalib/Matroska.h
>>>>>>> /xiph/matroskalib/MatroskaExports.cpp
>>>>>>> /xiph/matroskalib/MatroskaExports.h
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Image Size and Heap Use impact: minor
>>>>>>>
>>>>>>> Module Release testing (STIF) : Ongoing
>>>>>>>
>>>>>>> Test case(s) Added : No.
>>>>>>>
>>>>>>> Memory leak check performed : Yes. No new leaks introduced
>>>>>>>
>>>>>>> Platforms and Profiles Build Verified:
>>>>>>> helix-client-symbian-4
>>>>>>>
>>>>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>>>>
>>>>>>> Branch: 420Brizo, HEAD
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
From kliu at real.com Thu Mar 18 15:34:39 2010
From: kliu at real.com (Kinson Liu)
Date: Thu Mar 18 22:46:00 2010
Subject: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for
capturing thumbnail of a broken rmvb file
In-Reply-To: <4BA23BD2.7030300@real.com>
References: ,
<4BA23BD2.7030300@real.com>
Message-ID:
Sheldon,
After adding the "m_TotalFileSize != 0" back in, do you think this CR will be OK? Since time is running out, we can take this approach - settle with Li Qiang's CR for now; revise the file system when we have time.
Thanks,
Kinson
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Xiaodong (Sheldon) Fu
Sent: Thursday, March 18, 2010 7:42 AM
To: Qiang (Joe) Li
Cc: Manjunatha Kanthraju; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for capturing thumbnail of a broken rmvb file
In some cases, m_TotalFileSize may be unknown and it will be zero. The
'if' statement needs to account for this condition, just like the old
code does.
This is at least the 3rd time a CR is sent for these kind of out of
range seek delay problems in different data types I think. The fix
really should be in the file system itself -- i.e. if file format
requires a seek and it is out of range, file system/object should fail
the seek right way and file format just need to handle that error
condition in a timely manner. Otherwise, we'll have to fix the file
format plugins one by one.
fxd
Qiang (Joe) Li wrote:
>
> Project: Real Player for Android
>
>
>
> Synopsis: Fix for Bug 9974: It costs 24 seconds for capturing
> thumbnail of a broken rmvb file.
>
>
>
> Overview:
>
> This issue was conflict with Bug10036 (Bug 10036:"force close" when
> capturing thumbnail).
>
> So the Bug9974 was re-opened in RC14 due to bug 10036?s fixing.
>
>
>
>
>
> In Bug10036:
>
> When trying to capture thumbnail for this avi file.
>
> Thumbnail generation start time for android is 30sec and since we have
> 6 sec playback in this file, the ideal behavior for the player is to
> exit gracefully by returning an error.
>
>
>
> While In Bug9974:
>
> It was due to capturing thumbnail of a corrupted/broken RMVB file. In
> this given broken/corrupted RMVB file, The duration given in file
> header is around 111 minutes, whereas the actual clip is only around
> 7minutes. At some point in execution, the riff reader tries to seek to
> an offset (to around 111 minutes) which is way outside the file size
> limits and after this ->Seek() call, it takes about 24 seconds to
> return the control back to ::RIFFSeekDone() method.
>
>
>
> So in order not to affect these two test cases,
>
> I think added a check to make sure that desired seek offset falls
> within the file size limits. if desired seek offset is outside file
> size limits, we simply call RIFFSeekDone(HXR_FAILED).
>
>
>
>
>
> Files Added: None
>
>
>
> Files Modified:
>
> datatype/common/util/riff.cpp
>
>
>
> Platforms and Profiles Build and Functionality Verified:
>
> Platform: android-donut3230-arm.eabi
>
> Profile: helix-client-android-full
>
> target(s): android_omx
>
> Branch: hxclient_3_6_1_atlas_restricted
>
>
>
>
>
> DIFF:
>
>
>
> HX_RESULT
>
> CRIFFReader::FileSeek(UINT32 offset)
>
> {
>
> m_ulSeekOffset = offset;
>
> m_state = RS_UserSeekPending;
>
> - if(m_ulSeekOffset >= m_TotalFileSize && m_TotalFileSize != 0)
>
> - {
>
> - m_ulSeekOffset = m_TotalFileSize;
>
> - }
>
> - return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + if(m_ulSeekOffset <= m_TotalFileSize)
>
> + {
>
> + return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>
> + }
>
> + else
>
> + {
>
> + return m_pResponse->RIFFSeekDone(HXR_FAILED);
>
> + }
>
>
>
> }
>
>
>
> Umakant and Manjunatha please help to check this modification;
>
> Thanks.
>
>
>
>
>
> Test Result:
>
> Test files:
>
> crank2-tlr1b_mjpeg_wvga.avi
>
> conan.rmvb
>
>
>
> 01-30 01:36:03.879: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:36:03.889: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:04.009: DEBUG/HelixPlayer(1141):
> m_pMediaPlatform->AddPluginPath() path=/system/lib/helix.
>
> 01-30 01:36:04.229: INFO/ActivityManager(1191): Stopping service:
> com.android.camera/.ThumbnailScannerService
>
> 01-30 01:36:04.329: DEBUG/ddm-heap(1387): Got feature list request
>
> 01-30 01:36:05.279: DEBUG/KeyguardViewMediator(1191): pokeWakelock(5000)
>
> 01-30 01:36:05.339: INFO/ActivityManager(1191): Start proc
> com.android.inputmethod.latin for service
> com.android.inputmethod.latin/.LatinIME: pid=1409 uid=10008
> gids={3003, 3002, 3001, 1015}
>
> 01-30 01:36:05.389: DEBUG/ddm-heap(1409): Got feature list request
>
> 01-30 01:36:06.299: VERBOSE/HelixPlayer(1141): Helix Media platform
> created, thread_id = 86024.
>
> 01-30 01:36:07.189: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.259: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3343 ms
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:07.279: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:07.279: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 3362 ms
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:36:07.836: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.836: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:07.836: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:07.839: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:07.839: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:08.029: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.029: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 197 ms
>
> 01-30 01:36:08.049: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.099: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:08.099: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:08.099: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 267 ms
>
> 01-30 01:36:08.109: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:36:08.554: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.554: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:08.554: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:08.609: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:08.609: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:10.439: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.real.RealPlayer/.Home }
>
> 01-30 01:36:10.509: DEBUG/RP-HOME(1322): onCreate
>
> 01-30 01:36:11.019: VERBOSE/RP-HOME(1322): onCreate(): scanner already
> registered, no need to send the broadcast
>
> 01-30 01:36:11.069: VERBOSE/RP-MediaService(1322): onCreate
>
> 01-30 01:36:11.129: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:11.339: INFO/ActivityManager(1191): Displayed activity
> com.real.RealPlayer/.Home: 851 ms (total 851 ms)
>
> 01-30 01:36:19.789: WARN/IInputConnectionWrapper(1322): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:19.899: DEBUG/RP-HOME(1322): onDestroy
>
> 01-30 01:36:19.949: INFO/ActivityManager(1191): Stopping service:
> com.real.RealPlayer/.MediaPlaybackService
>
> 01-30 01:36:19.949: INFO/RP-HOME(1322): Skipping
> cleanup:isMediaScannerScanning():true, isRealDataScanning():true
>
> 01-30 01:36:19.959: VERBOSE/RP-MediaService(1322): onDestroy
>
> 01-30 01:36:23.199: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.239: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 14632 ms
>
> 01-30 01:36:23.309: VERBOSE/RP-BitmapUtils(1308):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.669: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:23.709: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:23.709: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 15159 ms
>
> 01-30 01:36:23.719: VERBOSE/RP-BitmapUtils(1322):
> saveMiniThumbToFile(): Thumbnail saved successfully at
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:36:23.909: INFO/RP-MediaScannerService(1308): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:true and
> isRealDataScanning:false
>
> 01-30 01:36:23.909: VERBOSE/RP-MediaScannerService(1308):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:24.279: INFO/RP-MediaScannerService(1322): SKIPPING
> Closing DB as appOpen:false and mIsMediaScanning:trueand
> isRealDataScanning:false
>
> 01-30 01:36:24.279: VERBOSE/RP-MediaScannerService(1322):
> doBgMediaScannerFinishedWork(): ends
>
> 01-30 01:36:25.659: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.MAIN
> cat=[android.intent.category.LAUNCHER] flg=0x10200000
> cmp=com.android.camera/.GalleryPicker }
>
> 01-30 01:36:26.029: WARN/IInputConnectionWrapper(1256): showStatusIcon
> on inactive InputConnection
>
> 01-30 01:36:26.089: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.GalleryPicker: 399 ms (total 399 ms)
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.259: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/video/Conan.rmvb
>
> 01-30 01:36:26.259: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.579: VERBOSE/HelixMetaDataDriver(1141): display width
> (856) and height (480), and size (821760)
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.609: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.609: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 351 ms
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.809: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/V100316_132800.3g2
>
> 01-30 01:36:26.809: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:26.919: VERBOSE/HelixMetaDataDriver(1141): display width
> (176) and height (144), and size (50688)
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:26.929: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:26.929: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 121 ms
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:26.999: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:26.999: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:28.139: INFO/ActivityManager(1191): Starting activity:
> Intent { act=android.intent.action.VIEW
> dat=content://media/internal/images/media
> cmp=com.android.camera/.ImageGallery (has extras) }
>
> 01-30 01:36:28.479: INFO/ActivityManager(1191): Displayed activity
> com.android.camera/.ImageGallery: 338 ms (total 338 ms)
>
> 01-30 01:36:34.419: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:34.449: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:34.449: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7456 ms
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver constructor
>
> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): meta data driver
> constructor
>
> 01-30 01:36:34.589: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>
> 01-30 01:36:34.589: INFO/HelixPlayer(1141): media platform finial
> release canceled.
>
> 01-30 01:36:34.709: ERROR/Database(1267): Leak found
>
> 01-30 01:36:34.709: ERROR/Database(1267):
> java.lang.IllegalStateException:
> /data/data/com.android.providers.media/databases/external-1e3b66a5.db
> SQLiteDatabase created and never closed
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.(SQLiteDatabase.java:1581)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:638)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:659)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:652)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.app.ApplicationContext.openOrCreateDatabase(ApplicationContext.java:482)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:193)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:98)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:158)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.query(MediaProvider.java:874)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.attachVolume(MediaProvider.java:2244)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insertInternal(MediaProvider.java:1420)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaProvider.insert(MediaProvider.java:1200)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentProvider$Transport.insert(ContentProvider.java:140)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.content.ContentResolver.insert(ContentResolver.java:479)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.openDatabase(MediaScannerService.java:61)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.scan(MediaScannerService.java:108)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.access$200(MediaScannerService.java:49)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService$ServiceHandler.handleMessage(MediaScannerService.java:280)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Handler.dispatchMessage(Handler.java:99)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> android.os.Looper.loop(Looper.java:123)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> com.android.providers.media.MediaScannerService.run(MediaScannerService.java:180)
>
> 01-30 01:36:34.709: ERROR/Database(1267): at
> java.lang.Thread.run(Thread.java:1060)
>
> 01-30 01:36:42.049: VERBOSE/HelixMetaDataDriver(1141): display width
> (848) and height (400), and size (678400)
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): Helix meta data
> driver destructor
>
> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): meta data driver
> destructor
>
> 01-30 01:36:42.079: INFO/HelixPlayer(1141): schedule media platform
> finial release
>
> 01-30 01:36:42.079: DEBUG/HelixMetaDataDriver(1141): [Timing]
> MetaDataDriver Lifetime: 7494 ms
>
> 01-30 01:37:01.169: DEBUG/RP-MediaScannerService(1308): Scanning SD Card
>
> 01-30 01:37:01.169: DEBUG/RP-MediaStore(1308): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.179: DEBUG/RP-MediaStore(1308): ScanSDCard start
>
> 01-30 01:37:01.379: DEBUG/RP-MediaStore(1308): ScanSDCard end
>
> 01-30 01:37:01.379: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.399: DEBUG/RP-DataStore(1308): verifyVideoThumbnails start
>
> 01-30 01:37:01.602: DEBUG/RP-MediaScannerService(1322): Scanning SD Card
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): mtime for:
> /sdcard/.helix.thumbnails/=1264813654000
>
> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): ScanSDCard start
>
> 01-30 01:37:01.689: DEBUG/RP-MediaStore(1322): ScanSDCard end
>
> 01-30 01:37:01.689: VERBOSE/RP-DataStore(1322): checkVideoMiniThumbails()
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/1
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/2
>
> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
> checkVideoMiniThumbails():Video uri:
> :/sdcard/.helix.thumbnails/videothumb/3
>
> 01-30 01:37:01.709: DEBUG/RP-DataStore(1322): verifyVideoThumbnails start
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): verifyVideoThumbnails
> complete
>
> 01-30 01:37:02.929: VERBOSE/RP-MediaScannerService(1308): Closing DB
> as appOpen:false and mIsMediaScanning:false and isRealDataScanning:false
>
> 01-30 01:37:02.929: VERBOSE/RP-DataStore(1308): cleanUp()
>
> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): resetAllScannerFlags
>
> 01-30 01:37:02.939: VERBOSE/RP-DataStore(1308): cleanUp(): finished
> normally
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): verifyVideoThumbnails
> complete
>
> 01-30 01:37:03.231: VERBOSE/RP-MediaScannerService(1322): Closing DB
> as appOpen:false and mIsMediaScanning:falseand isRealDataScanning:false
>
> 01-30 01:37:03.231: VERBOSE/RP-DataStore(1322): cleanUp()
>
> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): resetAllScannerFlags
>
> 01-30 01:37:03.309: VERBOSE/RP-DataStore(1322): cleanUp(): finished
> normally
>
> 01-30 01:37:06.309: INFO/HelixPlayer(1141): Helix Media platform
> finial release: done.
>
>
>
>
>
> more details please check the attached log file.
>
>
>
> Regards,
> LiQiang(Joe)
> RealNetworks, China
> T: +86(10)59542795
>
>
>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From Yury.Ramanovich at nokia.com Thu Mar 18 16:07:27 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Mar 18 23:16:00 2010
Subject: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
support for 'CreationTime" and "ModificationTime" content metadata
In-Reply-To: <4BA2A80F.4070907@real.com>
References:
<4BA2553D.2060100@real.com>
<4BA26DD9.5050503@real.com>
<4BA29A84.6060008@real.com>
<4BA2A80F.4070907@real.com>
Message-ID:
Checked in to 420Brizo and HEAD
BR
Yury
>-----Original Message-----
>From: ext Sheldon Fu [mailto:sfu@real.com]
>Sent: Thursday, March 18, 2010 5:24 PM
>To: Ramanovich Yury (Nokia-D/Dallas)
>Cc: clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 - helix
>support for 'CreationTime" and "ModificationTime" content metadata
>
>Looks good.
>
>fxd
>
>Yury.Ramanovich@nokia.com wrote:
>> Good catch! Same time format simplifies TLC code. Here's new diff
>>
>>
>>
>> BR
>> Yury
>>
>>
>>> -----Original Message-----
>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>> Sent: Thursday, March 18, 2010 4:26 PM
>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>dev@helixcommunity.org
>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>helix
>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>
>>> Now that they are all in the same format, we should name them the
>same I
>>> think to save the TLC from the trouble of getting them separately.
>>>
>>> Thanks for the effort. I know this is beyond what Nokia needs.
>>>
>>> fxd
>>>
>>> Yury.Ramanovich@nokia.com wrote:
>>>
>>>> Sheldon, please see the new diff, where creation time and
>modification
>>>>
>>> time metadata converted to seconds relative to POSIX time base
>>> 01/01/1970 UTC before setting them in file header values map. This is
>>> for mp4, wm, mkv file formats.
>>>
>>>> BR
>>>> Yury
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>>> Sent: Thursday, March 18, 2010 1:16 PM
>>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>>
>>> dev@helixcommunity.org
>>>
>>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420 -
>>>>>
>>> helix
>>>
>>>>> support for 'CreationTime" and "ModificationTime" content metadata
>>>>>
>>>>> The time base conversion logic certainly is not platform dependent.
>>>>> Helix may not have a handy class/function for that yet but you can
>>>>>
>>> add
>>>
>>>>> it. For this to be useful for Helix community as a whole, these
>time
>>>>> values really should come in with a standard format (doesn't matter
>>>>> which format). These are one time calculation per clip. I don't'
>>>>>
>>> think
>>>
>>>>> they have any impact on file format's performance or logic.
>>>>>
>>>>> You can check you change into Nokia's 420brizo branch now, but for
>>>>>
>>> Head,
>>>
>>>>> it would be nice if the values are in a unified format.
>>>>>
>>>>> fxd
>>>>>
>>>>>
>>>>> Yury.Ramanovich@Nokia.com wrote:
>>>>>
>>>>>
>>>>>> Hi
>>>>>> I just wanted to minimize impact on all the formats and preserve
>the
>>>>>>
>>>>>>
>>>>> original values as much as I can; plus I don't see any convenient
>>>>>
>>> apis
>>>
>>>>> in fileformats to deal with timebase conversions apart from some
>ad-
>>>>>
>>> hoc
>>>
>>>>> calculations and magic numbers.
>>>>>
>>>>>
>>>>>> BR
>>>>>> Yury
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ext Sheldon Fu [mailto:sfu@real.com]
>>>>>>> Sent: Thursday, March 18, 2010 11:31 AM
>>>>>>> To: Ramanovich Yury (Nokia-D/Dallas)
>>>>>>> Cc: clientapps-dev@helixcommunity.org; datatype-
>>>>>>>
>>>>>>>
>>>>> dev@helixcommunity.org
>>>>>
>>>>>
>>>>>>> Subject: Re: [datatype-dev] CR needed: req. 417-59758 - Brizo420
>-
>>>>>>>
>>>>>>>
>>>>> helix
>>>>>
>>>>>
>>>>>>> support for 'CreationTime" and "ModificationTime" content
>metadata
>>>>>>>
>>>>>>> It might be better for re-usability if we let each file format
>>>>>>>
>>> plugin
>>>
>>>>>>> convert the time/date values into a standard format (e.g. POSIX
>>>>>>>
>>>>>>>
>>>>> 1/1/1970
>>>>>
>>>>>
>>>>>>> based) , rather than letting them set the values with the native
>>>>>>>
>>>>>>>
>>>>> format
>>>>>
>>>>>
>>>>>>> and let TLC converts them.
>>>>>>>
>>>>>>> fxd
>>>>>>>
>>>>>>> Yury.Ramanovich@nokia.com wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> "Nokia submits this code under the terms of a commercial
>>>>>>>>
>>>>>>>>
>>>>> contribution
>>>>>
>>>>>
>>>>>>>> agreement with RealNetworks, and I am authorized to contribute
>>>>>>>>
>>> this
>>>
>>>>>>>> code under said agreement."
>>>>>>>>
>>>>>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>>>>>
>>>>>>>>
>>>>>>>> Reviewed by:
>>>>>>>>
>>>>>>>> Date: 03/18/2010
>>>>>>>>
>>>>>>>> Project: symbian_client_apps
>>>>>>>>
>>>>>>>> ErrorId: req. 417-59758
>>>>>>>>
>>>>>>>> Synopsis: added helix support for extraction of "CreationTime"
>and
>>>>>>>> 'ModificationTime" content metadata for .3gp, .mp4, .mkv, .wmv
>>>>>>>>
>>> file
>>>
>>>>>>>> formats
>>>>>>>>
>>>>>>>> Overview: in order to allow user to see creation date/time and
>>>>>>>> modification date/time of recorded video clips, helix needs to
>>>>>>>>
>>>>>>>>
>>>>> extract
>>>>>
>>>>>
>>>>>>>> corresponding metadata from content and make it available to UI.
>>>>>>>>
>>> The
>>>
>>>>>>>> support of content creation date/time and modification date/time
>>>>>>>> metadata by different file formats is not consistent. Some
>>>>>>>>
>>> formats
>>>
>>>>>>>> have both time values, some formats have only "CreationTime" and
>>>>>>>>
>>>>>>>>
>>>>> other
>>>>>
>>>>>
>>>>>>>> formats don't provide any such info at all. Moreover, time base
>>>>>>>> conversion is needed, since each format stores these time/date
>>>>>>>>
>>>>>>>>
>>>>> values
>>>>>
>>>>>
>>>>>>>> in different time units and relative to different time bases and
>>>>>>>>
>>> UI
>>>
>>>>>>>> needs those values in seconds relative to POSIX time base
>>>>>>>>
>>> 01/01/1970
>>>
>>>>>>>> 0:0:0 UTC. If a particular file format doesn't provide
>>>>>>>>
>>>>>>>>
>>>>> "CreationTime"
>>>>>
>>>>>
>>>>>>>> and/or "ModificationTime" values to UI or it is missing in the
>>>>>>>>
>>>>>>>>
>>>>> file's
>>>>>
>>>>>
>>>>>>>> metadata, then UI will substitute with values obtained via QT
>APIs
>>>>>>>> from filesystem.
>>>>>>>>
>>>>>>>> Solution:
>>>>>>>> Added support for retrieving "CreationTime" and
>"ModificationTime"
>>>>>>>> metadata from .3gp and .mp4 files; "CreationTime" only is
>>>>>>>>
>>>>>>>>
>>>>> retrieved
>>>>>
>>>>>
>>>>>>>> for WindowsMedia (.wm) and Matroska (.mkv) files. The
>>>>>>>>
>>>>>>>>
>>>>> 'CreationTime"
>>>>>
>>>>>
>>>>>>>> and "ModificationTIme" values, if any, will be converted to
>>>>>>>>
>>> seconds
>>>
>>>>>>>> relatively to POSIX time base 01/01/1970 0:0:0 UTC and provided
>to
>>>>>>>>
>>>>>>>>
>>>>> UI.
>>>>>
>>>>>
>>>>>>>> Note that not all tools that create Matroska (.mkv) files, write
>>>>>>>>
>>> out
>>>
>>>>>>>> this info in the Segment. RealMedia and AVI file formats do not
>>>>>>>>
>>> seem
>>>
>>>>>>>> to have any creation/modification time info.
>>>>>>>>
>>>>>>>> Files Added:
>>>>>>>> None.
>>>>>>>>
>>>>>>>> Files Modified:
>>>>>>>>
>>>>>>>> /clientapps/symbiancommon/hxsymmetadata.cpp
>>>>>>>> /datatype/mkv/fileformat/mkv_file_format.cpp
>>>>>>>> /datatype/mp4/fileformat/qtatmmgs.cpp
>>>>>>>> /datatype/mp4/fileformat/qtffplin.cpp
>>>>>>>> /datatype/mp4/fileformat/pub/qtatmmgs.h
>>>>>>>> /datatype/mp4/fileformat/pub/qtatoms.h
>>>>>>>> /datatype/wm/fileformat/asf_file_format_file.cpp
>>>>>>>> /xiph/matroskalib/Matroska.cpp
>>>>>>>> /xiph/matroskalib/Matroska.h
>>>>>>>> /xiph/matroskalib/MatroskaExports.cpp
>>>>>>>> /xiph/matroskalib/MatroskaExports.h
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Image Size and Heap Use impact: minor
>>>>>>>>
>>>>>>>> Module Release testing (STIF) : Ongoing
>>>>>>>>
>>>>>>>> Test case(s) Added : No.
>>>>>>>>
>>>>>>>> Memory leak check performed : Yes. No new leaks introduced
>>>>>>>>
>>>>>>>> Platforms and Profiles Build Verified:
>>>>>>>> helix-client-symbian-4
>>>>>>>>
>>>>>>>> Platforms and Profiles Functionality verified: armv5, winscw
>>>>>>>>
>>>>>>>> Branch: 420Brizo, HEAD
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
From sfu at real.com Thu Mar 18 16:24:42 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Mar 18 23:32:42 2010
Subject: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for
capturing thumbnail of a broken rmvb file
In-Reply-To:
References: ,
<4BA23BD2.7030300@real.com>
Message-ID: <4BA2C44A.30104@real.com>
Sure. it is a safe change. Go check it in.
fxd
Kinson Liu wrote:
> Sheldon,
>
> After adding the "m_TotalFileSize != 0" back in, do you think this CR will be OK? Since time is running out, we can take this approach - settle with Li Qiang's CR for now; revise the file system when we have time.
>
> Thanks,
>
> Kinson
> ________________________________________
> From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Xiaodong (Sheldon) Fu
> Sent: Thursday, March 18, 2010 7:42 AM
> To: Qiang (Joe) Li
> Cc: Manjunatha Kanthraju; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] CR: Fix for Bug 9974: It costs 24 seconds for capturing thumbnail of a broken rmvb file
>
> In some cases, m_TotalFileSize may be unknown and it will be zero. The
> 'if' statement needs to account for this condition, just like the old
> code does.
>
> This is at least the 3rd time a CR is sent for these kind of out of
> range seek delay problems in different data types I think. The fix
> really should be in the file system itself -- i.e. if file format
> requires a seek and it is out of range, file system/object should fail
> the seek right way and file format just need to handle that error
> condition in a timely manner. Otherwise, we'll have to fix the file
> format plugins one by one.
>
> fxd
>
> Qiang (Joe) Li wrote:
>
>> Project: Real Player for Android
>>
>>
>>
>> Synopsis: Fix for Bug 9974: It costs 24 seconds for capturing
>> thumbnail of a broken rmvb file.
>>
>>
>>
>> Overview:
>>
>> This issue was conflict with Bug10036 (Bug 10036:"force close" when
>> capturing thumbnail).
>>
>> So the Bug9974 was re-opened in RC14 due to bug 10036?s fixing.
>>
>>
>>
>>
>>
>> In Bug10036:
>>
>> When trying to capture thumbnail for this avi file.
>>
>> Thumbnail generation start time for android is 30sec and since we have
>> 6 sec playback in this file, the ideal behavior for the player is to
>> exit gracefully by returning an error.
>>
>>
>>
>> While In Bug9974:
>>
>> It was due to capturing thumbnail of a corrupted/broken RMVB file. In
>> this given broken/corrupted RMVB file, The duration given in file
>> header is around 111 minutes, whereas the actual clip is only around
>> 7minutes. At some point in execution, the riff reader tries to seek to
>> an offset (to around 111 minutes) which is way outside the file size
>> limits and after this ->Seek() call, it takes about 24 seconds to
>> return the control back to ::RIFFSeekDone() method.
>>
>>
>>
>> So in order not to affect these two test cases,
>>
>> I think added a check to make sure that desired seek offset falls
>> within the file size limits. if desired seek offset is outside file
>> size limits, we simply call RIFFSeekDone(HXR_FAILED).
>>
>>
>>
>>
>>
>> Files Added: None
>>
>>
>>
>> Files Modified:
>>
>> datatype/common/util/riff.cpp
>>
>>
>>
>> Platforms and Profiles Build and Functionality Verified:
>>
>> Platform: android-donut3230-arm.eabi
>>
>> Profile: helix-client-android-full
>>
>> target(s): android_omx
>>
>> Branch: hxclient_3_6_1_atlas_restricted
>>
>>
>>
>>
>>
>> DIFF:
>>
>>
>>
>> HX_RESULT
>>
>> CRIFFReader::FileSeek(UINT32 offset)
>>
>> {
>>
>> m_ulSeekOffset = offset;
>>
>> m_state = RS_UserSeekPending;
>>
>> - if(m_ulSeekOffset >= m_TotalFileSize && m_TotalFileSize != 0)
>>
>> - {
>>
>> - m_ulSeekOffset = m_TotalFileSize;
>>
>> - }
>>
>> - return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>>
>> + if(m_ulSeekOffset <= m_TotalFileSize)
>>
>> + {
>>
>> + return m_pFileObject->Seek(m_ulSeekOffset, FALSE);
>>
>> + }
>>
>> + else
>>
>> + {
>>
>> + return m_pResponse->RIFFSeekDone(HXR_FAILED);
>>
>> + }
>>
>>
>>
>> }
>>
>>
>>
>> Umakant and Manjunatha please help to check this modification;
>>
>> Thanks.
>>
>>
>>
>>
>>
>> Test Result:
>>
>> Test files:
>>
>> crank2-tlr1b_mjpeg_wvga.avi
>>
>> conan.rmvb
>>
>>
>>
>> 01-30 01:36:03.879: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>>
>> 01-30 01:36:03.889: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:36:03.919: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/video/Conan.rmvb
>>
>> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:03.919: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:03.919: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/video/Conan.rmvb
>>
>> 01-30 01:36:04.009: DEBUG/HelixPlayer(1141):
>> m_pMediaPlatform->AddPluginPath() path=/system/lib/helix.
>>
>> 01-30 01:36:04.229: INFO/ActivityManager(1191): Stopping service:
>> com.android.camera/.ThumbnailScannerService
>>
>> 01-30 01:36:04.329: DEBUG/ddm-heap(1387): Got feature list request
>>
>> 01-30 01:36:05.279: DEBUG/KeyguardViewMediator(1191): pokeWakelock(5000)
>>
>> 01-30 01:36:05.339: INFO/ActivityManager(1191): Start proc
>> com.android.inputmethod.latin for service
>> com.android.inputmethod.latin/.LatinIME: pid=1409 uid=10008
>> gids={3003, 3002, 3001, 1015}
>>
>> 01-30 01:36:05.389: DEBUG/ddm-heap(1409): Got feature list request
>>
>> 01-30 01:36:06.299: VERBOSE/HelixPlayer(1141): Helix Media platform
>> created, thread_id = 86024.
>>
>> 01-30 01:36:07.189: VERBOSE/HelixMetaDataDriver(1141): display width
>> (856) and height (480), and size (821760)
>>
>> 01-30 01:36:07.199: VERBOSE/HelixMetaDataDriver(1141): display width
>> (856) and height (480), and size (821760)
>>
>> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:07.259: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:07.259: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 3343 ms
>>
>> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:07.279: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:07.279: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:07.279: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 3362 ms
>>
>> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1322):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:36:07.329: VERBOSE/RP-BitmapUtils(1308):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:36:07.836: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:07.836: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:07.836: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/V100316_132800.3g2
>>
>> 01-30 01:36:07.836: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:07.839: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:07.839: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:07.839: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/V100316_132800.3g2
>>
>> 01-30 01:36:08.029: VERBOSE/HelixMetaDataDriver(1141): display width
>> (176) and height (144), and size (50688)
>>
>> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:08.029: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:08.029: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 197 ms
>>
>> 01-30 01:36:08.049: VERBOSE/RP-BitmapUtils(1322):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:36:08.099: VERBOSE/HelixMetaDataDriver(1141): display width
>> (176) and height (144), and size (50688)
>>
>> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:08.099: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:08.099: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:08.099: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 267 ms
>>
>> 01-30 01:36:08.109: VERBOSE/RP-BitmapUtils(1308):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:36:08.554: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:08.554: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:08.554: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>>
>> 01-30 01:36:08.554: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:08.609: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:08.609: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:08.609: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>>
>> 01-30 01:36:10.439: INFO/ActivityManager(1191): Starting activity:
>> Intent { act=android.intent.action.MAIN
>> cat=[android.intent.category.LAUNCHER] flg=0x10200000
>> cmp=com.real.RealPlayer/.Home }
>>
>> 01-30 01:36:10.509: DEBUG/RP-HOME(1322): onCreate
>>
>> 01-30 01:36:11.019: VERBOSE/RP-HOME(1322): onCreate(): scanner already
>> registered, no need to send the broadcast
>>
>> 01-30 01:36:11.069: VERBOSE/RP-MediaService(1322): onCreate
>>
>> 01-30 01:36:11.129: WARN/IInputConnectionWrapper(1256): showStatusIcon
>> on inactive InputConnection
>>
>> 01-30 01:36:11.339: INFO/ActivityManager(1191): Displayed activity
>> com.real.RealPlayer/.Home: 851 ms (total 851 ms)
>>
>> 01-30 01:36:19.789: WARN/IInputConnectionWrapper(1322): showStatusIcon
>> on inactive InputConnection
>>
>> 01-30 01:36:19.899: DEBUG/RP-HOME(1322): onDestroy
>>
>> 01-30 01:36:19.949: INFO/ActivityManager(1191): Stopping service:
>> com.real.RealPlayer/.MediaPlaybackService
>>
>> 01-30 01:36:19.949: INFO/RP-HOME(1322): Skipping
>> cleanup:isMediaScannerScanning():true, isRealDataScanning():true
>>
>> 01-30 01:36:19.959: VERBOSE/RP-MediaService(1322): onDestroy
>>
>> 01-30 01:36:23.199: VERBOSE/HelixMetaDataDriver(1141): display width
>> (848) and height (400), and size (678400)
>>
>> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:23.239: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:23.239: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 14632 ms
>>
>> 01-30 01:36:23.309: VERBOSE/RP-BitmapUtils(1308):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:36:23.669: VERBOSE/HelixMetaDataDriver(1141): display width
>> (848) and height (400), and size (678400)
>>
>> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:23.709: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:23.709: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:23.709: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 15159 ms
>>
>> 01-30 01:36:23.719: VERBOSE/RP-BitmapUtils(1322):
>> saveMiniThumbToFile(): Thumbnail saved successfully at
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:36:23.909: INFO/RP-MediaScannerService(1308): SKIPPING
>> Closing DB as appOpen:false and mIsMediaScanning:true and
>> isRealDataScanning:false
>>
>> 01-30 01:36:23.909: VERBOSE/RP-MediaScannerService(1308):
>> doBgMediaScannerFinishedWork(): ends
>>
>> 01-30 01:36:24.279: INFO/RP-MediaScannerService(1322): SKIPPING
>> Closing DB as appOpen:false and mIsMediaScanning:trueand
>> isRealDataScanning:false
>>
>> 01-30 01:36:24.279: VERBOSE/RP-MediaScannerService(1322):
>> doBgMediaScannerFinishedWork(): ends
>>
>> 01-30 01:36:25.659: INFO/ActivityManager(1191): Starting activity:
>> Intent { act=android.intent.action.MAIN
>> cat=[android.intent.category.LAUNCHER] flg=0x10200000
>> cmp=com.android.camera/.GalleryPicker }
>>
>> 01-30 01:36:26.029: WARN/IInputConnectionWrapper(1256): showStatusIcon
>> on inactive InputConnection
>>
>> 01-30 01:36:26.089: INFO/ActivityManager(1191): Displayed activity
>> com.android.camera/.GalleryPicker: 399 ms (total 399 ms)
>>
>> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:26.259: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:26.259: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/video/Conan.rmvb
>>
>> 01-30 01:36:26.259: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:26.579: VERBOSE/HelixMetaDataDriver(1141): display width
>> (856) and height (480), and size (821760)
>>
>> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:26.609: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:26.609: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:26.609: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 351 ms
>>
>> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:26.809: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:26.809: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/V100316_132800.3g2
>>
>> 01-30 01:36:26.809: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:26.919: VERBOSE/HelixMetaDataDriver(1141): display width
>> (176) and height (144), and size (50688)
>>
>> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:26.929: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:26.929: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:26.929: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 121 ms
>>
>> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:26.999: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:26.999: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>>
>> 01-30 01:36:26.999: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:28.139: INFO/ActivityManager(1191): Starting activity:
>> Intent { act=android.intent.action.VIEW
>> dat=content://media/internal/images/media
>> cmp=com.android.camera/.ImageGallery (has extras) }
>>
>> 01-30 01:36:28.479: INFO/ActivityManager(1191): Displayed activity
>> com.android.camera/.ImageGallery: 338 ms (total 338 ms)
>>
>> 01-30 01:36:34.419: VERBOSE/HelixMetaDataDriver(1141): display width
>> (848) and height (400), and size (678400)
>>
>> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:34.449: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:34.449: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:34.449: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 7456 ms
>>
>> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver constructor
>>
>> 01-30 01:36:34.584: INFO/HelixMetaDataDriver(1141): meta data driver
>> constructor
>>
>> 01-30 01:36:34.589: DEBUG/HelixMetaDataDriver(1141): m_pFileName :
>> /sdcard/movies/crank2-tlr1b_mjpeg_wvga.avi
>>
>> 01-30 01:36:34.589: INFO/HelixPlayer(1141): media platform finial
>> release canceled.
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): Leak found
>>
>> 01-30 01:36:34.709: ERROR/Database(1267):
>> java.lang.IllegalStateException:
>> /data/data/com.android.providers.media/databases/external-1e3b66a5.db
>> SQLiteDatabase created and never closed
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteDatabase.(SQLiteDatabase.java:1581)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:638)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:659)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:652)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.app.ApplicationContext.openOrCreateDatabase(ApplicationContext.java:482)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:193)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:98)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:158)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaProvider.query(MediaProvider.java:874)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaProvider.attachVolume(MediaProvider.java:2244)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaProvider.insertInternal(MediaProvider.java:1420)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaProvider.insert(MediaProvider.java:1200)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.content.ContentProvider$Transport.insert(ContentProvider.java:140)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.content.ContentResolver.insert(ContentResolver.java:479)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaScannerService.openDatabase(MediaScannerService.java:61)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaScannerService.scan(MediaScannerService.java:108)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaScannerService.access$200(MediaScannerService.java:49)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaScannerService$ServiceHandler.handleMessage(MediaScannerService.java:280)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.os.Handler.dispatchMessage(Handler.java:99)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> android.os.Looper.loop(Looper.java:123)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> com.android.providers.media.MediaScannerService.run(MediaScannerService.java:180)
>>
>> 01-30 01:36:34.709: ERROR/Database(1267): at
>> java.lang.Thread.run(Thread.java:1060)
>>
>> 01-30 01:36:42.049: VERBOSE/HelixMetaDataDriver(1141): display width
>> (848) and height (400), and size (678400)
>>
>> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): Helix meta data
>> driver destructor
>>
>> 01-30 01:36:42.079: INFO/HelixMetaDataDriver(1141): meta data driver
>> destructor
>>
>> 01-30 01:36:42.079: INFO/HelixPlayer(1141): schedule media platform
>> finial release
>>
>> 01-30 01:36:42.079: DEBUG/HelixMetaDataDriver(1141): [Timing]
>> MetaDataDriver Lifetime: 7494 ms
>>
>> 01-30 01:37:01.169: DEBUG/RP-MediaScannerService(1308): Scanning SD Card
>>
>> 01-30 01:37:01.169: DEBUG/RP-MediaStore(1308): mtime for:
>> /sdcard/.helix.thumbnails/=1264813654000
>>
>> 01-30 01:37:01.179: DEBUG/RP-MediaStore(1308): ScanSDCard start
>>
>> 01-30 01:37:01.379: DEBUG/RP-MediaStore(1308): ScanSDCard end
>>
>> 01-30 01:37:01.379: VERBOSE/RP-DataStore(1308): checkVideoMiniThumbails()
>>
>> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:37:01.399: VERBOSE/RP-DataStore(1308):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:37:01.399: DEBUG/RP-DataStore(1308): verifyVideoThumbnails start
>>
>> 01-30 01:37:01.602: DEBUG/RP-MediaScannerService(1322): Scanning SD Card
>>
>> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): mtime for:
>> /sdcard/.helix.thumbnails/=1264813654000
>>
>> 01-30 01:37:01.602: DEBUG/RP-MediaStore(1322): ScanSDCard start
>>
>> 01-30 01:37:01.689: DEBUG/RP-MediaStore(1322): ScanSDCard end
>>
>> 01-30 01:37:01.689: VERBOSE/RP-DataStore(1322): checkVideoMiniThumbails()
>>
>> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/1
>>
>> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/2
>>
>> 01-30 01:37:01.709: VERBOSE/RP-DataStore(1322):
>> checkVideoMiniThumbails():Video uri:
>> :/sdcard/.helix.thumbnails/videothumb/3
>>
>> 01-30 01:37:01.709: DEBUG/RP-DataStore(1322): verifyVideoThumbnails start
>>
>> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): verifyVideoThumbnails
>> complete
>>
>> 01-30 01:37:02.929: VERBOSE/RP-MediaScannerService(1308): Closing DB
>> as appOpen:false and mIsMediaScanning:false and isRealDataScanning:false
>>
>> 01-30 01:37:02.929: VERBOSE/RP-DataStore(1308): cleanUp()
>>
>> 01-30 01:37:02.929: DEBUG/RP-DataStore(1308): resetAllScannerFlags
>>
>> 01-30 01:37:02.939: VERBOSE/RP-DataStore(1308): cleanUp(): finished
>> normally
>>
>> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): verifyVideoThumbnails
>> complete
>>
>> 01-30 01:37:03.231: VERBOSE/RP-MediaScannerService(1322): Closing DB
>> as appOpen:false and mIsMediaScanning:falseand isRealDataScanning:false
>>
>> 01-30 01:37:03.231: VERBOSE/RP-DataStore(1322): cleanUp()
>>
>> 01-30 01:37:03.231: DEBUG/RP-DataStore(1322): resetAllScannerFlags
>>
>> 01-30 01:37:03.309: VERBOSE/RP-DataStore(1322): cleanUp(): finished
>> normally
>>
>> 01-30 01:37:06.309: INFO/HelixPlayer(1141): Helix Media platform
>> finial release: done.
>>
>>
>>
>>
>>
>> more details please check the attached log file.
>>
>>
>>
>> Regards,
>> LiQiang(Joe)
>> RealNetworks, China
>> T: +86(10)59542795
>>
>>
>>
>>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
From Joeli at real.com Thu Mar 18 20:04:56 2010
From: Joeli at real.com (Qiang (Joe) Li)
Date: Fri Mar 19 03:13:02 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IEZpeCBmb3IgQnVnIDk5NzQ6IEl0?=
=?gb2312?B?IGNvc3RzIDI0IHNlY29uZHMgZm9yIGNhcHR1cmluZyB0aHVtYm5haWwgb2Y=?=
=?gb2312?B?IGEgYnJva2VuIHJtdmIgZmlsZQ==?=
In-Reply-To: <4BA2C44A.30104@real.com>
References: ,
<4BA23BD2.7030300@real.com>
<4BA2C44A.30104@real.com>
Message-ID:
VGhhbmtzLiAgQ29tbWl0dGVkIHRvIDM2MWF0bGFzLg0KDQpSZWdhcmRzLA0KTGlRaWFuZyhKb2Up
DQpSZWFsTmV0d29ya3MsIENoaW5hDQpUOiArODYoMTApNTk1NDI3OTUNCi0tLS0t08q8/tStvP4t
LS0tLQ0Kt6K8/sjLOiBYaWFvZG9uZyAoU2hlbGRvbikgRnUNCreiy83KsbzkOiBGcmlkYXksIE1h
cmNoIDE5LCAyMDEwIDg6MjUgQU0NCsrVvP7IyzogS2luc29uIExpdQ0Ks63LzTogUWlhbmcgKEpv
ZSkgTGk7IE1hbmp1bmF0aGEgS2FudGhyYWp1OyBkYXRhdHlwZS1kZXZAaGVsaXhjb21tdW5pdHku
b3JnDQrW98ziOiBSZTogW2RhdGF0eXBlLWRldl0gQ1I6IEZpeCBmb3IgQnVnIDk5NzQ6IEl0IGNv
c3RzIDI0IHNlY29uZHMgZm9yIGNhcHR1cmluZyB0aHVtYm5haWwgb2YgYSBicm9rZW4gcm12YiBm
aWxlDQoNClN1cmUuIGl0IGlzIGEgc2FmZSBjaGFuZ2UuIEdvIGNoZWNrIGl0IGluLg0KDQpmeGQN
Cg0KS2luc29uIExpdSB3cm90ZToNCj4gU2hlbGRvbiwNCj4NCj4gQWZ0ZXIgYWRkaW5nIHRoZSAi
bV9Ub3RhbEZpbGVTaXplICE9IDAiIGJhY2sgaW4sIGRvIHlvdSB0aGluayB0aGlzIENSIHdpbGwg
YmUgT0s/ICBTaW5jZSB0aW1lIGlzIHJ1bm5pbmcgb3V0LCB3ZSBjYW4gdGFrZSB0aGlzIGFwcHJv
YWNoIC0gc2V0dGxlIHdpdGggTGkgUWlhbmcncyBDUiBmb3Igbm93OyByZXZpc2UgdGhlIGZpbGUg
c3lzdGVtIHdoZW4gd2UgaGF2ZSB0aW1lLg0KPg0KPiBUaGFua3MsDQo+DQo+IEtpbnNvbg0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IGRhdGF0eXBl
LWRldi1ib3VuY2VzQGhlbGl4Y29tbXVuaXR5Lm9yZyBbZGF0YXR5cGUtZGV2LWJvdW5jZXNAaGVs
aXhjb21tdW5pdHkub3JnXSBPbiBCZWhhbGYgT2YgWGlhb2RvbmcgKFNoZWxkb24pIEZ1DQo+IFNl
bnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAxMCA3OjQyIEFNDQo+IFRvOiBRaWFuZyAoSm9lKSBM
aQ0KPiBDYzogTWFuanVuYXRoYSBLYW50aHJhanU7IGRhdGF0eXBlLWRldkBoZWxpeGNvbW11bml0
eS5vcmcNCj4gU3ViamVjdDogUmU6IFtkYXRhdHlwZS1kZXZdIENSOiBGaXggZm9yIEJ1ZyA5OTc0
OiBJdCBjb3N0cyAyNCBzZWNvbmRzIGZvciAgICAgICBjYXB0dXJpbmcgdGh1bWJuYWlsIG9mIGEg
YnJva2VuIHJtdmIgZmlsZQ0KPg0KPiBJbiBzb21lIGNhc2VzLCBtX1RvdGFsRmlsZVNpemUgbWF5
IGJlIHVua25vd24gYW5kIGl0IHdpbGwgYmUgemVyby4gVGhlDQo+ICdpZicgc3RhdGVtZW50IG5l
ZWRzIHRvIGFjY291bnQgZm9yIHRoaXMgY29uZGl0aW9uLCBqdXN0IGxpa2UgdGhlIG9sZA0KPiBj
b2RlIGRvZXMuDQo+DQo+IFRoaXMgaXMgYXQgbGVhc3QgdGhlIDNyZCB0aW1lIGEgQ1IgaXMgc2Vu
dCBmb3IgdGhlc2Uga2luZCBvZiBvdXQgb2YNCj4gcmFuZ2Ugc2VlayBkZWxheSBwcm9ibGVtcyBp
biBkaWZmZXJlbnQgZGF0YSB0eXBlcyBJIHRoaW5rLiBUaGUgZml4DQo+IHJlYWxseSBzaG91bGQg
YmUgaW4gdGhlIGZpbGUgc3lzdGVtIGl0c2VsZiAtLSBpLmUuIGlmIGZpbGUgZm9ybWF0DQo+IHJl
cXVpcmVzIGEgc2VlayBhbmQgaXQgaXMgb3V0IG9mIHJhbmdlLCBmaWxlIHN5c3RlbS9vYmplY3Qg
c2hvdWxkIGZhaWwNCj4gdGhlIHNlZWsgcmlnaHQgd2F5IGFuZCBmaWxlIGZvcm1hdCBqdXN0IG5l
ZWQgdG8gaGFuZGxlIHRoYXQgZXJyb3INCj4gY29uZGl0aW9uIGluIGEgdGltZWx5IG1hbm5lci4g
T3RoZXJ3aXNlLCB3ZSdsbCBoYXZlIHRvIGZpeCB0aGUgZmlsZQ0KPiBmb3JtYXQgcGx1Z2lucyBv
bmUgYnkgb25lLg0KPg0KPiBmeGQNCj4NCj4gUWlhbmcgKEpvZSkgTGkgd3JvdGU6DQo+DQo+PiBQ
cm9qZWN0OiBSZWFsIFBsYXllciBmb3IgQW5kcm9pZA0KPj4NCj4+DQo+Pg0KPj4gU3lub3BzaXM6
IEZpeCBmb3IgQnVnIDk5NzQ6IEl0IGNvc3RzIDI0IHNlY29uZHMgZm9yIGNhcHR1cmluZw0KPj4g
dGh1bWJuYWlsIG9mIGEgYnJva2VuIHJtdmIgZmlsZS4NCj4+DQo+Pg0KPj4NCj4+IE92ZXJ2aWV3
Og0KPj4NCj4+IFRoaXMgaXNzdWUgd2FzIGNvbmZsaWN0IHdpdGggQnVnMTAwMzYgKEJ1ZyAxMDAz
NjoiZm9yY2UgY2xvc2UiIHdoZW4NCj4+IGNhcHR1cmluZyB0aHVtYm5haWwpLg0KPj4NCj4+IFNv
IHRoZSBCdWc5OTc0IHdhcyByZS1vcGVuZWQgaW4gUkMxNCBkdWUgdG8gYnVnIDEwMDM2oa9zIGZp
eGluZy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gSW4gQnVnMTAwMzY6DQo+Pg0KPj4gV2hlbiB0
cnlpbmcgdG8gY2FwdHVyZSB0aHVtYm5haWwgZm9yIHRoaXMgYXZpIGZpbGUuDQo+Pg0KPj4gVGh1
bWJuYWlsIGdlbmVyYXRpb24gc3RhcnQgdGltZSBmb3IgYW5kcm9pZCBpcyAzMHNlYyBhbmQgc2lu
Y2Ugd2UgaGF2ZQ0KPj4gNiBzZWMgcGxheWJhY2sgaW4gdGhpcyBmaWxlLCB0aGUgaWRlYWwgYmVo
YXZpb3IgZm9yIHRoZSBwbGF5ZXIgaXMgdG8NCj4+IGV4aXQgZ3JhY2VmdWxseSBieSByZXR1cm5p
bmcgYW4gZXJyb3IuDQo+Pg0KPj4NCj4+DQo+PiBXaGlsZSBJbiBCdWc5OTc0Og0KPj4NCj4+IEl0
IHdhcyBkdWUgdG8gY2FwdHVyaW5nIHRodW1ibmFpbCBvZiBhIGNvcnJ1cHRlZC9icm9rZW4gUk1W
QiBmaWxlLiBJbg0KPj4gdGhpcyBnaXZlbiBicm9rZW4vY29ycnVwdGVkIFJNVkIgZmlsZSwgVGhl
IGR1cmF0aW9uIGdpdmVuIGluIGZpbGUNCj4+IGhlYWRlciBpcyBhcm91bmQgMTExIG1pbnV0ZXMs
IHdoZXJlYXMgdGhlIGFjdHVhbCBjbGlwIGlzIG9ubHkgYXJvdW5kDQo+PiA3bWludXRlcy4gQXQg
c29tZSBwb2ludCBpbiBleGVjdXRpb24sIHRoZSByaWZmIHJlYWRlciB0cmllcyB0byBzZWVrIHRv
DQo+PiBhbiBvZmZzZXQgKHRvIGFyb3VuZCAxMTEgbWludXRlcykgd2hpY2ggaXMgd2F5IG91dHNp
ZGUgdGhlIGZpbGUgc2l6ZQ0KPj4gbGltaXRzIGFuZCBhZnRlciB0aGlzIC0+U2VlaygpIGNhbGws
IGl0IHRha2VzIGFib3V0IDI0IHNlY29uZHMgdG8NCj4+IHJldHVybiB0aGUgY29udHJvbCBiYWNr
IHRvIDo6UklGRlNlZWtEb25lKCkgbWV0aG9kLg0KPj4NCj4+DQo+Pg0KPj4gU28gaW4gb3JkZXIg
bm90IHRvIGFmZmVjdCB0aGVzZSB0d28gdGVzdCBjYXNlcywNCj4+DQo+PiBJIHRoaW5rIGFkZGVk
IGEgY2hlY2sgdG8gbWFrZSBzdXJlIHRoYXQgZGVzaXJlZCBzZWVrIG9mZnNldCBmYWxscw0KPj4g
d2l0aGluIHRoZSBmaWxlIHNpemUgbGltaXRzLiBpZiBkZXNpcmVkIHNlZWsgb2Zmc2V0IGlzIG91
dHNpZGUgZmlsZQ0KPj4gc2l6ZSBsaW1pdHMsIHdlIHNpbXBseSBjYWxsIFJJRkZTZWVrRG9uZShI
WFJfRkFJTEVEKS4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gIEZpbGVzIEFkZGVkOiBOb25lDQo+
Pg0KPj4NCj4+DQo+PiAgRmlsZXMgTW9kaWZpZWQ6DQo+Pg0KPj4gIGRhdGF0eXBlL2NvbW1vbi91
dGlsL3JpZmYuY3BwDQo+Pg0KPj4NCj4+DQo+PiAgUGxhdGZvcm1zIGFuZCBQcm9maWxlcyBCdWls
ZCBhbmQgRnVuY3Rpb25hbGl0eSBWZXJpZmllZDoNCj4+DQo+PiAgUGxhdGZvcm06IGFuZHJvaWQt
ZG9udXQzMjMwLWFybS5lYWJpDQo+Pg0KPj4gIFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRyb2lk
LWZ1bGwNCj4+DQo+PiAgdGFyZ2V0KHMpOiBhbmRyb2lkX29teA0KPj4NCj4+ICBCcmFuY2g6IGh4
Y2xpZW50XzNfNl8xX2F0bGFzX3Jlc3RyaWN0ZWQNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRElG
RjoNCj4+DQo+Pg0KPj4NCj4+IEhYX1JFU1VMVA0KPj4NCj4+IENSSUZGUmVhZGVyOjpGaWxlU2Vl
ayhVSU5UMzIgb2Zmc2V0KQ0KPj4NCj4+IHsNCj4+DQo+PiAgICAgbV91bFNlZWtPZmZzZXQgPSBv
ZmZzZXQ7DQo+Pg0KPj4gICAgIG1fc3RhdGUgPSBSU19Vc2VyU2Vla1BlbmRpbmc7DQo+Pg0KPj4g
LSAgIGlmKG1fdWxTZWVrT2Zmc2V0ID49IG1fVG90YWxGaWxlU2l6ZSAmJiBtX1RvdGFsRmlsZVNp
emUgIT0gMCkNCj4+DQo+PiAtICAgIHsNCj4+DQo+PiAtICAgICAgbV91bFNlZWtPZmZzZXQgPSBt
X1RvdGFsRmlsZVNpemU7DQo+Pg0KPj4gLSAgICB9DQo+Pg0KPj4gLSAgIHJldHVybiBtX3BGaWxl
T2JqZWN0LT5TZWVrKG1fdWxTZWVrT2Zmc2V0LCBGQUxTRSk7DQo+Pg0KPj4gKyAgIGlmKG1fdWxT
ZWVrT2Zmc2V0IDw9IG1fVG90YWxGaWxlU2l6ZSkNCj4+DQo+PiArICAgew0KPj4NCj4+ICsgICAg
ICAgcmV0dXJuIG1fcEZpbGVPYmplY3QtPlNlZWsobV91bFNlZWtPZmZzZXQsIEZBTFNFKTsNCj4+
DQo+PiArICAgfQ0KPj4NCj4+ICsgICBlbHNlDQo+Pg0KPj4gKyAgIHsNCj4+DQo+PiArICAgICAg
IHJldHVybiBtX3BSZXNwb25zZS0+UklGRlNlZWtEb25lKEhYUl9GQUlMRUQpOw0KPj4NCj4+ICsg
ICB9DQo+Pg0KPj4NCj4+DQo+PiB9DQo+Pg0KPj4NCj4+DQo+PiBVbWFrYW50IGFuZCBNYW5qdW5h
dGhhIHBsZWFzZSBoZWxwIHRvIGNoZWNrIHRoaXMgbW9kaWZpY2F0aW9uOw0KPj4NCj4+IFRoYW5r
cy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gVGVzdCBSZXN1bHQ6DQo+Pg0KPj4gVGVzdCBmaWxl
czoNCj4+DQo+PiBjcmFuazItdGxyMWJfbWpwZWdfd3ZnYS5hdmkNCj4+DQo+PiBjb25hbi5ybXZi
DQo+Pg0KPj4NCj4+DQo+PiAwMS0zMCAwMTozNjowMy44Nzk6IFZFUkJPU0UvUlAtRGF0YVN0b3Jl
KDEzMDgpOiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDMu
ODg5OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzIyKToNCj4+IGNoZWNrVmlkZW9NaW5pVGh1bWJh
aWxzKCk6VmlkZW8gdXJpOg0KPj4gOi9zZGNhcmQvLmhlbGl4LnRodW1ibmFpbHMvdmlkZW90aHVt
Yi8xDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDMuOTE5OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzA4
KToNCj4+IGNoZWNrVmlkZW9NaW5pVGh1bWJhaWxzKCk6VmlkZW8gdXJpOg0KPj4gOi9zZGNhcmQv
LmhlbGl4LnRodW1ibmFpbHMvdmlkZW90aHVtYi8xDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDMuOTE5
OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1ldGEgZGF0YQ0KPj4gZHJp
dmVyIGNvbnN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDMuOTE5OiBJTkZPL0hlbGl4TWV0
YURhdGFEcml2ZXIoMTE0MSk6IG1ldGEgZGF0YSBkcml2ZXINCj4+IGNvbnN0cnVjdG9yDQo+Pg0K
Pj4gMDEtMzAgMDE6MzY6MDMuOTE5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBt
X3BGaWxlTmFtZSA6DQo+PiAvc2RjYXJkL3ZpZGVvL0NvbmFuLnJtdmINCj4+DQo+PiAwMS0zMCAw
MTozNjowMy45MTk6IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBk
YXRhDQo+PiBkcml2ZXIgY29uc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjowMy45MTk6IElO
Rk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gY29uc3Ry
dWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjowMy45MTk6IERFQlVHL0hlbGl4TWV0YURhdGFEcml2
ZXIoMTE0MSk6IG1fcEZpbGVOYW1lIDoNCj4+IC9zZGNhcmQvdmlkZW8vQ29uYW4ucm12Yg0KPj4N
Cj4+IDAxLTMwIDAxOjM2OjA0LjAwOTogREVCVUcvSGVsaXhQbGF5ZXIoMTE0MSk6DQo+PiBtX3BN
ZWRpYVBsYXRmb3JtLT5BZGRQbHVnaW5QYXRoKCkgcGF0aD0vc3lzdGVtL2xpYi9oZWxpeC4NCj4+
DQo+PiAwMS0zMCAwMTozNjowNC4yMjk6IElORk8vQWN0aXZpdHlNYW5hZ2VyKDExOTEpOiBTdG9w
cGluZyBzZXJ2aWNlOg0KPj4gY29tLmFuZHJvaWQuY2FtZXJhLy5UaHVtYm5haWxTY2FubmVyU2Vy
dmljZQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjA0LjMyOTogREVCVUcvZGRtLWhlYXAoMTM4Nyk6IEdv
dCBmZWF0dXJlIGxpc3QgcmVxdWVzdA0KPj4NCj4+IDAxLTMwIDAxOjM2OjA1LjI3OTogREVCVUcv
S2V5Z3VhcmRWaWV3TWVkaWF0b3IoMTE5MSk6IHBva2VXYWtlbG9jayg1MDAwKQ0KPj4NCj4+IDAx
LTMwIDAxOjM2OjA1LjMzOTogSU5GTy9BY3Rpdml0eU1hbmFnZXIoMTE5MSk6IFN0YXJ0IHByb2MN
Cj4+IGNvbS5hbmRyb2lkLmlucHV0bWV0aG9kLmxhdGluIGZvciBzZXJ2aWNlDQo+PiBjb20uYW5k
cm9pZC5pbnB1dG1ldGhvZC5sYXRpbi8uTGF0aW5JTUU6IHBpZD0xNDA5IHVpZD0xMDAwOA0KPj4g
Z2lkcz17MzAwMywgMzAwMiwgMzAwMSwgMTAxNX0NCj4+DQo+PiAwMS0zMCAwMTozNjowNS4zODk6
IERFQlVHL2RkbS1oZWFwKDE0MDkpOiBHb3QgZmVhdHVyZSBsaXN0IHJlcXVlc3QNCj4+DQo+PiAw
MS0zMCAwMTozNjowNi4yOTk6IFZFUkJPU0UvSGVsaXhQbGF5ZXIoMTE0MSk6IEhlbGl4IE1lZGlh
IHBsYXRmb3JtDQo+PiBjcmVhdGVkLCB0aHJlYWRfaWQgPSA4NjAyNC4NCj4+DQo+PiAwMS0zMCAw
MTozNjowNy4xODk6IFZFUkJPU0UvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogZGlzcGxheSB3
aWR0aA0KPj4gKDg1NikgYW5kIGhlaWdodCAoNDgwKSwgYW5kIHNpemUgKDgyMTc2MCkNCj4+DQo+
PiAwMS0zMCAwMTozNjowNy4xOTk6IFZFUkJPU0UvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTog
ZGlzcGxheSB3aWR0aA0KPj4gKDg1NikgYW5kIGhlaWdodCAoNDgwKSwgYW5kIHNpemUgKDgyMTc2
MCkNCj4+DQo+PiAwMS0zMCAwMTozNjowNy4yNTk6IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigx
MTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgZGVzdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMw
IDAxOjM2OjA3LjI1OTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBtZXRhIGRhdGEg
ZHJpdmVyDQo+PiBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDcuMjU5OiBERUJVRy9I
ZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBbVGltaW5nXQ0KPj4gTWV0YURhdGFEcml2ZXIgTGlm
ZXRpbWU6IDMzNDMgbXMNCj4+DQo+PiAwMS0zMCAwMTozNjowNy4yNzk6IElORk8vSGVsaXhNZXRh
RGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgZGVzdHJ1Y3Rvcg0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjA3LjI3OTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEp
OiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDcu
Mjc5OiBJTkZPL0hlbGl4UGxheWVyKDExNDEpOiBzY2hlZHVsZSBtZWRpYSBwbGF0Zm9ybQ0KPj4g
ZmluaWFsIHJlbGVhc2UNCj4+DQo+PiAwMS0zMCAwMTozNjowNy4yNzk6IERFQlVHL0hlbGl4TWV0
YURhdGFEcml2ZXIoMTE0MSk6IFtUaW1pbmddDQo+PiBNZXRhRGF0YURyaXZlciBMaWZldGltZTog
MzM2MiBtcw0KPj4NCj4+IDAxLTMwIDAxOjM2OjA3LjMyOTogVkVSQk9TRS9SUC1CaXRtYXBVdGls
cygxMzIyKToNCj4+IHNhdmVNaW5pVGh1bWJUb0ZpbGUoKTogVGh1bWJuYWlsIHNhdmVkIHN1Y2Nl
c3NmdWxseSBhdA0KPj4gOi9zZGNhcmQvLmhlbGl4LnRodW1ibmFpbHMvdmlkZW90aHVtYi8xDQo+
Pg0KPj4gMDEtMzAgMDE6MzY6MDcuMzI5OiBWRVJCT1NFL1JQLUJpdG1hcFV0aWxzKDEzMDgpOg0K
Pj4gc2F2ZU1pbmlUaHVtYlRvRmlsZSgpOiBUaHVtYm5haWwgc2F2ZWQgc3VjY2Vzc2Z1bGx5IGF0
DQo+PiA6L3NkY2FyZC8uaGVsaXgudGh1bWJuYWlscy92aWRlb3RodW1iLzENCj4+DQo+PiAwMS0z
MCAwMTozNjowNy44MzY6IFZFUkJPU0UvUlAtRGF0YVN0b3JlKDEzMjIpOg0KPj4gY2hlY2tWaWRl
b01pbmlUaHVtYmFpbHMoKTpWaWRlbyB1cmk6DQo+PiA6L3NkY2FyZC8uaGVsaXgudGh1bWJuYWls
cy92aWRlb3RodW1iLzINCj4+DQo+PiAwMS0zMCAwMTozNjowNy44MzY6IElORk8vSGVsaXhNZXRh
RGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgY29uc3RydWN0b3IN
Cj4+DQo+PiAwMS0zMCAwMTozNjowNy44MzY6IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQx
KTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gY29uc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjow
Ny44MzY6IERFQlVHL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IG1fcEZpbGVOYW1lIDoNCj4+
IC9zZGNhcmQvbW92aWVzL1YxMDAzMTZfMTMyODAwLjNnMg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA3
LjgzNjogSU5GTy9IZWxpeFBsYXllcigxMTQxKTogbWVkaWEgcGxhdGZvcm0gZmluaWFsDQo+PiBy
ZWxlYXNlIGNhbmNlbGVkLg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA3LjgzOTogVkVSQk9TRS9SUC1E
YXRhU3RvcmUoMTMwOCk6DQo+PiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZpZGVvIHVyaToN
Cj4+IDovc2RjYXJkLy5oZWxpeC50aHVtYm5haWxzL3ZpZGVvdGh1bWIvMg0KPj4NCj4+IDAxLTMw
IDAxOjM2OjA3LjgzOTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBIZWxpeCBtZXRh
IGRhdGENCj4+IGRyaXZlciBjb25zdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA3LjgzOTog
SU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBjb25z
dHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA3LjgzOTogREVCVUcvSGVsaXhNZXRhRGF0YURy
aXZlcigxMTQxKTogbV9wRmlsZU5hbWUgOg0KPj4gL3NkY2FyZC9tb3ZpZXMvVjEwMDMxNl8xMzI4
MDAuM2cyDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDguMDI5OiBWRVJCT1NFL0hlbGl4TWV0YURhdGFE
cml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgNCj4+ICgxNzYpIGFuZCBoZWlnaHQgKDE0NCksIGFu
ZCBzaXplICg1MDY4OCkNCj4+DQo+PiAwMS0zMCAwMTozNjowOC4wMjk6IElORk8vSGVsaXhNZXRh
RGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgZGVzdHJ1Y3Rvcg0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjA4LjAyOTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEp
OiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDgu
MDI5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBbVGltaW5nXQ0KPj4gTWV0YURh
dGFEcml2ZXIgTGlmZXRpbWU6IDE5NyBtcw0KPj4NCj4+IDAxLTMwIDAxOjM2OjA4LjA0OTogVkVS
Qk9TRS9SUC1CaXRtYXBVdGlscygxMzIyKToNCj4+IHNhdmVNaW5pVGh1bWJUb0ZpbGUoKTogVGh1
bWJuYWlsIHNhdmVkIHN1Y2Nlc3NmdWxseSBhdA0KPj4gOi9zZGNhcmQvLmhlbGl4LnRodW1ibmFp
bHMvdmlkZW90aHVtYi8yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDguMDk5OiBWRVJCT1NFL0hlbGl4
TWV0YURhdGFEcml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgNCj4+ICgxNzYpIGFuZCBoZWlnaHQg
KDE0NCksIGFuZCBzaXplICg1MDY4OCkNCj4+DQo+PiAwMS0zMCAwMTozNjowOC4wOTk6IElORk8v
SGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgZGVz
dHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA4LjA5OTogSU5GTy9IZWxpeE1ldGFEYXRhRHJp
dmVyKDExNDEpOiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAg
MDE6MzY6MDguMDk5OiBJTkZPL0hlbGl4UGxheWVyKDExNDEpOiBzY2hlZHVsZSBtZWRpYSBwbGF0
Zm9ybQ0KPj4gZmluaWFsIHJlbGVhc2UNCj4+DQo+PiAwMS0zMCAwMTozNjowOC4wOTk6IERFQlVH
L0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IFtUaW1pbmddDQo+PiBNZXRhRGF0YURyaXZlciBM
aWZldGltZTogMjY3IG1zDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MDguMTA5OiBWRVJCT1NFL1JQLUJp
dG1hcFV0aWxzKDEzMDgpOg0KPj4gc2F2ZU1pbmlUaHVtYlRvRmlsZSgpOiBUaHVtYm5haWwgc2F2
ZWQgc3VjY2Vzc2Z1bGx5IGF0DQo+PiA6L3NkY2FyZC8uaGVsaXgudGh1bWJuYWlscy92aWRlb3Ro
dW1iLzINCj4+DQo+PiAwMS0zMCAwMTozNjowOC41NTQ6IFZFUkJPU0UvUlAtRGF0YVN0b3JlKDEz
MjIpOg0KPj4gY2hlY2tWaWRlb01pbmlUaHVtYmFpbHMoKTpWaWRlbyB1cmk6DQo+PiA6L3NkY2Fy
ZC8uaGVsaXgudGh1bWJuYWlscy92aWRlb3RodW1iLzMNCj4+DQo+PiAwMS0zMCAwMTozNjowOC41
NTQ6IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBk
cml2ZXIgY29uc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjowOC41NTQ6IElORk8vSGVsaXhN
ZXRhRGF0YURyaXZlcigxMTQxKTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gY29uc3RydWN0b3INCj4+
DQo+PiAwMS0zMCAwMTozNjowOC41NTQ6IERFQlVHL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6
IG1fcEZpbGVOYW1lIDoNCj4+IC9zZGNhcmQvbW92aWVzL2NyYW5rMi10bHIxYl9tanBlZ193dmdh
LmF2aQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjA4LjU1NDogSU5GTy9IZWxpeFBsYXllcigxMTQxKTog
bWVkaWEgcGxhdGZvcm0gZmluaWFsDQo+PiByZWxlYXNlIGNhbmNlbGVkLg0KPj4NCj4+IDAxLTMw
IDAxOjM2OjA4LjYwOTogVkVSQk9TRS9SUC1EYXRhU3RvcmUoMTMwOCk6DQo+PiBjaGVja1ZpZGVv
TWluaVRodW1iYWlscygpOlZpZGVvIHVyaToNCj4+IDovc2RjYXJkLy5oZWxpeC50aHVtYm5haWxz
L3ZpZGVvdGh1bWIvMw0KPj4NCj4+IDAxLTMwIDAxOjM2OjA4LjYwOTogSU5GTy9IZWxpeE1ldGFE
YXRhRHJpdmVyKDExNDEpOiBIZWxpeCBtZXRhIGRhdGENCj4+IGRyaXZlciBjb25zdHJ1Y3Rvcg0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjA4LjYwOTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEp
OiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBjb25zdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjA4
LjYwOTogREVCVUcvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbV9wRmlsZU5hbWUgOg0KPj4g
L3NkY2FyZC9tb3ZpZXMvY3JhbmsyLXRscjFiX21qcGVnX3d2Z2EuYXZpDQo+Pg0KPj4gMDEtMzAg
MDE6MzY6MTAuNDM5OiBJTkZPL0FjdGl2aXR5TWFuYWdlcigxMTkxKTogU3RhcnRpbmcgYWN0aXZp
dHk6DQo+PiBJbnRlbnQgeyBhY3Q9YW5kcm9pZC5pbnRlbnQuYWN0aW9uLk1BSU4NCj4+IGNhdD1b
YW5kcm9pZC5pbnRlbnQuY2F0ZWdvcnkuTEFVTkNIRVJdIGZsZz0weDEwMjAwMDAwDQo+PiBjbXA9
Y29tLnJlYWwuUmVhbFBsYXllci8uSG9tZSB9DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MTAuNTA5OiBE
RUJVRy9SUC1IT01FKDEzMjIpOiBvbkNyZWF0ZQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjExLjAxOTog
VkVSQk9TRS9SUC1IT01FKDEzMjIpOiBvbkNyZWF0ZSgpOiBzY2FubmVyIGFscmVhZHkNCj4+IHJl
Z2lzdGVyZWQsIG5vIG5lZWQgdG8gc2VuZCB0aGUgYnJvYWRjYXN0DQo+Pg0KPj4gMDEtMzAgMDE6
MzY6MTEuMDY5OiBWRVJCT1NFL1JQLU1lZGlhU2VydmljZSgxMzIyKTogb25DcmVhdGUNCj4+DQo+
PiAwMS0zMCAwMTozNjoxMS4xMjk6IFdBUk4vSUlucHV0Q29ubmVjdGlvbldyYXBwZXIoMTI1Nik6
IHNob3dTdGF0dXNJY29uDQo+PiBvbiBpbmFjdGl2ZSBJbnB1dENvbm5lY3Rpb24NCj4+DQo+PiAw
MS0zMCAwMTozNjoxMS4zMzk6IElORk8vQWN0aXZpdHlNYW5hZ2VyKDExOTEpOiBEaXNwbGF5ZWQg
YWN0aXZpdHkNCj4+IGNvbS5yZWFsLlJlYWxQbGF5ZXIvLkhvbWU6IDg1MSBtcyAodG90YWwgODUx
IG1zKQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjE5Ljc4OTogV0FSTi9JSW5wdXRDb25uZWN0aW9uV3Jh
cHBlcigxMzIyKTogc2hvd1N0YXR1c0ljb24NCj4+IG9uIGluYWN0aXZlIElucHV0Q29ubmVjdGlv
bg0KPj4NCj4+IDAxLTMwIDAxOjM2OjE5Ljg5OTogREVCVUcvUlAtSE9NRSgxMzIyKTogb25EZXN0
cm95DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MTkuOTQ5OiBJTkZPL0FjdGl2aXR5TWFuYWdlcigxMTkx
KTogU3RvcHBpbmcgc2VydmljZToNCj4+IGNvbS5yZWFsLlJlYWxQbGF5ZXIvLk1lZGlhUGxheWJh
Y2tTZXJ2aWNlDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MTkuOTQ5OiBJTkZPL1JQLUhPTUUoMTMyMik6
IFNraXBwaW5nDQo+PiBjbGVhbnVwOmlzTWVkaWFTY2FubmVyU2Nhbm5pbmcoKTp0cnVlLCBpc1Jl
YWxEYXRhU2Nhbm5pbmcoKTp0cnVlDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MTkuOTU5OiBWRVJCT1NF
L1JQLU1lZGlhU2VydmljZSgxMzIyKTogb25EZXN0cm95DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjMu
MTk5OiBWRVJCT1NFL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgNCj4+
ICg4NDgpIGFuZCBoZWlnaHQgKDQwMCksIGFuZCBzaXplICg2Nzg0MDApDQo+Pg0KPj4gMDEtMzAg
MDE6MzY6MjMuMjM5OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1ldGEg
ZGF0YQ0KPj4gZHJpdmVyIGRlc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjoyMy4yMzk6IElO
Rk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gZGVzdHJ1
Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjIzLjIzOTogREVCVUcvSGVsaXhNZXRhRGF0YURyaXZl
cigxMTQxKTogW1RpbWluZ10NCj4+IE1ldGFEYXRhRHJpdmVyIExpZmV0aW1lOiAxNDYzMiBtcw0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjIzLjMwOTogVkVSQk9TRS9SUC1CaXRtYXBVdGlscygxMzA4KToN
Cj4+IHNhdmVNaW5pVGh1bWJUb0ZpbGUoKTogVGh1bWJuYWlsIHNhdmVkIHN1Y2Nlc3NmdWxseSBh
dA0KPj4gOi9zZGNhcmQvLmhlbGl4LnRodW1ibmFpbHMvdmlkZW90aHVtYi8zDQo+Pg0KPj4gMDEt
MzAgMDE6MzY6MjMuNjY5OiBWRVJCT1NFL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IGRpc3Bs
YXkgd2lkdGgNCj4+ICg4NDgpIGFuZCBoZWlnaHQgKDQwMCksIGFuZCBzaXplICg2Nzg0MDApDQo+
Pg0KPj4gMDEtMzAgMDE6MzY6MjMuNzA5OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6
IEhlbGl4IG1ldGEgZGF0YQ0KPj4gZHJpdmVyIGRlc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMToz
NjoyMy43MDk6IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbWV0YSBkYXRhIGRyaXZl
cg0KPj4gZGVzdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjIzLjcwOTogSU5GTy9IZWxpeFBs
YXllcigxMTQxKTogc2NoZWR1bGUgbWVkaWEgcGxhdGZvcm0NCj4+IGZpbmlhbCByZWxlYXNlDQo+
Pg0KPj4gMDEtMzAgMDE6MzY6MjMuNzA5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEp
OiBbVGltaW5nXQ0KPj4gTWV0YURhdGFEcml2ZXIgTGlmZXRpbWU6IDE1MTU5IG1zDQo+Pg0KPj4g
MDEtMzAgMDE6MzY6MjMuNzE5OiBWRVJCT1NFL1JQLUJpdG1hcFV0aWxzKDEzMjIpOg0KPj4gc2F2
ZU1pbmlUaHVtYlRvRmlsZSgpOiBUaHVtYm5haWwgc2F2ZWQgc3VjY2Vzc2Z1bGx5IGF0DQo+PiA6
L3NkY2FyZC8uaGVsaXgudGh1bWJuYWlscy92aWRlb3RodW1iLzMNCj4+DQo+PiAwMS0zMCAwMToz
NjoyMy45MDk6IElORk8vUlAtTWVkaWFTY2FubmVyU2VydmljZSgxMzA4KTogU0tJUFBJTkcNCj4+
IENsb3NpbmcgREIgYXMgYXBwT3BlbjpmYWxzZSBhbmQgbUlzTWVkaWFTY2FubmluZzp0cnVlIGFu
ZA0KPj4gaXNSZWFsRGF0YVNjYW5uaW5nOmZhbHNlDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjMuOTA5
OiBWRVJCT1NFL1JQLU1lZGlhU2Nhbm5lclNlcnZpY2UoMTMwOCk6DQo+PiBkb0JnTWVkaWFTY2Fu
bmVyRmluaXNoZWRXb3JrKCk6IGVuZHMNCj4+DQo+PiAwMS0zMCAwMTozNjoyNC4yNzk6IElORk8v
UlAtTWVkaWFTY2FubmVyU2VydmljZSgxMzIyKTogU0tJUFBJTkcNCj4+IENsb3NpbmcgREIgYXMg
YXBwT3BlbjpmYWxzZSBhbmQgbUlzTWVkaWFTY2FubmluZzp0cnVlYW5kDQo+PiBpc1JlYWxEYXRh
U2Nhbm5pbmc6ZmFsc2UNCj4+DQo+PiAwMS0zMCAwMTozNjoyNC4yNzk6IFZFUkJPU0UvUlAtTWVk
aWFTY2FubmVyU2VydmljZSgxMzIyKToNCj4+IGRvQmdNZWRpYVNjYW5uZXJGaW5pc2hlZFdvcmso
KTogZW5kcw0KPj4NCj4+IDAxLTMwIDAxOjM2OjI1LjY1OTogSU5GTy9BY3Rpdml0eU1hbmFnZXIo
MTE5MSk6IFN0YXJ0aW5nIGFjdGl2aXR5Og0KPj4gSW50ZW50IHsgYWN0PWFuZHJvaWQuaW50ZW50
LmFjdGlvbi5NQUlODQo+PiBjYXQ9W2FuZHJvaWQuaW50ZW50LmNhdGVnb3J5LkxBVU5DSEVSXSBm
bGc9MHgxMDIwMDAwMA0KPj4gY21wPWNvbS5hbmRyb2lkLmNhbWVyYS8uR2FsbGVyeVBpY2tlciB9
DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuMDI5OiBXQVJOL0lJbnB1dENvbm5lY3Rpb25XcmFwcGVy
KDEyNTYpOiBzaG93U3RhdHVzSWNvbg0KPj4gb24gaW5hY3RpdmUgSW5wdXRDb25uZWN0aW9uDQo+
Pg0KPj4gMDEtMzAgMDE6MzY6MjYuMDg5OiBJTkZPL0FjdGl2aXR5TWFuYWdlcigxMTkxKTogRGlz
cGxheWVkIGFjdGl2aXR5DQo+PiBjb20uYW5kcm9pZC5jYW1lcmEvLkdhbGxlcnlQaWNrZXI6IDM5
OSBtcyAodG90YWwgMzk5IG1zKQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjI2LjI1OTogSU5GTy9IZWxp
eE1ldGFEYXRhRHJpdmVyKDExNDEpOiBIZWxpeCBtZXRhIGRhdGENCj4+IGRyaXZlciBjb25zdHJ1
Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjI2LjI1OTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVy
KDExNDEpOiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBjb25zdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAx
OjM2OjI2LjI1OTogREVCVUcvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbV9wRmlsZU5hbWUg
Og0KPj4gL3NkY2FyZC92aWRlby9Db25hbi5ybXZiDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuMjU5
OiBJTkZPL0hlbGl4UGxheWVyKDExNDEpOiBtZWRpYSBwbGF0Zm9ybSBmaW5pYWwNCj4+IHJlbGVh
c2UgY2FuY2VsZWQuDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuNTc5OiBWRVJCT1NFL0hlbGl4TWV0
YURhdGFEcml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgNCj4+ICg4NTYpIGFuZCBoZWlnaHQgKDQ4
MCksIGFuZCBzaXplICg4MjE3NjApDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuNjA5OiBJTkZPL0hl
bGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1ldGEgZGF0YQ0KPj4gZHJpdmVyIGRlc3Ry
dWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjoyNi42MDk6IElORk8vSGVsaXhNZXRhRGF0YURyaXZl
cigxMTQxKTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gZGVzdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAx
OjM2OjI2LjYwOTogSU5GTy9IZWxpeFBsYXllcigxMTQxKTogc2NoZWR1bGUgbWVkaWEgcGxhdGZv
cm0NCj4+IGZpbmlhbCByZWxlYXNlDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuNjA5OiBERUJVRy9I
ZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBbVGltaW5nXQ0KPj4gTWV0YURhdGFEcml2ZXIgTGlm
ZXRpbWU6IDM1MSBtcw0KPj4NCj4+IDAxLTMwIDAxOjM2OjI2LjgwOTogSU5GTy9IZWxpeE1ldGFE
YXRhRHJpdmVyKDExNDEpOiBIZWxpeCBtZXRhIGRhdGENCj4+IGRyaXZlciBjb25zdHJ1Y3Rvcg0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjI2LjgwOTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEp
OiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBjb25zdHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjI2
LjgwOTogREVCVUcvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbV9wRmlsZU5hbWUgOg0KPj4g
L3NkY2FyZC9tb3ZpZXMvVjEwMDMxNl8xMzI4MDAuM2cyDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYu
ODA5OiBJTkZPL0hlbGl4UGxheWVyKDExNDEpOiBtZWRpYSBwbGF0Zm9ybSBmaW5pYWwNCj4+IHJl
bGVhc2UgY2FuY2VsZWQuDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuOTE5OiBWRVJCT1NFL0hlbGl4
TWV0YURhdGFEcml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgNCj4+ICgxNzYpIGFuZCBoZWlnaHQg
KDE0NCksIGFuZCBzaXplICg1MDY4OCkNCj4+DQo+PiAwMS0zMCAwMTozNjoyNi45Mjk6IElORk8v
SGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogSGVsaXggbWV0YSBkYXRhDQo+PiBkcml2ZXIgZGVz
dHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjI2LjkyOTogSU5GTy9IZWxpeE1ldGFEYXRhRHJp
dmVyKDExNDEpOiBtZXRhIGRhdGEgZHJpdmVyDQo+PiBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAg
MDE6MzY6MjYuOTI5OiBJTkZPL0hlbGl4UGxheWVyKDExNDEpOiBzY2hlZHVsZSBtZWRpYSBwbGF0
Zm9ybQ0KPj4gZmluaWFsIHJlbGVhc2UNCj4+DQo+PiAwMS0zMCAwMTozNjoyNi45Mjk6IERFQlVH
L0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IFtUaW1pbmddDQo+PiBNZXRhRGF0YURyaXZlciBM
aWZldGltZTogMTIxIG1zDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuOTk5OiBJTkZPL0hlbGl4TWV0
YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1ldGEgZGF0YQ0KPj4gZHJpdmVyIGNvbnN0cnVjdG9y
DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MjYuOTk5OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0
MSk6IG1ldGEgZGF0YSBkcml2ZXINCj4+IGNvbnN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6
MjYuOTk5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBtX3BGaWxlTmFtZSA6DQo+
PiAvc2RjYXJkL21vdmllcy9jcmFuazItdGxyMWJfbWpwZWdfd3ZnYS5hdmkNCj4+DQo+PiAwMS0z
MCAwMTozNjoyNi45OTk6IElORk8vSGVsaXhQbGF5ZXIoMTE0MSk6IG1lZGlhIHBsYXRmb3JtIGZp
bmlhbA0KPj4gcmVsZWFzZSBjYW5jZWxlZC4NCj4+DQo+PiAwMS0zMCAwMTozNjoyOC4xMzk6IElO
Rk8vQWN0aXZpdHlNYW5hZ2VyKDExOTEpOiBTdGFydGluZyBhY3Rpdml0eToNCj4+IEludGVudCB7
IGFjdD1hbmRyb2lkLmludGVudC5hY3Rpb24uVklFVw0KPj4gZGF0PWNvbnRlbnQ6Ly9tZWRpYS9p
bnRlcm5hbC9pbWFnZXMvbWVkaWENCj4+IGNtcD1jb20uYW5kcm9pZC5jYW1lcmEvLkltYWdlR2Fs
bGVyeSAoaGFzIGV4dHJhcykgfQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjI4LjQ3OTogSU5GTy9BY3Rp
dml0eU1hbmFnZXIoMTE5MSk6IERpc3BsYXllZCBhY3Rpdml0eQ0KPj4gY29tLmFuZHJvaWQuY2Ft
ZXJhLy5JbWFnZUdhbGxlcnk6IDMzOCBtcyAodG90YWwgMzM4IG1zKQ0KPj4NCj4+IDAxLTMwIDAx
OjM2OjM0LjQxOTogVkVSQk9TRS9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBkaXNwbGF5IHdp
ZHRoDQo+PiAoODQ4KSBhbmQgaGVpZ2h0ICg0MDApLCBhbmQgc2l6ZSAoNjc4NDAwKQ0KPj4NCj4+
IDAxLTMwIDAxOjM2OjM0LjQ0OTogSU5GTy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBIZWxp
eCBtZXRhIGRhdGENCj4+IGRyaXZlciBkZXN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQu
NDQ5OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IG1ldGEgZGF0YSBkcml2ZXINCj4+
IGRlc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjozNC40NDk6IElORk8vSGVsaXhQbGF5ZXIo
MTE0MSk6IHNjaGVkdWxlIG1lZGlhIHBsYXRmb3JtDQo+PiBmaW5pYWwgcmVsZWFzZQ0KPj4NCj4+
IDAxLTMwIDAxOjM2OjM0LjQ0OTogREVCVUcvSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogW1Rp
bWluZ10NCj4+IE1ldGFEYXRhRHJpdmVyIExpZmV0aW1lOiA3NDU2IG1zDQo+Pg0KPj4gMDEtMzAg
MDE6MzY6MzQuNTg0OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1ldGEg
ZGF0YQ0KPj4gZHJpdmVyIGNvbnN0cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNTg0OiBJ
TkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IG1ldGEgZGF0YSBkcml2ZXINCj4+IGNvbnN0
cnVjdG9yDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNTg5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJp
dmVyKDExNDEpOiBtX3BGaWxlTmFtZSA6DQo+PiAvc2RjYXJkL21vdmllcy9jcmFuazItdGxyMWJf
bWpwZWdfd3ZnYS5hdmkNCj4+DQo+PiAwMS0zMCAwMTozNjozNC41ODk6IElORk8vSGVsaXhQbGF5
ZXIoMTE0MSk6IG1lZGlhIHBsYXRmb3JtIGZpbmlhbA0KPj4gcmVsZWFzZSBjYW5jZWxlZC4NCj4+
DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiBMZWFrIGZvdW5k
DQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNzA5OiBFUlJPUi9EYXRhYmFzZSgxMjY3KToNCj4+IGph
dmEubGFuZy5JbGxlZ2FsU3RhdGVFeGNlcHRpb246DQo+PiAvZGF0YS9kYXRhL2NvbS5hbmRyb2lk
LnByb3ZpZGVycy5tZWRpYS9kYXRhYmFzZXMvZXh0ZXJuYWwtMWUzYjY2YTUuZGINCj4+IFNRTGl0
ZURhdGFiYXNlIGNyZWF0ZWQgYW5kIG5ldmVyIGNsb3NlZA0KPj4NCj4+IDAxLTMwIDAxOjM2OjM0
LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4gYW5kcm9pZC5kYXRhYmFzZS5z
cWxpdGUuU1FMaXRlRGF0YWJhc2UuPGluaXQ+KFNRTGl0ZURhdGFiYXNlLmphdmE6MTU4MSkNCj4+
DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+
IGFuZHJvaWQuZGF0YWJhc2Uuc3FsaXRlLlNRTGl0ZURhdGFiYXNlLm9wZW5EYXRhYmFzZShTUUxp
dGVEYXRhYmFzZS5qYXZhOjYzOCkNCj4+DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0Rh
dGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGFuZHJvaWQuZGF0YWJhc2Uuc3FsaXRlLlNRTGl0ZURh
dGFiYXNlLm9wZW5PckNyZWF0ZURhdGFiYXNlKFNRTGl0ZURhdGFiYXNlLmphdmE6NjU5KQ0KPj4N
Cj4+IDAxLTMwIDAxOjM2OjM0LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4g
YW5kcm9pZC5kYXRhYmFzZS5zcWxpdGUuU1FMaXRlRGF0YWJhc2Uub3Blbk9yQ3JlYXRlRGF0YWJh
c2UoU1FMaXRlRGF0YWJhc2UuamF2YTo2NTIpDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNzA5OiBF
UlJPUi9EYXRhYmFzZSgxMjY3KTogICAgIGF0DQo+PiBhbmRyb2lkLmFwcC5BcHBsaWNhdGlvbkNv
bnRleHQub3Blbk9yQ3JlYXRlRGF0YWJhc2UoQXBwbGljYXRpb25Db250ZXh0LmphdmE6NDgyKQ0K
Pj4NCj4+IDAxLTMwIDAxOjM2OjM0LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0K
Pj4gYW5kcm9pZC5jb250ZW50LkNvbnRleHRXcmFwcGVyLm9wZW5PckNyZWF0ZURhdGFiYXNlKENv
bnRleHRXcmFwcGVyLmphdmE6MTkzKQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjM0LjcwOTogRVJST1Iv
RGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4gYW5kcm9pZC5kYXRhYmFzZS5zcWxpdGUuU1FMaXRl
T3BlbkhlbHBlci5nZXRXcml0YWJsZURhdGFiYXNlKFNRTGl0ZU9wZW5IZWxwZXIuamF2YTo5OCkN
Cj4+DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQN
Cj4+IGFuZHJvaWQuZGF0YWJhc2Uuc3FsaXRlLlNRTGl0ZU9wZW5IZWxwZXIuZ2V0UmVhZGFibGVE
YXRhYmFzZShTUUxpdGVPcGVuSGVscGVyLmphdmE6MTU4KQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjM0
LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4gY29tLmFuZHJvaWQucHJvdmlk
ZXJzLm1lZGlhLk1lZGlhUHJvdmlkZXIucXVlcnkoTWVkaWFQcm92aWRlci5qYXZhOjg3NCkNCj4+
DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+
IGNvbS5hbmRyb2lkLnByb3ZpZGVycy5tZWRpYS5NZWRpYVByb3ZpZGVyLmF0dGFjaFZvbHVtZShN
ZWRpYVByb3ZpZGVyLmphdmE6MjI0NCkNCj4+DQo+PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9S
L0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGNvbS5hbmRyb2lkLnByb3ZpZGVycy5tZWRpYS5N
ZWRpYVByb3ZpZGVyLmluc2VydEludGVybmFsKE1lZGlhUHJvdmlkZXIuamF2YToxNDIwKQ0KPj4N
Cj4+IDAxLTMwIDAxOjM2OjM0LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4g
Y29tLmFuZHJvaWQucHJvdmlkZXJzLm1lZGlhLk1lZGlhUHJvdmlkZXIuaW5zZXJ0KE1lZGlhUHJv
dmlkZXIuamF2YToxMjAwKQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjM0LjcwOTogRVJST1IvRGF0YWJh
c2UoMTI2Nyk6ICAgICBhdA0KPj4gYW5kcm9pZC5jb250ZW50LkNvbnRlbnRQcm92aWRlciRUcmFu
c3BvcnQuaW5zZXJ0KENvbnRlbnRQcm92aWRlci5qYXZhOjE0MCkNCj4+DQo+PiAwMS0zMCAwMToz
NjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGFuZHJvaWQuY29udGVu
dC5Db250ZW50UmVzb2x2ZXIuaW5zZXJ0KENvbnRlbnRSZXNvbHZlci5qYXZhOjQ3OSkNCj4+DQo+
PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGNv
bS5hbmRyb2lkLnByb3ZpZGVycy5tZWRpYS5NZWRpYVNjYW5uZXJTZXJ2aWNlLm9wZW5EYXRhYmFz
ZShNZWRpYVNjYW5uZXJTZXJ2aWNlLmphdmE6NjEpDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNzA5
OiBFUlJPUi9EYXRhYmFzZSgxMjY3KTogICAgIGF0DQo+PiBjb20uYW5kcm9pZC5wcm92aWRlcnMu
bWVkaWEuTWVkaWFTY2FubmVyU2VydmljZS5zY2FuKE1lZGlhU2Nhbm5lclNlcnZpY2UuamF2YTox
MDgpDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNzA5OiBFUlJPUi9EYXRhYmFzZSgxMjY3KTogICAg
IGF0DQo+PiBjb20uYW5kcm9pZC5wcm92aWRlcnMubWVkaWEuTWVkaWFTY2FubmVyU2VydmljZS5h
Y2Nlc3MkMjAwKE1lZGlhU2Nhbm5lclNlcnZpY2UuamF2YTo0OSkNCj4+DQo+PiAwMS0zMCAwMToz
NjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGNvbS5hbmRyb2lkLnBy
b3ZpZGVycy5tZWRpYS5NZWRpYVNjYW5uZXJTZXJ2aWNlJFNlcnZpY2VIYW5kbGVyLmhhbmRsZU1l
c3NhZ2UoTWVkaWFTY2FubmVyU2VydmljZS5qYXZhOjI4MCkNCj4+DQo+PiAwMS0zMCAwMTozNjoz
NC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGFuZHJvaWQub3MuSGFuZGxl
ci5kaXNwYXRjaE1lc3NhZ2UoSGFuZGxlci5qYXZhOjk5KQ0KPj4NCj4+IDAxLTMwIDAxOjM2OjM0
LjcwOTogRVJST1IvRGF0YWJhc2UoMTI2Nyk6ICAgICBhdA0KPj4gYW5kcm9pZC5vcy5Mb29wZXIu
bG9vcChMb29wZXIuamF2YToxMjMpDQo+Pg0KPj4gMDEtMzAgMDE6MzY6MzQuNzA5OiBFUlJPUi9E
YXRhYmFzZSgxMjY3KTogICAgIGF0DQo+PiBjb20uYW5kcm9pZC5wcm92aWRlcnMubWVkaWEuTWVk
aWFTY2FubmVyU2VydmljZS5ydW4oTWVkaWFTY2FubmVyU2VydmljZS5qYXZhOjE4MCkNCj4+DQo+
PiAwMS0zMCAwMTozNjozNC43MDk6IEVSUk9SL0RhdGFiYXNlKDEyNjcpOiAgICAgYXQNCj4+IGph
dmEubGFuZy5UaHJlYWQucnVuKFRocmVhZC5qYXZhOjEwNjApDQo+Pg0KPj4gMDEtMzAgMDE6MzY6
NDIuMDQ5OiBWRVJCT1NFL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IGRpc3BsYXkgd2lkdGgN
Cj4+ICg4NDgpIGFuZCBoZWlnaHQgKDQwMCksIGFuZCBzaXplICg2Nzg0MDApDQo+Pg0KPj4gMDEt
MzAgMDE6MzY6NDIuMDc5OiBJTkZPL0hlbGl4TWV0YURhdGFEcml2ZXIoMTE0MSk6IEhlbGl4IG1l
dGEgZGF0YQ0KPj4gZHJpdmVyIGRlc3RydWN0b3INCj4+DQo+PiAwMS0zMCAwMTozNjo0Mi4wNzk6
IElORk8vSGVsaXhNZXRhRGF0YURyaXZlcigxMTQxKTogbWV0YSBkYXRhIGRyaXZlcg0KPj4gZGVz
dHJ1Y3Rvcg0KPj4NCj4+IDAxLTMwIDAxOjM2OjQyLjA3OTogSU5GTy9IZWxpeFBsYXllcigxMTQx
KTogc2NoZWR1bGUgbWVkaWEgcGxhdGZvcm0NCj4+IGZpbmlhbCByZWxlYXNlDQo+Pg0KPj4gMDEt
MzAgMDE6MzY6NDIuMDc5OiBERUJVRy9IZWxpeE1ldGFEYXRhRHJpdmVyKDExNDEpOiBbVGltaW5n
XQ0KPj4gTWV0YURhdGFEcml2ZXIgTGlmZXRpbWU6IDc0OTQgbXMNCj4+DQo+PiAwMS0zMCAwMToz
NzowMS4xNjk6IERFQlVHL1JQLU1lZGlhU2Nhbm5lclNlcnZpY2UoMTMwOCk6IFNjYW5uaW5nIFNE
IENhcmQNCj4+DQo+PiAwMS0zMCAwMTozNzowMS4xNjk6IERFQlVHL1JQLU1lZGlhU3RvcmUoMTMw
OCk6IG10aW1lIGZvcjoNCj4+IC9zZGNhcmQvLmhlbGl4LnRodW1ibmFpbHMvPTEyNjQ4MTM2NTQw
MDANCj4+DQo+PiAwMS0zMCAwMTozNzowMS4xNzk6IERFQlVHL1JQLU1lZGlhU3RvcmUoMTMwOCk6
IFNjYW5TRENhcmQgc3RhcnQNCj4+DQo+PiAwMS0zMCAwMTozNzowMS4zNzk6IERFQlVHL1JQLU1l
ZGlhU3RvcmUoMTMwOCk6IFNjYW5TRENhcmQgZW5kDQo+Pg0KPj4gMDEtMzAgMDE6Mzc6MDEuMzc5
OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzA4KTogY2hlY2tWaWRlb01pbmlUaHVtYmFpbHMoKQ0K
Pj4NCj4+IDAxLTMwIDAxOjM3OjAxLjM5OTogVkVSQk9TRS9SUC1EYXRhU3RvcmUoMTMwOCk6DQo+
PiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZpZGVvIHVyaToNCj4+IDovc2RjYXJkLy5oZWxp
eC50aHVtYm5haWxzL3ZpZGVvdGh1bWIvMQ0KPj4NCj4+IDAxLTMwIDAxOjM3OjAxLjM5OTogVkVS
Qk9TRS9SUC1EYXRhU3RvcmUoMTMwOCk6DQo+PiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZp
ZGVvIHVyaToNCj4+IDovc2RjYXJkLy5oZWxpeC50aHVtYm5haWxzL3ZpZGVvdGh1bWIvMg0KPj4N
Cj4+IDAxLTMwIDAxOjM3OjAxLjM5OTogVkVSQk9TRS9SUC1EYXRhU3RvcmUoMTMwOCk6DQo+PiBj
aGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZpZGVvIHVyaToNCj4+IDovc2RjYXJkLy5oZWxpeC50
aHVtYm5haWxzL3ZpZGVvdGh1bWIvMw0KPj4NCj4+IDAxLTMwIDAxOjM3OjAxLjM5OTogREVCVUcv
UlAtRGF0YVN0b3JlKDEzMDgpOiB2ZXJpZnlWaWRlb1RodW1ibmFpbHMgc3RhcnQNCj4+DQo+PiAw
MS0zMCAwMTozNzowMS42MDI6IERFQlVHL1JQLU1lZGlhU2Nhbm5lclNlcnZpY2UoMTMyMik6IFNj
YW5uaW5nIFNEIENhcmQNCj4+DQo+PiAwMS0zMCAwMTozNzowMS42MDI6IERFQlVHL1JQLU1lZGlh
U3RvcmUoMTMyMik6IG10aW1lIGZvcjoNCj4+IC9zZGNhcmQvLmhlbGl4LnRodW1ibmFpbHMvPTEy
NjQ4MTM2NTQwMDANCj4+DQo+PiAwMS0zMCAwMTozNzowMS42MDI6IERFQlVHL1JQLU1lZGlhU3Rv
cmUoMTMyMik6IFNjYW5TRENhcmQgc3RhcnQNCj4+DQo+PiAwMS0zMCAwMTozNzowMS42ODk6IERF
QlVHL1JQLU1lZGlhU3RvcmUoMTMyMik6IFNjYW5TRENhcmQgZW5kDQo+Pg0KPj4gMDEtMzAgMDE6
Mzc6MDEuNjg5OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzIyKTogY2hlY2tWaWRlb01pbmlUaHVt
YmFpbHMoKQ0KPj4NCj4+IDAxLTMwIDAxOjM3OjAxLjcwOTogVkVSQk9TRS9SUC1EYXRhU3RvcmUo
MTMyMik6DQo+PiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZpZGVvIHVyaToNCj4+IDovc2Rj
YXJkLy5oZWxpeC50aHVtYm5haWxzL3ZpZGVvdGh1bWIvMQ0KPj4NCj4+IDAxLTMwIDAxOjM3OjAx
LjcwOTogVkVSQk9TRS9SUC1EYXRhU3RvcmUoMTMyMik6DQo+PiBjaGVja1ZpZGVvTWluaVRodW1i
YWlscygpOlZpZGVvIHVyaToNCj4+IDovc2RjYXJkLy5oZWxpeC50aHVtYm5haWxzL3ZpZGVvdGh1
bWIvMg0KPj4NCj4+IDAxLTMwIDAxOjM3OjAxLjcwOTogVkVSQk9TRS9SUC1EYXRhU3RvcmUoMTMy
Mik6DQo+PiBjaGVja1ZpZGVvTWluaVRodW1iYWlscygpOlZpZGVvIHVyaToNCj4+IDovc2RjYXJk
Ly5oZWxpeC50aHVtYm5haWxzL3ZpZGVvdGh1bWIvMw0KPj4NCj4+IDAxLTMwIDAxOjM3OjAxLjcw
OTogREVCVUcvUlAtRGF0YVN0b3JlKDEzMjIpOiB2ZXJpZnlWaWRlb1RodW1ibmFpbHMgc3RhcnQN
Cj4+DQo+PiAwMS0zMCAwMTozNzowMi45Mjk6IERFQlVHL1JQLURhdGFTdG9yZSgxMzA4KTogdmVy
aWZ5VmlkZW9UaHVtYm5haWxzDQo+PiBjb21wbGV0ZQ0KPj4NCj4+IDAxLTMwIDAxOjM3OjAyLjky
OTogVkVSQk9TRS9SUC1NZWRpYVNjYW5uZXJTZXJ2aWNlKDEzMDgpOiBDbG9zaW5nIERCDQo+PiBh
cyBhcHBPcGVuOmZhbHNlIGFuZCBtSXNNZWRpYVNjYW5uaW5nOmZhbHNlIGFuZCBpc1JlYWxEYXRh
U2Nhbm5pbmc6ZmFsc2UNCj4+DQo+PiAwMS0zMCAwMTozNzowMi45Mjk6IFZFUkJPU0UvUlAtRGF0
YVN0b3JlKDEzMDgpOiBjbGVhblVwKCkNCj4+DQo+PiAwMS0zMCAwMTozNzowMi45Mjk6IERFQlVH
L1JQLURhdGFTdG9yZSgxMzA4KTogcmVzZXRBbGxTY2FubmVyRmxhZ3MNCj4+DQo+PiAwMS0zMCAw
MTozNzowMi45Mzk6IFZFUkJPU0UvUlAtRGF0YVN0b3JlKDEzMDgpOiBjbGVhblVwKCk6IGZpbmlz
aGVkDQo+PiBub3JtYWxseQ0KPj4NCj4+IDAxLTMwIDAxOjM3OjAzLjIzMTogREVCVUcvUlAtRGF0
YVN0b3JlKDEzMjIpOiB2ZXJpZnlWaWRlb1RodW1ibmFpbHMNCj4+IGNvbXBsZXRlDQo+Pg0KPj4g
MDEtMzAgMDE6Mzc6MDMuMjMxOiBWRVJCT1NFL1JQLU1lZGlhU2Nhbm5lclNlcnZpY2UoMTMyMik6
IENsb3NpbmcgREINCj4+IGFzIGFwcE9wZW46ZmFsc2UgYW5kIG1Jc01lZGlhU2Nhbm5pbmc6ZmFs
c2VhbmQgaXNSZWFsRGF0YVNjYW5uaW5nOmZhbHNlDQo+Pg0KPj4gMDEtMzAgMDE6Mzc6MDMuMjMx
OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzIyKTogY2xlYW5VcCgpDQo+Pg0KPj4gMDEtMzAgMDE6
Mzc6MDMuMjMxOiBERUJVRy9SUC1EYXRhU3RvcmUoMTMyMik6IHJlc2V0QWxsU2Nhbm5lckZsYWdz
DQo+Pg0KPj4gMDEtMzAgMDE6Mzc6MDMuMzA5OiBWRVJCT1NFL1JQLURhdGFTdG9yZSgxMzIyKTog
Y2xlYW5VcCgpOiBmaW5pc2hlZA0KPj4gbm9ybWFsbHkNCj4+DQo+PiAwMS0zMCAwMTozNzowNi4z
MDk6IElORk8vSGVsaXhQbGF5ZXIoMTE0MSk6IEhlbGl4IE1lZGlhIHBsYXRmb3JtDQo+PiBmaW5p
YWwgcmVsZWFzZTogZG9uZS4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gbW9yZSBkZXRhaWxzIHBs
ZWFzZSBjaGVjayB0aGUgYXR0YWNoZWQgbG9nIGZpbGUuDQo+Pg0KPj4NCj4+DQo+PiBSZWdhcmRz
LA0KPj4gTGlRaWFuZyhKb2UpDQo+PiBSZWFsTmV0d29ya3MsIENoaW5hDQo+PiBUOiArODYoMTAp
NTk1NDI3OTUNCj4+DQo+Pg0KPj4NCj4+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+IERhdGF0eXBlLWRldiBtYWlsaW5nIGxpc3QNCj4g
RGF0YXR5cGUtZGV2QGhlbGl4Y29tbXVuaXR5Lm9yZw0KPiBodHRwOi8vbGlzdHMuaGVsaXhjb21t
dW5pdHkub3JnL21haWxtYW4vbGlzdGluZm8vZGF0YXR5cGUtZGV2DQo+DQo+DQoNCg==
From Alvaro.Vaquero at nokia.com Fri Mar 19 08:13:06 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Fri Mar 19 15:21:12 2010
Subject: [datatype-dev] RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.5
diff -w -u -b -r1.5 mkv_file_format.cpp
--- fileformat/mkv_file_format.cpp 19 Mar 2010 00:22:18 -0000 1.5
+++ fileformat/mkv_file_format.cpp 19 Mar 2010 16:12:30 -0000
@@ -655,6 +655,7 @@
pHdr->SetPropertyULONG32("Duration", m_pMKVHandle->DurationMS());
// set creation date/time in seconds measured relatively to POSIX time base 01/01/1970 UTC
pHdr->SetPropertyULONG32("CreationTime", m_pMKVHandle->EpochDate());
+ pHdr->SetPropertyULONG32("NonSeekable", m_pMKVHandle->NonSeekable());
retVal = SetTags(pHdr);
Index: matroskalib/MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.3
diff -w -u -b -r1.3 MatroskaExports.cpp
--- matroskalib/MatroskaExports.cpp 19 Mar 2010 00:21:33 -0000 1.3
+++ matroskalib/MatroskaExports.cpp 19 Mar 2010 16:12:32 -0000
@@ -80,6 +80,16 @@
return -1;
}
+HXBOOL MatroskaExports::NonSeekable()
+{
+ if(m_pSeg)
+ {
+ return !m_pSeg->m_bCues;
+ }
+
+ return -1;
+}
+
HX_RESULT MatroskaExports::Seek( double seekTime , UINT32& strNum, IHXBuffer*& pBuffer, UINT64& uTimeCode, HXBOOL& bKey)
{
if(m_pSeg)
Index: matroskalib/MatroskaExports.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.h,v
retrieving revision 1.3
diff -w -u -b -r1.3 MatroskaExports.h
--- matroskalib/MatroskaExports.h 19 Mar 2010 00:21:33 -0000 1.3
+++ matroskalib/MatroskaExports.h 19 Mar 2010 16:12:32 -0000
@@ -23,6 +23,7 @@
int64 DurationMS();
int32 EpochDate();
int NumTracks();
+ HXBOOL NonSeekable();
char* TagAuthor();
char* TagTitle();
From anuj.dhamija at nokia.com Fri Mar 19 08:30:57 2010
From: anuj.dhamija at nokia.com (anuj.dhamija@nokia.com)
Date: Fri Mar 19 15:39:01 2010
Subject: [datatype-dev] RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
In-Reply-To:
References:
Message-ID:
Hi Alvaro,
MatroskaExports::NonSeekable() returns -1 by default which doesn't seem right for HXBOOL function. We should return true or false there.
regds
AD
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Vaquero Alvaro (Nokia-D/Dallas)
Sent: Friday, March 19, 2010 11:13 AM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: alvaro.vaquero@nokia.com
Reviewed by:
Date: 03/19/2010
Project: SymbianMmf_wm
ErrorId: EHLI-83ME7Q
Synopsis: MKV ac3 file cannot replay after seeking fast backward
Overview:
The file is missing cue data which is required for seeking in matroska files. The file is therefore not seekable. This CR enables Matroska to notify UI that the file is not seekable and the user experience is correct.
Files Added: None.
Files Modified:
/datatype/mkv/fileformat/mkv_file_format.cpp
/datatype/mkv/libmatroska/MatroskaExports.cpp
/datatype/mkv/libmatroska/MatroskaExports.h
Image Size and Heap Use impact: minor
Module Release testing (STIF) : Passed
Test case(s) Added : No.
Memory leak check performed : Yes. No new leaks introduced
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Cays210, Brizo420, HEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100319/25fb0b62/attachment-0001.html
From gwright at real.com Fri Mar 19 09:38:57 2010
From: gwright at real.com (Gregory Wright)
Date: Fri Mar 19 16:46:51 2010
Subject: [datatype-dev] CR: EGRS-83FRVP Long duration MKV clips take
20-25 seconds to start playing
In-Reply-To:
References:
Message-ID: <13DAB070-6051-48F3-A316-68289753B33A@real.com>
Don't know much about Matroska, but the diff looks good to me.
--greg.
On Mar 17, 2010, at 12:28 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: alvaro.vaquero@nokia.com
>
> Reviewed by:
>
> Date: 03/17/2010
>
> Project: SymbianMmf_wm
>
> ErrorId: EGRS-83FRVP
>
> Synopsis: Long duration MKV clips take 20-25 seconds to start playing
>
> Overview:
> Due to the nature of Mkv container the fileformat currently parses the complete file looking for the different elements. It seems skipping through the clusters is not very efficient and it?s taking the most time. In this CR the SeekHead element is used to only parse one cluster and skip directly to the different locations of interest in the file. However, this optimization should have no effect if the seekhead is not present in the file. I?ve also cleaned up a few comments from the ebml files.
>
> From the two tested clips this are the results:
>
> File A:
> Pre Optimization Parsing Headers Time: 136.885
> Post Optimization Parsing Headers Time: 1.333
>
> File B:
> Pre Optimization Parsing Headers Time: 31.140
> Post Optimization Parsing Headers Time: 4.328
>
> Files Added: None.
>
> Files Modified:
> /datatype/mkv/libmatroska/Matroska.cpp
> /datatype/mkv/libmatroska/libebml/ebml/EbmlCrc32.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlDummy.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlElement.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlHead.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlSubHead.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlVoid.h
> /datatype/mkv/libmatroska/libebml/src/EbmlElement.cpp
> /datatype/mkv/libmatroska/libebml/src/EbmlMaster.cpp
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Cays210, Brizo420, HEAD
>
>
>
>
From Alvaro.Vaquero at nokia.com Fri Mar 19 11:33:41 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Fri Mar 19 18:41:20 2010
Subject: [datatype-dev] CR: EGRS-83FRVP Long duration MKV clips take
20-25 seconds to start playing
In-Reply-To: <13DAB070-6051-48F3-A316-68289753B33A@real.com>
References:
<13DAB070-6051-48F3-A316-68289753B33A@real.com>
Message-ID:
Thanks Greg. Checked in to Caye210, Brizo420 and HEAD.
BR,
/Alvaro
-----Original Message-----
From: ext Gregory Wright [mailto:gwright@real.com]
Sent: Friday, March 19, 2010 12:39 PM
To: Vaquero Alvaro (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: EGRS-83FRVP Long duration MKV clips take 20-25 seconds to start playing
Don't know much about Matroska, but the diff looks good to me.
--greg.
On Mar 17, 2010, at 12:28 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: alvaro.vaquero@nokia.com
>
> Reviewed by:
>
> Date: 03/17/2010
>
> Project: SymbianMmf_wm
>
> ErrorId: EGRS-83FRVP
>
> Synopsis: Long duration MKV clips take 20-25 seconds to start playing
>
> Overview:
> Due to the nature of Mkv container the fileformat currently parses the complete file looking for the different elements. It seems skipping through the clusters is not very efficient and it's taking the most time. In this CR the SeekHead element is used to only parse one cluster and skip directly to the different locations of interest in the file. However, this optimization should have no effect if the seekhead is not present in the file. I've also cleaned up a few comments from the ebml files.
>
> From the two tested clips this are the results:
>
> File A:
> Pre Optimization Parsing Headers Time: 136.885
> Post Optimization Parsing Headers Time: 1.333
>
> File B:
> Pre Optimization Parsing Headers Time: 31.140
> Post Optimization Parsing Headers Time: 4.328
>
> Files Added: None.
>
> Files Modified:
> /datatype/mkv/libmatroska/Matroska.cpp
> /datatype/mkv/libmatroska/libebml/ebml/EbmlCrc32.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlDummy.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlElement.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlHead.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlSubHead.h
> /datatype/mkv/libmatroska/libebml/ebml/EbmlVoid.h
> /datatype/mkv/libmatroska/libebml/src/EbmlElement.cpp
> /datatype/mkv/libmatroska/libebml/src/EbmlMaster.cpp
>
> Image Size and Heap Use impact: minor
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes. No new leaks introduced
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Cays210, Brizo420, HEAD
>
>
>
>
From Alvaro.Vaquero at nokia.com Mon Mar 22 12:15:27 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Mon Mar 22 19:22:23 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.5
diff -w -u -b -r1.5 mkv_file_format.cpp
--- fileformat/mkv_file_format.cpp 19 Mar 2010 00:22:18 -0000 1.5
+++ fileformat/mkv_file_format.cpp 19 Mar 2010 16:12:30 -0000
@@ -655,6 +655,7 @@
pHdr->SetPropertyULONG32("Duration", m_pMKVHandle->DurationMS());
// set creation date/time in seconds measured relatively to POSIX time base 01/01/1970 UTC
pHdr->SetPropertyULONG32("CreationTime", m_pMKVHandle->EpochDate());
+ pHdr->SetPropertyULONG32("NonSeekable", m_pMKVHandle->NonSeekable());
retVal = SetTags(pHdr);
Index: matroskalib/MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.3
diff -w -u -b -r1.3 MatroskaExports.cpp
--- matroskalib/MatroskaExports.cpp 19 Mar 2010 00:21:33 -0000 1.3
+++ matroskalib/MatroskaExports.cpp 19 Mar 2010 16:12:32 -0000
@@ -80,6 +80,16 @@
return -1;
}
+HXBOOL MatroskaExports::NonSeekable()
+{
+ if(m_pSeg)
+ {
+ return !m_pSeg->m_bCues;
+ }
+
+ return -1;
+}
+
HX_RESULT MatroskaExports::Seek( double seekTime , UINT32& strNum, IHXBuffer*& pBuffer, UINT64& uTimeCode, HXBOOL& bKey)
{
if(m_pSeg)
Index: matroskalib/MatroskaExports.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.h,v
retrieving revision 1.3
diff -w -u -b -r1.3 MatroskaExports.h
--- matroskalib/MatroskaExports.h 19 Mar 2010 00:21:33 -0000 1.3
+++ matroskalib/MatroskaExports.h 19 Mar 2010 16:12:32 -0000
@@ -23,6 +23,7 @@
int64 DurationMS();
int32 EpochDate();
int NumTracks();
+ HXBOOL NonSeekable();
char* TagAuthor();
char* TagTitle();
From rajesh.rathinasamy at nokia.com Mon Mar 22 13:03:23 2010
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Mar 22 20:11:49 2010
Subject: [datatype-dev] CR: Optimization of number of calls to devSound for
SamplesPlayed count
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.1.2.20
diff -w -u -b -r1.1.2.20 mdfauddevice.cpp
--- mdfauddevice.cpp 2 Mar 2010 00:27:08 -0000 1.1.2.20
+++ mdfauddevice.cpp 22 Mar 2010 18:37:48 -0000
@@ -56,6 +56,8 @@
#define DEFAULT_POWER_SAVE_HWM_MS 6000 //values are set in ms
#define DEFAULT_POWER_SAVE_LWM_MS 2000 //values are set in ms
+// Offset is added to the HWM when wakeupinterval is calculated
+#define POWER_SAVE_HWM_OFFSET_MS 500
static UINT32 Scale(UINT32 v, UINT32 f0, UINT32 f1, UINT32 t0, UINT32 t1);
@@ -126,6 +128,8 @@
m_nBytesPCMToPlay(0),
m_playing(FALSE),
m_ulAudioTimeOffset(0),
+ m_ulCurrPlayTime(0),
+ m_bDisableOnTimeSyncTimer(FALSE),
m_pAudioFormat(pAudioFormat),
m_pErrorMessage(NULL),
m_CurrentVolume(MDFDEVICE_INVALID_VOLUME),
@@ -385,8 +389,8 @@
if(m_pDeviceResponse)
{
ULONG32 ulAudioTime = 0;
- GetCurrentAudioTime(ulAudioTime);
- m_pDeviceResponse->OnTimeSync(ulAudioTime);
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ m_pDeviceResponse->OnTimeSync(m_ulCurrPlayTime);
}
//Set timer for next OnTimeSync callback
@@ -579,8 +583,8 @@
if(m_pDeviceResponse)
{
ULONG32 ulAudioTime = 0;
- GetCurrentAudioTime(ulAudioTime);
- m_pDeviceResponse->OnTimeSync(ulAudioTime);
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ m_pDeviceResponse->OnTimeSync(m_ulCurrPlayTime);
}
@@ -624,7 +628,6 @@
m_readyList.AddTail(pAudioData);
#if defined HELIX_FEATURE_POWER_SAVE_MODE
m_ulLastAudioWrite = pAudioData->m_ulAudioTime-m_ulAudioTimeOffset;
-
m_pDevSound->SetLastRecvdEncodedData(m_ulLastAudioWrite);
#endif /*HELIX_FEATURE_POWER_SAVE_MODE*/
@@ -730,6 +733,7 @@
//reset SecureOutput settings
m_bSecureOutputChanged = FALSE;
+ m_ulCurrPlayTime = 0;
// stop device.
if (m_pDevSound)
{
@@ -798,7 +802,19 @@
// HXLOGL2(HXLOG_MDFA,"mdfdeV:gettime < t=%d", ulCurrentTime);
HX_RESULT hxr = HXR_OK;
- hxr = m_pDevSound->GetCurrentPlayTime(ulCurrentTime);
+
+#ifdef HELIX_FEATURE_POWER_SAVE_MODE
+ // If scheduler is not running, the playback time is not current.
+ // Update the current playback time
+ if(m_bIsInPowerSave && m_pScheduler3->IsPaused())
+ {
+ hxr = m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ }
+#endif
+
+ // Return the last updated value
+ ulCurrentTime = m_ulCurrPlayTime;
+
#if defined(HELIX_FEATURE_DRM_SECURE_OUTPUT)
if(m_bSecureOutputChanged)
{
@@ -882,6 +898,7 @@
HXLOGL4(HXLOG_MDFA,"mdfdeV:setStartT <> %d", ulStartTime);
m_ulAudioTimeOffset = ulStartTime;
+ m_pDevSound->SetAudioTimeOffset(m_ulAudioTimeOffset);
}
void CHXMDFAudioDevice::SetStreamFinished(HXBOOL bEndOfStream)
@@ -924,7 +941,7 @@
{
HXLOGL4(HXLOG_MDFA,"mdfdeV:dosettimer <");
- if( !IsActive())
+ if( (!IsActive()) && (!m_bDisableOnTimeSyncTimer))
{
//HXLOGL4(HXLOG_MDFA, "mdfdeV:dosettimer .. set timer here. %d", iStatus.Int());
m_iTimer.After(iStatus, TIMESYNC_CALLBACK_INTERVAL_MS * 1000);
@@ -1107,12 +1124,8 @@
HX_RESULT retVal = HXR_OK;
if(m_bIsInPowerSave)
{
- if(m_pScheduler3->IsPaused())
- {
HXLOGL3( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::EndPowerSave calling ResumeScheduler ", this);
- retVal = m_pScheduler3->ResumeScheduler();
- }
-
+ LowWaterMark();
m_pDevSound->SetPowerSaveConfig(NULL, m_ulWakeUpInterval, m_ulLowWaterMark); //as such LowWaterMArk won't be called
m_bIsInPowerSave = FALSE;
@@ -1142,6 +1155,8 @@
CHXMDFAudioDevice::GetWakeUpInterval(UINT32& ulWakeUpInterval )
{
ulWakeUpInterval = m_ulWakeUpInterval;
+ // Adding an offset, so that the source does not stop sending data based on old playback time.
+ ulWakeUpInterval += POWER_SAVE_HWM_OFFSET_MS;
HXLOGL2( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::GetWakeUpInterval m_ulWakeUpInterval=%lu ", this, m_ulWakeUpInterval);
return HXR_OK;
@@ -1178,6 +1193,8 @@
m_pScheduler3->PauseScheduler();
}
+ m_bDisableOnTimeSyncTimer = TRUE;
+
// Cancel the timer used for ontimesync reporting
if (IsActive())
{
@@ -1207,8 +1224,10 @@
}
//set timer for OntimeSync or unpause timer for ontimesync
+ m_bDisableOnTimeSyncTimer = FALSE;
if( !IsActive())
{
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
HXLOGL3( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::LowWaterMark calling SetActive ", this);
DoSetTimer();
}
Index: mdfauddevice.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.h,v
retrieving revision 1.1.2.9
diff -w -u -b -r1.1.2.9 mdfauddevice.h
--- mdfauddevice.h 2 Mar 2010 00:27:24 -0000 1.1.2.9
+++ mdfauddevice.h 22 Mar 2010 18:37:48 -0000
@@ -215,6 +215,8 @@
//Timing
UINT32 m_ulAudioTimeOffset; //rendering time
+ UINT32 m_ulCurrPlayTime;
+ HXBOOL m_bDisableOnTimeSyncTimer;
// buffered frames
CHXSimpleList m_bufferList; //frames received from decoder
Index: mdfdevsound.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfdevsound.cpp,v
retrieving revision 1.1.2.31
diff -w -u -b -r1.1.2.31 mdfdevsound.cpp
--- mdfdevsound.cpp 2 Mar 2010 00:27:40 -0000 1.1.2.31
+++ mdfdevsound.cpp 22 Mar 2010 18:37:48 -0000
@@ -153,8 +153,11 @@
#endif
, m_ulHighWaterMark(0)
, m_ulLowWaterMark(0)
- , m_ulLastAudioWrite(0)
+ , m_ulLastEncodedWriteTime(0)
+ , m_ulLastDevWriteTime(0)
+ , m_ulAudioTimeOffset(0)
, m_pPowSaveAudDevObserver(NULL)
+ ,m_bDetectedHWM(FALSE)
{
HX_ASSERT(pFrameList);
HX_ASSERT(pFormat);
@@ -339,12 +342,24 @@
m_ulDevTime = 0; //ByMsPerFrame
m_ulFramesPlayedLastRound = 0; //ByMsPerFrame
m_ulTotalPCMBytesPlayed = 0; //BySampleRate
+
+ //
+ // m_ulSamplesPlayedOffset - Samplesplayed value before PauseAndFlush
+ // Older version of devsound does not reset the samples played counter
+ // during PauseAndFlush. Hence we cache this value and subtract it from
+ // the new value
+ //
m_ulSamplesPlayedOffset = GetValidSamplesPlayed(); //BySamplesPlayed
//samples played before taken and samples written reset to zero
m_ulSamplesPlayedBeforeTaken = 0;
m_ulSamplesWritten = 0;
+ m_ulLastDevWriteTime = 0;
+ m_ulLastEncodedWriteTime = 0;
+ m_ulAudioTimeOffset = 0;
+ m_bDetectedHWM = FALSE;
+
HXLOGL2(HXLOG_MDFA, "---devsnd:reset .. before flush %lu", (UINT32)m_ulSamplesPlayedOffset);
//
@@ -700,6 +715,8 @@
{
m_devStatus = DevPlayInitializing;
#ifdef S60_HX_CONVERGED_DEVSOUND
+ // New version ( also called Converged) devsound,
+ // resets the samples played during PauseAndFlush
m_ulSamplesPlayedOffset = 0;
m_ulLastValidSamplesPlayed = 0;
#endif
@@ -935,7 +952,7 @@
else
{
HXMDFAudioData* pAudioData = (HXMDFAudioData*)m_pDataList->GetHead();
- UINT32 ulDataTime = pAudioData->m_ulAudioTime;
+ m_ulLastDevWriteTime = pAudioData->m_ulAudioTime - m_ulAudioTimeOffset;
HX_RESULT retErr = HXR_OK;
if (pAudioData->m_bMissing || pAudioData->m_bConcealed)
@@ -1146,25 +1163,49 @@
//
void CMDFDevSound::SetLastRecvdEncodedData(const UINT32& ulLastAudioWrite)
{
- m_ulLastAudioWrite = ulLastAudioWrite;
-
+ m_ulLastEncodedWriteTime = ulLastAudioWrite;
+ CheckForHWM();
HXLOGL4(HXLOG_CORE,"mdfdev:Write .. Obs:%p last buf time:%lu", m_pPowSaveAudDevObserver, ulLastAudioWrite);
+}
+//
+// CMDFDevSound::CheckForHWM
+// Checks if Q has reached high water mark
+// and report to the observer
+//
+void CMDFDevSound::CheckForHWM()
+{
// Check if we have enough data to report
// high water mark
+
+ // We are not checking for m_bDetectedHWM as this call
+ // should not happen when it is TRUE
+ //
if(m_pPowSaveAudDevObserver != NULL)
{
UINT32 ulTimeLeft = 0;
- GetTotalUnPlayedDataInMs(ulTimeLeft);
+ UINT32 ulTimeInDev = 0;
+
+ // First caluclate the data in Q
+ ulTimeLeft = m_ulLastEncodedWriteTime - m_ulLastDevWriteTime;
+
+ // We use the last updated samples played
+ // Inaccuracy could be upto 30msec as it is updated from during
+ // the ontimesync reporting
+ ulTimeInDev = (m_ulLastValidSamplesPlayed - m_ulSamplesPlayedOffset) * 1000 / m_pAudioFormat->m_ulSamplesPerSec;
+ ulTimeInDev = m_ulLastDevWriteTime - ulTimeInDev;
- HXLOGL4(HXLOG_CORE,"mdfdev:Write .. unplayed:%lu last buf time:%lu",ulTimeLeft, ulLastAudioWrite);
+ ulTimeLeft += ulTimeInDev;
+
+ HXLOGL4(HXLOG_MDFA,"mdfdev:CheckForHWM .. DataInQ:%lu m_ulLastDevWriteTime:%lu",ulTimeLeft, m_ulLastDevWriteTime);
if(ulTimeLeft > m_ulHighWaterMark)
{
m_pPowSaveAudDevObserver->HighWaterMark();
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForHWM .. m_bDetectedHWM=%d", m_bDetectedHWM);
+ m_bDetectedHWM = TRUE;
}
} // End of if(m_pPowSaveAudDevObserver != NULL)
-
}
//
@@ -1174,15 +1215,28 @@
//
void CMDFDevSound::CheckForLWM()
{
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. m_bDetectedHWM=%d", m_bDetectedHWM);
+ if( (m_pPowSaveAudDevObserver != NULL) && (m_bDetectedHWM) )
+ {
+ UINT32 ulDataInQ = m_ulLastEncodedWriteTime - m_ulLastDevWriteTime;
+
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. ulDataInQ=%lu", ulDataInQ);
+ // We first check, if data in Q is nearing LWM.
+ // This will reduce the number of samplesplayed calculation
+ if(ulDataInQ < m_ulLowWaterMark)
+ {
UINT32 ulTotalUnplayedDataInMs = 0;
+ // Calculate accurate unplayed samples time
GetTotalUnPlayedDataInMs(ulTotalUnplayedDataInMs);
HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. Pending=%lu Obs:%p", ulTotalUnplayedDataInMs, m_pPowSaveAudDevObserver);
-
- if(m_pPowSaveAudDevObserver
- && ulTotalUnplayedDataInMs <= m_ulLowWaterMark)
+ if(ulTotalUnplayedDataInMs <= m_ulLowWaterMark)
{
m_pPowSaveAudDevObserver->LowWaterMark();
+ m_bDetectedHWM = FALSE;
}
+ } // End of if(ulDataInQ < m_ulLowWaterMark)
+
+ } // End of if( (m_pPowSaveAudDevObserver != NULL) && (!m_bDetectedHWM) )
}
//
@@ -1192,9 +1246,9 @@
//
void CMDFDevSound::GetTotalUnPlayedDataInMs( UINT32& ulUnPlayedData)
{
- UINT32 ulCurrTime = 0;
- GetCurrentPlayTime(ulCurrTime);
- ulUnPlayedData = m_ulLastAudioWrite - ulCurrTime;
+ UINT32 ulPlayTime = 0;
+ GetCurrentPlayTime(ulPlayTime);
+ ulUnPlayedData = m_ulLastEncodedWriteTime - ulPlayTime;
}
Index: mdfdevsound.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfdevsound.h,v
retrieving revision 1.1.2.16
diff -w -u -b -r1.1.2.16 mdfdevsound.h
--- mdfdevsound.h 2 Mar 2010 00:27:51 -0000 1.1.2.16
+++ mdfdevsound.h 22 Mar 2010 18:37:48 -0000
@@ -156,8 +156,10 @@
//for power save
void SetPowerSaveConfig(CHXPowerSaveAudDeviceObserver* pPowSaveAudDevObserver, const UINT32& ulHighWaterMark, const UINT32& ulLowWaterMark);
void CheckForLWM();
+ void CheckForHWM();
void GetTotalUnPlayedDataInMs( UINT32& ulUnPlayedData);
void SetLastRecvdEncodedData(const UINT32& ulLastAudioWrite);
+ void SetAudioTimeOffset(UINT32 ulAudioTimeOffset) {m_ulAudioTimeOffset = ulAudioTimeOffset;}
private:
@@ -228,7 +230,10 @@
UINT32 m_ulHighWaterMark;
UINT32 m_ulLowWaterMark;
- UINT32 m_ulLastAudioWrite;
+ UINT32 m_ulLastEncodedWriteTime;
+ UINT32 m_ulLastDevWriteTime;
+ UINT32 m_ulAudioTimeOffset;
+ HXBOOL m_bDetectedHWM;
CHXPowerSaveAudDeviceObserver* m_pPowSaveAudDevObserver;
Index: hxmmfstatectrl.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/hxmmfstatectrl.cpp,v
retrieving revision 1.4.2.33
diff -w -u -b -r1.4.2.33 hxmmfstatectrl.cpp
--- hxmmfstatectrl.cpp 11 Mar 2010 03:53:19 -0000 1.4.2.33
+++ hxmmfstatectrl.cpp 19 Mar 2010 22:00:54 -0000
@@ -297,7 +297,6 @@
ULONG32
HXMMFStateCtrl::GetPosition()
{
- ULONG32 ulRetPos = m_posLength;
#ifdef HELIX_FEATURE_POWER_SAVE_MODE
if(m_pScheduler3
@@ -305,13 +304,12 @@
&& m_pPlayerControl
&& m_pPlayerControl->m_pHXPlayer)
{
- ulRetPos = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
+ m_posLength = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
}
#endif /*HELIX_FEATURE_POWER_SAVE_MODE*/
- return ulRetPos;
+ return m_posLength;
- // return(m_posLength);
}
From jgordon at real.com Mon Mar 22 13:54:57 2010
From: jgordon at real.com (Jamie Gordon)
Date: Mon Mar 22 21:02:03 2010
Subject: [datatype-dev] CR: PR 256465: Excessively long start-up time for
unhinted h.264 content
Message-ID: <4BA7E731.7090500@real.com>
Synopsis
========
Fixes the unacceptably long start-up time for long, unhinted h.264
content
Branches: SERVER_14_0_RN, HEAD (SERVER_CURRENT)
Suggested Reviewer: anyone
Description
===========
h.264 descriptor atoms do not provide media bitrate at all, so it
hits the generic bitrate calculation. This calculation sums up every
sample in the track to get the track size in order to calculate the
bitrate of the entire track. This takes way too long for content that
is more than a few minutes long. This changes the bitrate calculation to
instead calculate an estimate by summing the sample sizes and durations
of a portion of the track.
The estimate is based on full key-frame intervals, calculated from the
beginning of the track until it's looked at either
MinKF key-frame intervals AND MinDuration milliseconds
OR
MaxDuration milliseconds
OR
Whole track
These are configurable (in server config, not sure about client
configurability?), with defaults of 3 KF intervals, 30 seconds min,
60 seconds max.
Files Affected
==============
datatype/mp4/fileformat/qttrack.cpp
datatype/mp4/fileformat/pub/qttrack.h
Testing Performed
=================
Unit Tests:
Integration Tests:
Tested various content - small and large bitrates, various encoders,
compared estimated average bitrate to prior average bitrate calculation,
ensuring it is reasonably close (largest difference found was ~3% larger
with this change)
Leak Tests:
Performance Tests:
Will be done after checkin, in uptimes
Platforms Tested: win32-i386-vc7
Build verified: win32-i386-vc7
QA Hints
===============
regress PR 256465 on uptimes
-------------- next part --------------
Index: datatype/mp4/fileformat/qttrack.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qttrack.cpp,v
retrieving revision 1.45.4.1
diff -u -w -r1.45.4.1 qttrack.cpp
--- datatype/mp4/fileformat/qttrack.cpp 2 Mar 2010 04:10:34 -0000 1.45.4.1
+++ datatype/mp4/fileformat/qttrack.cpp 22 Mar 2010 21:36:25 -0000
@@ -49,6 +49,10 @@
#define QT_MAX_SEEK_SKIPBACKAHEAD_RATIO_SERVER 5
#define QT_NO_KEY_FRAME_SKIPBACK_TIME 5000
+#define QT_BRE_KEY_FRAMES 3
+#define QT_BRE_MIN_DUR 30000 // milliseconds
+#define QT_BRE_MAX_DUR 60000 // milliseconds
+
/****************************************************************************
* Includes
@@ -61,6 +65,7 @@
#include "qtffrefcounter.h"
#include "hxstrutl.h"
+#include "hxmon.h"
#include "sdpchunk.h"
#include "sdppyldinfo.h"
@@ -333,7 +338,6 @@
HX_RELEASE(m_pFileSwitcher);
HX_RELEASE(m_pPacketizer);
HX_RELEASE(m_pClassFactory);
-
}
/****************************************************************************
@@ -931,6 +935,82 @@
return retVal;
}
+UINT32 CQTTrack::EstimateTrackBitrate(UINT32 ulMinKeyFrames,
+ UINT32 ulMinTime, UINT32 ulMaxTime)
+{
+ ULONG32 ulStartingMediaTime = m_TrackEdit.GetMediaTime();
+
+ // Anytime this is called we should be at time 0...
+ HX_ASSERT(ulStartingMediaTime == 0);
+
+ // XXXJDG This should seek to a sync point nearer the middle for
+ // cases where we have a seek table and can do so very quickly
+ Seek(0);
+
+ UINT32 ulSize = 0;
+ UINT32 ulDuration = 0;
+ UINT32 ulSampleSize = 0;
+ UINT32 ulMediaTime = 0;
+ UINT32 ulLastMediaTime = m_TrackEdit.GetMediaTime();
+ UINT32 ulNumKeyFrames = 0;
+ HXBOOL bDone = FALSE;
+
+ // convert input times to media timescale
+ double dTimeConv = (double)m_TrackInfo.GetMediaTimeScale() / 1000.0;
+ ulMinTime = (UINT32)((double)ulMinTime * dTimeConv + .5);
+ ulMaxTime = (UINT32)((double)ulMaxTime * dTimeConv + .5);
+
+ while (!bDone)
+ {
+ ulSampleSize = m_SampleManager.GetSampleSize();
+
+ if (AdvanceSample(m_TrackEdit, m_SampleManager))
+ {
+ if(m_SampleManager.IsOnSyncSample())
+ {
+ // If we've just moved to a new key frame and have now
+ // checked the min num of keyframe intervals AND
+ // the min duration, OR the max duration then we can quit
+ if ((++ulNumKeyFrames >= ulMinKeyFrames &&
+ ulDuration >= ulMinTime) || (ulDuration >= ulMaxTime))
+ {
+ break;
+ }
+ }
+
+ ulMediaTime = m_TrackEdit.GetMediaTime();
+ }
+ else
+ {
+ // We are at the end so we can't get the sample time diff,
+ // take the track duration (converted from movie time to
+ // media time).
+ ulMediaTime = (UINT32)(m_TrackInfo.GetMediaTimeScale() *
+ ((double)m_TrackInfo.GetTrackDuration() /
+ (double)m_pFileFormat->m_MovieInfo.GetMovieTimeScale()));
+
+ if (ulMediaTime < ulLastMediaTime)
+ {
+ ulMediaTime = ulLastMediaTime;
+ }
+ bDone = TRUE;
+ }
+
+ ulSize += ulSampleSize;
+ ulDuration += ulMediaTime - ulLastMediaTime;
+ ulLastMediaTime = ulMediaTime;
+ }
+
+ UINT32 ulBitRate = ulDuration > 0 ?
+ (UINT32)(.5 + (double)ulSize * 8.0 / ((double)ulDuration /
+ (double)m_TrackInfo.GetMediaTimeScale())) : 0;
+
+ // now seek back to the beginning
+ Seek(ulStartingMediaTime);
+
+ return ulBitRate;
+}
+
/****************************************************************************
* ObtainBandwidth
*/
@@ -998,30 +1078,70 @@
HX_RESULT CQTTrack::ObtainTrackBitrate(ULONG32& ulAvgBitrateOut)
{
ULONG32 ulAvgBitRate;
- ULONG32 ulDuration;
HX_RESULT retVal = HXR_FAIL;
ulAvgBitRate = m_TrackInfo.GetAvgBitrate();
if (ulAvgBitRate == 0)
{
- ulDuration = (ULONG32) ((((double) m_TrackInfo.GetTrackDuration())
- * 1000.0)
- / m_pFileFormat->m_MovieInfo.GetMovieTimeScale());
+ UINT32 ulTrackSize = m_TrackInfo.GetTrackSize();
+ UINT32 ulDuration = (UINT32)
+ ((((double) m_TrackInfo.GetTrackDuration()) * 1000.0) /
+ m_pFileFormat->m_MovieInfo.GetMovieTimeScale() + .5);
- if (ulDuration != 0)
+ if (ulDuration != 0 && ulTrackSize != 0)
{
- ULONG32 ulTrackSize = m_TrackInfo.GetTrackSize();
+ ulAvgBitRate = (ULONG32) ((((double) ulTrackSize) * 8000.0)
+ / ulDuration + 0.5);
+ }
+ else
+ {
+ IUnknown* pContext = m_pFileFormat->GetContext();
+ UINT32 ulKeyFrames = QT_BRE_KEY_FRAMES;
+ UINT32 ulMinDuration = QT_BRE_MIN_DUR;
+ UINT32 ulMaxDuration = QT_BRE_MAX_DUR;
+ IHXRegistry* pReg = NULL;
- if (ulTrackSize == 0)
+ if (SUCCEEDED(pContext->QueryInterface(IID_IHXRegistry, (void**)&pReg)))
{
- ComputeTrackSize(ulTrackSize);
- m_TrackInfo.SetTrackSize(ulTrackSize);
+ INT32 nTmp = 0;
+
+ if (SUCCEEDED(pReg->GetIntByName(
+ "config.Datatypes.BitrateEstimation.KeyFrameIntervals",
+ nTmp)) && nTmp > 0)
+ {
+ ulKeyFrames = (UINT32)nTmp;
+ }
+ if (SUCCEEDED(pReg->GetIntByName(
+ "config.Datatypes.BitrateEstimation.MinTimePeriod",
+ nTmp)) && nTmp > 0)
+ {
+ ulMinDuration = (UINT32)nTmp;
+ }
+ if (SUCCEEDED(pReg->GetIntByName(
+ "config.Datatypes.BitrateEstimation.MaxTimePeriod",
+ nTmp)) && nTmp > 0)
+ {
+ ulMaxDuration = (UINT32)nTmp;
}
+ pReg->Release();
+ }
+ if (ulDuration <= ulMinDuration && ulDuration != 0)
+ {
+ // if the track duration is less than the minimum duration check
+ // then calculate the total avg bitrate
+ ComputeTrackSize(ulTrackSize);
+ m_TrackInfo.SetTrackSize(ulTrackSize);
ulAvgBitRate = (ULONG32) ((((double) ulTrackSize) * 8000.0)
/ ulDuration + 0.5);
}
+ else
+ {
+ ulAvgBitRate = EstimateTrackBitrate(ulKeyFrames,
+ ulMinDuration, ulMaxDuration);
+ }
+ }
}
if (ulAvgBitRate != 0)
Index: datatype/mp4/fileformat/pub/qttrack.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qttrack.h,v
retrieving revision 1.21.4.1
diff -u -w -r1.21.4.1 qttrack.h
--- datatype/mp4/fileformat/pub/qttrack.h 18 Feb 2010 21:47:34 -0000 1.21.4.1
+++ datatype/mp4/fileformat/pub/qttrack.h 22 Mar 2010 21:36:25 -0000
@@ -114,6 +114,8 @@
virtual HXBOOL IsSubscribed(void);
virtual HX_RESULT ComputeTrackSize(ULONG32& ulTrackSizeOut);
+ virtual UINT32 EstimateTrackBitrate(UINT32 ulMinKeyFrames,
+ UINT32 ulMinTime, UINT32 ulMaxTime);
virtual HX_RESULT ObtainTrackBandwidth(ULONG32& ulBandwidthOut);
virtual HX_RESULT ObtainTrackBitrate(ULONG32& ulAvgBitrateOut);
From jgordon at real.com Mon Mar 22 17:03:01 2010
From: jgordon at real.com (Jamie Gordon)
Date: Tue Mar 23 00:10:06 2010
Subject: [datatype-dev] Checkin: PR 256465: Excessively long start-up time
for unhinted h.264 content
Message-ID: <4BA81345.1020300@real.com>
Synopsis
========
Fixes the unacceptably long start-up time for long, unhinted h.264
content
Branches: SERVER_14_0_RN, HEAD (SERVER_CURRENT)
Reviewer: chytanya
Build: http://build.dev.prognet.com/~build/report.cgi?id=209396
Description
===========
h.264 descriptor atoms do not provide media bitrate at all, so it
hits the generic bitrate calculation. This calculation sums up every
sample in the track to get the track size in order to calculate the
bitrate of the entire track. This takes way too long for content that
is more than a few minutes long. This changes the bitrate calculation to
instead calculate an estimate by summing the sample sizes and durations
of a portion of the track.
The estimate is based on full key-frame intervals, calculated from the
beginning of the track until it's looked at either
MinKF key-frame intervals AND MinDuration milliseconds
OR
MaxDuration milliseconds
OR
Whole track
These are configurable (in server config, not sure about client
configurability?), with defaults of 3 KF intervals, 30 seconds min,
60 seconds max.
Files Affected
==============
datatype/mp4/fileformat/qttrack.cpp
datatype/mp4/fileformat/pub/qttrack.h
Testing Performed
=================
Unit Tests:
Integration Tests:
Tested various content - small and large bitrates, various encoders,
compared estimated average bitrate to prior average bitrate calculation,
ensuring it is reasonably close (largest difference found was ~3% larger
with this change)
Leak Tests:
Performance Tests:
Will be done after checkin, in uptimes
Platforms Tested: win32-i386-vc7
Build verified: win32-i386-vc7
QA Hints
===============
regress PR 256465 on uptimes
From ext-sudhir.1.mishra at nokia.com Tue Mar 23 10:21:05 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Tue Mar 23 17:28:08 2010
Subject: [datatype-dev] CR: CPAY-82TEGE: Crash occurs after playing a 3gp
video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F17282DB3AE70@NOK-EUMSG-02.mgdnok.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: ext-debashis.2.panigrahi@nokia.com
Reviewed by: Junhong.Liu@nokia.com
TSW Id: CPAY-82TEGE
Date: 03/23/2010
Project: SymbianMmf_wm
Synopsis: Crash occurs after playing a 3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
Overview:
There are two problems with this stream:
1) Helix is getting unsupported/invalid NAL units in RTP payload (NAL types 0, 30 or 31) which are getting ignored
2) In MTAP payload most of the times data that is coming is corrupted which is causing the panic.
In case of corrupted Multitime aggregate NAL packet ( NAL-Type=26), total payload size shows less then the included NAL size. This causes the computation of the next NAL (MTAP16) size to go wrong, which later causes Buffer size to reset and result in a panic.
Fix:
In case of invalid/corrupted MTAP NAL, setting the NAL size equal to remaining available buffer size i.e. if the NAL coming is greater than the RTP payload then set it equal to available payload size instead of ignoring it completely, hence neglecting the fillers.
This will fix the crash but we may get artifacts or the video may stop gracefully at some later stage.
Files modified & changes:
datatype/mp4/payload/h264pyld.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS:
Index: h264pyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/h264pyld.cpp,v
retrieving revision 1.4.2.6
diff -u -w -r1.4.2.6 h264pyld.cpp
--- h264pyld.cpp 25 Jun 2008 05:33:18 -0000 1.4.2.6
+++ h264pyld.cpp 23 Mar 2010 12:11:37 -0000
@@ -1016,6 +1016,12 @@
else
{
UINT32 ulNalSize = ((UINT16)pData[0]<<8) + pData[1];
+ //If the NAL coming is greater than the RTP payload
+ //then set it equal to buff size hence neglect fillers
+ //This is invalid/corrupted MTAP NAL
+ if(ulNalSize > ulBuffSize){
+ ulNalSize = ulBuffSize;
+ }
offset = 2;
if (uPacketType == MTAP16)
{
From tseaward at real.com Tue Mar 23 13:43:06 2010
From: tseaward at real.com (Tony Seaward)
Date: Tue Mar 23 20:49:57 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
In-Reply-To:
References:
Message-ID: <4BA935EA.8090103@real.com>
Alvaro-
Have you addressed the concerns brought up by Anuj?
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/22/10 1:15 PM, Alvaro.Vaquero@nokia.com wrote:
>
> *From:* Vaquero Alvaro (Nokia-D/Dallas)
> *Sent:* Friday, March 19, 2010 11:13 AM
> *To:* 'datatype-dev@helixcommunity.org'
> *Subject:* RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after
> seeking fast backward
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: alvaro.vaquero@nokia.com
>
>
>
> Reviewed by:
>
>
>
> Date: 03/19/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> ErrorId: EHLI-83ME7Q
>
>
>
> Synopsis: MKV ac3 file cannot replay after seeking fast backward
>
>
>
> Overview:
>
> The file is missing cue data which is required for seeking in matroska
> files. The file is therefore not seekable. This CR enables Matroska to
> notify UI that the file is not seekable and the user experience is
> correct.
>
>
>
> Files Added: None.
>
>
>
> Files Modified:
>
> /datatype/mkv/fileformat/mkv_file_format.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.h
>
>
>
> Image Size and Heap Use impact: minor
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No.
>
>
>
> Memory leak check performed : Yes. No new leaks introduced
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: Cays210, Brizo420, HEAD
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100323/ae40a59c/attachment-0001.html
From rajesh.rathinasamy at nokia.com Tue Mar 23 13:47:50 2010
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Tue Mar 23 20:55:24 2010
Subject: [datatype-dev] [Nokia-private-dev] CR RESEND: Optimization of
number of calls to devSound for SamplesPlayed count
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.1.2.20
diff -w -u -b -r1.1.2.20 mdfauddevice.cpp
--- mdfauddevice.cpp 2 Mar 2010 00:27:08 -0000 1.1.2.20
+++ mdfauddevice.cpp 22 Mar 2010 18:37:48 -0000
@@ -56,6 +56,8 @@
#define DEFAULT_POWER_SAVE_HWM_MS 6000 //values are set in ms
#define DEFAULT_POWER_SAVE_LWM_MS 2000 //values are set in ms
+// Offset is added to the HWM when wakeupinterval is calculated
+#define POWER_SAVE_HWM_OFFSET_MS 500
static UINT32 Scale(UINT32 v, UINT32 f0, UINT32 f1, UINT32 t0, UINT32 t1);
@@ -126,6 +128,8 @@
m_nBytesPCMToPlay(0),
m_playing(FALSE),
m_ulAudioTimeOffset(0),
+ m_ulCurrPlayTime(0),
+ m_bDisableOnTimeSyncTimer(FALSE),
m_pAudioFormat(pAudioFormat),
m_pErrorMessage(NULL),
m_CurrentVolume(MDFDEVICE_INVALID_VOLUME),
@@ -385,8 +389,8 @@
if(m_pDeviceResponse)
{
ULONG32 ulAudioTime = 0;
- GetCurrentAudioTime(ulAudioTime);
- m_pDeviceResponse->OnTimeSync(ulAudioTime);
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ m_pDeviceResponse->OnTimeSync(m_ulCurrPlayTime);
}
//Set timer for next OnTimeSync callback
@@ -579,8 +583,8 @@
if(m_pDeviceResponse)
{
ULONG32 ulAudioTime = 0;
- GetCurrentAudioTime(ulAudioTime);
- m_pDeviceResponse->OnTimeSync(ulAudioTime);
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ m_pDeviceResponse->OnTimeSync(m_ulCurrPlayTime);
}
@@ -624,7 +628,6 @@
m_readyList.AddTail(pAudioData);
#if defined HELIX_FEATURE_POWER_SAVE_MODE
m_ulLastAudioWrite = pAudioData->m_ulAudioTime-m_ulAudioTimeOffset;
-
m_pDevSound->SetLastRecvdEncodedData(m_ulLastAudioWrite);
#endif /*HELIX_FEATURE_POWER_SAVE_MODE*/
@@ -730,6 +733,7 @@
//reset SecureOutput settings
m_bSecureOutputChanged = FALSE;
+ m_ulCurrPlayTime = 0;
// stop device.
if (m_pDevSound)
{
@@ -798,7 +802,19 @@
// HXLOGL2(HXLOG_MDFA,"mdfdeV:gettime < t=%d", ulCurrentTime);
HX_RESULT hxr = HXR_OK;
- hxr = m_pDevSound->GetCurrentPlayTime(ulCurrentTime);
+
+#ifdef HELIX_FEATURE_POWER_SAVE_MODE
+ // If scheduler is not running, the playback time is not current.
+ // Update the current playback time
+ if(m_bIsInPowerSave && m_pScheduler3->IsPaused())
+ {
+ hxr = m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
+ }
+#endif
+
+ // Return the last updated value
+ ulCurrentTime = m_ulCurrPlayTime;
+
#if defined(HELIX_FEATURE_DRM_SECURE_OUTPUT)
if(m_bSecureOutputChanged)
{
@@ -882,6 +898,7 @@
HXLOGL4(HXLOG_MDFA,"mdfdeV:setStartT <> %d", ulStartTime);
m_ulAudioTimeOffset = ulStartTime;
+ m_pDevSound->SetAudioTimeOffset(m_ulAudioTimeOffset);
}
void CHXMDFAudioDevice::SetStreamFinished(HXBOOL bEndOfStream)
@@ -924,7 +941,7 @@
{
HXLOGL4(HXLOG_MDFA,"mdfdeV:dosettimer <");
- if( !IsActive())
+ if( (!IsActive()) && (!m_bDisableOnTimeSyncTimer))
{
//HXLOGL4(HXLOG_MDFA, "mdfdeV:dosettimer .. set timer here. %d", iStatus.Int());
m_iTimer.After(iStatus, TIMESYNC_CALLBACK_INTERVAL_MS * 1000);
@@ -1107,12 +1124,8 @@
HX_RESULT retVal = HXR_OK;
if(m_bIsInPowerSave)
{
- if(m_pScheduler3->IsPaused())
- {
HXLOGL3( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::EndPowerSave calling ResumeScheduler ", this);
- retVal = m_pScheduler3->ResumeScheduler();
- }
-
+ LowWaterMark();
m_pDevSound->SetPowerSaveConfig(NULL, m_ulWakeUpInterval, m_ulLowWaterMark); //as such LowWaterMArk won't be called
m_bIsInPowerSave = FALSE;
@@ -1142,6 +1155,8 @@
CHXMDFAudioDevice::GetWakeUpInterval(UINT32& ulWakeUpInterval )
{
ulWakeUpInterval = m_ulWakeUpInterval;
+ // Adding an offset, so that the source does not stop sending data based on old playback time.
+ ulWakeUpInterval += POWER_SAVE_HWM_OFFSET_MS;
HXLOGL2( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::GetWakeUpInterval m_ulWakeUpInterval=%lu ", this, m_ulWakeUpInterval);
return HXR_OK;
@@ -1178,6 +1193,8 @@
m_pScheduler3->PauseScheduler();
}
+ m_bDisableOnTimeSyncTimer = TRUE;
+
// Cancel the timer used for ontimesync reporting
if (IsActive())
{
@@ -1207,8 +1224,10 @@
}
//set timer for OntimeSync or unpause timer for ontimesync
+ m_bDisableOnTimeSyncTimer = FALSE;
if( !IsActive())
{
+ m_pDevSound->GetCurrentPlayTime(m_ulCurrPlayTime);
HXLOGL3( HXLOG_MDFA, "CHXMDFAudioDevice[%p]::LowWaterMark calling SetActive ", this);
DoSetTimer();
}
Index: mdfauddevice.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.h,v
retrieving revision 1.1.2.9
diff -w -u -b -r1.1.2.9 mdfauddevice.h
--- mdfauddevice.h 2 Mar 2010 00:27:24 -0000 1.1.2.9
+++ mdfauddevice.h 22 Mar 2010 18:37:48 -0000
@@ -215,6 +215,8 @@
//Timing
UINT32 m_ulAudioTimeOffset; //rendering time
+ UINT32 m_ulCurrPlayTime;
+ HXBOOL m_bDisableOnTimeSyncTimer;
// buffered frames
CHXSimpleList m_bufferList; //frames received from decoder
Index: mdfdevsound.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfdevsound.cpp,v
retrieving revision 1.1.2.31
diff -w -u -b -r1.1.2.31 mdfdevsound.cpp
--- mdfdevsound.cpp 2 Mar 2010 00:27:40 -0000 1.1.2.31
+++ mdfdevsound.cpp 22 Mar 2010 18:37:48 -0000
@@ -153,8 +153,11 @@
#endif
, m_ulHighWaterMark(0)
, m_ulLowWaterMark(0)
- , m_ulLastAudioWrite(0)
+ , m_ulLastEncodedWriteTime(0)
+ , m_ulLastDevWriteTime(0)
+ , m_ulAudioTimeOffset(0)
, m_pPowSaveAudDevObserver(NULL)
+ ,m_bDetectedHWM(FALSE)
{
HX_ASSERT(pFrameList);
HX_ASSERT(pFormat);
@@ -339,12 +342,24 @@
m_ulDevTime = 0; //ByMsPerFrame
m_ulFramesPlayedLastRound = 0; //ByMsPerFrame
m_ulTotalPCMBytesPlayed = 0; //BySampleRate
+
+ //
+ // m_ulSamplesPlayedOffset - Samplesplayed value before PauseAndFlush
+ // Older version of devsound does not reset the samples played counter
+ // during PauseAndFlush. Hence we cache this value and subtract it from
+ // the new value
+ //
m_ulSamplesPlayedOffset = GetValidSamplesPlayed(); //BySamplesPlayed
//samples played before taken and samples written reset to zero
m_ulSamplesPlayedBeforeTaken = 0;
m_ulSamplesWritten = 0;
+ m_ulLastDevWriteTime = 0;
+ m_ulLastEncodedWriteTime = 0;
+ m_ulAudioTimeOffset = 0;
+ m_bDetectedHWM = FALSE;
+
HXLOGL2(HXLOG_MDFA, "---devsnd:reset .. before flush %lu", (UINT32)m_ulSamplesPlayedOffset);
//
@@ -700,6 +715,8 @@
{
m_devStatus = DevPlayInitializing;
#ifdef S60_HX_CONVERGED_DEVSOUND
+ // New version ( also called Converged) devsound,
+ // resets the samples played during PauseAndFlush
m_ulSamplesPlayedOffset = 0;
m_ulLastValidSamplesPlayed = 0;
#endif
@@ -935,7 +952,7 @@
else
{
HXMDFAudioData* pAudioData = (HXMDFAudioData*)m_pDataList->GetHead();
- UINT32 ulDataTime = pAudioData->m_ulAudioTime;
+ m_ulLastDevWriteTime = pAudioData->m_ulAudioTime - m_ulAudioTimeOffset;
HX_RESULT retErr = HXR_OK;
if (pAudioData->m_bMissing || pAudioData->m_bConcealed)
@@ -1146,25 +1163,49 @@
//
void CMDFDevSound::SetLastRecvdEncodedData(const UINT32& ulLastAudioWrite)
{
- m_ulLastAudioWrite = ulLastAudioWrite;
-
+ m_ulLastEncodedWriteTime = ulLastAudioWrite;
+ CheckForHWM();
HXLOGL4(HXLOG_CORE,"mdfdev:Write .. Obs:%p last buf time:%lu", m_pPowSaveAudDevObserver, ulLastAudioWrite);
+}
+//
+// CMDFDevSound::CheckForHWM
+// Checks if Q has reached high water mark
+// and report to the observer
+//
+void CMDFDevSound::CheckForHWM()
+{
// Check if we have enough data to report
// high water mark
+
+ // We are not checking for m_bDetectedHWM as this call
+ // should not happen when it is TRUE
+ //
if(m_pPowSaveAudDevObserver != NULL)
{
UINT32 ulTimeLeft = 0;
- GetTotalUnPlayedDataInMs(ulTimeLeft);
+ UINT32 ulTimeInDev = 0;
+
+ // First caluclate the data in Q
+ ulTimeLeft = m_ulLastEncodedWriteTime - m_ulLastDevWriteTime;
+
+ // We use the last updated samples played
+ // Inaccuracy could be upto 30msec as it is updated from during
+ // the ontimesync reporting
+ ulTimeInDev = (m_ulLastValidSamplesPlayed - m_ulSamplesPlayedOffset) * 1000 / m_pAudioFormat->m_ulSamplesPerSec;
+ ulTimeInDev = m_ulLastDevWriteTime - ulTimeInDev;
- HXLOGL4(HXLOG_CORE,"mdfdev:Write .. unplayed:%lu last buf time:%lu",ulTimeLeft, ulLastAudioWrite);
+ ulTimeLeft += ulTimeInDev;
+
+ HXLOGL4(HXLOG_MDFA,"mdfdev:CheckForHWM .. DataInQ:%lu m_ulLastDevWriteTime:%lu",ulTimeLeft, m_ulLastDevWriteTime);
if(ulTimeLeft > m_ulHighWaterMark)
{
m_pPowSaveAudDevObserver->HighWaterMark();
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForHWM .. m_bDetectedHWM=%d", m_bDetectedHWM);
+ m_bDetectedHWM = TRUE;
}
} // End of if(m_pPowSaveAudDevObserver != NULL)
-
}
//
@@ -1174,15 +1215,28 @@
//
void CMDFDevSound::CheckForLWM()
{
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. m_bDetectedHWM=%d", m_bDetectedHWM);
+ if( (m_pPowSaveAudDevObserver != NULL) && (m_bDetectedHWM) )
+ {
+ UINT32 ulDataInQ = m_ulLastEncodedWriteTime - m_ulLastDevWriteTime;
+
+ HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. ulDataInQ=%lu", ulDataInQ);
+ // We first check, if data in Q is nearing LWM.
+ // This will reduce the number of samplesplayed calculation
+ if(ulDataInQ < m_ulLowWaterMark)
+ {
UINT32 ulTotalUnplayedDataInMs = 0;
+ // Calculate accurate unplayed samples time
GetTotalUnPlayedDataInMs(ulTotalUnplayedDataInMs);
HXLOGL4(HXLOG_MDFA,"devsnd:CheckForLWM .. Pending=%lu Obs:%p", ulTotalUnplayedDataInMs, m_pPowSaveAudDevObserver);
-
- if(m_pPowSaveAudDevObserver
- && ulTotalUnplayedDataInMs <= m_ulLowWaterMark)
+ if(ulTotalUnplayedDataInMs <= m_ulLowWaterMark)
{
m_pPowSaveAudDevObserver->LowWaterMark();
+ m_bDetectedHWM = FALSE;
}
+ } // End of if(ulDataInQ < m_ulLowWaterMark)
+
+ } // End of if( (m_pPowSaveAudDevObserver != NULL) && (!m_bDetectedHWM) )
}
//
@@ -1192,9 +1246,9 @@
//
void CMDFDevSound::GetTotalUnPlayedDataInMs( UINT32& ulUnPlayedData)
{
- UINT32 ulCurrTime = 0;
- GetCurrentPlayTime(ulCurrTime);
- ulUnPlayedData = m_ulLastAudioWrite - ulCurrTime;
+ UINT32 ulPlayTime = 0;
+ GetCurrentPlayTime(ulPlayTime);
+ ulUnPlayedData = m_ulLastEncodedWriteTime - ulPlayTime;
}
Index: mdfdevsound.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfdevsound.h,v
retrieving revision 1.1.2.16
diff -w -u -b -r1.1.2.16 mdfdevsound.h
--- mdfdevsound.h 2 Mar 2010 00:27:51 -0000 1.1.2.16
+++ mdfdevsound.h 22 Mar 2010 18:37:48 -0000
@@ -156,8 +156,10 @@
//for power save
void SetPowerSaveConfig(CHXPowerSaveAudDeviceObserver* pPowSaveAudDevObserver, const UINT32& ulHighWaterMark, const UINT32& ulLowWaterMark);
void CheckForLWM();
+ void CheckForHWM();
void GetTotalUnPlayedDataInMs( UINT32& ulUnPlayedData);
void SetLastRecvdEncodedData(const UINT32& ulLastAudioWrite);
+ void SetAudioTimeOffset(UINT32 ulAudioTimeOffset) {m_ulAudioTimeOffset = ulAudioTimeOffset;}
private:
@@ -228,7 +230,10 @@
UINT32 m_ulHighWaterMark;
UINT32 m_ulLowWaterMark;
- UINT32 m_ulLastAudioWrite;
+ UINT32 m_ulLastEncodedWriteTime;
+ UINT32 m_ulLastDevWriteTime;
+ UINT32 m_ulAudioTimeOffset;
+ HXBOOL m_bDetectedHWM;
CHXPowerSaveAudDeviceObserver* m_pPowSaveAudDevObserver;
Index: hxmmfstatectrl.cpp
===================================================================
RCS file: /cvsroot/clientapps/symbianMmf/hxmmfstatectrl.cpp,v
retrieving revision 1.4.2.33
diff -w -u -b -r1.4.2.33 hxmmfstatectrl.cpp
--- hxmmfstatectrl.cpp 11 Mar 2010 03:53:19 -0000 1.4.2.33
+++ hxmmfstatectrl.cpp 19 Mar 2010 22:00:54 -0000
@@ -297,7 +297,6 @@
ULONG32
HXMMFStateCtrl::GetPosition()
{
- ULONG32 ulRetPos = m_posLength;
#ifdef HELIX_FEATURE_POWER_SAVE_MODE
if(m_pScheduler3
@@ -305,13 +304,12 @@
&& m_pPlayerControl
&& m_pPlayerControl->m_pHXPlayer)
{
- ulRetPos = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
+ m_posLength = m_pPlayerControl->m_pHXPlayer->GetCurrentPlayTime();
}
#endif /*HELIX_FEATURE_POWER_SAVE_MODE*/
- return ulRetPos;
+ return m_posLength;
- // return(m_posLength);
}
-------------- next part --------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From Alvaro.Vaquero at nokia.com Tue Mar 23 13:54:43 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Tue Mar 23 21:02:04 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot
replay after seeking fast backward
In-Reply-To: <4BA935EA.8090103@real.com>
References:
<4BA935EA.8090103@real.com>
Message-ID:
Tony,
Yes, the idea would be to return TRUE rather than -1 to comply with the HXBOOL type. It seemed straight forward enough so I didn't bother sending a new file. I hope that's ok.
BR,
/Alvaro
From: ext Tony Seaward [mailto:tseaward@real.com]
Sent: Tuesday, March 23, 2010 4:43 PM
To: Vaquero Alvaro (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
Alvaro-
Have you addressed the concerns brought up by Anuj?
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/22/10 1:15 PM, Alvaro.Vaquero@nokia.com wrote:
From: Vaquero Alvaro (Nokia-D/Dallas)
Sent: Friday, March 19, 2010 11:13 AM
To: 'datatype-dev@helixcommunity.org'
Subject: RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: alvaro.vaquero@nokia.com
Reviewed by:
Date: 03/19/2010
Project: SymbianMmf_wm
ErrorId: EHLI-83ME7Q
Synopsis: MKV ac3 file cannot replay after seeking fast backward
Overview:
The file is missing cue data which is required for seeking in matroska files. The file is therefore not seekable. This CR enables Matroska to notify UI that the file is not seekable and the user experience is correct.
Files Added: None.
Files Modified:
/datatype/mkv/fileformat/mkv_file_format.cpp
/datatype/mkv/libmatroska/MatroskaExports.cpp
/datatype/mkv/libmatroska/MatroskaExports.h
Image Size and Heap Use impact: minor
Module Release testing (STIF) : Passed
Test case(s) Added : No.
Memory leak check performed : Yes. No new leaks introduced
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Cays210, Brizo420, HEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100323/6323f335/attachment.html
From tseaward at real.com Tue Mar 23 14:29:09 2010
From: tseaward at real.com (Tony Seaward)
Date: Tue Mar 23 21:35:47 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
In-Reply-To:
References:
<4BA935EA.8090103@real.com>
Message-ID: <4BA940B5.1090008@real.com>
Alvaro-
That is perfectly fine, just wanted to ensure that it wasn't missed.
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/23/10 2:54 PM, Alvaro.Vaquero@nokia.com wrote:
>
> Tony,
>
>
>
> Yes, the idea would be to return TRUE rather than -1 to comply with
> the HXBOOL type. It seemed straight forward enough so I didn?t bother
> sending a new file. I hope that?s ok.
>
>
>
> BR,
>
> /Alvaro
>
>
>
> *From:* ext Tony Seaward [mailto:tseaward@real.com]
> *Sent:* Tuesday, March 23, 2010 4:43 PM
> *To:* Vaquero Alvaro (Nokia-D/Dallas)
> *Cc:* datatype-dev@helixcommunity.org
> *Subject:* Re: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file
> cannot replay after seeking fast backward
>
>
>
> Alvaro-
> Have you addressed the concerns brought up by Anuj?
>
> Tony Seaward
> Helix DNA Program Manager
> RealNetworks, Inc.
> (206) 674-2391
>
>
> On 3/22/10 1:15 PM, Alvaro.Vaquero@nokia.com
> wrote:
>
> *From:* Vaquero Alvaro (Nokia-D/Dallas)
> *Sent:* Friday, March 19, 2010 11:13 AM
> *To:* 'datatype-dev@helixcommunity.org
> '
> *Subject:* RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after
> seeking fast backward
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: alvaro.vaquero@nokia.com
>
>
>
> Reviewed by:
>
>
>
> Date: 03/19/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> ErrorId: EHLI-83ME7Q
>
>
>
> Synopsis: MKV ac3 file cannot replay after seeking fast backward
>
>
>
> Overview:
>
> The file is missing cue data which is required for seeking in matroska
> files. The file is therefore not seekable. This CR enables Matroska to
> notify UI that the file is not seekable and the user experience is
> correct.
>
>
>
> Files Added: None.
>
>
>
> Files Modified:
>
> /datatype/mkv/fileformat/mkv_file_format.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.h
>
>
>
> Image Size and Heap Use impact: minor
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No.
>
>
>
> Memory leak check performed : Yes. No new leaks introduced
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: Cays210, Brizo420, HEAD
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100323/2bd893e4/attachment-0001.html
From qluo at real.com Tue Mar 23 15:03:54 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Mar 23 22:10:42 2010
Subject: [datatype-dev] CR: Optimization of number of calls to devSound
for SamplesPlayed count
In-Reply-To:
References:
Message-ID: <4BA948DA.3030902@real.com>
The fix looks good. Consider this cr as a sanity check. I don't really
know much about this s60 platform and its audio dsp power save mode.
Qiang
On 3/22/2010 2:03 PM, rajesh.rathinasamy@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
> Modified by: rajesh.rathinasamy@nokia.com
> Reviewed by: Ashish Gupta
> Date: 19-Mar-2010
> Project: SymbianMmf
> Error Id: DALM-83PT9G
> Synopsis: Optimization of number of calls to devSound for
> SamplesPlayed count
> Overview:
> PowerSave feature is implemented to allow the playback engine to be in
> sleep between high water mark and low water mark. It was noticed
> during CPU profiling that playback engine still runs during the sleep
> period. This CR also covers the original CR review comments.
> Analysis:
> RunL for timer in mdfaudiodevice invokes OnTimeSync which results in
> more audio data to be written. Within the same callstack, High water
> was reached and the callback checks for IsActive to disable timer.
> Since the callstack is already in RunL, the active object was not
> active and later the timer was still running. So introduced a flag to
> handle this case.
> Proposal also has optimizations to the number of samplesplayed calls
> invoked on devsound. Introduced member variable in mdfaudiodevice to
> store the audio time and it will be updated only during the timer
> RunL. So any calls between RunL will result in returning the cached
> value. So the possibility of inaccuracy is 30msec which is acceptable.
> Made an additional modification to mdfdevice for wakeup interval
> calculation.
> Sometimes, it took more time to fill the HWM amount data. Core had
> read the data from fileformat, but was not pushed to renderer due to
> the inaccuracy in the playback time. Added an offset of 500msec to HWM
> to report it as wakeupinterval. Idea is that core will try to send
> more data and Audio device will pause scheduler based on HWM.
> In State controller, while querying for Position, it uses its local
> value or gets it from playback engine. The value queried from playback
> engine is not updated in state controller which leads to inconsistent
> time reporting when the playback engine wakes up from sleep.
> Files removed: None
> Files added: None
> Files modified:
> datatype/mdf/audio/dsp/mdfdevsound.h
> datatype/mdf/audio/dsp/mdfdevsound.cpp
> datatype/mdf/audio/dsp/mdfauddevice.h
> datatype/mdf/audio/dsp/mdfauddevice.cpp
> clientapps/symbianMmf/hxmmfstatectrl.cpp
> Image size and heap use impact: None
> Module release testing (STIF): PARTIALLY PASSED (Failing cases are
> related to fullscreen, virtual window, playrate)
> Test case(s) added: No
> Memory leak check performed: No. Support not available for mdfauddevice
> Platforms and profiles build verified: helix-client-s60-50-mmf-mdf-dsp
> Platforms and profiles functionality verified: armv5
> Branch: 210CayS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100323/de7a057b/attachment.html
From sfu at real.com Tue Mar 23 15:36:55 2010
From: sfu at real.com (Sheldon Fu)
Date: Tue Mar 23 22:43:27 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay
after seeking fast backward
In-Reply-To:
References:
Message-ID: <4BA95097.7020202@real.com>
This looks ok other than the HXBOOL, -1 issue Anuj pointed out. Return
value should explicitly be either TRUE or FALSE.
fxd
Alvaro.Vaquero@nokia.com wrote:
>
> *From:* Vaquero Alvaro (Nokia-D/Dallas)
> *Sent:* Friday, March 19, 2010 11:13 AM
> *To:* 'datatype-dev@helixcommunity.org'
> *Subject:* RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after
> seeking fast backward
>
>
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: alvaro.vaquero@nokia.com
>
>
>
> Reviewed by:
>
>
>
> Date: 03/19/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> ErrorId: EHLI-83ME7Q
>
>
>
> Synopsis: MKV ac3 file cannot replay after seeking fast backward
>
>
>
> Overview:
>
> The file is missing cue data which is required for seeking in matroska
> files. The file is therefore not seekable. This CR enables Matroska to
> notify UI that the file is not seekable and the user experience is
> correct.
>
>
>
> Files Added: None.
>
>
>
> Files Modified:
>
> /datatype/mkv/fileformat/mkv_file_format.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.cpp
>
> /datatype/mkv/libmatroska/MatroskaExports.h
>
>
>
> Image Size and Heap Use impact: minor
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No.
>
>
>
> Memory leak check performed : Yes. No new leaks introduced
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: Cays210, Brizo420, HEAD
>
>
>
>
>
>
>
From rajesh.rathinasamy at nokia.com Wed Mar 24 07:16:57 2010
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Mar 24 14:24:13 2010
Subject: [datatype-dev] CN: Optimization of number of calls to devSound
for SamplesPlayed count
In-Reply-To: <4BA948DA.3030902@real.com>
References:
<4BA948DA.3030902@real.com>
Message-ID:
Hi Qiang,
Thanks for your review. We have done our internal review too.
The changes are checked into 210CayS.
Thanks,
Rajesh.
________________________________
From: ext Qiang Luo [mailto:qluo@real.com]
Sent: Tuesday, March 23, 2010 6:04 PM
To: Rathinasamy Rajesh (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: Optimization of number of calls to devSound for SamplesPlayed count
The fix looks good. Consider this cr as a sanity check. I don't really know much about this s60 platform and its audio dsp power save mode.
Qiang
On 3/22/2010 2:03 PM, rajesh.rathinasamy@nokia.com wrote:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: rajesh.rathinasamy@nokia.com
Reviewed by: Ashish Gupta
Date: 19-Mar-2010
Project: SymbianMmf
Error Id: DALM-83PT9G
Synopsis: Optimization of number of calls to devSound for SamplesPlayed count
Overview:
PowerSave feature is implemented to allow the playback engine to be in sleep between high water mark and low water mark. It was noticed during CPU profiling that playback engine still runs during the sleep period. This CR also covers the original CR review comments.
Analysis:
RunL for timer in mdfaudiodevice invokes OnTimeSync which results in more audio data to be written. Within the same callstack, High water was reached and the callback checks for IsActive to disable timer. Since the callstack is already in RunL, the active object was not active and later the timer was still running. So introduced a flag to handle this case.
Proposal also has optimizations to the number of samplesplayed calls invoked on devsound. Introduced member variable in mdfaudiodevice to store the audio time and it will be updated only during the timer RunL. So any calls between RunL will result in returning the cached value. So the possibility of inaccuracy is 30msec which is acceptable.
Made an additional modification to mdfdevice for wakeup interval calculation.
Sometimes, it took more time to fill the HWM amount data. Core had read the data from fileformat, but was not pushed to renderer due to the inaccuracy in the playback time. Added an offset of 500msec to HWM to report it as wakeupinterval. Idea is that core will try to send more data and Audio device will pause scheduler based on HWM.
In State controller, while querying for Position, it uses its local value or gets it from playback engine. The value queried from playback engine is not updated in state controller which leads to inconsistent time reporting when the playback engine wakes up from sleep.
Files removed: None
Files added: None
Files modified:
datatype/mdf/audio/dsp/mdfdevsound.h
datatype/mdf/audio/dsp/mdfdevsound.cpp
datatype/mdf/audio/dsp/mdfauddevice.h
datatype/mdf/audio/dsp/mdfauddevice.cpp
clientapps/symbianMmf/hxmmfstatectrl.cpp
Image size and heap use impact: None
Module release testing (STIF): PARTIALLY PASSED (Failing cases are related to fullscreen, virtual window, playrate)
Test case(s) added: No
Memory leak check performed: No. Support not available for mdfauddevice
Platforms and profiles build verified: helix-client-s60-50-mmf-mdf-dsp
Platforms and profiles functionality verified: armv5
Branch: 210CayS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100324/0112c946/attachment-0001.html
From Alvaro.Vaquero at nokia.com Wed Mar 24 07:50:42 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Wed Mar 24 14:58:14 2010
Subject: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot
replay after seeking fast backward
In-Reply-To: <4BA940B5.1090008@real.com>
References:
<4BA935EA.8090103@real.com>
<4BA940B5.1090008@real.com>
Message-ID:
Thanks Tony, Sheldon,
I've checked it in to Cay, Brizo and HEAD returning TRUE as agreed.
BR,
/Alvaro
From: ext Tony Seaward [mailto:tseaward@real.com]
Sent: Tuesday, March 23, 2010 5:29 PM
To: Vaquero Alvaro (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
Alvaro-
That is perfectly fine, just wanted to ensure that it wasn't missed.
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/23/10 2:54 PM, Alvaro.Vaquero@nokia.com wrote:
Tony,
Yes, the idea would be to return TRUE rather than -1 to comply with the HXBOOL type. It seemed straight forward enough so I didn't bother sending a new file. I hope that's ok.
BR,
/Alvaro
From: ext Tony Seaward [mailto:tseaward@real.com]
Sent: Tuesday, March 23, 2010 4:43 PM
To: Vaquero Alvaro (Nokia-D/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] RESEND: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
Alvaro-
Have you addressed the concerns brought up by Anuj?
Tony Seaward
Helix DNA Program Manager
RealNetworks, Inc.
(206) 674-2391
On 3/22/10 1:15 PM, Alvaro.Vaquero@nokia.com wrote:
From: Vaquero Alvaro (Nokia-D/Dallas)
Sent: Friday, March 19, 2010 11:13 AM
To: 'datatype-dev@helixcommunity.org'
Subject: RE: CR: EHLI-83ME7Q: MKV ac3 file cannot replay after seeking fast backward
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
Modified by: alvaro.vaquero@nokia.com
Reviewed by:
Date: 03/19/2010
Project: SymbianMmf_wm
ErrorId: EHLI-83ME7Q
Synopsis: MKV ac3 file cannot replay after seeking fast backward
Overview:
The file is missing cue data which is required for seeking in matroska files. The file is therefore not seekable. This CR enables Matroska to notify UI that the file is not seekable and the user experience is correct.
Files Added: None.
Files Modified:
/datatype/mkv/fileformat/mkv_file_format.cpp
/datatype/mkv/libmatroska/MatroskaExports.cpp
/datatype/mkv/libmatroska/MatroskaExports.h
Image Size and Heap Use impact: minor
Module Release testing (STIF) : Passed
Test case(s) Added : No.
Memory leak check performed : Yes. No new leaks introduced
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: Cays210, Brizo420, HEAD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100324/6e708644/attachment.html
From jgordon at real.com Wed Mar 24 12:46:54 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Mar 24 19:53:33 2010
Subject: [datatype-dev] CR: PR 260179,
others: various issues related to h.264 inter-stream packet ordering
Message-ID: <4BAA7A3E.8060800@real.com>
Synopsis
========
Fixes PR 260179
Branches: SERVER_14_0 (maybe), HEAD (SERVER_CURRENT)
Suggested Reviewer: anyone
Description
===========
There are various issues that crop up when the first packet for the
session returned by the file format has a later timestamp (RTP time)
than the first packet of a different stream. Currently, the file
format determines inter-stream packet ordering by delivery time, then
stream number, not considering RTP time.
This happens with most h.264 content from Adobe's encoders, because they
usually start video with an offset composition time (so delivery time is
0, RTP time is ~42ms) while the audio of course has no composition
offsets (thus starting at delivery time 0, RTP time 0). And they stick
the video track in first, so it gets picked first.
This change adds RTP time to the selection criteria, between delivery
time and stream number. So if the delivery times are the same then it
will compare the RTP timestamps and choose the earliest, or if RTP times
are also the same, then the lower stream number wins.
Files Affected
==============
datatype/mp4/fileformat/qtffplin.cpp
datatype/mp4/fileformat/qtswtrack.cpp
datatype/mp4/fileformat/pub/iqttrack.h
datatype/mp4/fileformat/pub/qtffplin.h
datatype/mp4/fileformat/pub/qtswtrack.h
datatype/mp4/fileformat/pub/qttrack.h
Testing Performed
=================
Unit Tests:
Integration Tests:
Verified various playback scenarios with this type of content
Leak Tests:
Performance Tests:
Platforms Tested: win32-i386-vc7, linux-rhel5-i686
Build verified: win32-i386-vc7, linux-rhel5-i686
QA Hints
===============
-------------- next part --------------
Index: datatype/mp4/fileformat/qtffplin.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtffplin.cpp,v
retrieving revision 1.84.4.5
diff -u -w -r1.84.4.5 qtffplin.cpp
--- datatype/mp4/fileformat/qtffplin.cpp 18 Feb 2010 21:47:34 -0000 1.84.4.5
+++ datatype/mp4/fileformat/qtffplin.cpp 24 Mar 2010 19:35:43 -0000
@@ -80,6 +80,8 @@
#include "stream_desc_hlpr.h"
#include "altidset.h"
#include "altgrpitr.h"
+#include "tscalc.h"
+#include "tsconvrt.h"
#include "sdpchunk.h"
#include "sdppyldinfo.h"
@@ -2145,8 +2147,16 @@
if (m_TrackManager.IsStreamTrackActive(0))
{
- return m_TrackManager.GetStreamTrack(0)->
- GetPacket(0);
+ IQTTrack* pTrack = m_TrackManager.GetStreamTrack(0);
+ if (!m_pPacketCache[0].pTSConverter &&
+ pTrack->GetMediaTimeScale() !=
+ m_MovieInfo.GetMovieTimeScale())
+ {
+ m_pPacketCache[0].pTSConverter =
+ new CTSConverter(pTrack->GetMediaTimeScale(),
+ m_MovieInfo.GetMovieTimeScale());
+ }
+ return pTrack->GetPacket(0);
}
else
{
@@ -3075,8 +3085,16 @@
// we still have stream packets to prime
if (m_TrackManager.IsStreamTrackActive(uStreamNum))
{
- retVal = m_TrackManager.GetStreamTrack(uStreamNum)->
- GetPacket(uStreamNum);
+ IQTTrack* pTrack = m_TrackManager.GetStreamTrack(uStreamNum);
+ if (!m_pPacketCache[uStreamNum].pTSConverter &&
+ pTrack->GetMediaTimeScale() !=
+ m_MovieInfo.GetMovieTimeScale())
+ {
+ m_pPacketCache[uStreamNum].pTSConverter =
+ new CTSConverter(pTrack->GetMediaTimeScale(),
+ m_MovieInfo.GetMovieTimeScale());
+ }
+ retVal = pTrack->GetPacket(uStreamNum);
}
else
{
@@ -3142,7 +3160,8 @@
inline UINT16 CQTFileFormat::GetNextPacketStreamNum(void)
{
UINT16 uStreamNum;
- ULONG32 ulLowestTime = 0xFFFFFFFF;
+ UINT32 ulLowestTime = 0xFFFFFFFF;
+ UINT32 ulPacketTime = 0;
UINT16 uNextPacketStream = NO_STREAM_SET;
HX_ASSERT(m_pPacketCache);
@@ -3164,13 +3183,52 @@
return uStreamNum;
}
}
- else if (ulLowestTime >
- m_pPacketCache[uStreamNum].pPacket->GetTime())
+ else
+ {
+ ulPacketTime = m_pPacketCache[uStreamNum].pPacket->GetTime();
+ if (ulLowestTime > ulPacketTime)
{
uNextPacketStream = uStreamNum;
ulLowestTime = m_pPacketCache[uStreamNum].
pPacket->GetTime();
m_ulNextPacketTime = ulLowestTime;
+
+ }
+ else if (ulLowestTime == ulPacketTime)
+ {
+ // If the delivery times are the same, compare the RTP
+ // timestamps (composition time) and order by timestamp
+ IHXRTPPacket* pRTPPkt1 = NULL;
+ IHXRTPPacket* pRTPPkt2 = NULL;
+ UINT32 ulCompTime1 = ulLowestTime;
+ UINT32 ulCompTime2 = ulPacketTime;
+
+ if (SUCCEEDED(m_pPacketCache[uNextPacketStream].pPacket->
+ QueryInterface(IID_IHXRTPPacket, (void**)&pRTPPkt1)) &&
+ SUCCEEDED(m_pPacketCache[uStreamNum].pPacket->
+ QueryInterface(IID_IHXRTPPacket, (void**)&pRTPPkt2)))
+ {
+ CTSConverter* pConv;
+ pConv = m_pPacketCache[uNextPacketStream].pTSConverter;
+ ulCompTime1 = pConv ?
+ pConv->Convert(pRTPPkt1->GetRTPTime()) :
+ pRTPPkt1->GetRTPTime();
+
+ pConv = m_pPacketCache[uStreamNum].pTSConverter;
+ ulCompTime2 = pConv ?
+ pConv->Convert(pRTPPkt2->GetRTPTime()) :
+ pRTPPkt2->GetRTPTime();
+ }
+ HX_RELEASE(pRTPPkt1);
+ HX_RELEASE(pRTPPkt2);
+
+ if (IsEarlier(ulCompTime2, ulCompTime1))
+ {
+ // Same delivery time with earlier RTP time.
+ // Take this one next.
+ uNextPacketStream = uStreamNum;
+ }
+ }
}
}
}
Index: datatype/mp4/fileformat/qtswtrack.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/qtswtrack.cpp,v
retrieving revision 1.3.108.1
diff -u -w -r1.3.108.1 qtswtrack.cpp
--- datatype/mp4/fileformat/qtswtrack.cpp 18 Feb 2010 21:47:34 -0000 1.3.108.1
+++ datatype/mp4/fileformat/qtswtrack.cpp 24 Mar 2010 19:35:43 -0000
@@ -729,6 +729,11 @@
return m_pPrimaryTrack->GetTrackHeight();
}
+UINT32 CQTSwitchTrack::GetMediaTimeScale(void)
+{
+ return m_pPrimaryTrack->GetMediaTimeScale();
+}
+
/****************************************************************************
* GetSDPLength
*/
Index: datatype/mp4/fileformat/pub/iqttrack.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/iqttrack.h,v
retrieving revision 1.4.4.1
diff -u -w -r1.4.4.1 iqttrack.h
--- datatype/mp4/fileformat/pub/iqttrack.h 18 Feb 2010 21:47:34 -0000 1.4.4.1
+++ datatype/mp4/fileformat/pub/iqttrack.h 24 Mar 2010 19:35:43 -0000
@@ -147,6 +147,7 @@
virtual void GetTrackHeader(IHXValues*& pHeader) = 0;
virtual ULONG32 GetTrackWidth(void) = 0;
virtual ULONG32 GetTrackHeight(void) = 0;
+ virtual UINT32 GetMediaTimeScale(void) = 0;
virtual ULONG32 GetSDPLength(void) = 0;
virtual const UINT8* GetSDP(void) = 0;
Index: datatype/mp4/fileformat/pub/qtffplin.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtffplin.h,v
retrieving revision 1.26.4.2
diff -u -w -r1.26.4.2 qtffplin.h
--- datatype/mp4/fileformat/pub/qtffplin.h 18 Feb 2010 21:47:34 -0000 1.26.4.2
+++ datatype/mp4/fileformat/pub/qtffplin.h 24 Mar 2010 19:35:43 -0000
@@ -72,7 +72,7 @@
class CQTOffsetToTimeMapper;
-
+class CTSConverter;
/****************************************************************************
*
@@ -342,13 +342,15 @@
CPacketCache(void)
: pPacket(NULL)
, bPending(FALSE)
- , bStreamDone(FALSE) {;}
+ , bStreamDone(FALSE)
+ , pTSConverter(NULL) {;}
- ~CPacketCache() { HX_RELEASE(pPacket); }
+ ~CPacketCache() { HX_RELEASE(pPacket); HX_DELETE(pTSConverter); }
IHXPacket* pPacket;
HXBOOL bPending;
HXBOOL bStreamDone;
+ CTSConverter* pTSConverter;
};
inline UINT16 GetNextPacketStreamNum(void);
Index: datatype/mp4/fileformat/pub/qtswtrack.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qtswtrack.h,v
retrieving revision 1.4.4.1
diff -u -w -r1.4.4.1 qtswtrack.h
--- datatype/mp4/fileformat/pub/qtswtrack.h 18 Feb 2010 21:47:34 -0000 1.4.4.1
+++ datatype/mp4/fileformat/pub/qtswtrack.h 24 Mar 2010 19:35:43 -0000
@@ -108,6 +108,7 @@
virtual ULONG32 GetTrackWidth(void);
virtual ULONG32 GetTrackHeight(void);
+ virtual UINT32 GetMediaTimeScale(void);
virtual ULONG32 GetSDPLength(void);
virtual const UINT8* GetSDP(void);
Index: datatype/mp4/fileformat/pub/qttrack.h
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/pub/qttrack.h,v
retrieving revision 1.21.4.2
diff -u -w -r1.21.4.2 qttrack.h
--- datatype/mp4/fileformat/pub/qttrack.h 23 Mar 2010 00:47:26 -0000 1.21.4.2
+++ datatype/mp4/fileformat/pub/qttrack.h 24 Mar 2010 19:35:43 -0000
@@ -138,6 +138,10 @@
{
return m_TrackInfo.GetTrackHeight();
}
+ virtual UINT32 GetMediaTimeScale(void)
+ {
+ return m_TrackInfo.GetMediaTimeScale();
+ }
virtual ULONG32 GetSDPLength(void)
{
From jgordon at real.com Wed Mar 24 15:45:52 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Mar 24 22:52:29 2010
Subject: [datatype-dev] Checkin: PR 260179,
others: various issues related to h.264 inter-stream packet ordering
Message-ID: <4BAAA430.8010900@real.com>
Synopsis
========
Fixes PR 260179
Branches: SERVER_14_0, HEAD (SERVER_CURRENT)
Reviewer: chytanya
Description
===========
There are various issues that crop up when the first packet for the
session returned by the file format has a later timestamp (RTP time)
than the first packet of a different stream. Currently, the file
format determines inter-stream packet ordering by delivery time, then
stream number, not considering RTP time.
This happens with most h.264 content from Adobe's encoders, because they
usually start video with an offset composition time (so delivery time is
0, RTP time is ~42ms) while the audio of course has no composition
offsets (thus starting at delivery time 0, RTP time 0). And they stick
the video track in first, so it gets picked first.
This change adds RTP time to the selection criteria, between delivery
time and stream number. So if the delivery times are the same then it
will compare the RTP timestamps and choose the earliest, or if RTP times
are also the same, then the lower stream number wins.
Files Affected
==============
datatype/mp4/fileformat/qtffplin.cpp
datatype/mp4/fileformat/qtswtrack.cpp
datatype/mp4/fileformat/pub/iqttrack.h
datatype/mp4/fileformat/pub/qtffplin.h
datatype/mp4/fileformat/pub/qtswtrack.h
datatype/mp4/fileformat/pub/qttrack.h
Testing Performed
=================
Unit Tests:
Integration Tests:
Verified various playback scenarios with this type of content
Leak Tests:
Performance Tests:
Platforms Tested: win32-i386-vc7, linux-rhel5-i686
Build verified: win32-i386-vc7, linux-rhel5-i686
QA Hints
===============
From qluo at real.com Wed Mar 24 16:58:37 2010
From: qluo at real.com (Qiang Luo)
Date: Thu Mar 25 00:04:46 2010
Subject: [datatype-dev] CR: CPAY-82TEGE: Crash occurs after playing a
3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
In-Reply-To: <0D5D8A0728D4FC43BB0A2393C9AE8F17282DB3AE70@NOK-EUMSG-02.mgdnok.nokia.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F17282DB3AE70@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4BAAB53D.9070002@real.com>
The fix loos good. Please make some cosmetic changes to conform to the
helix coding style:
--use space instead of tabs
--put opening curly brace on a new line
Please merge the fix to hxclient_3_1_0_atlas branch as well.
Thanks,
Qiang
On 3/23/2010 11:21 AM, ext-sudhir.1.mishra@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Junhong.Liu@nokia.com
>
> TSW Id: CPAY-82TEGE
>
> Date: 03/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Crash occurs after playing a 3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
>
> Overview:
> There are two problems with this stream:
> 1) Helix is getting unsupported/invalid NAL units in RTP payload (NAL types 0, 30 or 31) which are getting ignored
> 2) In MTAP payload most of the times data that is coming is corrupted which is causing the panic.
>
> In case of corrupted Multitime aggregate NAL packet ( NAL-Type=26), total payload size shows less then the included NAL size. This causes the computation of the next NAL (MTAP16) size to go wrong, which later causes Buffer size to reset and result in a panic.
>
> Fix:
> In case of invalid/corrupted MTAP NAL, setting the NAL size equal to remaining available buffer size i.e. if the NAL coming is greater than the RTP payload then set it equal to available payload size instead of ignoring it completely, hence neglecting the fillers.
> This will fix the crash but we may get artifacts or the video may stop gracefully at some later stage.
>
> Files modified& changes:
> datatype/mp4/payload/h264pyld.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: h264pyld.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/payload/h264pyld.cpp,v
> retrieving revision 1.4.2.6
> diff -u -w -r1.4.2.6 h264pyld.cpp
> --- h264pyld.cpp 25 Jun 2008 05:33:18 -0000 1.4.2.6
> +++ h264pyld.cpp 23 Mar 2010 12:11:37 -0000
> @@ -1016,6 +1016,12 @@
> else
> {
> UINT32 ulNalSize = ((UINT16)pData[0]<<8) + pData[1];
> + //If the NAL coming is greater than the RTP payload
> + //then set it equal to buff size hence neglect fillers
> + //This is invalid/corrupted MTAP NAL
> + if(ulNalSize> ulBuffSize){
> + ulNalSize = ulBuffSize;
> + }
> offset = 2;
> if (uPacketType == MTAP16)
> {
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
> .
>
>
From jgordon at real.com Wed Mar 24 22:42:05 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Mar 25 05:48:37 2010
Subject: [datatype-dev] CR: h.264 bitrate accuracy and start-up overhead
Message-ID: <4BAB05BD.3010403@real.com>
Synopsis
========
Adds support for the 'btrt' box in the 'avc1' sample entry
Branches: HEAD (SERVER_CURRENT), SERVER_14_0???
Suggested Reviewer: chytanya, anyone
Description
===========
For the few encoders that actually include the 'btrt' box, we
really should use it.
Files Affected
==============
datatype/mp4/fileformat/qtatmmgs.cpp
datatype/mp4/fileformat/pub/qtatmmgs.h
datatype/mp4/fileformat/pub/qtatoms.h
Testing Performed
=================
Unit Tests:
Integration Tests:
* playback, check bitrate and opaque data are correct with HMP11 content
with btrt in the avc1
* playback, check bitrate and opaque data are correct with Envivio
content with btrt in the avc1
* playback, check opaque data is correct with HMP13 content without btrt
* playback, check opaque data is correct with CS4 content without btrt
* playback, check opaque data is correct with AFML content without btrt
and with junk 'skip' atom in the avc1
* playback, check opaque data is correct with Sorenson content without
btrt and with junk 'uuid' atom in the avc1
Leak Tests:
Performance Tests:
Platforms Tested: win32-i386-vc7
Build verified: win32-i386-vc7
QA Hints
===============
spot check mp4ff use cases per encoder and protocol
From psamuel at real.com Thu Mar 25 10:05:25 2010
From: psamuel at real.com (Peter Samuel)
Date: Thu Mar 25 17:11:44 2010
Subject: [datatype-dev] CR : Changes to MP4 filewriter for Linux platform
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07DBB3F4AA@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4filewriter.diff
Type: application/octet-stream
Size: 2978 bytes
Desc: mp4filewriter.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100325/944b4c27/mp4filewriter.obj
From jgordon at real.com Thu Mar 25 12:03:31 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Mar 25 19:09:40 2010
Subject: [datatype-dev] Checkin: h.264 bitrate accuracy and start-up overhead
Message-ID: <4BABC193.5040300@real.com>
Synopsis
========
Adds support for the 'btrt' box in the 'avc1' sample entry
Branches: HEAD (SERVER_CURRENT), SERVER_14_0
Reviewer: chytanya
Description
===========
For the few encoders that actually include the 'btrt' box, we
really should use it.
Files Affected
==============
datatype/mp4/fileformat/qtatmmgs.cpp
datatype/mp4/fileformat/pub/qtatmmgs.h
datatype/mp4/fileformat/pub/qtatoms.h
Testing Performed
=================
Unit Tests:
Integration Tests:
* playback, check bitrate and opaque data are correct with HMP11 content
with btrt in the avc1
* playback, check bitrate and opaque data are correct with Envivio
content with btrt in the avc1
* playback, check opaque data is correct with HMP13 content without btrt
* playback, check opaque data is correct with CS4 content without btrt
* playback, check opaque data is correct with AFML content without btrt
and with junk 'skip' atom in the avc1
* playback, check opaque data is correct with Sorenson content without
btrt and with junk 'uuid' atom in the avc1
Leak Tests:
Performance Tests:
Platforms Tested: win32-i386-vc7
Build verified: win32-i386-vc7
QA Hints
===============
spot check mp4ff use cases per encoder and protocol
From mazimi at real.com Thu Mar 25 12:16:58 2010
From: mazimi at real.com (Mehran Azimi)
Date: Thu Mar 25 19:23:19 2010
Subject: [datatype-dev] FW: Fixed a streaming issue for 3gp hinted files
with QTSS.
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07DBB3F63E@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype-mp4.diff
Type: application/octet-stream
Size: 3230 bytes
Desc: datatype-mp4.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100325/d6cdbfe9/datatype-mp4.obj
From skharkar at real.com Thu Mar 25 12:23:17 2010
From: skharkar at real.com (Sujeet Kharkar)
Date: Thu Mar 25 19:29:50 2010
Subject: [datatype-dev] RE: Changes to MP4 filewriter for Linux platform
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07DBB3F4AA@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA07DBB3F4AA@SEAMBX.corp.real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507DFDFC5B0@SEAMBX.corp.real.com>
Looks good.
--Sujeet
________________________________________
From: Peter Samuel
Sent: Thursday, March 25, 2010 11:05 AM
To: datatype-dev@helixcommunity.org
Subject: CR : Changes to MP4 filewriter for Linux platform
Synopsis
===============================================================
Changes for compiling on Linux platform.
Branches: HEAD
Suggested reviewer: Sujeet
Description
===============================================================
Files Affected
===============================================================
datatype/mp4/filewriter/m4avsh.cpp
datatype/mp4/filewriter/mp4arch.cpp
datatype/mp4/filewriter/mp4atoms.h
datatype/mp4/filewriter/ra10sh.cpp
Testing Performed
===============================================================
Platforms Tested: win32-i386-vc9 , RHEL 5
From psamuel at real.com Thu Mar 25 13:01:24 2010
From: psamuel at real.com (Peter Samuel)
Date: Thu Mar 25 20:08:20 2010
Subject: [datatype-dev] CN : Changes to MP4 filewriter for Linux platform
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07DBB3F6B5@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4filewriter.diff
Type: application/octet-stream
Size: 2978 bytes
Desc: mp4filewriter.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100325/480cf694/mp4filewriter-0001.obj
From sblanding at real.com Thu Mar 25 14:10:23 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 21:17:03 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
Message-ID:
Streaming certain mp4 content from certain helix servers results in dropped frames.
The problem has been traced to issues around 3GPP-Adaptation-Support.
There has been code checked in to the head to deal with this for a while now but that code was never migrated into the RP codebase.
Furthermore, while porting the code from the Head to the RP codebase I discovered that there is a pretty serious flaw in the HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against parameters that have values which overflow their allotted bit counts. While testing this fix I discovered that the build version of the helix server was large enough to overflow its bits, thereby bumping up the release bit fields. The result is that something like the following statement would have returned true:
HX_ENCODE_PROD_VERSION(1,1,1,5000) > HX_ENCODE_PROD_VERSION(1,1,2,0)
To fix this, I've modified the macro to throw out overflow bits. This isn't a perfect fix but it's no worse than the current behavior and it should be sufficient for the way we use the macro.
Here's the diff:
Index: hxtypes.h
===================================================================
RCS file: /cvsroot/common/include/hxtypes.h,v
retrieving revision 1.24.4.6.2.1
diff -u -w -r1.24.4.6.2.1 hxtypes.h
--- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
+++ hxtypes.h 25 Mar 2010 21:58:04 -0000
@@ -690,8 +690,8 @@
*/
#define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
- ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
- ((ULONG32)release << 12) | (ULONG32)build)
+ ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) | (((ULONG32)0xF & (ULONG32)minor) << 20) | \
+ (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF & (ULONG32)build))
#define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) | (ULONG32)(ulprivate) )
Index: rateadaptinfo.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
retrieving revision 1.5.2.11.2.2
diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
--- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000 1.5.2.11.2.2
+++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
@@ -490,8 +490,8 @@
hdrType = ahtHelix;
}
else if (m_pNADU &&
- HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
- ulReportFreq))
+ (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
+ ulReportFreq)) && (ulReportFreq == 1))
{
hdrType = aht3GPP;
}
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.148.2.51.2.9
diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
--- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
+++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
@@ -10495,7 +10495,8 @@
if (m_pRateAdaptInfo)
{
UINT32 ulHelixAdaptation = 0;
- UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
+ UINT32 ul3GPPRateAdaptation = 0;
+ UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
//
// due to a bug in released Helix Server, the client needs to disable "Helix-Adaption"
@@ -10503,12 +10504,16 @@
//
// see https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
//
- if ((m_ulServerVersion < ulVersionTarget) &&
+ if (IsRealServer() && (m_ulServerVersion < ulVersionTarget) &&
HXR_OK == ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
ulHelixAdaptation) &&
(1 == ulHelixAdaptation))
{
+ HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP() Disabling RateAdaptation", this);
+
+ // switch off both rate adaptation
ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
+ ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
}
m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
ppRealHeaders[i]);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100325/e9d74894/attachment.html
From jgordon at real.com Thu Mar 25 14:29:50 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Mar 25 21:36:11 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in
RP
In-Reply-To:
References:
Message-ID: <4BABE3DE.7010904@real.com>
> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) && (ulReportFreq == 1))
I'm not sure the precise context of this code, but checking ==1 is
surely not right. The field is an integer report frequency, not a 0/1
boolean. If that is just checking there whether it should use
3gpp-adaptation at all, it should check != 0.
On 3/25/2010 3:10 PM, Steve Blanding wrote:
> Streaming certain mp4 content from certain helix servers results in
> dropped frames.
>
> The problem has been traced to issues around 3GPP-Adaptation-Support.
>
> There has been code checked in to the head to deal with this for a while
> now but that code was never migrated into the RP codebase.
>
> Furthermore, while porting the code from the Head to the RP codebase I
> discovered that there is a pretty serious flaw in the
> HX_ENCODE_PROD_VERSION macro. Namely that we don?t guard against
> parameters that have values which overflow their allotted bit counts.
> While testing this fix I discovered that the build version of the helix
> server was large enough to overflow its bits, thereby bumping up the
> release bit fields. The result is that something like the following
> statement would have returned true:
>
> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
> HX_ENCODE_PROD_VERSION(1,1,2,0)
>
> To fix this, I?ve modified the macro to throw out overflow bits. This
> isn?t a perfect fix but it?s no worse than the current behavior and it
> should be sufficient for the way we use the macro.
>
>
>
> Here?s the diff:
>
>
>
> Index: hxtypes.h
>
> ===================================================================
>
> RCS file: /cvsroot/common/include/hxtypes.h,v
>
> retrieving revision 1.24.4.6.2.1
>
> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>
> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>
> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>
> @@ -690,8 +690,8 @@
>
> */
>
>
>
> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>
> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>
> - ((ULONG32)release << 12) | (ULONG32)build)
>
> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>
> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
> & (ULONG32)build))
>
>
>
> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>
>
> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
> (ULONG32)(ulprivate) )
>
> Index: rateadaptinfo.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>
> retrieving revision 1.5.2.11.2.2
>
> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>
> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
> 1.5.2.11.2.2
>
> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -490,8 +490,8 @@
>
> hdrType = ahtHelix;
>
> }
>
> else if (m_pNADU &&
>
> - HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> - ulReportFreq))
>
> + (HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) &&
> (ulReportFreq == 1))
>
> {
>
> hdrType = aht3GPP;
>
> }
>
> Index: rtspclnt.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>
> retrieving revision 1.148.2.51.2.9
>
> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>
> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>
> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -10495,7 +10495,8 @@
>
> if (m_pRateAdaptInfo)
>
> {
>
> UINT32 ulHelixAdaptation = 0;
>
> - UINT32 ulVersionTarget =
> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>
> + UINT32 ul3GPPRateAdaptation = 0;
>
> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>
>
>
> //
>
> // due to a bug in released Helix
> Server, the client needs to disable "Helix-Adaption"
>
> @@ -10503,12 +10504,16 @@
>
> //
>
> // see
> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>
> //
>
> - if ((m_ulServerVersion < ulVersionTarget) &&
>
> + if (IsRealServer() && (m_ulServerVersion <
> ulVersionTarget) &&
>
> HXR_OK ==
> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>
>
> ulHelixAdaptation) &&
>
> (1 == ulHelixAdaptation))
>
> {
>
> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
> Disabling RateAdaptation", this);
>
> +
>
> + // switch off both rate adaptation
>
>
> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>
> +
> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>
> }
>
> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>
> ppRealHeaders[i]);
>
From sblanding at real.com Thu Mar 25 14:34:19 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 21:40:55 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
In-Reply-To: <4BABE3DE.7010904@real.com>
References:
<4BABE3DE.7010904@real.com>
Message-ID:
That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
-----Original Message-----
From: Jamie Gordon
Sent: Thursday, March 25, 2010 3:30 PM
To: Steve Blanding
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) && (ulReportFreq == 1))
I'm not sure the precise context of this code, but checking ==1 is
surely not right. The field is an integer report frequency, not a 0/1
boolean. If that is just checking there whether it should use
3gpp-adaptation at all, it should check != 0.
On 3/25/2010 3:10 PM, Steve Blanding wrote:
> Streaming certain mp4 content from certain helix servers results in
> dropped frames.
>
> The problem has been traced to issues around 3GPP-Adaptation-Support.
>
> There has been code checked in to the head to deal with this for a while
> now but that code was never migrated into the RP codebase.
>
> Furthermore, while porting the code from the Head to the RP codebase I
> discovered that there is a pretty serious flaw in the
> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
> parameters that have values which overflow their allotted bit counts.
> While testing this fix I discovered that the build version of the helix
> server was large enough to overflow its bits, thereby bumping up the
> release bit fields. The result is that something like the following
> statement would have returned true:
>
> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
> HX_ENCODE_PROD_VERSION(1,1,2,0)
>
> To fix this, I've modified the macro to throw out overflow bits. This
> isn't a perfect fix but it's no worse than the current behavior and it
> should be sufficient for the way we use the macro.
>
>
>
> Here's the diff:
>
>
>
> Index: hxtypes.h
>
> ===================================================================
>
> RCS file: /cvsroot/common/include/hxtypes.h,v
>
> retrieving revision 1.24.4.6.2.1
>
> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>
> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>
> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>
> @@ -690,8 +690,8 @@
>
> */
>
>
>
> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>
> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>
> - ((ULONG32)release << 12) | (ULONG32)build)
>
> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>
> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
> & (ULONG32)build))
>
>
>
> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>
>
> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
> (ULONG32)(ulprivate) )
>
> Index: rateadaptinfo.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>
> retrieving revision 1.5.2.11.2.2
>
> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>
> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
> 1.5.2.11.2.2
>
> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -490,8 +490,8 @@
>
> hdrType = ahtHelix;
>
> }
>
> else if (m_pNADU &&
>
> - HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> - ulReportFreq))
>
> + (HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) &&
> (ulReportFreq == 1))
>
> {
>
> hdrType = aht3GPP;
>
> }
>
> Index: rtspclnt.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>
> retrieving revision 1.148.2.51.2.9
>
> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>
> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>
> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -10495,7 +10495,8 @@
>
> if (m_pRateAdaptInfo)
>
> {
>
> UINT32 ulHelixAdaptation = 0;
>
> - UINT32 ulVersionTarget =
> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>
> + UINT32 ul3GPPRateAdaptation = 0;
>
> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>
>
>
> //
>
> // due to a bug in released Helix
> Server, the client needs to disable "Helix-Adaption"
>
> @@ -10503,12 +10504,16 @@
>
> //
>
> // see
> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>
> //
>
> - if ((m_ulServerVersion < ulVersionTarget) &&
>
> + if (IsRealServer() && (m_ulServerVersion <
> ulVersionTarget) &&
>
> HXR_OK ==
> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>
>
> ulHelixAdaptation) &&
>
> (1 == ulHelixAdaptation))
>
> {
>
> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
> Disabling RateAdaptation", this);
>
> +
>
> + // switch off both rate adaptation
>
>
> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>
> +
> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>
> }
>
> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>
> ppRealHeaders[i]);
>
From sblanding at real.com Thu Mar 25 15:27:35 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 22:34:27 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
In-Reply-To:
References:
<4BABE3DE.7010904@real.com>
Message-ID:
Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
-----Original Message-----
From: Steve Blanding
Sent: Thursday, March 25, 2010 3:34 PM
To: Jamie Gordon
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
-----Original Message-----
From: Jamie Gordon
Sent: Thursday, March 25, 2010 3:30 PM
To: Steve Blanding
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) && (ulReportFreq == 1))
I'm not sure the precise context of this code, but checking ==1 is
surely not right. The field is an integer report frequency, not a 0/1
boolean. If that is just checking there whether it should use
3gpp-adaptation at all, it should check != 0.
On 3/25/2010 3:10 PM, Steve Blanding wrote:
> Streaming certain mp4 content from certain helix servers results in
> dropped frames.
>
> The problem has been traced to issues around 3GPP-Adaptation-Support.
>
> There has been code checked in to the head to deal with this for a while
> now but that code was never migrated into the RP codebase.
>
> Furthermore, while porting the code from the Head to the RP codebase I
> discovered that there is a pretty serious flaw in the
> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
> parameters that have values which overflow their allotted bit counts.
> While testing this fix I discovered that the build version of the helix
> server was large enough to overflow its bits, thereby bumping up the
> release bit fields. The result is that something like the following
> statement would have returned true:
>
> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
> HX_ENCODE_PROD_VERSION(1,1,2,0)
>
> To fix this, I've modified the macro to throw out overflow bits. This
> isn't a perfect fix but it's no worse than the current behavior and it
> should be sufficient for the way we use the macro.
>
>
>
> Here's the diff:
>
>
>
> Index: hxtypes.h
>
> ===================================================================
>
> RCS file: /cvsroot/common/include/hxtypes.h,v
>
> retrieving revision 1.24.4.6.2.1
>
> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>
> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>
> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>
> @@ -690,8 +690,8 @@
>
> */
>
>
>
> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>
> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>
> - ((ULONG32)release << 12) | (ULONG32)build)
>
> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>
> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
> & (ULONG32)build))
>
>
>
> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>
>
> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
> (ULONG32)(ulprivate) )
>
> Index: rateadaptinfo.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>
> retrieving revision 1.5.2.11.2.2
>
> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>
> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
> 1.5.2.11.2.2
>
> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -490,8 +490,8 @@
>
> hdrType = ahtHelix;
>
> }
>
> else if (m_pNADU &&
>
> - HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> - ulReportFreq))
>
> + (HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) &&
> (ulReportFreq == 1))
>
> {
>
> hdrType = aht3GPP;
>
> }
>
> Index: rtspclnt.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>
> retrieving revision 1.148.2.51.2.9
>
> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>
> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>
> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -10495,7 +10495,8 @@
>
> if (m_pRateAdaptInfo)
>
> {
>
> UINT32 ulHelixAdaptation = 0;
>
> - UINT32 ulVersionTarget =
> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>
> + UINT32 ul3GPPRateAdaptation = 0;
>
> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>
>
>
> //
>
> // due to a bug in released Helix
> Server, the client needs to disable "Helix-Adaption"
>
> @@ -10503,12 +10504,16 @@
>
> //
>
> // see
> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>
> //
>
> - if ((m_ulServerVersion < ulVersionTarget) &&
>
> + if (IsRealServer() && (m_ulServerVersion <
> ulVersionTarget) &&
>
> HXR_OK ==
> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>
>
> ulHelixAdaptation) &&
>
> (1 == ulHelixAdaptation))
>
> {
>
> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
> Disabling RateAdaptation", this);
>
> +
>
> + // switch off both rate adaptation
>
>
> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>
> +
> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>
> }
>
> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>
> ppRealHeaders[i]);
>
From sblanding at real.com Thu Mar 25 15:28:50 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 22:35:46 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
References:
<4BABE3DE.7010904@real.com>
Message-ID:
Yes. I meant ulReportFreq.
-----Original Message-----
From: Steve Blanding
Sent: Thursday, March 25, 2010 4:28 PM
To: Jamie Gordon
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
-----Original Message-----
From: Steve Blanding
Sent: Thursday, March 25, 2010 3:34 PM
To: Jamie Gordon
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
-----Original Message-----
From: Jamie Gordon
Sent: Thursday, March 25, 2010 3:30 PM
To: Steve Blanding
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) && (ulReportFreq == 1))
I'm not sure the precise context of this code, but checking ==1 is
surely not right. The field is an integer report frequency, not a 0/1
boolean. If that is just checking there whether it should use
3gpp-adaptation at all, it should check != 0.
On 3/25/2010 3:10 PM, Steve Blanding wrote:
> Streaming certain mp4 content from certain helix servers results in
> dropped frames.
>
> The problem has been traced to issues around 3GPP-Adaptation-Support.
>
> There has been code checked in to the head to deal with this for a while
> now but that code was never migrated into the RP codebase.
>
> Furthermore, while porting the code from the Head to the RP codebase I
> discovered that there is a pretty serious flaw in the
> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
> parameters that have values which overflow their allotted bit counts.
> While testing this fix I discovered that the build version of the helix
> server was large enough to overflow its bits, thereby bumping up the
> release bit fields. The result is that something like the following
> statement would have returned true:
>
> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
> HX_ENCODE_PROD_VERSION(1,1,2,0)
>
> To fix this, I've modified the macro to throw out overflow bits. This
> isn't a perfect fix but it's no worse than the current behavior and it
> should be sufficient for the way we use the macro.
>
>
>
> Here's the diff:
>
>
>
> Index: hxtypes.h
>
> ===================================================================
>
> RCS file: /cvsroot/common/include/hxtypes.h,v
>
> retrieving revision 1.24.4.6.2.1
>
> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>
> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>
> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>
> @@ -690,8 +690,8 @@
>
> */
>
>
>
> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>
> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>
> - ((ULONG32)release << 12) | (ULONG32)build)
>
> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>
> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
> & (ULONG32)build))
>
>
>
> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>
>
> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
> (ULONG32)(ulprivate) )
>
> Index: rateadaptinfo.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>
> retrieving revision 1.5.2.11.2.2
>
> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>
> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
> 1.5.2.11.2.2
>
> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -490,8 +490,8 @@
>
> hdrType = ahtHelix;
>
> }
>
> else if (m_pNADU &&
>
> - HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> - ulReportFreq))
>
> + (HXR_OK ==
> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>
> + ulReportFreq)) &&
> (ulReportFreq == 1))
>
> {
>
> hdrType = aht3GPP;
>
> }
>
> Index: rtspclnt.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>
> retrieving revision 1.148.2.51.2.9
>
> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>
> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>
> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>
> @@ -10495,7 +10495,8 @@
>
> if (m_pRateAdaptInfo)
>
> {
>
> UINT32 ulHelixAdaptation = 0;
>
> - UINT32 ulVersionTarget =
> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>
> + UINT32 ul3GPPRateAdaptation = 0;
>
> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>
>
>
> //
>
> // due to a bug in released Helix
> Server, the client needs to disable "Helix-Adaption"
>
> @@ -10503,12 +10504,16 @@
>
> //
>
> // see
> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>
> //
>
> - if ((m_ulServerVersion < ulVersionTarget) &&
>
> + if (IsRealServer() && (m_ulServerVersion <
> ulVersionTarget) &&
>
> HXR_OK ==
> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>
>
> ulHelixAdaptation) &&
>
> (1 == ulHelixAdaptation))
>
> {
>
> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
> Disabling RateAdaptation", this);
>
> +
>
> + // switch off both rate adaptation
>
>
> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>
> +
> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>
> }
>
> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>
> ppRealHeaders[i]);
>
From jgordon at real.com Thu Mar 25 15:37:10 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Mar 25 22:43:30 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in
RP
In-Reply-To:
References:
<4BABE3DE.7010904@real.com>
Message-ID: <4BABF3A6.3080303@real.com>
hmmmm the SDP variable is definitely supposed to be an integer
frequency, not a boolean, and will often have a value other
than 0 or 1!
On 3/25/2010 4:28 PM, Steve Blanding wrote:
> Yes. I meant ulReportFreq.
>
> -----Original Message-----
> From: Steve Blanding
> Sent: Thursday, March 25, 2010 4:28 PM
> To: Jamie Gordon
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
> Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
>
> -----Original Message-----
> From: Steve Blanding
> Sent: Thursday, March 25, 2010 3:34 PM
> To: Jamie Gordon
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
> That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
>
> -----Original Message-----
> From: Jamie Gordon
> Sent: Thursday, March 25, 2010 3:30 PM
> To: Steve Blanding
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
>> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> + ulReportFreq)) && (ulReportFreq == 1))
>
> I'm not sure the precise context of this code, but checking ==1 is
> surely not right. The field is an integer report frequency, not a 0/1
> boolean. If that is just checking there whether it should use
> 3gpp-adaptation at all, it should check != 0.
>
> On 3/25/2010 3:10 PM, Steve Blanding wrote:
>> Streaming certain mp4 content from certain helix servers results in
>> dropped frames.
>>
>> The problem has been traced to issues around 3GPP-Adaptation-Support.
>>
>> There has been code checked in to the head to deal with this for a while
>> now but that code was never migrated into the RP codebase.
>>
>> Furthermore, while porting the code from the Head to the RP codebase I
>> discovered that there is a pretty serious flaw in the
>> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
>> parameters that have values which overflow their allotted bit counts.
>> While testing this fix I discovered that the build version of the helix
>> server was large enough to overflow its bits, thereby bumping up the
>> release bit fields. The result is that something like the following
>> statement would have returned true:
>>
>> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
>> HX_ENCODE_PROD_VERSION(1,1,2,0)
>>
>> To fix this, I've modified the macro to throw out overflow bits. This
>> isn't a perfect fix but it's no worse than the current behavior and it
>> should be sufficient for the way we use the macro.
>>
>>
>>
>> Here's the diff:
>>
>>
>>
>> Index: hxtypes.h
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/common/include/hxtypes.h,v
>>
>> retrieving revision 1.24.4.6.2.1
>>
>> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>>
>> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>>
>> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>>
>> @@ -690,8 +690,8 @@
>>
>> */
>>
>>
>>
>> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>>
>> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>>
>> - ((ULONG32)release << 12) | (ULONG32)build)
>>
>> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
>> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>>
>> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
>> & (ULONG32)build))
>>
>>
>>
>> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>>
>>
>> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
>> (ULONG32)(ulprivate) )
>>
>> Index: rateadaptinfo.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>>
>> retrieving revision 1.5.2.11.2.2
>>
>> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>>
>> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
>> 1.5.2.11.2.2
>>
>> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>>
>> @@ -490,8 +490,8 @@
>>
>> hdrType = ahtHelix;
>>
>> }
>>
>> else if (m_pNADU &&
>>
>> - HXR_OK ==
>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> - ulReportFreq))
>>
>> + (HXR_OK ==
>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> + ulReportFreq)) &&
>> (ulReportFreq == 1))
>>
>> {
>>
>> hdrType = aht3GPP;
>>
>> }
>>
>> Index: rtspclnt.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>>
>> retrieving revision 1.148.2.51.2.9
>>
>> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>>
>> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>>
>> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>>
>> @@ -10495,7 +10495,8 @@
>>
>> if (m_pRateAdaptInfo)
>>
>> {
>>
>> UINT32 ulHelixAdaptation = 0;
>>
>> - UINT32 ulVersionTarget =
>> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>>
>> + UINT32 ul3GPPRateAdaptation = 0;
>>
>> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>>
>>
>>
>> //
>>
>> // due to a bug in released Helix
>> Server, the client needs to disable "Helix-Adaption"
>>
>> @@ -10503,12 +10504,16 @@
>>
>> //
>>
>> // see
>> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>>
>> //
>>
>> - if ((m_ulServerVersion < ulVersionTarget) &&
>>
>> + if (IsRealServer() && (m_ulServerVersion <
>> ulVersionTarget) &&
>>
>> HXR_OK ==
>> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>>
>>
>> ulHelixAdaptation) &&
>>
>> (1 == ulHelixAdaptation))
>>
>> {
>>
>> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
>> Disabling RateAdaptation", this);
>>
>> +
>>
>> + // switch off both rate adaptation
>>
>>
>> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>>
>> +
>> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>>
>> }
>>
>> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>>
>> ppRealHeaders[i]);
>>
From sblanding at real.com Thu Mar 25 15:43:55 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 22:50:27 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
In-Reply-To: <4BABF3A6.3080303@real.com>
References:
<4BABE3DE.7010904@real.com>
<4BABF3A6.3080303@real.com>
Message-ID:
It could very easily be incorrect on the head.
-----Original Message-----
From: Jamie Gordon
Sent: Thursday, March 25, 2010 4:37 PM
To: Steve Blanding
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
hmmmm the SDP variable is definitely supposed to be an integer
frequency, not a boolean, and will often have a value other
than 0 or 1!
On 3/25/2010 4:28 PM, Steve Blanding wrote:
> Yes. I meant ulReportFreq.
>
> -----Original Message-----
> From: Steve Blanding
> Sent: Thursday, March 25, 2010 4:28 PM
> To: Jamie Gordon
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
> Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
>
> -----Original Message-----
> From: Steve Blanding
> Sent: Thursday, March 25, 2010 3:34 PM
> To: Jamie Gordon
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
> That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
>
> -----Original Message-----
> From: Jamie Gordon
> Sent: Thursday, March 25, 2010 3:30 PM
> To: Steve Blanding
> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>
>> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> + ulReportFreq)) && (ulReportFreq == 1))
>
> I'm not sure the precise context of this code, but checking ==1 is
> surely not right. The field is an integer report frequency, not a 0/1
> boolean. If that is just checking there whether it should use
> 3gpp-adaptation at all, it should check != 0.
>
> On 3/25/2010 3:10 PM, Steve Blanding wrote:
>> Streaming certain mp4 content from certain helix servers results in
>> dropped frames.
>>
>> The problem has been traced to issues around 3GPP-Adaptation-Support.
>>
>> There has been code checked in to the head to deal with this for a while
>> now but that code was never migrated into the RP codebase.
>>
>> Furthermore, while porting the code from the Head to the RP codebase I
>> discovered that there is a pretty serious flaw in the
>> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
>> parameters that have values which overflow their allotted bit counts.
>> While testing this fix I discovered that the build version of the helix
>> server was large enough to overflow its bits, thereby bumping up the
>> release bit fields. The result is that something like the following
>> statement would have returned true:
>>
>> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
>> HX_ENCODE_PROD_VERSION(1,1,2,0)
>>
>> To fix this, I've modified the macro to throw out overflow bits. This
>> isn't a perfect fix but it's no worse than the current behavior and it
>> should be sufficient for the way we use the macro.
>>
>>
>>
>> Here's the diff:
>>
>>
>>
>> Index: hxtypes.h
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/common/include/hxtypes.h,v
>>
>> retrieving revision 1.24.4.6.2.1
>>
>> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>>
>> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>>
>> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>>
>> @@ -690,8 +690,8 @@
>>
>> */
>>
>>
>>
>> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>>
>> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>>
>> - ((ULONG32)release << 12) | (ULONG32)build)
>>
>> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
>> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>>
>> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
>> & (ULONG32)build))
>>
>>
>>
>> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>>
>>
>> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
>> (ULONG32)(ulprivate) )
>>
>> Index: rateadaptinfo.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>>
>> retrieving revision 1.5.2.11.2.2
>>
>> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>>
>> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
>> 1.5.2.11.2.2
>>
>> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>>
>> @@ -490,8 +490,8 @@
>>
>> hdrType = ahtHelix;
>>
>> }
>>
>> else if (m_pNADU &&
>>
>> - HXR_OK ==
>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> - ulReportFreq))
>>
>> + (HXR_OK ==
>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>
>> + ulReportFreq)) &&
>> (ulReportFreq == 1))
>>
>> {
>>
>> hdrType = aht3GPP;
>>
>> }
>>
>> Index: rtspclnt.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>>
>> retrieving revision 1.148.2.51.2.9
>>
>> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>>
>> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>>
>> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>>
>> @@ -10495,7 +10495,8 @@
>>
>> if (m_pRateAdaptInfo)
>>
>> {
>>
>> UINT32 ulHelixAdaptation = 0;
>>
>> - UINT32 ulVersionTarget =
>> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>>
>> + UINT32 ul3GPPRateAdaptation = 0;
>>
>> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>>
>>
>>
>> //
>>
>> // due to a bug in released Helix
>> Server, the client needs to disable "Helix-Adaption"
>>
>> @@ -10503,12 +10504,16 @@
>>
>> //
>>
>> // see
>> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>>
>> //
>>
>> - if ((m_ulServerVersion < ulVersionTarget) &&
>>
>> + if (IsRealServer() && (m_ulServerVersion <
>> ulVersionTarget) &&
>>
>> HXR_OK ==
>> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>>
>>
>> ulHelixAdaptation) &&
>>
>> (1 == ulHelixAdaptation))
>>
>> {
>>
>> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
>> Disabling RateAdaptation", this);
>>
>> +
>>
>> + // switch off both rate adaptation
>>
>>
>> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>>
>> +
>> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>>
>> }
>>
>> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>>
>> ppRealHeaders[i]);
>>
From jgordon at real.com Thu Mar 25 15:45:40 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Mar 25 22:52:01 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in
RP
In-Reply-To: <4BABF3A6.3080303@real.com>
References:
<4BABE3DE.7010904@real.com>
<4BABF3A6.3080303@real.com>
Message-ID: <4BABF5A4.9060108@real.com>
Actually the head does not have check for == 1, it checks != 0.
Maybe you are mixing it up with "Helix-Adaptation-Support" which
is a boolean header and is checked for == 1 on the head.
On 3/25/2010 4:37 PM, Jamie Gordon wrote:
> hmmmm the SDP variable is definitely supposed to be an integer
> frequency, not a boolean, and will often have a value other
> than 0 or 1!
>
> On 3/25/2010 4:28 PM, Steve Blanding wrote:
>> Yes. I meant ulReportFreq.
>>
>> -----Original Message-----
>> From: Steve Blanding
>> Sent: Thursday, March 25, 2010 4:28 PM
>> To: Jamie Gordon
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>> Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
>>
>> -----Original Message-----
>> From: Steve Blanding
>> Sent: Thursday, March 25, 2010 3:34 PM
>> To: Jamie Gordon
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>> That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
>>
>> -----Original Message-----
>> From: Jamie Gordon
>> Sent: Thursday, March 25, 2010 3:30 PM
>> To: Steve Blanding
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>>> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> + ulReportFreq)) && (ulReportFreq == 1))
>> I'm not sure the precise context of this code, but checking ==1 is
>> surely not right. The field is an integer report frequency, not a 0/1
>> boolean. If that is just checking there whether it should use
>> 3gpp-adaptation at all, it should check != 0.
>>
>> On 3/25/2010 3:10 PM, Steve Blanding wrote:
>>> Streaming certain mp4 content from certain helix servers results in
>>> dropped frames.
>>>
>>> The problem has been traced to issues around 3GPP-Adaptation-Support.
>>>
>>> There has been code checked in to the head to deal with this for a while
>>> now but that code was never migrated into the RP codebase.
>>>
>>> Furthermore, while porting the code from the Head to the RP codebase I
>>> discovered that there is a pretty serious flaw in the
>>> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
>>> parameters that have values which overflow their allotted bit counts.
>>> While testing this fix I discovered that the build version of the helix
>>> server was large enough to overflow its bits, thereby bumping up the
>>> release bit fields. The result is that something like the following
>>> statement would have returned true:
>>>
>>> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
>>> HX_ENCODE_PROD_VERSION(1,1,2,0)
>>>
>>> To fix this, I've modified the macro to throw out overflow bits. This
>>> isn't a perfect fix but it's no worse than the current behavior and it
>>> should be sufficient for the way we use the macro.
>>>
>>>
>>>
>>> Here's the diff:
>>>
>>>
>>>
>>> Index: hxtypes.h
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/common/include/hxtypes.h,v
>>>
>>> retrieving revision 1.24.4.6.2.1
>>>
>>> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>>>
>>> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>>>
>>> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>>>
>>> @@ -690,8 +690,8 @@
>>>
>>> */
>>>
>>>
>>>
>>> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>>>
>>> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>>>
>>> - ((ULONG32)release << 12) | (ULONG32)build)
>>>
>>> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
>>> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>>>
>>> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
>>> & (ULONG32)build))
>>>
>>>
>>>
>>> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>>>
>>>
>>> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
>>> (ULONG32)(ulprivate) )
>>>
>>> Index: rateadaptinfo.cpp
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>>>
>>> retrieving revision 1.5.2.11.2.2
>>>
>>> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>>>
>>> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
>>> 1.5.2.11.2.2
>>>
>>> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>>>
>>> @@ -490,8 +490,8 @@
>>>
>>> hdrType = ahtHelix;
>>>
>>> }
>>>
>>> else if (m_pNADU &&
>>>
>>> - HXR_OK ==
>>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> - ulReportFreq))
>>>
>>> + (HXR_OK ==
>>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> + ulReportFreq)) &&
>>> (ulReportFreq == 1))
>>>
>>> {
>>>
>>> hdrType = aht3GPP;
>>>
>>> }
>>>
>>> Index: rtspclnt.cpp
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>>>
>>> retrieving revision 1.148.2.51.2.9
>>>
>>> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>>>
>>> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>>>
>>> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>>>
>>> @@ -10495,7 +10495,8 @@
>>>
>>> if (m_pRateAdaptInfo)
>>>
>>> {
>>>
>>> UINT32 ulHelixAdaptation = 0;
>>>
>>> - UINT32 ulVersionTarget =
>>> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>>>
>>> + UINT32 ul3GPPRateAdaptation = 0;
>>>
>>> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>>>
>>>
>>>
>>> //
>>>
>>> // due to a bug in released Helix
>>> Server, the client needs to disable "Helix-Adaption"
>>>
>>> @@ -10503,12 +10504,16 @@
>>>
>>> //
>>>
>>> // see
>>> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>>>
>>> //
>>>
>>> - if ((m_ulServerVersion < ulVersionTarget) &&
>>>
>>> + if (IsRealServer() && (m_ulServerVersion <
>>> ulVersionTarget) &&
>>>
>>> HXR_OK ==
>>> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>>>
>>>
>>> ulHelixAdaptation) &&
>>>
>>> (1 == ulHelixAdaptation))
>>>
>>> {
>>>
>>> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
>>> Disabling RateAdaptation", this);
>>>
>>> +
>>>
>>> + // switch off both rate adaptation
>>>
>>>
>>> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>>>
>>> +
>>> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>>>
>>> }
>>>
>>> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>>>
>>> ppRealHeaders[i]);
>>>
>
>
From sblanding at real.com Thu Mar 25 15:46:36 2010
From: sblanding at real.com (Steve Blanding)
Date: Thu Mar 25 22:58:12 2010
Subject: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
In-Reply-To: <4BABF5A4.9060108@real.com>
References:
<4BABE3DE.7010904@real.com>
<4BABF3A6.3080303@real.com> <4BABF5A4.9060108@real.com>
Message-ID:
Very probably. Thanks for double checking. I've got it != 0 in my code now and as soon as I've verified it that way I'll check it in.
-----Original Message-----
From: Jamie Gordon
Sent: Thursday, March 25, 2010 4:46 PM
To: Steve Blanding
Cc: player-dev@real.com; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
Actually the head does not have check for == 1, it checks != 0.
Maybe you are mixing it up with "Helix-Adaptation-Support" which
is a boolean header and is checked for == 1 on the head.
On 3/25/2010 4:37 PM, Jamie Gordon wrote:
> hmmmm the SDP variable is definitely supposed to be an integer
> frequency, not a boolean, and will often have a value other
> than 0 or 1!
>
> On 3/25/2010 4:28 PM, Steve Blanding wrote:
>> Yes. I meant ulReportFreq.
>>
>> -----Original Message-----
>> From: Steve Blanding
>> Sent: Thursday, March 25, 2010 4:28 PM
>> To: Jamie Gordon
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>> Actually, upon further review, the code is correct. ulHelixAdaptation is not treated as a Boolean. It's a unsigned long (hence the ul) and it's explicitly set to 1 earlier in the code. Perhaps it _should_ be a boolean but it clearly isn't.
>>
>> -----Original Message-----
>> From: Steve Blanding
>> Sent: Thursday, March 25, 2010 3:34 PM
>> To: Jamie Gordon
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: RE: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>> That part of the code was migrated over from the Head but you're right. Checking != 0 would be more correct. It ought to be changed on the Head too.
>>
>> -----Original Message-----
>> From: Jamie Gordon
>> Sent: Thursday, March 25, 2010 3:30 PM
>> To: Steve Blanding
>> Cc: player-dev@real.com; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] 258751: Fix streaming of certain mp4 files in RP
>>
>>> + (HXR_OK == pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> + ulReportFreq)) && (ulReportFreq == 1))
>> I'm not sure the precise context of this code, but checking ==1 is
>> surely not right. The field is an integer report frequency, not a 0/1
>> boolean. If that is just checking there whether it should use
>> 3gpp-adaptation at all, it should check != 0.
>>
>> On 3/25/2010 3:10 PM, Steve Blanding wrote:
>>> Streaming certain mp4 content from certain helix servers results in
>>> dropped frames.
>>>
>>> The problem has been traced to issues around 3GPP-Adaptation-Support.
>>>
>>> There has been code checked in to the head to deal with this for a while
>>> now but that code was never migrated into the RP codebase.
>>>
>>> Furthermore, while porting the code from the Head to the RP codebase I
>>> discovered that there is a pretty serious flaw in the
>>> HX_ENCODE_PROD_VERSION macro. Namely that we don't guard against
>>> parameters that have values which overflow their allotted bit counts.
>>> While testing this fix I discovered that the build version of the helix
>>> server was large enough to overflow its bits, thereby bumping up the
>>> release bit fields. The result is that something like the following
>>> statement would have returned true:
>>>
>>> HX_ENCODE_PROD_VERSION(1,1,1,5000) >
>>> HX_ENCODE_PROD_VERSION(1,1,2,0)
>>>
>>> To fix this, I've modified the macro to throw out overflow bits. This
>>> isn't a perfect fix but it's no worse than the current behavior and it
>>> should be sufficient for the way we use the macro.
>>>
>>>
>>>
>>> Here's the diff:
>>>
>>>
>>>
>>> Index: hxtypes.h
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/common/include/hxtypes.h,v
>>>
>>> retrieving revision 1.24.4.6.2.1
>>>
>>> diff -u -w -r1.24.4.6.2.1 hxtypes.h
>>>
>>> --- hxtypes.h 29 Sep 2008 18:12:47 -0000 1.24.4.6.2.1
>>>
>>> +++ hxtypes.h 25 Mar 2010 21:58:04 -0000
>>>
>>> @@ -690,8 +690,8 @@
>>>
>>> */
>>>
>>>
>>>
>>> #define HX_ENCODE_PROD_VERSION(major,minor,release,build) \
>>>
>>> - ((ULONG32)((ULONG32)major << 28) | ((ULONG32)minor << 20) | \
>>>
>>> - ((ULONG32)release << 12) | (ULONG32)build)
>>>
>>> + ((ULONG32)(((ULONG32)0x7 & (ULONG32)major) << 28) |
>>> (((ULONG32)0xF & (ULONG32)minor) << 20) | \
>>>
>>> + (((ULONG32)0xF & (ULONG32)release) << 12) | ((ULONG32)0xFFF
>>> & (ULONG32)build))
>>>
>>>
>>>
>>> #define HX_ENCODE_ADD_PRIVATE_FIELD(ulversion,ulprivate) \
>>>
>>>
>>> ((ULONG32)((ULONG32)(ulversion) & (UINT32)0xFFFFFF00) |
>>> (ULONG32)(ulprivate) )
>>>
>>> Index: rateadaptinfo.cpp
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/protocol/rtsp/rateadaptinfo.cpp,v
>>>
>>> retrieving revision 1.5.2.11.2.2
>>>
>>> diff -u -w -r1.5.2.11.2.2 rateadaptinfo.cpp
>>>
>>> --- rateadaptinfo.cpp 15 Jul 2009 20:34:39 -0000
>>> 1.5.2.11.2.2
>>>
>>> +++ rateadaptinfo.cpp 25 Mar 2010 21:58:25 -0000
>>>
>>> @@ -490,8 +490,8 @@
>>>
>>> hdrType = ahtHelix;
>>>
>>> }
>>>
>>> else if (m_pNADU &&
>>>
>>> - HXR_OK ==
>>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> - ulReportFreq))
>>>
>>> + (HXR_OK ==
>>> pHdr->GetPropertyULONG32("3GPP-Adaptation-Support",
>>>
>>> + ulReportFreq)) &&
>>> (ulReportFreq == 1))
>>>
>>> {
>>>
>>> hdrType = aht3GPP;
>>>
>>> }
>>>
>>> Index: rtspclnt.cpp
>>>
>>> ===================================================================
>>>
>>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>>>
>>> retrieving revision 1.148.2.51.2.9
>>>
>>> diff -u -w -r1.148.2.51.2.9 rtspclnt.cpp
>>>
>>> --- rtspclnt.cpp 28 Aug 2009 22:28:56 -0000 1.148.2.51.2.9
>>>
>>> +++ rtspclnt.cpp 25 Mar 2010 21:58:25 -0000
>>>
>>> @@ -10495,7 +10495,8 @@
>>>
>>> if (m_pRateAdaptInfo)
>>>
>>> {
>>>
>>> UINT32 ulHelixAdaptation = 0;
>>>
>>> - UINT32 ulVersionTarget =
>>> HX_ENCODE_PROD_VERSION(11L, 1L, 0L, 0L);
>>>
>>> + UINT32 ul3GPPRateAdaptation = 0;
>>>
>>> + UINT32 ulVersionTarget = HX_ENCODE_PROD_VERSION(11L, 1L, 9L, 0L);
>>>
>>>
>>>
>>> //
>>>
>>> // due to a bug in released Helix
>>> Server, the client needs to disable "Helix-Adaption"
>>>
>>> @@ -10503,12 +10504,16 @@
>>>
>>> //
>>>
>>> // see
>>> https://bugs.helixcommunity.org/show_bug.cgi?id=4989 for details
>>>
>>> //
>>>
>>> - if ((m_ulServerVersion < ulVersionTarget) &&
>>>
>>> + if (IsRealServer() && (m_ulServerVersion <
>>> ulVersionTarget) &&
>>>
>>> HXR_OK ==
>>> ppRealHeaders[i]->GetPropertyULONG32("Helix-Adaptation-Support",
>>>
>>>
>>> ulHelixAdaptation) &&
>>>
>>> (1 == ulHelixAdaptation))
>>>
>>> {
>>>
>>> + HXLOGL2(HXLOG_RTSP, "RTSPClientProtocol[%p]::ParseSDP()
>>> Disabling RateAdaptation", this);
>>>
>>> +
>>>
>>> + // switch off both rate adaptation
>>>
>>>
>>> ppRealHeaders[i]->SetPropertyULONG32("Helix-Adaptation-Support", 0);
>>>
>>> +
>>> ppRealHeaders[i]->SetPropertyULONG32("3GPP-Adaptation-Support", 0);
>>>
>>> }
>>>
>>> m_pRateAdaptInfo->OnStreamHeader((UINT16)streamNumber,
>>>
>>> ppRealHeaders[i]);
>>>
>
>
From ext-anugrah.2.kashari at nokia.com Fri Mar 26 05:09:20 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Fri Mar 26 12:15:58 2010
Subject: [datatype-dev] CR: EKWM-83NJQ8 : Video FUSION: Player -
MMFControllerProxyServer
panic happens when starting playback for a certain DIVX3 + MKV video file
Message-ID:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
Modified By: ext-anugrah.2.kashari@nokia.com
Review By: Liu Junhong (Nokia-D/Dallas)
TSW-ID: EKWM-83NJQ8
Date : 20/03/2010
Project: SymbianMmf_wm
Synopsis: Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
Overview: There are two aspects of this issue. One is crash and second is codecspecfic data for audio.
1. Crash issue: During SourceInfo::InitializeRenderers(), audio renderer fails to initialize because CAudioSpecificConfig::Read() fails. It does not recognizes bitstream (mediainfo shows it is AAC LC v2). So a dummy renderer is initialized for audio (ulNumNULLRenderer count incremented to 1). Next video MimeType is returned as NULL (pMimeTypeBuffer is NULL because MKV FF does not find any equivalent mime-type for helix for DIV3) so it goes to exit subroutine. In exit it check for if partial playback is enabled and it tries to find out if any renderer is valid. If any render is valid then it will set partial playback flag. The catch is it check against number of streams ( here 2) and dummy render (is 1). So interprets wrongly that one render is valid. But this render is NULL. So when trying to SetupRendererSites() it crashes (pRenderer->GetDisplayType() ). If any render is successfully initialized then for audio and video, ulNumberOfAudioStreams and ulNumberOfVideoStreams will be greater than zero respectively. So this should be checked before resetting all the error codes and partial playback flag.
2. CodecSpecfic data : In this case audio is AAC LC v2 and no codec specific info is available. So MP4APayloadFormat::SetAssemblerAACGenericHeader() fails as no "OpaqueData" is found ( Actually not set by MKV FF format as ). However this error is propagated to PayloadFormatFactory::BuildFormat() and it keeps looking through other payload format (IMP4APayloadFormat) to find a suitable format. When it is checking with MP3, in CMP3DraftPayloadFormat::SetStreamHeader() , it successfully gets the mime-type and retval is set to HXR_OK. Now even if mime type does not match, as retval was still HXR_OK so it creates a MP3 bit-stream header for AAC! And since return code is HXR_OK CMP3DraftPayloadFormat is initialized instead of MP4APayloadFormat. However, finally CAudioSpecificConfig::Read() fails (after creating audio render, decoder etc) and renderer fails to initialize.
Fix: 1. If mimetype is not set, instead of going to exit routine we can try to initialize NULL renderer and see if partial playback is possible. This will attempt to do a partial playback if mimetype for either first or second stream is known.
2. To avoid crash changes has been made in srcinfo.cpp to ensure that partial playback is enable only if at-least one valid render is initialized. And in case none is initialized remap final error to HXR_NOT_SUPPORTED from HXR_FAILED, otherwise UI will show "General error".
3. If mime-type does not matches return HXR_FAIL for CMP3DraftPayloadFormat to avoid initialization of wrong payload format.
Files modified & changes 210Cays , Brizo420 and Head :
/cvsroot/client/core/srcinfo.cpp
/cvsroot/datatype/mp4/payload/mp3draft.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : PASSED
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5
Branch : 210Cays, Brizo420 & Head :
CVS diff: Attached for 210Cays
1. Srcinfo_cpp.txt for srcinfo.cpp
2. Mp3draft_cpp.txt or mp3draft.cpp
-------------- next part --------------
Index: srcinfo.cpp
===================================================================
RCS file: /cvsroot/client/core/srcinfo.cpp,v
retrieving revision 1.54.2.7
diff -u -w -r1.54.2.7 srcinfo.cpp
--- srcinfo.cpp 10 May 2007 17:46:25 -0000 1.54.2.7
+++ srcinfo.cpp 24 Mar 2010 05:31:12 -0000
@@ -2012,7 +2012,7 @@
HX_ASSERT(pMimeTypeBuffer && pMimeTypeBuffer->GetBuffer());
if (!pMimeTypeBuffer || !pMimeTypeBuffer->GetBuffer())
{
- GOTOEXITONERROR(theErr = HXR_NOT_INITIALIZED, exit);
+ GOTOEXITONERROR(theErr = HXR_NO_RENDERER, nextrend);
}
/*
@@ -2232,6 +2232,8 @@
{
// Partial playback is enabled.
// check valid renderer count against min value required.
+ if(ulNumberOfAudioStreams > 0 || ulNumberOfVideoStreams > 0 )
+ {
if((theFinalErr || theErr) && (ulNumNULLRenderer > 0))
{
UINT32 ulValidRenderers = m_pSource->GetNumStreams() - ulNumNULLRenderer;
@@ -2246,6 +2248,12 @@
m_bIsPartialPlayback = TRUE;
}
} // End of if(theFinalErr || theErr)
+ }
+ else
+ {
+ theFinalErr = HXR_NOT_SUPPORTED; // As no valid render is intialized. We can not do partial playback so remapp error message.
+ bSourceInitialized = FALSE;
+ }
} // if(bPartialPlaybackEnabled)
#endif
-------------- next part --------------
Index: mp3draft.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp3draft.cpp,v
retrieving revision 1.7
diff -u -w -r1.7 mp3draft.cpp
--- mp3draft.cpp 14 Mar 2005 19:17:44 -0000 1.7
+++ mp3draft.cpp 20 Mar 2010 10:39:59 -0000
@@ -140,6 +140,7 @@
retVal = pHeader->GetPropertyCString("MimeType", pBuffer);
if (SUCCEEDED(retVal))
{
+ retVal = HXR_FAIL;
const char* pszMimeType = (const char*) pBuffer->GetBuffer();
if (pszMimeType)
{
From sfu at real.com Fri Mar 26 05:51:18 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Mar 26 12:57:26 2010
Subject: [datatype-dev] Re: [Client-dev] CR: EKWM-83NJQ8 : Video FUSION:
Player - MMFControllerProxyServer
panic happens when starting playback for a certain DIVX3 + MKV video file
In-Reply-To:
References:
Message-ID: <4BACBBD6.5090309@real.com>
This looks ok.
Instead of changing the core though, you could also just modify the mkv
fileformat so it doesn't create a stream without a mime-type string.
There is really no point for a file format to return a stream without
mimetype since Helix will never be able to handle it. File format could
either define a new mimetype (even if there is no renderer that can
handle it yet), silently skip the stream within or assign the stream to
a catch-call mime-type (e.g. applicaiton/mkv-unknown or something like
that).
fxd
ext-anugrah.2.kashari@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
>
> Modified By: ext-anugrah.2.kashari@nokia.com
>
> Review By: Liu Junhong (Nokia-D/Dallas)
>
> TSW-ID: EKWM-83NJQ8
>
> Date : 20/03/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
>
> Overview: There are two aspects of this issue. One is crash and second is codecspecfic data for audio.
>
> 1. Crash issue: During SourceInfo::InitializeRenderers(), audio renderer fails to initialize because CAudioSpecificConfig::Read() fails. It does not recognizes bitstream (mediainfo shows it is AAC LC v2). So a dummy renderer is initialized for audio (ulNumNULLRenderer count incremented to 1). Next video MimeType is returned as NULL (pMimeTypeBuffer is NULL because MKV FF does not find any equivalent mime-type for helix for DIV3) so it goes to exit subroutine. In exit it check for if partial playback is enabled and it tries to find out if any renderer is valid. If any render is valid then it will set partial playback flag. The catch is it check against number of streams ( here 2) and dummy render (is 1). So interprets wrongly that one render is valid. But this render is NULL. So when trying to SetupRendererSites() it crashes (pRenderer->GetDisplayType() ). If any render is successfully initialized then for audio and video, ulNumberOfAudioStreams and ulNumberOfVideoStreams will be greater than zero respectively. So this should be checked before resetting all the error codes and partial playback flag.
>
> 2. CodecSpecfic data : In this case audio is AAC LC v2 and no codec specific info is available. So MP4APayloadFormat::SetAssemblerAACGenericHeader() fails as no "OpaqueData" is found ( Actually not set by MKV FF format as ). However this error is propagated to PayloadFormatFactory::BuildFormat() and it keeps looking through other payload format (IMP4APayloadFormat) to find a suitable format. When it is checking with MP3, in CMP3DraftPayloadFormat::SetStreamHeader() , it successfully gets the mime-type and retval is set to HXR_OK. Now even if mime type does not match, as retval was still HXR_OK so it creates a MP3 bit-stream header for AAC! And since return code is HXR_OK CMP3DraftPayloadFormat is initialized instead of MP4APayloadFormat. However, finally CAudioSpecificConfig::Read() fails (after creating audio render, decoder etc) and renderer fails to initialize.
>
> Fix: 1. If mimetype is not set, instead of going to exit routine we can try to initialize NULL renderer and see if partial playback is possible. This will attempt to do a partial playback if mimetype for either first or second stream is known.
> 2. To avoid crash changes has been made in srcinfo.cpp to ensure that partial playback is enable only if at-least one valid render is initialized. And in case none is initialized remap final error to HXR_NOT_SUPPORTED from HXR_FAILED, otherwise UI will show "General error".
> 3. If mime-type does not matches return HXR_FAIL for CMP3DraftPayloadFormat to avoid initialization of wrong payload format.
>
> Files modified & changes 210Cays , Brizo420 and Head :
> /cvsroot/client/core/srcinfo.cpp
> /cvsroot/datatype/mp4/payload/mp3draft.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : PASSED
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch : 210Cays, Brizo420 & Head :
>
> CVS diff: Attached for 210Cays
>
> 1. Srcinfo_cpp.txt for srcinfo.cpp
>
> 2. Mp3draft_cpp.txt or mp3draft.cpp
>
>
From ext-anugrah.2.kashari at nokia.com Sun Mar 28 19:57:36 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Mon Mar 29 03:03:14 2010
Subject: [datatype-dev] CR: IWOD-83KC2Y: Audio Related Panic When Playing
WMVHD Clip With 6 Channel Audio
Message-ID:
"Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
Modified By: ext-anugrah.2.kashari@nokia.com
Review By: Rathinasamy Rajesh
TSW-ID: IWOD-83KC2Y
Date : 29/03/2010
Project: SymbianMmf_wm
Synopsis: Audio Related Panic When Playing WMVHD Clip With 6 Channel Audio
Overview: Audio stream in this file has 6 channel. This is not supported but this was not checked while initializing devsound. As a result devsound configuration fails and this leads to various problem including crash when setting volume.
Fix: Added code to check maximum number of channel supported(in class HXMDFAudioWMA).
Files modified & changes 210Cays , Brizo420 and Head :
/cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.cpp
/cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Ongoing
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5
Branch : 210Cays, Brizo420 & Head :
Index: mdfaudfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.cpp,v
retrieving revision 1.1.2.17
diff -u -w -r1.1.2.17 mdfaudfmt.cpp
--- mdfaudfmt.cpp 26 Jan 2010 17:52:31 -0000 1.1.2.17
+++ mdfaudfmt.cpp 29 Mar 2010 03:54:10 -0000
@@ -57,6 +57,7 @@
#include "mdfdebug.h"
#include "mdfaudfmt.h"
#include "stdlib.h"
+#include "hxprefutil.h"
//Dolby Digital frame size table, the first column is framesizecode, it is the lower 6 bits
// of the 4th byte, the 2nd column is the norminal bit rate, the 3rd, 4th and 5th columns are
@@ -660,10 +661,14 @@
HXMDFAudioWMA::HXMDFAudioWMA(IUnknown *pContext)
{
m_tFourCC = KMMFFourCCCodeWMA;
+ // save the context for collecting information
+ m_pContext = pContext;
+ HX_ADDREF(m_pContext);
}
HXMDFAudioWMA::~HXMDFAudioWMA()
{
+ HX_RELEASE(m_pContext);
}
@@ -730,6 +735,14 @@
}
free(buf);
+ UINT16 usWMAChannels = 2;
+ ReadPrefUINT16(m_pContext, "MAXSupportedWMAChannels", usWMAChannels);
+ if(m_uChannels > usWMAChannels)
+ {
+ HXLOGL2(HXLOG_WMAR, "HXMDFAudioWMA::ParseConfig Error:More than %d channels not supported. Channels for this Stream:%d", usWMAChannels, m_uChannels );
+ result = HXR_UNSUPPORTED_AUDIO;
+ }
+
return result;
}
Index: mdfaudfmt.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h,v
retrieving revision 1.1.2.11
diff -u -w -r1.1.2.11 mdfaudfmt.h
--- mdfaudfmt.h 15 Dec 2009 20:37:34 -0000 1.1.2.11
+++ mdfaudfmt.h 29 Mar 2010 03:54:20 -0000
@@ -183,6 +183,8 @@
UINT32 m_MDFWMAHeader[WMAMMFCODEC10_HEADER_SIZE/sizeof(UINT32)];
+ IUnknown* m_pContext;
+
};
class HXMDFAudioAC3 : public HXMDFAudioFormat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100329/495b81d1/attachment.html
From ext-anugrah.2.kashari at nokia.com Sun Mar 28 22:41:29 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Mon Mar 29 05:47:27 2010
Subject: [datatype-dev] CR: CPAY-82TEGE: Crash occurs after playing a
3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
In-Reply-To: <4BAAB53D.9070002@real.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F17282DB3AE70@NOK-EUMSG-02.mgdnok.nokia.com>
<4BAAB53D.9070002@real.com>
Message-ID:
Thanks Qiang,
Submitted the code in 210CayS, 420Bizo and HEAD.
Also submitted in hxclient_3_1_0_atlas branch as requested.
Regards,
Anugrah K
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Qiang Luo
Sent: Thursday, March 25, 2010 6:29 AM
To: Mishra Sudhir.1 (EXT-Sasken/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: CPAY-82TEGE: Crash occurs after playing a 3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
The fix loos good. Please make some cosmetic changes to conform to the
helix coding style:
--use space instead of tabs
--put opening curly brace on a new line
Please merge the fix to hxclient_3_1_0_atlas branch as well.
Thanks,
Qiang
On 3/23/2010 11:21 AM, ext-sudhir.1.mishra@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement."
>
> Modified by: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: Junhong.Liu@nokia.com
>
> TSW Id: CPAY-82TEGE
>
> Date: 03/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Crash occurs after playing a 3gp video (Ovi Video_Main_704x528_3.0.3gp) for a while via Flash player
>
> Overview:
> There are two problems with this stream:
> 1) Helix is getting unsupported/invalid NAL units in RTP payload (NAL types 0, 30 or 31) which are getting ignored
> 2) In MTAP payload most of the times data that is coming is corrupted which is causing the panic.
>
> In case of corrupted Multitime aggregate NAL packet ( NAL-Type=26), total payload size shows less then the included NAL size. This causes the computation of the next NAL (MTAP16) size to go wrong, which later causes Buffer size to reset and result in a panic.
>
> Fix:
> In case of invalid/corrupted MTAP NAL, setting the NAL size equal to remaining available buffer size i.e. if the NAL coming is greater than the RTP payload then set it equal to available payload size instead of ignoring it completely, hence neglecting the fillers.
> This will fix the crash but we may get artifacts or the video may stop gracefully at some later stage.
>
> Files modified& changes:
> datatype/mp4/payload/h264pyld.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: h264pyld.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp4/payload/h264pyld.cpp,v
> retrieving revision 1.4.2.6
> diff -u -w -r1.4.2.6 h264pyld.cpp
> --- h264pyld.cpp 25 Jun 2008 05:33:18 -0000 1.4.2.6
> +++ h264pyld.cpp 23 Mar 2010 12:11:37 -0000
> @@ -1016,6 +1016,12 @@
> else
> {
> UINT32 ulNalSize = ((UINT16)pData[0]<<8) + pData[1];
> + //If the NAL coming is greater than the RTP payload
> + //then set it equal to buff size hence neglect fillers
> + //This is invalid/corrupted MTAP NAL
> + if(ulNalSize> ulBuffSize){
> + ulNalSize = ulBuffSize;
> + }
> offset = 2;
> if (uPacketType == MTAP16)
> {
> _______________________________________________
> 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
From ext-anugrah.2.kashari at nokia.com Sun Mar 28 23:08:32 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Mon Mar 29 06:14:51 2010
Subject: [datatype-dev] RE: [Client-dev] CR: EKWM-83NJQ8 : Video FUSION:
Player -
MMFControllerProxyServer panic happens when starting playback for a certain
DIVX3 + MKV video file
In-Reply-To: <4BACBBD6.5090309@real.com>
References:
<4BACBBD6.5090309@real.com>
Message-ID:
Hi Sheldon,
I have made changes in MKV file format for relevant changes. But we still need to keep changes in core as we need to remap error to HXR_NOT_SUPPORTED when no valid renderer is initialized. This change is required so that UI can display correct error message.
Reattaching the diff for reference.
Thanks,
Anugrah K
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, March 26, 2010 7:21 PM
To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Cc: client-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Client-dev] CR: EKWM-83NJQ8 : Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
This looks ok.
Instead of changing the core though, you could also just modify the mkv
fileformat so it doesn't create a stream without a mime-type string.
There is really no point for a file format to return a stream without
mimetype since Helix will never be able to handle it. File format could
either define a new mimetype (even if there is no renderer that can
handle it yet), silently skip the stream within or assign the stream to
a catch-call mime-type (e.g. applicaiton/mkv-unknown or something like
that).
fxd
ext-anugrah.2.kashari@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
>
> Modified By: ext-anugrah.2.kashari@nokia.com
>
> Review By: Liu Junhong (Nokia-D/Dallas)
>
> TSW-ID: EKWM-83NJQ8
>
> Date : 20/03/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
>
> Overview: There are two aspects of this issue. One is crash and second is codecspecfic data for audio.
>
> 1. Crash issue: During SourceInfo::InitializeRenderers(), audio renderer fails to initialize because CAudioSpecificConfig::Read() fails. It does not recognizes bitstream (mediainfo shows it is AAC LC v2). So a dummy renderer is initialized for audio (ulNumNULLRenderer count incremented to 1). Next video MimeType is returned as NULL (pMimeTypeBuffer is NULL because MKV FF does not find any equivalent mime-type for helix for DIV3) so it goes to exit subroutine. In exit it check for if partial playback is enabled and it tries to find out if any renderer is valid. If any render is valid then it will set partial playback flag. The catch is it check against number of streams ( here 2) and dummy render (is 1). So interprets wrongly that one render is valid. But this render is NULL. So when trying to SetupRendererSites() it crashes (pRenderer->GetDisplayType() ). If any render is successfully initialized then for audio and video, ulNumberOfAudioStreams and ulNumberOfVideoStreams will be greater than zero respectively. So this should be checked before resetting all the error codes and partial playback flag.
>
> 2. CodecSpecfic data : In this case audio is AAC LC v2 and no codec specific info is available. So MP4APayloadFormat::SetAssemblerAACGenericHeader() fails as no "OpaqueData" is found ( Actually not set by MKV FF format as ). However this error is propagated to PayloadFormatFactory::BuildFormat() and it keeps looking through other payload format (IMP4APayloadFormat) to find a suitable format. When it is checking with MP3, in CMP3DraftPayloadFormat::SetStreamHeader() , it successfully gets the mime-type and retval is set to HXR_OK. Now even if mime type does not match, as retval was still HXR_OK so it creates a MP3 bit-stream header for AAC! And since return code is HXR_OK CMP3DraftPayloadFormat is initialized instead of MP4APayloadFormat. However, finally CAudioSpecificConfig::Read() fails (after creating audio render, decoder etc) and renderer fails to initialize.
>
> Fix: 1. If mimetype is not set, instead of going to exit routine we can try to initialize NULL renderer and see if partial playback is possible. This will attempt to do a partial playback if mimetype for either first or second stream is known.
> 2. To avoid crash changes has been made in srcinfo.cpp to ensure that partial playback is enable only if at-least one valid render is initialized. And in case none is initialized remap final error to HXR_NOT_SUPPORTED from HXR_FAILED, otherwise UI will show "General error".
> 3. If mime-type does not matches return HXR_FAIL for CMP3DraftPayloadFormat to avoid initialization of wrong payload format.
>
> Files modified & changes 210Cays , Brizo420 and Head :
> /cvsroot/client/core/srcinfo.cpp
> /cvsroot/datatype/mp4/payload/mp3draft.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : PASSED
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch : 210Cays, Brizo420 & Head :
>
> CVS diff: Attached for 210Cays
>
> 1. Srcinfo_cpp.txt for srcinfo.cpp
>
> 2. Mp3draft_cpp.txt or mp3draft.cpp
>
>
-------------- next part --------------
Index: srcinfo.cpp
===================================================================
RCS file: /cvsroot/client/core/srcinfo.cpp,v
retrieving revision 1.54.2.7
diff -u -w -r1.54.2.7 srcinfo.cpp
--- srcinfo.cpp 10 May 2007 17:46:25 -0000 1.54.2.7
+++ srcinfo.cpp 29 Mar 2010 07:02:31 -0000
@@ -2012,7 +2012,7 @@
HX_ASSERT(pMimeTypeBuffer && pMimeTypeBuffer->GetBuffer());
if (!pMimeTypeBuffer || !pMimeTypeBuffer->GetBuffer())
{
- GOTOEXITONERROR(theErr = HXR_NOT_INITIALIZED, exit);
+ GOTOEXITONERROR(theErr = HXR_NO_RENDERER, nextrend);
}
/*
@@ -2232,6 +2232,8 @@
{
// Partial playback is enabled.
// check valid renderer count against min value required.
+ if(ulNumberOfAudioStreams > 0 || ulNumberOfVideoStreams > 0 )
+ {
if((theFinalErr || theErr) && (ulNumNULLRenderer > 0))
{
UINT32 ulValidRenderers = m_pSource->GetNumStreams() - ulNumNULLRenderer;
@@ -2246,6 +2248,12 @@
m_bIsPartialPlayback = TRUE;
}
} // End of if(theFinalErr || theErr)
+ }
+ else if(theErr != HXR_OUTOFMEMORY && theFinalErr != HXR_OUTOFMEMORY)
+ {
+ theFinalErr = HXR_NOT_SUPPORTED; // As no valid render is intialized. We can not do partial playback so remapp error message.
+ bSourceInitialized = FALSE;
+ }
} // if(bPartialPlaybackEnabled)
#endif
-------------- next part --------------
Index: mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.4
diff -u -w -r1.1.1.1.2.4 mkv_file_format.cpp
--- mkv_file_format.cpp 24 Mar 2010 15:45:43 -0000 1.1.1.1.2.4
+++ mkv_file_format.cpp 29 Mar 2010 07:00:47 -0000
@@ -75,6 +75,17 @@
#define MKV_AAC_MIMETYPE "A_AAC"
#define HELIX_AAC_MIMETYPE "audio/X-HX-AAC-GENERIC"
+#define HELIX_UNKNOWN_AUDIO_MIMETYPE "audio/X-HX-UNKNOWN"
+#define HELIX_UNKNOWN_VIDEO_MIMETYPE "video/X-HX-UNKNOWN"
+#define HELIX_UNKNOWN_MIMETYPE "application/X-HX-UNKNOWN"
+
+const char* MkvUnknownMimeType[] =
+{
+ {HELIX_UNKNOWN_AUDIO_MIMETYPE},
+ {HELIX_UNKNOWN_VIDEO_MIMETYPE},
+ {HELIX_UNKNOWN_MIMETYPE},
+};
+
//MimeType Mapping
const char* MkvToHelixMimeTypeMap[][2] =
{
@@ -362,7 +373,14 @@
pHdr->SetPropertyULONG32("AvgBitRate", fBytesPerSecond);
// Set the mime type
- SetCStringPropertyCCF(pHdr, "MimeType", GetMimeType(trk->pszCodec, trk->pExtraData), m_pContext);
+ const char* pszMimeType = NULL;
+ pszMimeType = GetMimeType(trk->pszCodec, trk->pExtraData);
+ if(pszMimeType == NULL)
+ {
+ pszMimeType = MkvUnknownMimeType[trk->type];
+ }
+
+ SetCStringPropertyCCF(pHdr, "MimeType", pszMimeType , m_pContext);
SetTypeSpecificProperties(pHdr, trk);
-------------- next part --------------
Index: mp3draft.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp3draft.cpp,v
retrieving revision 1.7
diff -u -w -r1.7 mp3draft.cpp
--- mp3draft.cpp 14 Mar 2005 19:17:44 -0000 1.7
+++ mp3draft.cpp 20 Mar 2010 10:39:59 -0000
@@ -140,6 +140,7 @@
retVal = pHeader->GetPropertyCString("MimeType", pBuffer);
if (SUCCEEDED(retVal))
{
+ retVal = HXR_FAIL;
const char* pszMimeType = (const char*) pBuffer->GetBuffer();
if (pszMimeType)
{
From sfu at real.com Mon Mar 29 05:12:55 2010
From: sfu at real.com (Sheldon Fu)
Date: Mon Mar 29 12:18:40 2010
Subject: [datatype-dev] Re: [Client-dev] CR: EKWM-83NJQ8 : Video FUSION:
Player - MMFControllerProxyServer
panic happens when starting playback for a certain DIVX3 + MKV video file
In-Reply-To:
References:
<4BACBBD6.5090309@real.com>
Message-ID: <4BB0A757.7040109@real.com>
Looks good.
fxd
ext-anugrah.2.kashari@nokia.com wrote:
> Hi Sheldon,
>
> I have made changes in MKV file format for relevant changes. But we still need to keep changes in core as we need to remap error to HXR_NOT_SUPPORTED when no valid renderer is initialized. This change is required so that UI can display correct error message.
>
> Reattaching the diff for reference.
>
> Thanks,
> Anugrah K
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Friday, March 26, 2010 7:21 PM
> To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> Cc: client-dev@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [Client-dev] CR: EKWM-83NJQ8 : Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
>
> This looks ok.
>
> Instead of changing the core though, you could also just modify the mkv
> fileformat so it doesn't create a stream without a mime-type string.
> There is really no point for a file format to return a stream without
> mimetype since Helix will never be able to handle it. File format could
> either define a new mimetype (even if there is no renderer that can
> handle it yet), silently skip the stream within or assign the stream to
> a catch-call mime-type (e.g. applicaiton/mkv-unknown or something like
> that).
>
> fxd
>
> ext-anugrah.2.kashari@nokia.com wrote:
>
>> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement"
>>
>> Modified By: ext-anugrah.2.kashari@nokia.com
>>
>> Review By: Liu Junhong (Nokia-D/Dallas)
>>
>> TSW-ID: EKWM-83NJQ8
>>
>> Date : 20/03/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: Video FUSION: Player - MMFControllerProxyServer panic happens when starting playback for a certain DIVX3 + MKV video file
>>
>> Overview: There are two aspects of this issue. One is crash and second is codecspecfic data for audio.
>>
>> 1. Crash issue: During SourceInfo::InitializeRenderers(), audio renderer fails to initialize because CAudioSpecificConfig::Read() fails. It does not recognizes bitstream (mediainfo shows it is AAC LC v2). So a dummy renderer is initialized for audio (ulNumNULLRenderer count incremented to 1). Next video MimeType is returned as NULL (pMimeTypeBuffer is NULL because MKV FF does not find any equivalent mime-type for helix for DIV3) so it goes to exit subroutine. In exit it check for if partial playback is enabled and it tries to find out if any renderer is valid. If any render is valid then it will set partial playback flag. The catch is it check against number of streams ( here 2) and dummy render (is 1). So interprets wrongly that one render is valid. But this render is NULL. So when trying to SetupRendererSites() it crashes (pRenderer->GetDisplayType() ). If any render is successfully initialized then for audio and video, ulNumberOfAudioStreams and ulNumberOfVideoStreams will be greater than zero respectively. So this should be checked before resetting all the error codes and partial playback flag.
>>
>> 2. CodecSpecfic data : In this case audio is AAC LC v2 and no codec specific info is available. So MP4APayloadFormat::SetAssemblerAACGenericHeader() fails as no "OpaqueData" is found ( Actually not set by MKV FF format as ). However this error is propagated to PayloadFormatFactory::BuildFormat() and it keeps looking through other payload format (IMP4APayloadFormat) to find a suitable format. When it is checking with MP3, in CMP3DraftPayloadFormat::SetStreamHeader() , it successfully gets the mime-type and retval is set to HXR_OK. Now even if mime type does not match, as retval was still HXR_OK so it creates a MP3 bit-stream header for AAC! And since return code is HXR_OK CMP3DraftPayloadFormat is initialized instead of MP4APayloadFormat. However, finally CAudioSpecificConfig::Read() fails (after creating audio render, decoder etc) and renderer fails to initialize.
>>
>> Fix: 1. If mimetype is not set, instead of going to exit routine we can try to initialize NULL renderer and see if partial playback is possible. This will attempt to do a partial playback if mimetype for either first or second stream is known.
>> 2. To avoid crash changes has been made in srcinfo.cpp to ensure that partial playback is enable only if at-least one valid render is initialized. And in case none is initialized remap final error to HXR_NOT_SUPPORTED from HXR_FAILED, otherwise UI will show "General error".
>> 3. If mime-type does not matches return HXR_FAIL for CMP3DraftPayloadFormat to avoid initialization of wrong payload format.
>>
>> Files modified & changes 210Cays , Brizo420 and Head :
>> /cvsroot/client/core/srcinfo.cpp
>> /cvsroot/datatype/mp4/payload/mp3draft.cpp
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : PASSED
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : Passed, No additional leaks introduced.
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch : 210Cays, Brizo420 & Head :
>>
>> CVS diff: Attached for 210Cays
>>
>> 1. Srcinfo_cpp.txt for srcinfo.cpp
>>
>> 2. Mp3draft_cpp.txt or mp3draft.cpp
>>
>>
>>
>
>
>
From gwright at real.com Mon Mar 29 09:30:49 2010
From: gwright at real.com (Gregory Wright)
Date: Mon Mar 29 16:36:21 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: IWOD-83KC2Y: Audio
Related Panic When Playing WMVHD Clip With 6 Channel Audio
In-Reply-To:
References:
Message-ID:
Looks good.
--greg.
On Mar 28, 2010, at 8:57 PM, wrote:
> "Nokia submits this code under the terms of a commercial contribution agreement with RealNetworks, and I am authorized to contribute this code under said agreement?
>
> Modified By: ext-anugrah.2.kashari@nokia.com
>
> Review By: Rathinasamy Rajesh
>
> TSW-ID: IWOD-83KC2Y
>
> Date : 29/03/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Audio Related Panic When Playing WMVHD Clip With 6 Channel Audio
>
> Overview: Audio stream in this file has 6 channel. This is not supported but this was not checked while initializing devsound. As a result devsound configuration fails and this leads to various problem including crash when setting volume.
>
> Fix: Added code to check maximum number of channel supported(in class HXMDFAudioWMA).
>
> Files modified & changes 210Cays , Brizo420 and Head :
> /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.cpp
> /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Ongoing
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch : 210Cays, Brizo420 & Head :
>
> Index: mdfaudfmt.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.cpp,v
> retrieving revision 1.1.2.17
> diff -u -w -r1.1.2.17 mdfaudfmt.cpp
> --- mdfaudfmt.cpp 26 Jan 2010 17:52:31 -0000 1.1.2.17
> +++ mdfaudfmt.cpp 29 Mar 2010 03:54:10 -0000
> @@ -57,6 +57,7 @@
> #include "mdfdebug.h"
> #include "mdfaudfmt.h"
> #include "stdlib.h"
> +#include "hxprefutil.h"
>
> //Dolby Digital frame size table, the first column is framesizecode, it is the lower 6 bits
> // of the 4th byte, the 2nd column is the norminal bit rate, the 3rd, 4th and 5th columns are
> @@ -660,10 +661,14 @@
> HXMDFAudioWMA::HXMDFAudioWMA(IUnknown *pContext)
> {
> m_tFourCC = KMMFFourCCCodeWMA;
> + // save the context for collecting information
> + m_pContext = pContext;
> + HX_ADDREF(m_pContext);
> }
>
> HXMDFAudioWMA::~HXMDFAudioWMA()
> {
> + HX_RELEASE(m_pContext);
> }
>
>
> @@ -730,6 +735,14 @@
> }
> free(buf);
>
> + UINT16 usWMAChannels = 2;
> + ReadPrefUINT16(m_pContext, "MAXSupportedWMAChannels", usWMAChannels);
> + if(m_uChannels > usWMAChannels)
> + {
> + HXLOGL2(HXLOG_WMAR, "HXMDFAudioWMA::ParseConfig Error:More than %d channels not supported. Channels for this Stream:%d", usWMAChannels, m_uChannels );
> + result = HXR_UNSUPPORTED_AUDIO;
> + }
> +
> return result;
> }
>
> Index: mdfaudfmt.h
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h,v
> retrieving revision 1.1.2.11
> diff -u -w -r1.1.2.11 mdfaudfmt.h
> --- mdfaudfmt.h 15 Dec 2009 20:37:34 -0000 1.1.2.11
> +++ mdfaudfmt.h 29 Mar 2010 03:54:20 -0000
> @@ -183,6 +183,8 @@
>
> UINT32 m_MDFWMAHeader[WMAMMFCODEC10_HEADER_SIZE/sizeof(UINT32)];
>
> + IUnknown* m_pContext;
> +
> };
>
> class HXMDFAudioAC3 : public HXMDFAudioFormat
>
>
>
From kliu at real.com Mon Mar 29 20:06:07 2010
From: kliu at real.com (Kinson Liu)
Date: Tue Mar 30 03:11:35 2010
Subject: [datatype-dev] CR: Fixing helix crashes when seeking beyond end of
avi files
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype.diff
Type: application/octet-stream
Size: 1111 bytes
Desc: datatype.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100329/446aa17e/datatype.obj
From ext-anugrah.2.kashari at nokia.com Mon Mar 29 21:53:07 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Tue Mar 30 04:59:12 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: IWOD-83KC2Y: Audio
Related Panic When Playing WMVHD Clip With 6 Channel Audio
In-Reply-To: