From chrisy at real.com Fri Jul 2 07:43:07 2010
From: chrisy at real.com (Chris Young)
Date: Fri Jul 2 14:24:46 2010
Subject: [datatype-dev] CR: Merge security fixes for bugs 259244, 259180,
259177, 259325 and 259190 into hxclient_3_4_10_atlas
Message-ID: <4C2E090B.7040004@real.com>
Synopsis: Merge security fixes for bugs 259244,259180,259177,259325 and
259190 into hxclient_3_4_10_atlas
Files Modified:
datatype/qcelp/fileformat/qcpplin.cpp merge
hxclient_3_1_0_atlas(1.2.8.2) into hxclient_3_4_10_atlas(1.2)
datatype-restricted/rm/audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp
merge HEAD(1.8) into hxclient_3_4_10_atlas(1.5.18.2)
datatype-restricted/rm/audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp
merge HEAD(1.6) into hxclient_3_4_10_atlas(1.5)
datatype-restricted/rm/audio/common/raparser.cpp merge HEAD(1.10)
hxclient_3_4_10_atlas(1.9)
datatype-restricted/rm/video/codec/rv1dec/decoder/getpic.c merge
HEAD(1.6) hxclient_3_4_10_atlas(1.4)
datatype-restricted/rm/video/codec/rv1dec/decoder/postfltr.c merge
HEAD(1.3) hxclient_3_4_10_atlas(1.2)
datatype-restricted/rm/video/codec/g2mp4combo/dec/core_dec.cpp merge
HEAD(1.8) hxclient_3_4_10_atlas(1.5.12.1)
Platforms and Profiles Build Verified:
Platform: linux-2.2-libc6-gcc32-i586
Profile: helix-client-moblin
bug 259244 Potential Exploit: Secunia_QCP_Parsing_SA38550-1
datatype/qcelp/fileformat/qcpplin.cpp merge
hxclient_3_1_0_atlas(1.2.8.2) into hxclient_3_4_10_atlas(1.2)
bug 259182 Potential Exploit: Secunia_Cook_channels_SA38550-6
datatype-restricted/rm/audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp
merge HEAD(1.8) into hxclient_3_4_10_atlas(1.5.18.2)
datatype-restricted/rm/audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp
merge HEAD(1.6) into hxclient_3_4_10_atlas(1.5)
bug 259177 Potential Exploit: VUPEN-SR-2010-30_RA5-Memory-Corruption-1
datatype-restricted/rm/audio/common/raparser.cpp merge HEAD(1.10)
hxclient_3_4_10_atlas(1.9)
bug 259325 Potential Exploit: TippingPoint_ZDI-CAN-728_SIPR_Stream
bug 262064 Potential Exploit: iDefense V-9qd9xd9qhh (G2 video heap
corruption)
datatype-restricted/rm/video/codec/rv1dec/decoder/getpic.c merge
HEAD(1.6) hxclient_3_4_10_atlas(1.4)
datatype-restricted/rm/video/codec/rv1dec/decoder/postfltr.c merge
HEAD(1.3) hxclient_3_4_10_atlas(1.2)
bug 259190 Potential Exploit: Secunia_MP4_SA38550-2
datatype-restricted/rm/video/codec/g2mp4combo/dec/core_dec.cpp merge
HEAD(1.8) hxclient_3_4_10_atlas(1.5.12.1)
--
Chris Young
chrisy@real.com
-------------- next part --------------
Index: datatype/qcelp/fileformat/qcpplin.cpp
===================================================================
RCS file: /cvsroot/datatype/qcelp/fileformat/qcpplin.cpp,v
retrieving revision 1.2
diff -w -u -r1.2 qcpplin.cpp
--- datatype/qcelp/fileformat/qcpplin.cpp 31 Jul 2009 16:59:20 -0000 1.2
+++ datatype/qcelp/fileformat/qcpplin.cpp 22 Jun 2010 22:56:02 -0000
@@ -73,10 +73,10 @@
#include "hxengin.h"
#include "baseobj.h"
#include "qcpplin.h"
+#include "qcpfformat.ver"
#include "hxver.h"
#include "rmfftype.h" // for the HX_SAVE_ENABLED flag
#include "hlxclib/math.h"
-#include "qcpfformat.ver"
#include "netbyte.h"
#include "hxassert.h"
#include "pckunpck.h"
@@ -839,12 +839,26 @@
// variable rate = num-rates (UINT32) rate-map-table
// rate-map-table = 8rate-map-entry
// rate-map-entry = rate-size(octet - 1 byte) rate-octet(octet - 1 byte)
+ UINT32 k;
+ for(k=0; kGetLong(&fmtBuf[fmtBuf_index]);
fmtBuf_index += 4;
+ // PR# 259244
+ // m_ulNumOfRates is insecure. Hacker can set this to arbitrarily
+ // high values, which causes us to try reading past the end of fmtBuf.
+ // Limit to reasonable values, that is, the most number of rates that
+ // can be in the format buffer given how much is left.
+ UINT32 ulMaxRates;
+ ulMaxRates = (len - fmtBuf_index) / 2;
+ m_ulNumOfRates = (m_ulNumOfRates <= ulMaxRates) ? m_ulNumOfRates : ulMaxRates;
+
// build Rate-Map ( rate-size rate-octet )
- HX_VECTOR_DELETE(m_pRateMapTable);
m_pRateMapTable = new UCHAR*[m_ulNumOfRates];
if(m_pRateMapTable)
{
@@ -858,9 +872,16 @@
for(i=0;iInitDone(HXR_OK);
m_state = AS_FindDATAChunkPending;
m_pRiffReader->FindChunk(DATA_CHUNK_ID, FALSE);
Index: datatype-restricted/rm/audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp
===================================================================
RCS file: /cvsroot/rarvcode-audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp,v
retrieving revision 1.5.18.2
diff -w -u -r1.5.18.2 gecko2decshim.cpp
--- datatype-restricted/rm/audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp 3 Feb 2008 02:14:19 -0000 1.5.18.2
+++ datatype-restricted/rm/audio/codec/ra8lbr/fixpt/decoder/hxwrapper/gecko2decshim.cpp 22 Jun 2010 23:01:36 -0000
@@ -82,7 +82,13 @@
return HXR_OK ;
}
-COldGeckoDecoderShim::COldGeckoDecoderShim() {}
+COldGeckoDecoderShim::COldGeckoDecoderShim():
+ mChannels(0),
+ mFrameSamples(0),
+ mFrameBytes(0),
+ mInterleaveBuffer(NULL),
+ codecs(NULL)
+{}
COldGeckoDecoderShim::~COldGeckoDecoderShim(){}
HX_RESULT COldGeckoDecoderShim::InitDecoder(int sampleRate, int nChannels, int nFrameBits, BYTE *pOpaqueData, int opaqueDataLength, int &codingDelay)
@@ -160,7 +166,11 @@
/* the shim for the new codec is rather thin in fact */
-CNewGeckoDecoderShim::CNewGeckoDecoderShim() {}
+CNewGeckoDecoderShim::CNewGeckoDecoderShim():
+ mFrameBits(0),
+ mSamplesPerFrame(0),
+ pCodec(NULL)
+{}
CNewGeckoDecoderShim::~CNewGeckoDecoderShim(){}
HX_RESULT CNewGeckoDecoderShim::InitDecoder(int sampleRate, int nChannels, int nFrameBits, BYTE *pOpaqueData, int opaqueDataLength, int &codingDelay)
Index: datatype-restricted/rm/audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp
===================================================================
RCS file: /cvsroot/rarvcode-audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp,v
retrieving revision 1.5
diff -w -u -r1.5 gecko2decshim.cpp
--- datatype-restricted/rm/audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp 27 Apr 2005 19:21:06 -0000 1.5
+++ datatype-restricted/rm/audio/codec/ra8lbr/fltpt/decoder/gecko2decshim.cpp 22 Jun 2010 23:01:36 -0000
@@ -82,7 +82,13 @@
return HXR_OK ;
}
-COldGeckoDecoderShim::COldGeckoDecoderShim() {}
+COldGeckoDecoderShim::COldGeckoDecoderShim():
+ mChannels(0),
+ mFrameSamples(0),
+ mFrameBytes(0),
+ mInterleaveBuffer(NULL),
+ codecs(NULL)
+{}
COldGeckoDecoderShim::~COldGeckoDecoderShim(){}
HX_RESULT COldGeckoDecoderShim::InitDecoder(int sampleRate, int nChannels, int nFrameBits, BYTE *pOpaqueData, int opaqueDataLength, int &codingDelay)
@@ -184,7 +190,11 @@
/* the shim for the new codec is rather thin in fact */
-CNewGeckoDecoderShim::CNewGeckoDecoderShim() {}
+CNewGeckoDecoderShim::CNewGeckoDecoderShim():
+ mFrameBits(0),
+ mSamplesPerFrame(0),
+ pCodec(NULL)
+{}
CNewGeckoDecoderShim::~CNewGeckoDecoderShim(){}
HX_RESULT CNewGeckoDecoderShim::InitDecoder(int sampleRate, int nChannels, int nFrameBits, BYTE *pOpaqueData, int opaqueDataLength, int &codingDelay)
@@ -219,7 +229,14 @@
}
/* multi channel decoder */
-CGeckoMCDecoderShim::CGeckoMCDecoderShim() {}
+CGeckoMCDecoderShim::CGeckoMCDecoderShim():
+ mNumCodecs(0),
+ mTotalBytes(0),
+ mChannelsTotal(0),
+ mSamplesPerFrame(0),
+ mInterleaveBuffer(NULL),
+ codecs(NULL)
+{}
CGeckoMCDecoderShim::~CGeckoMCDecoderShim(){}
HX_RESULT CGeckoMCDecoderShim::InitDecoder(int sampleRate, int nChannels, int nFrameBits, BYTE *pOpaqueData, int opaqueDataLength, int &codingDelay)
Index: datatype-restricted/rm/audio/common/raparser.cpp
===================================================================
RCS file: /cvsroot/rarvcode-audio/common/raparser.cpp,v
retrieving revision 1.9
diff -w -u -r1.9 raparser.cpp
--- datatype-restricted/rm/audio/common/raparser.cpp 27 Apr 2005 19:21:38 -0000 1.9
+++ datatype-restricted/rm/audio/common/raparser.cpp 22 Jun 2010 23:01:36 -0000
@@ -409,6 +409,8 @@
off = format.unpack(buf+offset,bLength);
+ if (!off)
+ return HXR_INVALID_FILE;
if (format.version != RA_VERSION_5)
return HXR_INVALID_VERSION;
if (format.revision != 0)
Index: datatype-restricted/rm/video/codec/rv1dec/decoder/getpic.c
===================================================================
RCS file: /cvsroot/rarvcode-video/codec/rv1dec/decoder/getpic.c,v
retrieving revision 1.4
diff -w -u -r1.4 getpic.c
--- datatype-restricted/rm/video/codec/rv1dec/decoder/getpic.c 10 Mar 2005 20:03:47 -0000 1.4
+++ datatype-restricted/rm/video/codec/rv1dec/decoder/getpic.c 22 Jun 2010 23:01:41 -0000
@@ -376,6 +376,13 @@
missingMB=1;
}
MBA = packetInfo->xStart +(packetInfo->yStart)*mb_width;
+ if (MBA >= MBAmax)
+ {
+ fillInMissingBlocks((void *)state);
+ if(imageInfo->fault) goto resync;
+
+ return OK_DECODE; /* error or at premature end of frame information */
+ }
}
if (!gobheader_read) {
@@ -1326,38 +1333,38 @@
REPLICATE(a,*p);
REPLICATE(b,*q);
c = edge;
- do {
+ while (c--) {
p -= next_row_plus_edge;
q -= next_row_minus_edge;
d = edge_8;
- do {
+ while (d--) {
*(UINT32 *)(p + 0) = a; // interleaving pointers may help in avoiding
*(UINT32 *)(q - 3) = b; // memory bank conflicts on Pentium...
*(UINT32 *)(p + 4) = a;
*(UINT32 *)(q - 7) = b;
p += 8;
q -= 8;
- } while (--d);
- } while (--c);
+ }
+ }
/* expand left and right edges: */
p = ptr;
q = qptr;
- do {
+ while (height--) {
REPLICATE(a,*p);
REPLICATE(b,*q);
d = edge_8;
- do {
+ while (d--) {
*(UINT32 *)(p - 4) = a;
*(UINT32 *)(q + 1) = b;
*(UINT32 *)(p - 8) = a;
*(UINT32 *)(q + 5) = b;
p -= 8;
q += 8;
- } while (--d);
+ }
p += next_row_plus_edge;
q += next_row_minus_edge;
- } while (--height);
+ }
/* expand lower corners: */
p -= next_row;
@@ -1366,29 +1373,29 @@
REPLICATE(a,*p);
REPLICATE(b,*q);
c = edge;
- do {
+ while (c--) {
p += next_row_minus_edge;
q += next_row_plus_edge;
d = edge_8;
- do {
+ while (d--) {
*(UINT32 *)(p + 0) = a;
*(UINT32 *)(q - 3) = b;
*(UINT32 *)(p + 4) = a;
*(UINT32 *)(q - 7) = b;
p += 8;
q -= 8;
- } while (--d);
- } while (--c);
+ }
+ }
/* expand top and buttom edges: */
c = (unsigned int)width >> 2;
- do {
+ while (c--) {
p = ptr;
q = qptr;
a = *(UINT32 *)p;
b = *(UINT32 *)q;
d = edge_8;
- do {
+ while (d--) {
p -= next_row; q += next_row; *(UINT32 *)p = a;
*(UINT32 *)q = b;
p -= next_row; q += next_row; *(UINT32 *)p = a;
@@ -1405,10 +1412,10 @@
*(UINT32 *)q = b;
p -= next_row; q += next_row; *(UINT32 *)p = a;
*(UINT32 *)q = b;
- } while (--d);
+ }
ptr += 4;
qptr += 4;
- } while (--c);
+ }
}
#else
Index: datatype-restricted/rm/video/codec/rv1dec/decoder/postfltr.c
===================================================================
RCS file: /cvsroot/rarvcode-video/codec/rv1dec/decoder/postfltr.c,v
retrieving revision 1.2
diff -w -u -r1.2 postfltr.c
--- datatype-restricted/rm/video/codec/rv1dec/decoder/postfltr.c 2 Jun 2005 23:34:37 -0000 1.2
+++ datatype-restricted/rm/video/codec/rv1dec/decoder/postfltr.c 22 Jun 2010 23:01:41 -0000
@@ -167,11 +167,11 @@
static void __copy_image (unsigned char *dest, unsigned char *src,
int width, int height, int dest_pitch, int src_pitch)
{
- do {
+ while (height--) {
memcpy (dest, src, width); /* Flawfinder: ignore */
dest += dest_pitch;
src += src_pitch;
- } while (--height);
+ }
}
// PPC runs out of registers for the following two functions.
Index: datatype-restricted/rm/video/codec/g2mp4combo/dec/core_dec.cpp
===================================================================
RCS file: /cvsroot/rarvcode-mpeg4combo/codec/g2mp4combo/dec/core_dec.cpp,v
retrieving revision 1.5.12.1
diff -w -u -r1.5.12.1 core_dec.cpp
--- datatype-restricted/rm/video/codec/g2mp4combo/dec/core_dec.cpp 23 Oct 2009 10:39:57 -0000 1.5.12.1
+++ datatype-restricted/rm/video/codec/g2mp4combo/dec/core_dec.cpp 22 Jun 2010 23:01:43 -0000
@@ -2210,6 +2210,15 @@
}
goto start;
} else {
+ // PR# 259190 : Security Vuln.
+ // Trying to resize dst larger will cause heap overwrites past the end of dst.data buffer,
+ // which has already been allocated to a size determined from dst.format.dimensions.
+ if ( (m_FrameHdr.cpfmt.width * m_FrameHdr.cpfmt.height) > (dst.format.dimensions.width * dst.format.dimensions.height) )
+ {
+ Status = PIA_S_ERROR;
+ goto done;
+ }
+
dst.format.dimensions.width = m_FrameHdr.cpfmt.width;
dst.format.dimensions.height = m_FrameHdr.cpfmt.height;
dst.size = m_FrameHdr.cpfmt.width * m_FrameHdr.cpfmt.height;
@@ -2273,6 +2282,16 @@
goto start;
}
}
+
+ // PR# 259190 : Security Vuln.
+ // Trying to resize dst larger will cause heap overwrites past the end of dst.data buffer,
+ // which has already been allocated to a size determined from dst.format.dimensions.
+ if ( (m_FrameHdr.cpfmt.width * m_FrameHdr.cpfmt.height) > (dst.format.dimensions.width * dst.format.dimensions.height) )
+ {
+ Status = PIA_S_ERROR;
+ goto done;
+ }
+
dst.format.dimensions.width = m_FrameHdr.cpfmt.width;
dst.format.dimensions.height = m_FrameHdr.cpfmt.height;
dst.size = m_FrameHdr.cpfmt.width * m_FrameHdr.cpfmt.height;
From ext-shashi.merapala at nokia.com Fri Jul 2 13:37:07 2010
From: ext-shashi.merapala at nokia.com (ext-shashi.merapala@nokia.com)
Date: Fri Jul 2 20:19:42 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#442906 - Inc13 MS: Can't play
30s preview on 3.0 Server - Bug 10540
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-shashi.merapala@nokia.com
Reviewed by: shy.ward@nokia.com
Date: 07/02/2010
Project: SymbianMmf_wm
Error Id: ou1cimx1#442906
Synopsis: Inc13 MS: Can't play 30s preview on 3.0 Server - Bug 10540
Overview: It is observed that the timer used for DNS resolution (RESOLVE_TIMEOUT = 20000) times out in certain cases due to delays in the connection process. Because of which we receive "Unable to connect to server" message.
Solution: Hence, increasing the time-out values for resolution and connection fixes this issue. As such, the following values are being proposed for RESOLVE_TIMEOUT and CONNECT_TIMEOUT -
RESOLVE_TIMEOUT = 100000
CONNECT_TIMEOUT = 50000
The proposed change is in basesession.h which is common across all the platforms, but as these time-out values are used to handle any erroneous conditions during opening a connection, this change should be alright for other platforms as well.
However, if other platforms get impacted by this change, it is also fine to guard this change under platform #ifdef _SYMBIAN.
Diff below.
Files added: None
Files modified: \datatype-restricted\wm\rtsp\import\wmrtsp-porting-kit\network\client\common\basesession.h
Image size and heap use impact: Negligible
Module release testing (STIF): Done. Passed.
Test case(s) added: No
Memory leak check performed: NA
Platforms and profiles build verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and profiles functionality verified: armv5, winscw
Branch: 210CayS, HEAD, 420Brizo
Index: basesession.h
===================================================================
RCS file: /cvsroot/wmcode-protocol/rtsp/import/wmrtsp-porting-kit/network/client/common/basesession.h,v
retrieving revision 1.4.10.2
diff -u -w -r1.4.10.2 basesession.h
--- basesession.h 24 Jan 2008 19:52:35 -0000 1.4.10.2
+++ basesession.h 2 Jul 2010 20:25:14 -0000
@@ -295,9 +295,9 @@
enum
{
- RESOLVE_TIMEOUT = 20000,
- CONNECT_TIMEOUT = 5000,
- TOTAL_TIMEOUT = 25000,
+ RESOLVE_TIMEOUT = 100000,
+ CONNECT_TIMEOUT = 50000,
+ TOTAL_TIMEOUT = 150000,
};
protected:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100702/cca03d44/attachment-0001.html
From xzhao at real.com Mon Jul 5 03:37:28 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Mon Jul 5 10:18:26 2010
Subject: [datatype-dev] Render Optimization for TI omap3
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6753@SEAMBX.corp.real.com>
Hi, All
Please review attached patch for render optimization for TI omap3 board.
Overview:
In this render optimization, let omx wrapper allocate overlay buffer during port reconfiguration process. So after this point, omx hardware decoder will put decoded frame into overlay buffer directly in UYVY format, not need to do memory copy and color convert. In the implementation, new interface IID_IHXSiteCustomBuffer being defined, which could be used to allocate customized buffer like overlay buffer here from decoder.
Since TI RV decoder still not stable, some temp tweak has been added in COmxVideoDec.cpp to make RV work now, and will be removed when TI RV decoder improve.
Any comments are welcomed.
Best Regards
Zhao Xiaolu
Tel extension: 2837
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.diff
Type: text/x-patch
Size: 3209 bytes
Desc: common.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100705/39de8208/common-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_omx.diff
Type: text/x-patch
Size: 11918 bytes
Desc: datatype_omx.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100705/39de8208/datatype_omx-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_rm.diff
Type: text/x-patch
Size: 3674 bytes
Desc: datatype_rm.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100705/39de8208/datatype_rm-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: video.diff
Type: text/x-patch
Size: 11588 bytes
Desc: video.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100705/39de8208/video-0001.bin
From ext-sowmya.kanni at nokia.com Mon Jul 5 22:15:43 2010
From: ext-sowmya.kanni at nokia.com (ext-sowmya.kanni@nokia.com)
Date: Tue Jul 6 04:57:00 2010
Subject: [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
Pause and Resume playback it fails to play at EOF
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-sowmya.kanni@nokia.com
Reviewed by: rajesh.rathinasamy@nokia.com
RC Id: ou1cimx1#436751
Date: 07/06/2010
Project: SymbianMmf_wm
Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
Fix: This issue needs two fixes.
1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
Files modified & changes:
/datatype/xps/fileformat/CXPSFileformat.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done
Test case(s) Added : No
Memory leak check performed : NA
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5
Branch: 210CayS, 420Brizo and HEAD
-------------- next part --------------
Index: CXPSFileformat.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/fileformat/CXPSFileformat.cpp,v
retrieving revision 1.1.1.1.2.18
diff -u -w -r1.1.1.1.2.18 CXPSFileformat.cpp
--- CXPSFileformat.cpp 27 May 2010 08:36:25 -0000 1.1.1.1.2.18
+++ CXPSFileformat.cpp 6 Jul 2010 04:28:19 -0000
@@ -1277,6 +1277,10 @@
void CMediaStream::Reset()
{
HXLOGL2(HXLOG_SXPS, "CMediaStream[%d]::Reset", m_ulStreamId);
+
+ //Reset the flag m_bStreamEnd
+ m_bStreamEnd = FALSE;
+
m_ulLastPktSeqNoDispatched = MAX_UINT32;
ResetQue();
From sgarg at real.com Tue Jul 6 02:35:52 2010
From: sgarg at real.com (Sushant Garg)
Date: Tue Jul 6 09:16:33 2010
Subject: [datatype-dev] CR: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
Message-ID: <4C330708.807@real.com>
*Project: RealPlayer for Netbook*
*Synopsis:*
Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
* *
*Overview:*
Added support to play AVI ADTS files.
Created a new mime type for such files & handle their parsing in mp4
renderer.
*Files Modified:
*/cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
/cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
/cvsroot/datatype/mp4/payload/mp4apyld.cpp
/cvsroot/datatype/mp4/payload/pub/mp4apyld.h
/cvsroot/datatype/avi/fileformat/avistrm.cpp
*Files Added: *
None
*Platforms and Profiles Affected:
*Linux
*Distribution Libraries Affected:*
None.
*Platforms and Profiles Build Verified:
Bif:* realplay_gtk_atlas_restricted_gold_1.2
*Profile:* helix-client-moblin
*Target:* mediasinkplayer
*Branch:*
Atlas3_4_10, Atlas310
*Attachment:*
diff.txt
Thanks & Regards,
Sushant
-------------- next part --------------
Index: mp4audio.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp,v
retrieving revision 1.23.16.2
diff -u -r1.23.16.2 mp4audio.cpp
--- mp4audio.cpp 2 Nov 2009 07:45:26 -0000 1.23.16.2
+++ mp4audio.cpp 6 Jul 2010 07:17:23 -0000
@@ -97,6 +97,7 @@
"audio/mpeg4-simple-A2",
"audio/mpeg4-generic",
"audio/X-HX-AAC-GENERIC",
+ "audio/X-HX-AAC-AVIADTS",
#endif /* #if defined(HELIX_FEATURE_AUDIO_CODEC_AAC) || defined(HELIX_FEATURE_AUDIO_CODEC_RAAC) */
#if defined(HELIX_FEATURE_AUDIO_CODEC_AMRNB)
"audio/X-RN-3GPP-AMR",
Index: raacdecinfo.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp,v
retrieving revision 1.6
diff -u -r1.6 raacdecinfo.cpp
--- raacdecinfo.cpp 14 Mar 2005 19:17:42 -0000 1.6
+++ raacdecinfo.cpp 6 Jul 2010 07:17:23 -0000
@@ -39,7 +39,8 @@
HXBOOL CRAACDecInfo::IsMatch(const char* pMimeType, IMP4APayloadFormat* pRssm)
{
return CAACDecInfo::IsMatch(pMimeType, pRssm) ||
- (!strcasecmp("audio/X-HX-AAC-GENERIC", pMimeType));
+ (!strcasecmp("audio/X-HX-AAC-GENERIC", pMimeType)) ||
+ (!strcasecmp("audio/X-HX-AAC-AVIADTS", pMimeType));
}
const char* CRAACDecInfo::GetLibName(void)
Index: mp4apyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
retrieving revision 1.14.14.1
diff -u -r1.14.14.1 mp4apyld.cpp
--- mp4apyld.cpp 4 Jul 2008 07:15:23 -0000 1.14.14.1
+++ mp4apyld.cpp 6 Jul 2010 07:18:34 -0000
@@ -67,6 +67,10 @@
#include "mp4apyld.h"
#include "mp4pyldutil.h"
+#define DEFAULT_AUDIO_CONFIG 0
+#define DEFAULT_AUDIO_CONFIG_SIZE 0
+#define DEFAULT_AUDIO_CONFIG_TYPE 2
+
MP4APayloadFormat::MP4APayloadFormat()
: m_lRefCount (0)
, m_pClassFactory (NULL)
@@ -286,6 +290,10 @@
{
m_PayloadID = PYID_X_HX_AAC_GENERIC;
}
+ else if (strcasecmp(pMimeTypeData, "audio/X-HX-AAC-AVIADTS") == 0)
+ {
+ m_PayloadID = PYID_X_HX_AAC_AVIADTS;
+ }
else if (strcasecmp(pMimeTypeData, "audio/X-HX-3GPP-QCELP") == 0)
{
m_PayloadID = PYID_X_HX_3GPP_QCELP;
@@ -310,6 +318,9 @@
case PYID_X_HX_AAC_GENERIC:
retVal = SetAssemblerAACGenericHeader(pHeader);
break;
+ case PYID_X_HX_AAC_AVIADTS:
+ retVal = SetAssemblerAACAVIADTS(pHeader);
+ break;
case PYID_X_HX_3GPP_QCELP:
retVal = SetAssemblerQCELPHeader(pHeader);
break;
@@ -378,6 +388,14 @@
return retVal;
}
+HX_RESULT MP4APayloadFormat::SetAssemblerAACAVIADTS(IHXValues* pHeader)
+{
+ m_pAudioConfig = DEFAULT_AUDIO_CONFIG;
+ m_ulAudioConfigSize = DEFAULT_AUDIO_CONFIG_SIZE;
+ m_unAudioConfigType = DEFAULT_AUDIO_CONFIG_TYPE;
+ return HXR_OK;
+}
+
HX_RESULT MP4APayloadFormat::SetAssemblerHXHeader(IHXValues* pHeader)
{
ES_Descriptor ESDesc;
@@ -639,6 +657,7 @@
case PYID_X_HX_MP4_RAWAU:
case PYID_X_HX_QT_RAWAU:
case PYID_X_HX_AAC_GENERIC:
+ case PYID_X_HX_AAC_AVIADTS:
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
break;
@@ -794,6 +813,7 @@
switch (m_PayloadID)
{
case PYID_X_HX_AAC_GENERIC:
+ case PYID_X_HX_AAC_AVIADTS:
case PYID_X_HX_MP4_RAWAU:
case PYID_X_HX_QT_RAWAU:
retVal = CreateRawAUMediaPacket(pOutMediaPacket);
Index: pub/mp4apyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4apyld.h,v
retrieving revision 1.7.16.1
diff -u -r1.7.16.1 mp4apyld.h
--- pub/mp4apyld.h 4 Jul 2008 07:15:23 -0000 1.7.16.1
+++ pub/mp4apyld.h 6 Jul 2010 07:18:34 -0000
@@ -103,6 +103,7 @@
PYID_MPEG4_SIMPLE_A2,
PYID_MP4A_LATM,
PYID_X_HX_AAC_GENERIC,
+ PYID_X_HX_AAC_AVIADTS,
PYID_X_HX_3GPP_QCELP
} PayloadID;
@@ -114,6 +115,7 @@
HX_RESULT SetAssemblerHXHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerLATMHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerAACGenericHeader(IHXValues* pHeader);
+ HX_RESULT SetAssemblerAACAVIADTS(IHXValues* pHeader);
HX_RESULT SetAssemblerQCELPHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerLATMConfig(IHXValues* pHeader);
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.10.2.15
diff -u -r1.10.2.15 avistrm.cpp
--- avistrm.cpp 28 Oct 2009 20:50:11 -0000 1.10.2.15
+++ avistrm.cpp 6 Jul 2010 07:25:31 -0000
@@ -247,6 +247,7 @@
#define WAVE_FORMAT_DVM 0x2000 /* FAST Multimedia AG */
#define WAVE_FORMAT_EXTENSIBLE 0xFFFE /* Microsoft */
#define WAVE_FORMAT_DEVELOPMENT 0xFFFF /* new wave formats in development */
+#define WAVE_FORMAT_AAC_AVIADTS 0x00FF
#define VIDEO_FORMAT_H263 HX_MAKE4CC('3', '6', '2', 'H')
#define VIDEO_FORMAT_divx HX_MAKE4CC('x', 'v', 'i', 'd')
@@ -886,6 +887,11 @@
}
}
break;
+ case WAVE_FORMAT_AAC_AVIADTS:
+ {
+ pMimeType = "audio/X-HX-AAC-AVIADTS";
+ }
+ break;
default:
{
pMimeType = szMimeTypeACM;
From qluo at real.com Tue Jul 6 05:39:44 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Jul 6 12:20:36 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0
-XPS Streaming-
After We Pause and Resume playback it fails to play at EOF
In-Reply-To:
References:
Message-ID: <4C333220.5020503@real.com>
Looks good.
Qiang
On 7/5/2010 11:15 PM, ext-sowmya.kanni@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-sowmya.kanni@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> RC Id: ou1cimx1#436751
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>
> Fix: This issue needs two fixes.
> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>
> Files modified& changes:
> /datatype/xps/fileformat/CXPSFileformat.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> Test case(s) Added : No
>
> Memory leak check performed : NA
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, 420Brizo and HEAD
>
>
From jgordon at real.com Tue Jul 6 09:54:26 2010
From: jgordon at real.com (Jamie Gordon)
Date: Tue Jul 6 16:35:03 2010
Subject: [datatype-dev] CR: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C330708.807@real.com>
References: <4C330708.807@real.com>
Message-ID: <4C336DD2.8040901@real.com>
ok
On 7/6/2010 3:35 AM, Sushant Garg wrote:
> *Project: RealPlayer for Netbook*
>
> *Synopsis:*
>
> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>
> * *
>
> *Overview:*
>
> Added support to play AVI ADTS files.
>
> Created a new mime type for such files & handle their parsing in mp4
> renderer.
>
>
>
> *Files Modified:
> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>
> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>
> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>
> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>
> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>
>
>
> *Files Added: *
>
> None
>
>
>
> *Platforms and Profiles Affected:
> *Linux
>
> *Distribution Libraries Affected:*
> None.
>
> *Platforms and Profiles Build Verified:
> Bif:* realplay_gtk_atlas_restricted_gold_1.2
> *Profile:* helix-client-moblin
> *Target:* mediasinkplayer
>
>
> *Branch:*
> Atlas3_4_10, Atlas310
>
>
>
> *Attachment:*
>
> diff.txt
>
>
>
> Thanks & Regards,
>
> Sushant
>
>
From hxing at real.com Wed Jul 7 00:01:51 2010
From: hxing at real.com (hxing)
Date: Wed Jul 7 06:42:15 2010
Subject: [datatype-dev] bug10054 a rmvb file with realevent and imagemap do
not play
Message-ID: <20100707082958.8236C7AA84@spamwall.internal.helixcommunity.org>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_nullrend_cpp
Type: application/octet-stream
Size: 487 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100707/3fc6fc07/diff_nullrend_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_hxclient_361_atlas_bif
Type: application/octet-stream
Size: 826 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100707/3fc6fc07/diff_hxclient_361_atlas_bif-0001.obj
From ext-sowmya.kanni at nokia.com Wed Jul 7 00:43:52 2010
From: ext-sowmya.kanni at nokia.com (ext-sowmya.kanni@nokia.com)
Date: Wed Jul 7 07:24:57 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0
-XPS Streaming-
After We Pause and Resume playback it fails to play at EOF
In-Reply-To: <4C333220.5020503@real.com>
References:
<4C333220.5020503@real.com>
Message-ID:
Thanks Qiang,
Checked into 210CayS, 420Brizo and HEAD.
-----Original Message-----
From: ext Qiang Luo [mailto:qluo@real.com]
Sent: Tuesday, July 06, 2010 7:10 PM
To: Kanni Sowmya (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
Looks good.
Qiang
On 7/5/2010 11:15 PM, ext-sowmya.kanni@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-sowmya.kanni@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> RC Id: ou1cimx1#436751
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>
> Fix: This issue needs two fixes.
> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>
> Files modified& changes:
> /datatype/xps/fileformat/CXPSFileformat.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> Test case(s) Added : No
>
> Memory leak check performed : NA
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, 420Brizo and HEAD
>
>
From sfu at real.com Wed Jul 7 04:23:03 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Jul 7 11:03:41 2010
Subject: [datatype-dev] Re: [Android-port-dev] bug10054 a rmvb file with
realevent and imagemap do not play
In-Reply-To: <20100707082958.8236C7AA84@spamwall.internal.helixcommunity.org>
References: <20100707082958.8236C7AA84@spamwall.internal.helixcommunity.org>
Message-ID: <4C3471A7.4080204@real.com>
This looks ok.
I don't quite get why a preroll of 50ms in null renderer would cause
problem but since null renderer simply discards the incoming packets, it
doesn't really need a preroll. So, setting preroll to zero seems logical
anyway.
fxd
Henry Xing wrote:
>
> by: hxing@real.com
> Date: 06/25/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: a rmvb file with application/x-pn-realevent and
> application/x-pn-imagemap do not play
>
>
> Overview: this rmvb media include two additional streams
> application/x-pn-realvent and application/x-pn-imagemap except for
> audio and video stream. These two streams were not supported on phone,
> so send them to null render, remove image map render plugin. We should
> set the preroll to 0, it?s default value is 50, that can cause
> buffering about 60ms when send packet to render every time on phone,
> drop video frames because of too late than clock, video do no display
> on screen, maybe it do not happen on pc.
>
>
> Files Added:
> None
>
>
> Files Modified:
> datatype/null/renderer/nullrend.cpp
>
> build/bif-cvs/helix/client/build/BIF/hxclient_3_6_1_atlas.bif
>
>
> 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: 361atlas
>
>
>
>
>
>
>
>
>
From jgordon at real.com Wed Jul 7 07:50:56 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 7 14:31:21 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: Provide support for
playing PlayReady encrypted media clips
In-Reply-To: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4C34A260.7080101@real.com>
What is the purpose of the "replicated data"? Why does it need to be
carried in the packets separately from the regular buffer?
On 6/30/2010 3:13 PM, ext-sanket.lopes@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-sanket.lopes@nokia.com
>
>
>
> Reviewed by: anshuman.tewari@nokia.com
>
>
>
> TSW Id:
>
>
>
> Date: 06/30/2010
>
>
>
> Project: symbian_client_apps
>
>
>
> Synopsis: Provide support for playing PlayReady encrypted media clips on
> 420Brizo.
>
>
>
> Overview: Microsoft PlayReady content access technology is a new content
> access technology designed for digital entertainment services, devices
> and applications. Playready DRM protected files have clear headers only
> the data is encrypted. So Helix needs to recognize the file by
> interpreting the headers correctly, then read the encrypted Data and get
> it decrypted from WmDrmServer and then pass for playing. With this CR we
> are only submitting changes required for Helix to support Playready.
> WmDrmServer code is not yet available and so this Helix implementation
> is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
>
>
>
>
>
> Files modified & changes:
>
> /cvsroot/client/medpltfm/chxmedpltfm.cpp,v
>
> /cvsroot/client/common/system/hxcommn.cpp,v
>
>
>
> /cvsroot/common/include/ihxpckts.h,v
>
> /cvsroot/common/include/hxiids.h,v
>
>
>
> /cvsroot/common/container/pub/old_hxpckts.h,v
>
> /cvsroot/common/container/pub/chxpckts.h,v
>
> /cvsroot/common/container/old_hxpckts.cpp,v
>
> /cvsroot/common/container/chxpckts.cpp,v
>
>
>
> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>
> /cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
>
> /cvsroot/datatype/wm/common/pub/asf_guids.h,v
>
> /cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
>
> /cvsroot/datatype/wm/common/parse_video.cpp,v
>
> /cvsroot/datatype/wm/common/parse_audio.cpp,v
>
> /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>
> /cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
>
>
>
> /cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
>
> /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
>
> /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
>
> /cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
>
> /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
>
>
>
> /cvsroot/datatype/wm/wmdrm/guids.cpp,v
>
> /cvsroot/datatype/wm/wmdrm/symbian.pcf,v
>
> /cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
>
> /cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
>
>
>
>
>
>
>
> Image Size and Heap Use impact: No major impact
>
>
>
> Module Release testing (STIF) : Yes
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : No additional leaks introduced.
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5
>
>
>
> Branch: 420Bizo and HEAD
>
>
>
> Diff attached:
>
>
>
From jgordon at real.com Wed Jul 7 13:27:48 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 7 20:07:53 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: Provide support for
playing PlayReady encrypted media clips
In-Reply-To: <89F9BF23C080784180D44D7A8FEBA4292BC147EBD4@NOK-EUMSG-03.mgdnok.nokia.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
<4C34A260.7080101@real.com>
<89F9BF23C080784180D44D7A8FEBA4292BC147EBD4@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4C34F154.7010107@real.com>
Ahh, I see. Looks good!
On 7/7/2010 1:03 PM, ext-sanket.lopes@nokia.com wrote:
> Hi Jamie,
>
> Replicated Data is stored as part of the each packet in Windows Media files it may or may not be present in all files. For Playready file it is guaranteed to be present and this holds sampleid, which is like a key required by the wmdrm to decrypt the contents.
>
> You can always refer to ASF specification, however here is a snippet from the same
> ----------------------------------------------------------------------------------------------------------------------
> 4.1 Extended Stream Properties Object (optional, 1 per media stream)
> The Extended Stream Properties Object defines additional optional properties and characteristics of a digital media stream that are not described in the Stream Properties Object.
>
> Typically, the basic Stream Properties Object is present in the Header Object, and the Extended Stream Properties Object is present in the Header Extension Object. Sometimes, however, the Stream Properties Object for a stream may be embedded inside the Extended Stream Properties Object for that stream. This approach facilitates the creation of backward-compatible content and is appropriate for some of the scenarios discussed in section 8.
>
> This object has an optional provision to include application-specific or implementation-specific data attached to the payloads of each digital media sample stored within a Data Packet. This data can be looked at as digital media sample properties and is stored in the Replicated Data field of a payload header. The Payload Extension Systems fields of the Extended Stream Properties Object describes what this data is and is necessary for that data to be parsed, if present.
> ----------------------------------------------------------------------------------------------------------------------
>
> If we enable "HXASF_COPY_REPLICATED_DATA_INTO_PACKET" macro, it copies replicated data into the packet buffer even for non-playready contents (non-DRM WM clips) as well which we don't want. Otherwise WM DRM plugin needs to be loaded for all the clips and it has to chop-off replicated data from the buffer every time OnPacket() gets called for non-DRM protected clips.
>
> Taking our current approach makes sure execution for regular wma files is not altered in any way.
>
>
> Thanks,
> Sanket
>
>
> -----Original Message-----
> From: ext Jamie Gordon [mailto:jgordon@real.com]
> Sent: Wednesday, July 07, 2010 10:51 AM
> To: Lopes Sanket (EXT-Infovision/Dallas)
> Cc: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
>
> What is the purpose of the "replicated data"? Why does it need to be
> carried in the packets separately from the regular buffer?
>
> On 6/30/2010 3:13 PM, ext-sanket.lopes@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-sanket.lopes@nokia.com
>>
>>
>>
>> Reviewed by: anshuman.tewari@nokia.com
>>
>>
>>
>> TSW Id:
>>
>>
>>
>> Date: 06/30/2010
>>
>>
>>
>> Project: symbian_client_apps
>>
>>
>>
>> Synopsis: Provide support for playing PlayReady encrypted media clips on
>> 420Brizo.
>>
>>
>>
>> Overview: Microsoft PlayReady content access technology is a new content
>> access technology designed for digital entertainment services, devices
>> and applications. Playready DRM protected files have clear headers only
>> the data is encrypted. So Helix needs to recognize the file by
>> interpreting the headers correctly, then read the encrypted Data and get
>> it decrypted from WmDrmServer and then pass for playing. With this CR we
>> are only submitting changes required for Helix to support Playready.
>> WmDrmServer code is not yet available and so this Helix implementation
>> is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
>>
>>
>>
>>
>>
>> Files modified & changes:
>>
>> /cvsroot/client/medpltfm/chxmedpltfm.cpp,v
>>
>> /cvsroot/client/common/system/hxcommn.cpp,v
>>
>>
>>
>> /cvsroot/common/include/ihxpckts.h,v
>>
>> /cvsroot/common/include/hxiids.h,v
>>
>>
>>
>> /cvsroot/common/container/pub/old_hxpckts.h,v
>>
>> /cvsroot/common/container/pub/chxpckts.h,v
>>
>> /cvsroot/common/container/old_hxpckts.cpp,v
>>
>> /cvsroot/common/container/chxpckts.cpp,v
>>
>>
>>
>> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>>
>> /cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
>>
>> /cvsroot/datatype/wm/common/pub/asf_guids.h,v
>>
>> /cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
>>
>> /cvsroot/datatype/wm/common/parse_video.cpp,v
>>
>> /cvsroot/datatype/wm/common/parse_audio.cpp,v
>>
>> /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>>
>> /cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
>>
>>
>>
>> /cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
>>
>> /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
>>
>>
>>
>> /cvsroot/datatype/wm/wmdrm/guids.cpp,v
>>
>> /cvsroot/datatype/wm/wmdrm/symbian.pcf,v
>>
>> /cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
>>
>> /cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
>>
>>
>>
>>
>>
>>
>>
>> Image Size and Heap Use impact: No major impact
>>
>>
>>
>> Module Release testing (STIF) : Yes
>>
>>
>>
>> Test case(s) Added : No
>>
>>
>>
>> Memory leak check performed : No additional leaks introduced.
>>
>>
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-dsp
>>
>>
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>>
>>
>> Branch: 420Bizo and HEAD
>>
>>
>>
>> Diff attached:
>>
>>
>>
From sgarg at real.com Wed Jul 7 20:21:55 2010
From: sgarg at real.com (Sushant Garg)
Date: Thu Jul 8 03:02:07 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C336DD2.8040901@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com>
Message-ID: <4C355263.6080304@real.com>
Thanks Jamie,
Changes checked in to Atlas3410 & Atlas310.
Regards,
Sushant
Jamie Gordon wrote:
> ok
>
> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>
>> *Project: RealPlayer for Netbook*
>>
>> *Synopsis:*
>>
>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>
>> * *
>>
>> *Overview:*
>>
>> Added support to play AVI ADTS files.
>>
>> Created a new mime type for such files & handle their parsing in mp4
>> renderer.
>>
>>
>>
>> *Files Modified:
>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>
>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>
>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>
>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>
>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>
>>
>>
>> *Files Added: *
>>
>> None
>>
>>
>>
>> *Platforms and Profiles Affected:
>> *Linux
>>
>> *Distribution Libraries Affected:*
>> None.
>>
>> *Platforms and Profiles Build Verified:
>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>> *Profile:* helix-client-moblin
>> *Target:* mediasinkplayer
>>
>>
>> *Branch:*
>> Atlas3_4_10, Atlas310
>>
>>
>>
>> *Attachment:*
>>
>> diff.txt
>>
>>
>>
>> Thanks & Regards,
>>
>> Sushant
>>
>>
>>
> .
>
>
From sfu at real.com Wed Jul 7 21:18:29 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 8 03:58:40 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C355263.6080304@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com>
<4C355263.6080304@real.com>
Message-ID: <4C355FA5.7080200@real.com>
What's the stream format of X-HX-AAC-AVIADTS? We already added
X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
carries ADTS frames as packets and first frame as OapqueData. What is
different for AVIADTS? There might be a chance these two can be merged
as one.
And if AVIADTS is different and needed, this should go into Head too.
fxd
Sushant Garg wrote:
> Thanks Jamie,
>
> Changes checked in to Atlas3410 & Atlas310.
>
> Regards,
> Sushant
>
> Jamie Gordon wrote:
>
>> ok
>>
>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>
>>
>>> *Project: RealPlayer for Netbook*
>>>
>>> *Synopsis:*
>>>
>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>
>>> * *
>>>
>>> *Overview:*
>>>
>>> Added support to play AVI ADTS files.
>>>
>>> Created a new mime type for such files & handle their parsing in mp4
>>> renderer.
>>>
>>>
>>>
>>> *Files Modified:
>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>
>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>
>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>
>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>
>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>
>>>
>>>
>>> *Files Added: *
>>>
>>> None
>>>
>>>
>>>
>>> *Platforms and Profiles Affected:
>>> *Linux
>>>
>>> *Distribution Libraries Affected:*
>>> None.
>>>
>>> *Platforms and Profiles Build Verified:
>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>> *Profile:* helix-client-moblin
>>> *Target:* mediasinkplayer
>>>
>>>
>>> *Branch:*
>>> Atlas3_4_10, Atlas310
>>>
>>>
>>>
>>> *Attachment:*
>>>
>>> diff.txt
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Sushant
>>>
>>>
>>>
>>>
>> .
>>
>>
>>
>
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
>
From xzhao at real.com Thu Jul 8 02:51:24 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Thu Jul 8 09:31:37 2010
Subject: [datatype-dev] CR: Render Optimization for TI Omap3
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>
by: xzhao@real.com
Date: 07/08/2010
Project: RealPlayer for Android Smartphones
Synopsis: Render Optimization for TI Omap3 platform
Overview:
The basic idea is to let omx decoder place the decoded video frames into the omap3 overlay buffer directly in the overlay's native color format(UYVY), avoiding any memory copy
and color conversion.
This feature is controlled(enabled) by below 2 helix features:
HELIX_FEATURE_USE_SITEBUFFERS(newly added) is used for letting the decoder use site
provided buffers. In omx port reconfiguration, we know the video frame
width/height. This is the place where we allocate the overlay buffer
via new IHXSiteCustomBufferAllocator interface and instruct the omx decode to use
the overlay buffer via OMX_UseBuffer().
HELIX_FEATURE_USE_OMX_DECODED_BUFFERS is used for sending the overlay
buffer pointers to minisurf without touching the data. This part of the
code is also shared by the QC snapdragon optimization.
Thank you for Qiang, Sheldon and Eric's comments. Compare with previous version, improve list as below:
1) Change the interface name to be IHXSiteCustomBufferAllocator
2) Change variable name nOverlayFmt to nColorID, take out +#define
CID_UYVY 4 and pull the cid form the include file video/include/ciddefs.h
3) Add a size parameter to GetNumberOfCustomBuffers(UINT32 ulSize); add method RelaeseCustomBuffers() to release overlay buffer
4) Fix the method name to start with upper case letter
5) Make video site a friend class of CMiniBaseSurface under this optimization, so to manipulate some protected members (AllocateDestBuffers etc), this way will more conform to CMiniBaseSurface's code sequence
Files Added:
None
Files Modified:
include/hxiids.h
include/hxwin.h
common/CBaseOmxDec.cpp
common/pub/CBaseOmxDec.h
video/decoder/COmxVideoDec.cpp
video/decoder/COmxVideoDec.h
video/decoder/Umakefil
video/decoder/rv20strm.cpp
video/decoder/rv89helper.cpp
video/renderer/rvxvdec.cpp
video/renderer/rvxvdfmt.cpp
video/renderer/pub/rvxvdec.h
video/renderer/pub/rvxvdfmt.h
sitelib/minisite.cpp
sitelib/minisitebuild.cpp
sitelib/minisurf.cpp
sitelib/platform/unix/miniandroidsite.cpp
sitelib/platform/unix/miniandroidsurf_omap3.cpp
sitelib/pub/minisite.h
sitelib/pub/minisurf.h
sitelib/pub/platform/unix/miniandroidsite.h
sitelib/pub/platform/unix/miniandroidsurf_omap3.h
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: android-eclair-arm-omap34xx_zoom2
Profile: helix-client-android
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Platforms and Profiles Build Verified:
Platform: android-eclair-arm-omap34xx_zoom2
Profile: helix-client-android
Platforms and Profiles Functionality verified:
Platform: android-eclair-arm-omap34xx_zoom2
Profile: helix-client-android
Branch for: 310atlas
Best Regards
Zhao Xiaolu
Tel extension: 2837
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.diff
Type: text/x-patch
Size: 3560 bytes
Desc: common.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100708/f2667fb0/common-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_omx.diff
Type: text/x-patch
Size: 13777 bytes
Desc: datatype_omx.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100708/f2667fb0/datatype_omx-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_rm.diff
Type: text/x-patch
Size: 3658 bytes
Desc: datatype_rm.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100708/f2667fb0/datatype_rm-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: video.diff
Type: text/x-patch
Size: 11719 bytes
Desc: video.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100708/f2667fb0/video-0001.bin
From qluo at real.com Thu Jul 8 07:31:21 2010
From: qluo at real.com (Qiang Luo)
Date: Thu Jul 8 14:11:55 2010
Subject: [datatype-dev] CR: Render Optimization for TI Omap3
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>
Message-ID: <4C35EF49.3030003@real.com>
1) datatype/rm/video/renderer/pub/rvxvdfmt.h:
+ HXBOOL m_bDecoderMemMgt;
I didn't see m_bDecoderMemMgt get used in the diff. Do you need this somewhere else?
2) Please take out the per video frame debug log code.
The rest look good to me.
Qiang
On 7/8/2010 3:51 AM, Xiaolu Zhao wrote:
> by: xzhao@real.com
> Date: 07/08/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: Render Optimization for TI Omap3 platform
>
>
> Overview:
> The basic idea is to let omx decoder place the decoded video frames into the omap3 overlay buffer directly in the overlay's native color format(UYVY), avoiding any memory copy
> and color conversion.
>
> This feature is controlled(enabled) by below 2 helix features:
> HELIX_FEATURE_USE_SITEBUFFERS(newly added) is used for letting the decoder use site
> provided buffers. In omx port reconfiguration, we know the video frame
> width/height. This is the place where we allocate the overlay buffer
> via new IHXSiteCustomBufferAllocator interface and instruct the omx decode to use
> the overlay buffer via OMX_UseBuffer().
> HELIX_FEATURE_USE_OMX_DECODED_BUFFERS is used for sending the overlay
> buffer pointers to minisurf without touching the data. This part of the
> code is also shared by the QC snapdragon optimization.
>
> Thank you for Qiang, Sheldon and Eric's comments. Compare with previous version, improve list as below:
> 1) Change the interface name to be IHXSiteCustomBufferAllocator
> 2) Change variable name nOverlayFmt to nColorID, take out +#define
> CID_UYVY 4 and pull the cid form the include file video/include/ciddefs.h
> 3) Add a size parameter to GetNumberOfCustomBuffers(UINT32 ulSize); add method RelaeseCustomBuffers() to release overlay buffer
> 4) Fix the method name to start with upper case letter
> 5) Make video site a friend class of CMiniBaseSurface under this optimization, so to manipulate some protected members (AllocateDestBuffers etc), this way will more conform to CMiniBaseSurface's code sequence
>
> Files Added:
> None
>
>
> Files Modified:
> include/hxiids.h
> include/hxwin.h
> common/CBaseOmxDec.cpp
> common/pub/CBaseOmxDec.h
> video/decoder/COmxVideoDec.cpp
> video/decoder/COmxVideoDec.h
> video/decoder/Umakefil
> video/decoder/rv20strm.cpp
> video/decoder/rv89helper.cpp
> video/renderer/rvxvdec.cpp
> video/renderer/rvxvdfmt.cpp
> video/renderer/pub/rvxvdec.h
> video/renderer/pub/rvxvdfmt.h
> sitelib/minisite.cpp
> sitelib/minisitebuild.cpp
> sitelib/minisurf.cpp
> sitelib/platform/unix/miniandroidsite.cpp
> sitelib/platform/unix/miniandroidsurf_omap3.cpp
> sitelib/pub/minisite.h
> sitelib/pub/minisurf.h
> sitelib/pub/platform/unix/miniandroidsite.h
> sitelib/pub/platform/unix/miniandroidsurf_omap3.h
>
>
>
> Image Size and Heap Use impact (Client -Only):
> None
>
>
> Platforms and Profiles Affected:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
> Platforms and Profiles Build Verified:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Platforms and Profiles Functionality verified:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Branch for: 310atlas
>
>
> Best Regards
> Zhao Xiaolu
> Tel extension: 2837
From ext-sudhir.1.mishra at nokia.com Thu Jul 8 10:45:09 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Thu Jul 8 17:25:56 2010
Subject: [datatype-dev] CR: Video playback freezes,
then crashes when trying to play MKV video
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFA2D98F@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- 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.7
diff -u -w -r1.1.1.1.2.7 mkv_file_format.cpp
--- mkv_file_format.cpp 29 Jun 2010 10:13:10 -0000 1.1.1.1.2.7
+++ mkv_file_format.cpp 7 Jul 2010 14:21:23 -0000
@@ -83,6 +83,8 @@
#define DEFAULT_RTP_SAMPLES 90000
#define CONVERT_TO_MILI_SECOND 1000000 // MKV file format duration are in nanoseconds.
+#define MKV_ABSVAL(val) (((val) < 0) ? (-(val)) : (val))
+#define MKV_BFRAME_MAXIMUMDEPTH 16
const char* MkvUnknownMimeType[] =
{
@@ -134,7 +136,7 @@
m_pRequest(NULL), m_pFormatResponse(NULL), m_pScheduler(NULL),
m_pGetPacketReqQ(NULL), m_pMKVFileObject(NULL), m_pMKVHandle(NULL),
m_ulAdjustedPresentationVideoTime(0),m_ulRTPTimeScale(DEFAULT_RTP_SAMPLES),
- m_bResetPresentationTime(TRUE), m_ulTimeCodeOfLastBlock(0)
+ m_bResetPresentationTime(TRUE), m_ulTimeCodeOfLastBlock(0),m_ulminimumBlockDuration(0),m_uFrameReferenceCount(0)
{
HXLOGL3(HXLOG_MKVF, "Construct CMKVFileFormat this=%p", this);
}
@@ -575,8 +577,6 @@
// if $DEFAULTDURATION is zero it means duration of frames of track may not be constant
// If both $BLOCKDURATION and $DEFAULTDURATION is zero then, frame duration should be computed as
// difference of timecode of next block of same stream
- if(blockDuration == 0)
- {
if(trk->uDefaultDuration != 0)
{
blockDuration = trk->uDefaultDuration/CONVERT_TO_MILI_SECOND;
@@ -585,11 +585,17 @@
{
// If B-Frame are present uTimeCode is less than m_ulTimeCodeOfLastBlock
// as there is no way to know in advance so remember last one
- if(uTimeCode > m_ulTimeCodeOfLastBlock )
+ if(m_uFrameReferenceCount < MKV_BFRAME_MAXIMUMDEPTH )
+ {
+ blockDuration = MKV_ABSVAL(uTimeCode - m_ulTimeCodeOfLastBlock);
+ m_ulminimumBlockDuration=HX_MIN(m_ulminimumBlockDuration,blockDuration);
+ if(m_ulminimumBlockDuration == 0)
{
- blockDuration = uTimeCode - m_ulTimeCodeOfLastBlock;
+ m_ulminimumBlockDuration = blockDuration;
}
+ m_uFrameReferenceCount++;
}
+ blockDuration = m_ulminimumBlockDuration;
}
ulAdjustedPresentationTime = m_ulAdjustedPresentationVideoTime;
-------------- next part --------------
Index: mkv_file_format.h
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/pub/mkv_file_format.h,v
retrieving revision 1.1.1.1.2.2
diff -u -w -r1.1.1.1.2.2 mkv_file_format.h
--- mkv_file_format.h 27 Apr 2010 05:21:21 -0000 1.1.1.1.2.2
+++ mkv_file_format.h 7 Jul 2010 14:09:04 -0000
@@ -137,6 +137,8 @@
HXBOOL m_bResetPresentationTime;
UINT64 m_ulTimeCodeOfLastBlock;
UINT32 m_ulRTPTimeScale;
+ UINT64 m_ulminimumBlockDuration;
+ UINT32 m_uFrameReferenceCount;
INT32 m_lRefCount;
IUnknown* m_pContext;
From ext-sudhir.1.mishra at nokia.com Thu Jul 8 14:33:16 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Thu Jul 8 21:13:24 2010
Subject: [datatype-dev] CR: ESLM-869LV3 : Memory full error when seeking
forward on a long corrupted wmv file
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFA2DA33@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-anugrah.2.kashari@nokia.com
Reviewed by: Shy.Ward@nokia.com
TSW Id: ESLM-869LV3
Date: 07/06/2010
Project: SymbianMmf_wm
Synopsis: Memory full error when seeking forward on a long corrupted wmv file
Overview: Changes done for this error earlier (see attached e-mail for reference) has caused a regression because failure case for SendFileHeader() was not handled. The error appears with DRM content only.
Fix: In case of failure send IHXFormatResponse::FileHeaderReady() with appropriate error code.
Files modified & changes:
/datatype/wm/fileformat/asf_file_format_file.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done
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, 420Bizo and HEAD
Diff attached:
-------------- 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.20
diff -u -w -r1.5.4.20 asf_file_format_file.cpp
--- asf_file_format_file.cpp 25 Jun 2010 16:19:07 -0000 1.5.4.20
+++ asf_file_format_file.cpp 6 Jul 2010 05:16:06 -0000
@@ -1040,12 +1040,16 @@
m_bReadyToSentHeader = FALSE;
m_bIsContentSeekable = (INT64_TO_UINT32(m_ullASFObjectSize) != 0) ? TRUE : FALSE ;
retVal = SendFileHeader();
+ if(SUCCEEDED(retVal))
+ {
// Reset offset to start of packet;
m_ullSeekOffsetRequested = m_ullFirstASFPacketFileOffset;
// Set the state saying this is the final seek prior to calling SeekDone()
m_ulState = kStateGFHASFIndexObjectFinalSeekDonePending;
// Now seek the file object to the first ASF packet
DoSeek(m_ullSeekOffsetRequested);
+ HXLOGL1(HXLOG_ASFF, "CASFFileFormatFile::ReadDone m_ullSeekOffsetRequested %x line %d",m_ullSeekOffsetRequested,__LINE__);
+ }
}
}
else
@@ -1070,14 +1074,30 @@
m_bReadyToSentHeader = FALSE;
m_bIsContentSeekable = FALSE;
retVal = SendFileHeader();
+ if(SUCCEEDED(retVal))
+ {
// Reset offset to start of packet;
m_ullSeekOffsetRequested = m_ullFirstASFPacketFileOffset;
// Set the state saying this is the final seek prior to calling SeekDone()
m_ulState = kStateGFHASFIndexObjectFinalSeekDonePending;
// Now seek the file object to the first ASF packet
DoSeek(m_ullSeekOffsetRequested);
+ HXLOGL1(HXLOG_ASFF, "CASFFileFormatFile::ReadDone m_ullSeekOffsetRequested %d line %d",INT64_TO_UINT32(m_ullSeekOffsetRequested),__LINE__);
+ }
+
+ }
+
}
+ // If SendFileHeader() fails
+ if (FAILED(retVal))
+ {
+ // Set the state
+ m_ulState = kStateReady;
+ // Call back to the response interface
+ m_pFormatResponse->FileHeaderReady(retVal, NULL);
+ // Clear the return value
+ retVal = HXR_OK;
}
}
-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: CR: ESLM-869LV3 : Memory full error when seeking forward on a long
corrupted wmv file
Date: Thu, 24 Jun 2010 00:18:52 +0200
Size: 15437
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100709/2f556ba3/attachment-0001.mht
From xzhao at real.com Thu Jul 8 17:48:57 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Fri Jul 9 00:29:44 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IFJlbmRlciBPcHRpbWl6YXRpb24g?=
=?gb2312?B?Zm9yIFRJIE9tYXAz?=
In-Reply-To: <4C35EF49.3030003@real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>,
<4C35EF49.3030003@real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675C@SEAMBX.corp.real.com>
Qiang:
1) For variable m_bDecoderMemMgt, it is used CRVXVideoFormat::Init to let OMXVStream pass decoder buffer directly to render without touch the data. It has been added with feature HELIX_FEATURE_USE_OMX_DECODED_BUFFERS. Mp4 and wmv fileformat have this calling too (without macro embraced).
2) "take out the per video frame debug log code", done
3) There are some changes in android-eclair-arm-omap34xx_zoom2.cf as attached. Maybe I should commit those into 310atlas too, right?
Best Regards
Zhao Xiaolu
Tel extension: 2837
________________________________________
·¢¼þÈË: Qiang Luo
·¢ËÍʱ¼ä: 2010Äê7ÔÂ8ÈÕ 23:31
ÊÕ¼þÈË: Xiaolu Zhao
³ËÍ: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org; video-dev@helixcommunity.org
Ö÷Ìâ: Re: [datatype-dev] CR: Render Optimization for TI Omap3
1) datatype/rm/video/renderer/pub/rvxvdfmt.h:
+ HXBOOL m_bDecoderMemMgt;
I didn't see m_bDecoderMemMgt get used in the diff. Do you need this somewhere else?
2) Please take out the per video frame debug log code.
The rest look good to me.
Qiang
On 7/8/2010 3:51 AM, Xiaolu Zhao wrote:
> by: xzhao@real.com
> Date: 07/08/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: Render Optimization for TI Omap3 platform
>
>
> Overview:
> The basic idea is to let omx decoder place the decoded video frames into the omap3 overlay buffer directly in the overlay's native color format(UYVY), avoiding any memory copy
> and color conversion.
>
> This feature is controlled(enabled) by below 2 helix features:
> HELIX_FEATURE_USE_SITEBUFFERS(newly added) is used for letting the decoder use site
> provided buffers. In omx port reconfiguration, we know the video frame
> width/height. This is the place where we allocate the overlay buffer
> via new IHXSiteCustomBufferAllocator interface and instruct the omx decode to use
> the overlay buffer via OMX_UseBuffer().
> HELIX_FEATURE_USE_OMX_DECODED_BUFFERS is used for sending the overlay
> buffer pointers to minisurf without touching the data. This part of the
> code is also shared by the QC snapdragon optimization.
>
> Thank you for Qiang, Sheldon and Eric's comments. Compare with previous version, improve list as below:
> 1) Change the interface name to be IHXSiteCustomBufferAllocator
> 2) Change variable name nOverlayFmt to nColorID, take out +#define
> CID_UYVY 4 and pull the cid form the include file video/include/ciddefs.h
> 3) Add a size parameter to GetNumberOfCustomBuffers(UINT32 ulSize); add method RelaeseCustomBuffers() to release overlay buffer
> 4) Fix the method name to start with upper case letter
> 5) Make video site a friend class of CMiniBaseSurface under this optimization, so to manipulate some protected members (AllocateDestBuffers etc), this way will more conform to CMiniBaseSurface's code sequence
>
> Files Added:
> None
>
>
> Files Modified:
> include/hxiids.h
> include/hxwin.h
> common/CBaseOmxDec.cpp
> common/pub/CBaseOmxDec.h
> video/decoder/COmxVideoDec.cpp
> video/decoder/COmxVideoDec.h
> video/decoder/Umakefil
> video/decoder/rv20strm.cpp
> video/decoder/rv89helper.cpp
> video/renderer/rvxvdec.cpp
> video/renderer/rvxvdfmt.cpp
> video/renderer/pub/rvxvdec.h
> video/renderer/pub/rvxvdfmt.h
> sitelib/minisite.cpp
> sitelib/minisitebuild.cpp
> sitelib/minisurf.cpp
> sitelib/platform/unix/miniandroidsite.cpp
> sitelib/platform/unix/miniandroidsurf_omap3.cpp
> sitelib/pub/minisite.h
> sitelib/pub/minisurf.h
> sitelib/pub/platform/unix/miniandroidsite.h
> sitelib/pub/platform/unix/miniandroidsurf_omap3.h
>
>
>
> Image Size and Heap Use impact (Client -Only):
> None
>
>
> Platforms and Profiles Affected:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
> Platforms and Profiles Build Verified:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Platforms and Profiles Functionality verified:
> Platform: android-eclair-arm-omap34xx_zoom2
> Profile: helix-client-android
>
>
> Branch for: 310atlas
>
>
> Best Regards
> Zhao Xiaolu
> Tel extension: 2837
-------------- next part --------------
A non-text attachment was scrubbed...
Name: android-eclair-arm-omap34xx_zoom2.diff
Type: text/x-patch
Size: 701 bytes
Desc: android-eclair-arm-omap34xx_zoom2.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100708/0fe81815/android-eclair-arm-omap34xx_zoom2.bin
From qluo at real.com Thu Jul 8 18:36:42 2010
From: qluo at real.com (Qiang Luo)
Date: Fri Jul 9 01:17:15 2010
Subject: =?GB2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IFJlbmRlciBPcHRpbQ==?=
=?GB2312?B?aXphdGlvbiBmb3IgVEkgT21hcDM=?=
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675C@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>,
<4C35EF49.3030003@real.com>
<766B5A29D28DA442AB229AAEE2AFC44507F7BD675C@SEAMBX.corp.real.com>
Message-ID: <4C368B3A.3020508@real.com>
On 7/8/2010 6:48 PM, Xiaolu Zhao wrote:
> Qiang:
>
> 1) For variable m_bDecoderMemMgt, it is used CRVXVideoFormat::Init to l=
et OMXVStream pass decoder buffer directly to render without touch the da=
ta. It has been added with feature HELIX_FEATURE_USE_OMX_DECODED_BUFFERS.=
Mp4 and wmv fileformat have this calling too (without macro embraced).
>
> =20
OK.
> 2) "take out the per video frame debug log code", done
>
> 3) There are some changes in android-eclair-arm-omap34xx_zoom2.cf as at=
tached. Maybe I should commit those into 310atlas too, right?
>
> =20
Yes, please check in the build cf file for omap3.
Qiang
> Best Regards
> Zhao Xiaolu
> Tel extension: 2837
> ________________________________________
> =B7=A2=BC=FE=C8=CB: Qiang Luo
> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C28=C8=D5 23:31
> =CA=D5=BC=FE=C8=CB: Xiaolu Zhao
> =B3=AD=CB=CD: android-port-dev@helixcommunity.org; datatype-dev@helixco=
mmunity.org; video-dev@helixcommunity.org
> =D6=F7=CC=E2: Re: [datatype-dev] CR: Render Optimization for TI Omap3
>
> 1) datatype/rm/video/renderer/pub/rvxvdfmt.h:
> + HXBOOL m_bDecoderMemMgt;
> I didn't see m_bDecoderMemMgt get used in the diff. Do you need this s=
omewhere else?
>
> 2) Please take out the per video frame debug log code.
>
> The rest look good to me.
>
> Qiang
>
> On 7/8/2010 3:51 AM, Xiaolu Zhao wrote:
> =20
>> by: xzhao@real.com
>> Date: 07/08/2010
>>
>> Project: RealPlayer for Android Smartphones
>>
>>
>> Synopsis: Render Optimization for TI Omap3 platform
>>
>>
>> Overview:
>> The basic idea is to let omx decoder place the decoded video frames in=
to the omap3 overlay buffer directly in the overlay's native color format=
(UYVY), avoiding any memory copy
>> and color conversion.
>>
>> This feature is controlled(enabled) by below 2 helix features:
>> HELIX_FEATURE_USE_SITEBUFFERS(newly added) is used for letting the dec=
oder use site
>> provided buffers. In omx port reconfiguration, we know the video fram=
e
>> width/height. This is the place where we allocate the overlay buffer
>> via new IHXSiteCustomBufferAllocator interface and instruct the omx de=
code to use
>> the overlay buffer via OMX_UseBuffer().
>> HELIX_FEATURE_USE_OMX_DECODED_BUFFERS is used for sending the overlay
>> buffer pointers to minisurf without touching the data. This part of t=
he
>> code is also shared by the QC snapdragon optimization.
>>
>> Thank you for Qiang, Sheldon and Eric's comments. Compare with previou=
s version, improve list as below:
>> 1) Change the interface name to be IHXSiteCustomBufferAllocator
>> 2) Change variable name nOverlayFmt to nColorID, take out +#define
>> CID_UYVY 4 and pull the cid form the include file video/include/ciddef=
s.h
>> 3) Add a size parameter to GetNumberOfCustomBuffers(UINT32 ulSize); ad=
d method RelaeseCustomBuffers() to release overlay buffer
>> 4) Fix the method name to start with upper case letter
>> 5) Make video site a friend class of CMiniBaseSurface under this optim=
ization, so to manipulate some protected members (AllocateDestBuffers etc=
), this way will more conform to CMiniBaseSurface's code sequence
>>
>> Files Added:
>> None
>>
>>
>> Files Modified:
>> include/hxiids.h
>> include/hxwin.h
>> common/CBaseOmxDec.cpp
>> common/pub/CBaseOmxDec.h
>> video/decoder/COmxVideoDec.cpp
>> video/decoder/COmxVideoDec.h
>> video/decoder/Umakefil
>> video/decoder/rv20strm.cpp
>> video/decoder/rv89helper.cpp
>> video/renderer/rvxvdec.cpp
>> video/renderer/rvxvdfmt.cpp
>> video/renderer/pub/rvxvdec.h
>> video/renderer/pub/rvxvdfmt.h
>> sitelib/minisite.cpp
>> sitelib/minisitebuild.cpp
>> sitelib/minisurf.cpp
>> sitelib/platform/unix/miniandroidsite.cpp
>> sitelib/platform/unix/miniandroidsurf_omap3.cpp
>> sitelib/pub/minisite.h
>> sitelib/pub/minisurf.h
>> sitelib/pub/platform/unix/miniandroidsite.h
>> sitelib/pub/platform/unix/miniandroidsurf_omap3.h
>>
>>
>>
>> Image Size and Heap Use impact (Client -Only):
>> None
>>
>>
>> Platforms and Profiles Affected:
>> Platform: android-eclair-arm-omap34xx_zoom2
>> Profile: helix-client-android
>>
>>
>> Distribution Libraries Affected:
>> None
>>
>> Distribution library impact and planned action:
>> None
>>
>> Platforms and Profiles Build Verified:
>> Platform: android-eclair-arm-omap34xx_zoom2
>> Profile: helix-client-android
>>
>>
>> Platforms and Profiles Functionality verified:
>> Platform: android-eclair-arm-omap34xx_zoom2
>> Profile: helix-client-android
>>
>>
>> Branch for: 310atlas
>>
>>
>> Best Regards
>> Zhao Xiaolu
>> Tel extension: 2837
>> =20
> =20
From xzhao at real.com Thu Jul 8 19:24:22 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Fri Jul 9 02:07:38 2010
Subject: =?gb2312?B?tPC4tDogtPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IFJlbmRlciBPcHRpbWl6?=
=?gb2312?B?YXRpb24gZm9yIFRJIE9tYXAz?=
In-Reply-To: <4C368B3A.3020508@real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F7BD675A@SEAMBX.corp.real.com>,
<4C35EF49.3030003@real.com>
<766B5A29D28DA442AB229AAEE2AFC44507F7BD675C@SEAMBX.corp.real.com>,
<4C368B3A.3020508@real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6760@SEAMBX.corp.real.com>
UWlhbmc6DQoNCkFsbCBjaGVja2VkIGludG8gMzEwYXRsYXMuIFRoYW5rIHlvdSBzbyBtdWNoIGZv
ciB5b3VyIGd1aWRlcyBhbmQgaGVscCBkdXJpbmcgdGhlc2UgZGF5cywgSSByZWFsbHkgYXBwcmVj
aWF0ZSBpdC4NCg0KQmVzdCBSZWdhcmRzDQpaaGFvIFhpYW9sdQ0KVGVsIGV4dGVuc2lvbjogMjgz
Nw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBRaWFu
ZyBMdW8NCreiy83KsbzkOiAyMDEwxOo31MI5yNUgMTA6MzYNCsrVvP7IyzogWGlhb2x1IFpoYW8N
CrOty806IGFuZHJvaWQtcG9ydC1kZXZAaGVsaXhjb21tdW5pdHkub3JnOyBkYXRhdHlwZS1kZXZA
aGVsaXhjb21tdW5pdHkub3JnOyB2aWRlby1kZXZAaGVsaXhjb21tdW5pdHkub3JnDQrW98ziOiBS
ZTogtPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IFJlbmRlciBPcHRpbWl6YXRpb24gZm9yIFRJIE9t
YXAzDQoNCk9uIDcvOC8yMDEwIDY6NDggUE0sIFhpYW9sdSBaaGFvIHdyb3RlOg0KPiBRaWFuZzoN
Cj4NCj4gMSkgRm9yIHZhcmlhYmxlIG1fYkRlY29kZXJNZW1NZ3QsIGl0IGlzIHVzZWQgQ1JWWFZp
ZGVvRm9ybWF0OjpJbml0IHRvIGxldCBPTVhWU3RyZWFtIHBhc3MgZGVjb2RlciBidWZmZXIgZGly
ZWN0bHkgdG8gcmVuZGVyIHdpdGhvdXQgdG91Y2ggdGhlIGRhdGEuIEl0IGhhcyBiZWVuIGFkZGVk
IHdpdGggZmVhdHVyZSBIRUxJWF9GRUFUVVJFX1VTRV9PTVhfREVDT0RFRF9CVUZGRVJTLiBNcDQg
YW5kIHdtdiBmaWxlZm9ybWF0IGhhdmUgdGhpcyBjYWxsaW5nIHRvbyAod2l0aG91dCBtYWNybyBl
bWJyYWNlZCkuDQo+DQo+DQpPSy4NCj4gMikgInRha2Ugb3V0IHRoZSBwZXIgdmlkZW8gZnJhbWUg
ZGVidWcgbG9nIGNvZGUiLCBkb25lDQo+DQo+IDMpIFRoZXJlIGFyZSBzb21lIGNoYW5nZXMgaW4g
YW5kcm9pZC1lY2xhaXItYXJtLW9tYXAzNHh4X3pvb20yLmNmIGFzIGF0dGFjaGVkLiBNYXliZSBJ
IHNob3VsZCBjb21taXQgdGhvc2UgaW50byAzMTBhdGxhcyB0b28sIHJpZ2h0Pw0KPg0KPg0KWWVz
LCBwbGVhc2UgY2hlY2sgaW4gdGhlIGJ1aWxkIGNmIGZpbGUgZm9yIG9tYXAzLg0KDQpRaWFuZw0K
DQo+IEJlc3QgUmVnYXJkcw0KPiBaaGFvIFhpYW9sdQ0KPiBUZWwgZXh0ZW5zaW9uOiAyODM3DQo+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBRaWFu
ZyBMdW8NCj4gt6LLzcqxvOQ6IDIwMTDE6jfUwjjI1SAyMzozMQ0KPiDK1bz+yMs6IFhpYW9sdSBa
aGFvDQo+ILOty806IGFuZHJvaWQtcG9ydC1kZXZAaGVsaXhjb21tdW5pdHkub3JnOyBkYXRhdHlw
ZS1kZXZAaGVsaXhjb21tdW5pdHkub3JnOyB2aWRlby1kZXZAaGVsaXhjb21tdW5pdHkub3JnDQo+
INb3zOI6IFJlOiBbZGF0YXR5cGUtZGV2XSBDUjogUmVuZGVyIE9wdGltaXphdGlvbiBmb3IgVEkg
T21hcDMNCj4NCj4gMSkgZGF0YXR5cGUvcm0vdmlkZW8vcmVuZGVyZXIvcHViL3J2eHZkZm10Lmg6
DQo+ICsgICAgSFhCT09MICBtX2JEZWNvZGVyTWVtTWd0Ow0KPiBJIGRpZG4ndCBzZWUgbV9iRGVj
b2Rlck1lbU1ndCBnZXQgdXNlZCBpbiB0aGUgZGlmZi4gIERvIHlvdSBuZWVkIHRoaXMgc29tZXdo
ZXJlIGVsc2U/DQo+DQo+IDIpIFBsZWFzZSB0YWtlIG91dCB0aGUgcGVyIHZpZGVvIGZyYW1lIGRl
YnVnIGxvZyBjb2RlLg0KPg0KPiBUaGUgcmVzdCBsb29rIGdvb2QgdG8gbWUuDQo+DQo+IFFpYW5n
DQo+DQo+IE9uIDcvOC8yMDEwIDM6NTEgQU0sIFhpYW9sdSBaaGFvIHdyb3RlOg0KPg0KPj4gYnk6
IHh6aGFvQHJlYWwuY29tDQo+PiBEYXRlOiAwNy8wOC8yMDEwDQo+Pg0KPj4gUHJvamVjdDogUmVh
bFBsYXllciBmb3IgQW5kcm9pZCBTbWFydHBob25lcw0KPj4NCj4+DQo+PiBTeW5vcHNpczogUmVu
ZGVyIE9wdGltaXphdGlvbiBmb3IgVEkgT21hcDMgcGxhdGZvcm0NCj4+DQo+Pg0KPj4gT3ZlcnZp
ZXc6DQo+PiBUaGUgYmFzaWMgaWRlYSBpcyB0byBsZXQgb214IGRlY29kZXIgcGxhY2UgdGhlIGRl
Y29kZWQgdmlkZW8gZnJhbWVzIGludG8gdGhlIG9tYXAzIG92ZXJsYXkgYnVmZmVyIGRpcmVjdGx5
IGluIHRoZSBvdmVybGF5J3MgbmF0aXZlIGNvbG9yIGZvcm1hdChVWVZZKSwgYXZvaWRpbmcgYW55
IG1lbW9yeSBjb3B5DQo+PiBhbmQgY29sb3IgY29udmVyc2lvbi4NCj4+DQo+PiBUaGlzIGZlYXR1
cmUgaXMgY29udHJvbGxlZChlbmFibGVkKSBieSBiZWxvdyAyIGhlbGl4IGZlYXR1cmVzOg0KPj4g
SEVMSVhfRkVBVFVSRV9VU0VfU0lURUJVRkZFUlMobmV3bHkgYWRkZWQpIGlzIHVzZWQgZm9yIGxl
dHRpbmcgdGhlIGRlY29kZXIgdXNlIHNpdGUNCj4+IHByb3ZpZGVkIGJ1ZmZlcnMuICBJbiBvbXgg
cG9ydCByZWNvbmZpZ3VyYXRpb24sIHdlIGtub3cgdGhlIHZpZGVvIGZyYW1lDQo+PiB3aWR0aC9o
ZWlnaHQuICBUaGlzIGlzIHRoZSBwbGFjZSB3aGVyZSB3ZSBhbGxvY2F0ZSB0aGUgb3ZlcmxheSBi
dWZmZXINCj4+IHZpYSBuZXcgSUhYU2l0ZUN1c3RvbUJ1ZmZlckFsbG9jYXRvciBpbnRlcmZhY2Ug
YW5kIGluc3RydWN0IHRoZSBvbXggZGVjb2RlIHRvIHVzZQ0KPj4gdGhlIG92ZXJsYXkgYnVmZmVy
IHZpYSBPTVhfVXNlQnVmZmVyKCkuDQo+PiBIRUxJWF9GRUFUVVJFX1VTRV9PTVhfREVDT0RFRF9C
VUZGRVJTIGlzIHVzZWQgZm9yIHNlbmRpbmcgdGhlIG92ZXJsYXkNCj4+IGJ1ZmZlciBwb2ludGVy
cyB0byBtaW5pc3VyZiB3aXRob3V0IHRvdWNoaW5nIHRoZSBkYXRhLiAgVGhpcyBwYXJ0IG9mIHRo
ZQ0KPj4gY29kZSBpcyBhbHNvIHNoYXJlZCBieSB0aGUgUUMgc25hcGRyYWdvbiBvcHRpbWl6YXRp
b24uDQo+Pg0KPj4gVGhhbmsgeW91IGZvciBRaWFuZywgU2hlbGRvbiBhbmQgRXJpYydzIGNvbW1l
bnRzLiBDb21wYXJlIHdpdGggcHJldmlvdXMgdmVyc2lvbiwgaW1wcm92ZSBsaXN0IGFzIGJlbG93
Og0KPj4gMSkgQ2hhbmdlIHRoZSBpbnRlcmZhY2UgbmFtZSB0byBiZSBJSFhTaXRlQ3VzdG9tQnVm
ZmVyQWxsb2NhdG9yDQo+PiAyKSBDaGFuZ2UgdmFyaWFibGUgbmFtZSBuT3ZlcmxheUZtdCB0byBu
Q29sb3JJRCwgdGFrZSBvdXQgKyNkZWZpbmUNCj4+IENJRF9VWVZZIDQgYW5kIHB1bGwgdGhlIGNp
ZCBmb3JtIHRoZSBpbmNsdWRlIGZpbGUgdmlkZW8vaW5jbHVkZS9jaWRkZWZzLmgNCj4+IDMpIEFk
ZCBhIHNpemUgcGFyYW1ldGVyIHRvIEdldE51bWJlck9mQ3VzdG9tQnVmZmVycyhVSU5UMzIgdWxT
aXplKTsgYWRkIG1ldGhvZCBSZWxhZXNlQ3VzdG9tQnVmZmVycygpIHRvIHJlbGVhc2Ugb3Zlcmxh
eSBidWZmZXINCj4+IDQpIEZpeCB0aGUgbWV0aG9kIG5hbWUgdG8gc3RhcnQgd2l0aCB1cHBlciBj
YXNlIGxldHRlcg0KPj4gNSkgTWFrZSB2aWRlbyBzaXRlIGEgZnJpZW5kIGNsYXNzIG9mIENNaW5p
QmFzZVN1cmZhY2UgdW5kZXIgdGhpcyBvcHRpbWl6YXRpb24sIHNvIHRvIG1hbmlwdWxhdGUgc29t
ZSBwcm90ZWN0ZWQgbWVtYmVycyAoQWxsb2NhdGVEZXN0QnVmZmVycyBldGMpLCB0aGlzIHdheSB3
aWxsIG1vcmUgY29uZm9ybSB0byBDTWluaUJhc2VTdXJmYWNlJ3MgY29kZSBzZXF1ZW5jZQ0KPj4N
Cj4+IEZpbGVzIEFkZGVkOg0KPj4gTm9uZQ0KPj4NCj4+DQo+PiBGaWxlcyBNb2RpZmllZDoNCj4+
IGluY2x1ZGUvaHhpaWRzLmgNCj4+IGluY2x1ZGUvaHh3aW4uaA0KPj4gY29tbW9uL0NCYXNlT214
RGVjLmNwcA0KPj4gY29tbW9uL3B1Yi9DQmFzZU9teERlYy5oDQo+PiB2aWRlby9kZWNvZGVyL0NP
bXhWaWRlb0RlYy5jcHANCj4+IHZpZGVvL2RlY29kZXIvQ09teFZpZGVvRGVjLmgNCj4+IHZpZGVv
L2RlY29kZXIvVW1ha2VmaWwNCj4+IHZpZGVvL2RlY29kZXIvcnYyMHN0cm0uY3BwDQo+PiB2aWRl
by9kZWNvZGVyL3J2ODloZWxwZXIuY3BwDQo+PiB2aWRlby9yZW5kZXJlci9ydnh2ZGVjLmNwcA0K
Pj4gdmlkZW8vcmVuZGVyZXIvcnZ4dmRmbXQuY3BwDQo+PiB2aWRlby9yZW5kZXJlci9wdWIvcnZ4
dmRlYy5oDQo+PiB2aWRlby9yZW5kZXJlci9wdWIvcnZ4dmRmbXQuaA0KPj4gc2l0ZWxpYi9taW5p
c2l0ZS5jcHANCj4+IHNpdGVsaWIvbWluaXNpdGVidWlsZC5jcHANCj4+IHNpdGVsaWIvbWluaXN1
cmYuY3BwDQo+PiBzaXRlbGliL3BsYXRmb3JtL3VuaXgvbWluaWFuZHJvaWRzaXRlLmNwcA0KPj4g
c2l0ZWxpYi9wbGF0Zm9ybS91bml4L21pbmlhbmRyb2lkc3VyZl9vbWFwMy5jcHANCj4+IHNpdGVs
aWIvcHViL21pbmlzaXRlLmgNCj4+IHNpdGVsaWIvcHViL21pbmlzdXJmLmgNCj4+IHNpdGVsaWIv
cHViL3BsYXRmb3JtL3VuaXgvbWluaWFuZHJvaWRzaXRlLmgNCj4+IHNpdGVsaWIvcHViL3BsYXRm
b3JtL3VuaXgvbWluaWFuZHJvaWRzdXJmX29tYXAzLmgNCj4+DQo+Pg0KPj4NCj4+IEltYWdlIFNp
emUgYW5kIEhlYXAgVXNlIGltcGFjdCAoQ2xpZW50IC1Pbmx5KToNCj4+IE5vbmUNCj4+DQo+Pg0K
Pj4gUGxhdGZvcm1zIGFuZCBQcm9maWxlcyBBZmZlY3RlZDoNCj4+IFBsYXRmb3JtOiAgYW5kcm9p
ZC1lY2xhaXItYXJtLW9tYXAzNHh4X3pvb20yDQo+PiBQcm9maWxlOiBoZWxpeC1jbGllbnQtYW5k
cm9pZA0KPj4NCj4+DQo+PiBEaXN0cmlidXRpb24gTGlicmFyaWVzIEFmZmVjdGVkOg0KPj4gTm9u
ZQ0KPj4NCj4+IERpc3RyaWJ1dGlvbiBsaWJyYXJ5IGltcGFjdCBhbmQgcGxhbm5lZCBhY3Rpb246
DQo+PiBOb25lDQo+Pg0KPj4gUGxhdGZvcm1zIGFuZCBQcm9maWxlcyBCdWlsZCBWZXJpZmllZDoN
Cj4+IFBsYXRmb3JtOiBhbmRyb2lkLWVjbGFpci1hcm0tb21hcDM0eHhfem9vbTINCj4+IFByb2Zp
bGU6IGhlbGl4LWNsaWVudC1hbmRyb2lkDQo+Pg0KPj4NCj4+IFBsYXRmb3JtcyBhbmQgUHJvZmls
ZXMgRnVuY3Rpb25hbGl0eSB2ZXJpZmllZDoNCj4+IFBsYXRmb3JtOiBhbmRyb2lkLWVjbGFpci1h
cm0tb21hcDM0eHhfem9vbTINCj4+IFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRyb2lkDQo+Pg0K
Pj4NCj4+IEJyYW5jaCBmb3I6IDMxMGF0bGFzDQo+Pg0KPj4NCj4+IEJlc3QgUmVnYXJkcw0KPj4g
WmhhbyBYaWFvbHUNCj4+IFRlbCBleHRlbnNpb246IDI4MzcNCj4+DQo+DQoNCg==
From hxing at real.com Thu Jul 8 19:39:41 2010
From: hxing at real.com (hxing)
Date: Fri Jul 9 02:20:09 2010
Subject: [datatype-dev] bug9975 playback problem of a broken file
Message-ID: <20100709040751.4669595700@spamwall.internal.helixcommunity.org>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_hxflsrc_cpp
Type: application/octet-stream
Size: 519 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100709/fca58e7f/diff_hxflsrc_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_hxplay_cpp
Type: application/octet-stream
Size: 495 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100709/fca58e7f/diff_hxplay_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_intrstrm_cpp
Type: application/octet-stream
Size: 894 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100709/fca58e7f/diff_intrstrm_cpp-0001.obj
From ext-sudhir.1.mishra at nokia.com Fri Jul 9 14:38:39 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Fri Jul 9 21:18:36 2010
Subject: [datatype-dev] RE: ESLM-869LV3 : Memory full error when seeking
forward on a long corrupted wmv file
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFE8A944@NOK-EUMSG-02.mgdnok.nokia.com>
Any comments?
Regards,
Sudhir
-----Original Message-----
From: Mishra Sudhir.1 (EXT-Sasken/Dallas)
Sent: Thursday, July 08, 2010 5:33 PM
To: datatype-dev@helixcommunity.org
Cc: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Subject: CR: ESLM-869LV3 : Memory full error when seeking forward on a long corrupted wmv file
"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
Reviewed by: Shy.Ward@nokia.com
TSW Id: ESLM-869LV3
Date: 07/06/2010
Project: SymbianMmf_wm
Synopsis: Memory full error when seeking forward on a long corrupted wmv file
Overview: Changes done for this error earlier (see attached e-mail for reference) has caused a regression because failure case for SendFileHeader() was not handled. The error appears with DRM content only.
Fix: In case of failure send IHXFormatResponse::FileHeaderReady() with appropriate error code.
Files modified & changes:
/datatype/wm/fileformat/asf_file_format_file.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done
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, 420Bizo and HEAD
Diff attached:
-------------- 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.20
diff -u -w -r1.5.4.20 asf_file_format_file.cpp
--- asf_file_format_file.cpp 25 Jun 2010 16:19:07 -0000 1.5.4.20
+++ asf_file_format_file.cpp 6 Jul 2010 05:16:06 -0000
@@ -1040,12 +1040,16 @@
m_bReadyToSentHeader = FALSE;
m_bIsContentSeekable = (INT64_TO_UINT32(m_ullASFObjectSize) != 0) ? TRUE : FALSE ;
retVal = SendFileHeader();
+ if(SUCCEEDED(retVal))
+ {
// Reset offset to start of packet;
m_ullSeekOffsetRequested = m_ullFirstASFPacketFileOffset;
// Set the state saying this is the final seek prior to calling SeekDone()
m_ulState = kStateGFHASFIndexObjectFinalSeekDonePending;
// Now seek the file object to the first ASF packet
DoSeek(m_ullSeekOffsetRequested);
+ HXLOGL1(HXLOG_ASFF, "CASFFileFormatFile::ReadDone m_ullSeekOffsetRequested %x line %d",m_ullSeekOffsetRequested,__LINE__);
+ }
}
}
else
@@ -1070,14 +1074,30 @@
m_bReadyToSentHeader = FALSE;
m_bIsContentSeekable = FALSE;
retVal = SendFileHeader();
+ if(SUCCEEDED(retVal))
+ {
// Reset offset to start of packet;
m_ullSeekOffsetRequested = m_ullFirstASFPacketFileOffset;
// Set the state saying this is the final seek prior to calling SeekDone()
m_ulState = kStateGFHASFIndexObjectFinalSeekDonePending;
// Now seek the file object to the first ASF packet
DoSeek(m_ullSeekOffsetRequested);
+ HXLOGL1(HXLOG_ASFF, "CASFFileFormatFile::ReadDone m_ullSeekOffsetRequested %d line %d",INT64_TO_UINT32(m_ullSeekOffsetRequested),__LINE__);
+ }
+
+ }
+
}
+ // If SendFileHeader() fails
+ if (FAILED(retVal))
+ {
+ // Set the state
+ m_ulState = kStateReady;
+ // Call back to the response interface
+ m_pFormatResponse->FileHeaderReady(retVal, NULL);
+ // Clear the return value
+ retVal = HXR_OK;
}
}
-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: CR: ESLM-869LV3 : Memory full error when seeking forward on a long
corrupted wmv file
Date: Thu, 24 Jun 2010 00:18:52 +0200
Size: 15430
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100710/b84551ff/attachment.mht
From ext-sudhir.1.mishra at nokia.com Fri Jul 9 14:39:31 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Fri Jul 9 21:19:29 2010
Subject: [datatype-dev] RESEND CR: Video playback freezes,
then crashes when trying to play MKV video
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFE8A947@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- 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.7
diff -u -w -r1.1.1.1.2.7 mkv_file_format.cpp
--- mkv_file_format.cpp 29 Jun 2010 10:13:10 -0000 1.1.1.1.2.7
+++ mkv_file_format.cpp 7 Jul 2010 14:21:23 -0000
@@ -83,6 +83,8 @@
#define DEFAULT_RTP_SAMPLES 90000
#define CONVERT_TO_MILI_SECOND 1000000 // MKV file format duration are in nanoseconds.
+#define MKV_ABSVAL(val) (((val) < 0) ? (-(val)) : (val))
+#define MKV_BFRAME_MAXIMUMDEPTH 16
const char* MkvUnknownMimeType[] =
{
@@ -134,7 +136,7 @@
m_pRequest(NULL), m_pFormatResponse(NULL), m_pScheduler(NULL),
m_pGetPacketReqQ(NULL), m_pMKVFileObject(NULL), m_pMKVHandle(NULL),
m_ulAdjustedPresentationVideoTime(0),m_ulRTPTimeScale(DEFAULT_RTP_SAMPLES),
- m_bResetPresentationTime(TRUE), m_ulTimeCodeOfLastBlock(0)
+ m_bResetPresentationTime(TRUE), m_ulTimeCodeOfLastBlock(0),m_ulminimumBlockDuration(0),m_uFrameReferenceCount(0)
{
HXLOGL3(HXLOG_MKVF, "Construct CMKVFileFormat this=%p", this);
}
@@ -575,8 +577,6 @@
// if $DEFAULTDURATION is zero it means duration of frames of track may not be constant
// If both $BLOCKDURATION and $DEFAULTDURATION is zero then, frame duration should be computed as
// difference of timecode of next block of same stream
- if(blockDuration == 0)
- {
if(trk->uDefaultDuration != 0)
{
blockDuration = trk->uDefaultDuration/CONVERT_TO_MILI_SECOND;
@@ -585,11 +585,17 @@
{
// If B-Frame are present uTimeCode is less than m_ulTimeCodeOfLastBlock
// as there is no way to know in advance so remember last one
- if(uTimeCode > m_ulTimeCodeOfLastBlock )
+ if(m_uFrameReferenceCount < MKV_BFRAME_MAXIMUMDEPTH )
+ {
+ blockDuration = MKV_ABSVAL(uTimeCode - m_ulTimeCodeOfLastBlock);
+ m_ulminimumBlockDuration=HX_MIN(m_ulminimumBlockDuration,blockDuration);
+ if(m_ulminimumBlockDuration == 0)
{
- blockDuration = uTimeCode - m_ulTimeCodeOfLastBlock;
+ m_ulminimumBlockDuration = blockDuration;
}
+ m_uFrameReferenceCount++;
}
+ blockDuration = m_ulminimumBlockDuration;
}
ulAdjustedPresentationTime = m_ulAdjustedPresentationVideoTime;
-------------- next part --------------
Index: mkv_file_format.h
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/pub/mkv_file_format.h,v
retrieving revision 1.1.1.1.2.2
diff -u -w -r1.1.1.1.2.2 mkv_file_format.h
--- mkv_file_format.h 27 Apr 2010 05:21:21 -0000 1.1.1.1.2.2
+++ mkv_file_format.h 7 Jul 2010 14:09:04 -0000
@@ -137,6 +137,8 @@
HXBOOL m_bResetPresentationTime;
UINT64 m_ulTimeCodeOfLastBlock;
UINT32 m_ulRTPTimeScale;
+ UINT64 m_ulminimumBlockDuration;
+ UINT32 m_uFrameReferenceCount;
INT32 m_lRefCount;
IUnknown* m_pContext;
From qluo at real.com Fri Jul 9 14:47:35 2010
From: qluo at real.com (Qiang Luo)
Date: Fri Jul 9 21:27:47 2010
Subject: [datatype-dev] Re: [Android-port-dev] bug9975 playback problem of a
broken file
In-Reply-To: <20100709040751.4669595700@spamwall.internal.helixcommunity.org>
References: <20100709040751.4669595700@spamwall.internal.helixcommunity.org>
Message-ID: <4C37A707.7040305@real.com>
Henry,
Is the new fix independent of the original fix for bug9975 or
accumulative? If we can, we should avoid/minimize client core changes.
Gurpreet, could you please review this patch for Henry since you made
the original fix?
Thanks,
Qiang
On 7/8/2010 8:39 PM, Henry Xing wrote:
>
> by: hxing@real.com
> Date: 07/09/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: no error message output when seek or end of the actual data
> length to a broken file
>
>
> Overview: to this broken file, the file length and stream length have
> the save value 1 hour 51 minutes, but the actual data length is about
> 7 minutes. In my update when seek to the error position, the error
> message reported to hxplayer, in the original code, the error message
> will be ignored in SeekPlayer function. When play to the end of the
> data, according to the data length read is not equal to packet length,
> report error to hxplayer.
>
>
> Files Added:
> None
>
>
> Files Modified:
> client/core/hxplay.cpp
>
> client/core/hxflsrc.cpp
>
> datatype-restricted/rm/fileformat/intrstrm.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: 361atlas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100709/83893a0d/attachment.html
From jgordon at real.com Fri Jul 9 15:19:08 2010
From: jgordon at real.com (Jamie Gordon)
Date: Fri Jul 9 21:58:58 2010
Subject: [datatype-dev] CR: ESLM-869LV3 : Memory full error when seeking
forward on a long corrupted wmv file
In-Reply-To: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFA2DA33@NOK-EUMSG-02.mgdnok.nokia.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFA2DA33@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C37AE6C.3060007@real.com>
ok
On 7/8/2010 3:33 PM, 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-anugrah.2.kashari@nokia.com
>
> Reviewed by: Shy.Ward@nokia.com
>
> TSW Id: ESLM-869LV3
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Memory full error when seeking forward on a long corrupted wmv file
>
> Overview: Changes done for this error earlier (see attached e-mail for reference) has caused a regression because failure case for SendFileHeader() was not handled. The error appears with DRM content only.
>
> Fix: In case of failure send IHXFormatResponse::FileHeaderReady() with appropriate error code.
>
> Files modified & changes:
> /datatype/wm/fileformat/asf_file_format_file.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> 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, 420Bizo and HEAD
>
> Diff attached:
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> CR: ESLM-869LV3 : Memory full error when seeking forward on a long
> corrupted wmv file
> From:
> "ext-sudhir.1.mishra@nokia.com"
> Date:
> Wed, 23 Jun 2010 15:18:52 -0700
> To:
> "datatype-dev@helixcommunity.org"
>
> To:
> "datatype-dev@helixcommunity.org"
> CC:
> "ext-anugrah.2.kashari@nokia.com" ,
> "ext-v.gunashree@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-anugrah.2.kashari@nokia.com
>
> Reviewed by: Shy.Ward@nokia.com; girish.shetty@nokia.com
>
> TSW Id: ESLM-869LV3
>
> Date: 06/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Memory full error when seeking forward on a long corrupted wmv file
>
> Overview: For this content, when user seeks after playback has begun, "Memory Full" error message in shown and playback closes. Attached video file does not have index object so seek is not possible. Current implementation of ASF file format is that if index object is not available then seek to first packet and start sending packets from there (see the else case for m_ulState == kStateSeekIndexObjectHeaderReadDonePending in CASFFileFormatFile::ReadDone() ). So after seek ASF FF starts sending packet from very first payload and HXFileSource keeps appending them to the event list. But helix core does not process these events (or packets) as they are too old, and event-list keeps growing and helix finally runs out of memory.
>
> Fix: ASF FF looks for index object and load index object during first seek. If index object is not present then seek is not possible. This information need to be passed in stream header. So changes code to look for index object during header parsing and set "NonSeekable" flag accordingly.
>
> Files modified & changes:
> /datatype/wm/fileformat/asf_file_format_file.cpp
> /datatype/wm/fileformat/pub/asf_file_format_file.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> 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, 420Bizo and HEAD
>
> Diff: Attached.
>
From jgordon at real.com Fri Jul 9 15:23:25 2010
From: jgordon at real.com (Jamie Gordon)
Date: Fri Jul 9 22:03:14 2010
Subject: [datatype-dev] RESEND CR: Video playback freezes, then crashes
when trying to play MKV video
In-Reply-To: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFE8A947@NOK-EUMSG-02.mgdnok.nokia.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFE8A947@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C37AF6D.7050804@real.com>
ok
On 7/9/2010 3:39 PM, ext-sudhir.1.mishra@nokia.com wrote:
> Any comments?
>
> _____________________________________________
> *From: *Mishra Sudhir.1 (EXT-Sasken/Dallas)
> *Sent: *Thursday, July 08, 2010 1:45 PM
> *To: *datatype-dev@helixcommunity.org
> *Cc: *Manikanda G (EXT-Sasken/Bangalore)
> *Subject: *CR: Video playback freezes, then crashes when trying
> to play MKV video
>
> "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: Alvaro.Vaquero@nokia.com
>
> Date: 07 / 07 /2010
>
> Project: datatype-dev
>
> ErrorId: ou1cimx1#435472
> Synopsis: Video playback freezes, then crashes when trying to play MKV
> video.
> Overview: Reported clip does not have frame-duration information. In
> mkvfileformat module block-duration value was misinterpreted as
> frame-duration and which caused reading lots of Video and Audio packets
> from mkv. Eventually, this resulted in running out of memory leading to
> a crash .
>
> Solution: Since for the error reported clip, default duration is not
> available ( Default duration is not mandatory) and clip has B-Frames
> with 4 refs frames, computing the duration for each video frame from two
> consecutive frames/packets does not give correct value. So computing
> video frame duration as the minimum value among first 16 frames ( 16 is
> considered to be the maximum possibilities for reference frames for any
> clip).
>
> Modified files:
> \datatype\mkv\fileformat\mkv_file_format.cpp
> \datatype\mkv\fileformat\pub\mkv_file_format.h
> Image size and heap use impact: None
> Module Release testing (STIF): Done
> Test case(s) added: None
> Memory leak check performed: No new leaks introduced
> Branch(es) : cays 210, Brizo 420 and Head.
> Diff: Attached
>
>
From ext-anugrah.2.kashari at nokia.com Fri Jul 9 20:49:25 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Sat Jul 10 03:29:58 2010
Subject: [datatype-dev] CR: ESLM-869LV3 : Memory full error when seeking
forward on a long corrupted wmv file
In-Reply-To: <4C37AE6C.3060007@real.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFA2DA33@NOK-EUMSG-02.mgdnok.nokia.com>
<4C37AE6C.3060007@real.com>
Message-ID:
Thanks Jamie,
Checked in 210CayS, 420Bizo and HEAD.
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Jamie Gordon
Sent: Saturday, July 10, 2010 4:49 AM
To: Mishra Sudhir.1 (EXT-Sasken/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: ESLM-869LV3 : Memory full error when seeking forward on a long corrupted wmv file
ok
On 7/8/2010 3:33 PM, 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-anugrah.2.kashari@nokia.com
>
> Reviewed by: Shy.Ward@nokia.com
>
> TSW Id: ESLM-869LV3
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Memory full error when seeking forward on a long corrupted wmv file
>
> Overview: Changes done for this error earlier (see attached e-mail for reference) has caused a regression because failure case for SendFileHeader() was not handled. The error appears with DRM content only.
>
> Fix: In case of failure send IHXFormatResponse::FileHeaderReady() with appropriate error code.
>
> Files modified & changes:
> /datatype/wm/fileformat/asf_file_format_file.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> 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, 420Bizo and HEAD
>
> Diff attached:
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> CR: ESLM-869LV3 : Memory full error when seeking forward on a long
> corrupted wmv file
> From:
> "ext-sudhir.1.mishra@nokia.com"
> Date:
> Wed, 23 Jun 2010 15:18:52 -0700
> To:
> "datatype-dev@helixcommunity.org"
>
> To:
> "datatype-dev@helixcommunity.org"
> CC:
> "ext-anugrah.2.kashari@nokia.com" ,
> "ext-v.gunashree@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-anugrah.2.kashari@nokia.com
>
> Reviewed by: Shy.Ward@nokia.com; girish.shetty@nokia.com
>
> TSW Id: ESLM-869LV3
>
> Date: 06/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Memory full error when seeking forward on a long corrupted wmv file
>
> Overview: For this content, when user seeks after playback has begun, "Memory Full" error message in shown and playback closes. Attached video file does not have index object so seek is not possible. Current implementation of ASF file format is that if index object is not available then seek to first packet and start sending packets from there (see the else case for m_ulState == kStateSeekIndexObjectHeaderReadDonePending in CASFFileFormatFile::ReadDone() ). So after seek ASF FF starts sending packet from very first payload and HXFileSource keeps appending them to the event list. But helix core does not process these events (or packets) as they are too old, and event-list keeps growing and helix finally runs out of memory.
>
> Fix: ASF FF looks for index object and load index object during first seek. If index object is not present then seek is not possible. This information need to be passed in stream header. So changes code to look for index object during header parsing and set "NonSeekable" flag accordingly.
>
> Files modified & changes:
> /datatype/wm/fileformat/asf_file_format_file.cpp
> /datatype/wm/fileformat/pub/asf_file_format_file.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> 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, 420Bizo and HEAD
>
> Diff: Attached.
>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From ext-g.manikanda at nokia.com Fri Jul 9 22:38:14 2010
From: ext-g.manikanda at nokia.com (ext-g.manikanda@nokia.com)
Date: Sat Jul 10 05:18:03 2010
Subject: [datatype-dev] RESEND CR: Video playback freezes, then crashes
when trying to play MKV video
In-Reply-To: <4C37AF6D.7050804@real.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DCFE8A947@NOK-EUMSG-02.mgdnok.nokia.com>
<4C37AF6D.7050804@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE27978FEACA@NOK-EUMSG-02.mgdnok.nokia.com>
Thank You Jamie. Checked into 210CayS, 420Brizo and HEAD.
Regards,
Manikandan.G
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Jamie Gordon
Sent: Saturday, July 10, 2010 4:53 AM
To: Mishra Sudhir.1 (EXT-Sasken/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] RESEND CR: Video playback freezes, then crashes when trying to play MKV video
ok
On 7/9/2010 3:39 PM, ext-sudhir.1.mishra@nokia.com wrote:
> Any comments?
>
> _____________________________________________
> *From: *Mishra Sudhir.1 (EXT-Sasken/Dallas)
> *Sent: *Thursday, July 08, 2010 1:45 PM
> *To: *datatype-dev@helixcommunity.org
> *Cc: *Manikanda G (EXT-Sasken/Bangalore)
> *Subject: *CR: Video playback freezes, then crashes when trying
> to play MKV video
>
> "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: Alvaro.Vaquero@nokia.com
>
> Date: 07 / 07 /2010
>
> Project: datatype-dev
>
> ErrorId: ou1cimx1#435472
> Synopsis: Video playback freezes, then crashes when trying to play MKV
> video.
> Overview: Reported clip does not have frame-duration information. In
> mkvfileformat module block-duration value was misinterpreted as
> frame-duration and which caused reading lots of Video and Audio
> packets from mkv. Eventually, this resulted in running out of memory
> leading to a crash .
>
> Solution: Since for the error reported clip, default duration is not
> available ( Default duration is not mandatory) and clip has B-Frames
> with 4 refs frames, computing the duration for each video frame from
> two consecutive frames/packets does not give correct value. So
> computing video frame duration as the minimum value among first 16
> frames ( 16 is considered to be the maximum possibilities for
> reference frames for any clip).
>
> Modified files:
> \datatype\mkv\fileformat\mkv_file_format.cpp
> \datatype\mkv\fileformat\pub\mkv_file_format.h
> Image size and heap use impact: None
> Module Release testing (STIF): Done
> Test case(s) added: None
> Memory leak check performed: No new leaks introduced
> Branch(es) : cays 210, Brizo 420 and Head.
> Diff: Attached
>
>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From ext-anugrah.2.kashari at nokia.com Sat Jul 10 01:30:16 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Sat Jul 10 08:10:27 2010
Subject: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music playback stops
if you play around with progress bar
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
Reviewed by: Ashish.As.Gupta@nokia.com
TSW Id: : ESLM-86FLBD
RC Id : ou1cimx1#439939
Date: 07/10/2010
Project: SymbianMmf_wm
Synopsis: RPN 200: WMA Music playback stops if you play around with progress bar
Overview: Random seek on certain WMA clips results in audio getting stuck when using DSP decoder. The reason behind this are filler frames and a deadlock condition involving high water mark (HWM) and low water mark (LWM). For WMA if a filler frame is found then devsound buffer is not returned till new encoded data has been written to audio device( in CHXMDFAudioDevice::Write() ). But if m_pScheduler3 is paused (due to HWM) then Write() does not happen until LWM is reached and it will not reach LWM because devsound buffers are not being returned. Helix core calls CHXMDFAudioDevice::Write() to write the dummy PCM samples as returned by CHXMDFAudioDecoder::Decode(). In CHXMDFAudioDevice::Write(), encoded data is moved from buffer list to ready list when its presentation time is close to time as indicated by the PCM data. CHXMDFAudioDevice::Write() is called repeatedly to write small part of PCM data (dummy) in small chunk (in this case 50 ms). When buffer list is empty, filler frame is added for each such call.
Fix: Filler frames are added typically added only at end of stream to keep audio device alive while devsound is still processing data.
Files modified & changes:
/cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done. Tested with various contents with audio type WMA, AAC, AC3 and EAC3.
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, 420Bizo and HEAD
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.1.2.26
diff -u -w -r1.1.2.26 mdfauddevice.cpp
--- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
+++ mdfauddevice.cpp 10 Jul 2010 09:21:03 -0000
@@ -685,9 +685,13 @@
while(m_nBytesPCMToPlay >= m_pAudioFormat->m_uBytesPerFrame && m_pAudioFormat->m_uBytesPerFrame)
{
+ //Filler frames are typically added only at the end of the stream
+ if(m_bEndOfStreamSent)
+ {
m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
+ }
m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
- HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
+ HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
}
}
From ext-anugrah.2.kashari at nokia.com Sat Jul 10 01:46:47 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Sat Jul 10 08:27:05 2010
Subject: RESEND: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music
playback stops if you play around with progress bar
In-Reply-To:
References:
Message-ID:
Resending with new diff.
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.1.2.26
diff -u -w -r1.1.2.26 mdfauddevice.cpp
--- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
+++ mdfauddevice.cpp 10 Jul 2010 09:44:00 -0000
@@ -683,11 +683,13 @@
{
m_nBytesPCMToPlay += dataSize;
- while(m_nBytesPCMToPlay >= m_pAudioFormat->m_uBytesPerFrame && m_pAudioFormat->m_uBytesPerFrame)
+ //Filler frames are typically added only at the end of the stream
+ while(m_nBytesPCMToPlay >= m_pAudioFormat->m_uBytesPerFrame && m_pAudioFormat->m_uBytesPerFrame
+ && m_bEndOfStreamSent)
{
m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
- HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
+ HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
}
}
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Sent: Saturday, July 10, 2010 3:00 PM
To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music playback stops if you play around with progress bar
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
Reviewed by: Ashish.As.Gupta@nokia.com
TSW Id: : ESLM-86FLBD
RC Id : ou1cimx1#439939
Date: 07/10/2010
Project: SymbianMmf_wm
Synopsis: RPN 200: WMA Music playback stops if you play around with progress bar
Overview: Random seek on certain WMA clips results in audio getting stuck when using DSP decoder. The reason behind this are filler frames and a deadlock condition involving high water mark (HWM) and low water mark (LWM). For WMA if a filler frame is found then devsound buffer is not returned till new encoded data has been written to audio device( in CHXMDFAudioDevice::Write() ). But if m_pScheduler3 is paused (due to HWM) then Write() does not happen until LWM is reached and it will not reach LWM because devsound buffers are not being returned. Helix core calls CHXMDFAudioDevice::Write() to write the dummy PCM samples as returned by CHXMDFAudioDecoder::Decode(). In CHXMDFAudioDevice::Write(), encoded data is moved from buffer list to ready list when its presentation time is close to time as indicated by the PCM data. CHXMDFAudioDevice::Write() is called repeatedly to write small part of PCM data (dummy) in small chunk (in this case 50 ms). When buffer list is empty, filler frame is added for each such call.
Fix: Filler frames are added typically added only at end of stream to keep audio device alive while devsound is still processing data.
Files modified & changes:
/cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done. Tested with various contents with audio type WMA, AAC, AC3 and EAC3.
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, 420Bizo and HEAD
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.1.2.26
diff -u -w -r1.1.2.26 mdfauddevice.cpp
--- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
+++ mdfauddevice.cpp 10 Jul 2010 09:21:03 -0000
@@ -685,9 +685,13 @@
while(m_nBytesPCMToPlay >= m_pAudioFormat->m_uBytesPerFrame && m_pAudioFormat->m_uBytesPerFrame)
{
+ //Filler frames are typically added only at the end of the stream
+ if(m_bEndOfStreamSent)
+ {
m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
+ }
m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
- HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
+ HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
}
}
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From qluo at real.com Sat Jul 10 08:34:10 2010
From: qluo at real.com (Qiang Luo)
Date: Sat Jul 10 15:14:03 2010
Subject: [Nokia-private-dev] RESEND: [datatype-dev] CR: ESLM-86FLBD :
RPN 200: WMA Music playback stops if you play around with progress bar
In-Reply-To:
References:
Message-ID: <4C38A102.7080100@real.com>
Looks good.
Qiang
On 7/10/2010 2:46 AM, ext-anugrah.2.kashari@nokia.com wrote:
> Resending with new diff.
>
> Index: mdfauddevice.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
> retrieving revision 1.1.2.26
> diff -u -w -r1.1.2.26 mdfauddevice.cpp
> --- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
> +++ mdfauddevice.cpp 10 Jul 2010 09:44:00 -0000
> @@ -683,11 +683,13 @@
> {
> m_nBytesPCMToPlay += dataSize;
>
> - while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame)
> + //Filler frames are typically added only at the end of the stream
> + while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame
> +&& m_bEndOfStreamSent)
> {
> m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
> m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
> - HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
> + HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
> }
> }
>
>
> -----Original Message-----
> From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> Sent: Saturday, July 10, 2010 3:00 PM
> To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music playback stops if you play around with progress bar
>
> 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
>
> Reviewed by: Ashish.As.Gupta@nokia.com
>
> TSW Id: : ESLM-86FLBD
>
> RC Id : ou1cimx1#439939
>
> Date: 07/10/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: RPN 200: WMA Music playback stops if you play around with progress bar
>
> Overview: Random seek on certain WMA clips results in audio getting stuck when using DSP decoder. The reason behind this are filler frames and a deadlock condition involving high water mark (HWM) and low water mark (LWM). For WMA if a filler frame is found then devsound buffer is not returned till new encoded data has been written to audio device( in CHXMDFAudioDevice::Write() ). But if m_pScheduler3 is paused (due to HWM) then Write() does not happen until LWM is reached and it will not reach LWM because devsound buffers are not being returned. Helix core calls CHXMDFAudioDevice::Write() to write the dummy PCM samples as returned by CHXMDFAudioDecoder::Decode(). In CHXMDFAudioDevice::Write(), encoded data is moved from buffer list to ready list when its presentation time is close to time as indicated by the PCM data. CHXMDFAudioDevice::Write() is called repeatedly to write small part of PCM data (dummy) in small chunk (in this case 50 ms). When buffer list is empty, filler frame is added for each such call.
>
> Fix: Filler frames are added typically added only at end of stream to keep audio device alive while devsound is still processing data.
>
> Files modified& changes:
> /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done. Tested with various contents with audio type WMA, AAC, AC3 and EAC3.
>
> 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, 420Bizo and HEAD
>
> Index: mdfauddevice.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
> retrieving revision 1.1.2.26
> diff -u -w -r1.1.2.26 mdfauddevice.cpp
> --- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
> +++ mdfauddevice.cpp 10 Jul 2010 09:21:03 -0000
> @@ -685,9 +685,13 @@
>
> while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame)
> {
> + //Filler frames are typically added only at the end of the stream
> + if(m_bEndOfStreamSent)
> + {
> m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
> + }
> m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
> - HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
> + HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
> }
> }
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> _______________________________________________
> 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 Jul 11 20:39:33 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Mon Jul 12 03:19:24 2010
Subject: [Nokia-private-dev] RESEND: [datatype-dev] CR: ESLM-86FLBD :
RPN 200: WMA Music playback stops if you play around with progress bar
In-Reply-To: <4C38A102.7080100@real.com>
References:
<4C38A102.7080100@real.com>
Message-ID:
Thanks Qiang,
Checked in 210CayS. 420Bizo and HEAD already have this fix.
-----Original Message-----
From: ext Qiang Luo [mailto:qluo@real.com]
Sent: Saturday, July 10, 2010 10:04 PM
To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] RESEND: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music playback stops if you play around with progress bar
Looks good.
Qiang
On 7/10/2010 2:46 AM, ext-anugrah.2.kashari@nokia.com wrote:
> Resending with new diff.
>
> Index: mdfauddevice.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
> retrieving revision 1.1.2.26
> diff -u -w -r1.1.2.26 mdfauddevice.cpp
> --- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
> +++ mdfauddevice.cpp 10 Jul 2010 09:44:00 -0000
> @@ -683,11 +683,13 @@
> {
> m_nBytesPCMToPlay += dataSize;
>
> - while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame)
> + //Filler frames are typically added only at the end of the stream
> + while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame
> +&& m_bEndOfStreamSent)
> {
> m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
> m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
> - HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
> + HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
> }
> }
>
>
> -----Original Message-----
> From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> Sent: Saturday, July 10, 2010 3:00 PM
> To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: [datatype-dev] CR: ESLM-86FLBD : RPN 200: WMA Music playback stops if you play around with progress bar
>
> 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
>
> Reviewed by: Ashish.As.Gupta@nokia.com
>
> TSW Id: : ESLM-86FLBD
>
> RC Id : ou1cimx1#439939
>
> Date: 07/10/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: RPN 200: WMA Music playback stops if you play around with progress bar
>
> Overview: Random seek on certain WMA clips results in audio getting stuck when using DSP decoder. The reason behind this are filler frames and a deadlock condition involving high water mark (HWM) and low water mark (LWM). For WMA if a filler frame is found then devsound buffer is not returned till new encoded data has been written to audio device( in CHXMDFAudioDevice::Write() ). But if m_pScheduler3 is paused (due to HWM) then Write() does not happen until LWM is reached and it will not reach LWM because devsound buffers are not being returned. Helix core calls CHXMDFAudioDevice::Write() to write the dummy PCM samples as returned by CHXMDFAudioDecoder::Decode(). In CHXMDFAudioDevice::Write(), encoded data is moved from buffer list to ready list when its presentation time is close to time as indicated by the PCM data. CHXMDFAudioDevice::Write() is called repeatedly to write small part of PCM data (dummy) in small chunk (in this case 50 ms). When buffer list is empty, filler frame is added for each such call.
>
> Fix: Filler frames are added typically added only at end of stream to keep audio device alive while devsound is still processing data.
>
> Files modified& changes:
> /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done. Tested with various contents with audio type WMA, AAC, AC3 and EAC3.
>
> 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, 420Bizo and HEAD
>
> Index: mdfauddevice.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
> retrieving revision 1.1.2.26
> diff -u -w -r1.1.2.26 mdfauddevice.cpp
> --- mdfauddevice.cpp 8 Jun 2010 08:28:32 -0000 1.1.2.26
> +++ mdfauddevice.cpp 10 Jul 2010 09:21:03 -0000
> @@ -685,9 +685,13 @@
>
> while(m_nBytesPCMToPlay>= m_pAudioFormat->m_uBytesPerFrame&& m_pAudioFormat->m_uBytesPerFrame)
> {
> + //Filler frames are typically added only at the end of the stream
> + if(m_bEndOfStreamSent)
> + {
> m_readyList.AddTail(&m_pAudioFormat->m_fillerFrame);
> + }
> m_nBytesPCMToPlay -= m_pAudioFormat->m_uBytesPerFrame;
> - HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame");
> + HXLOGL4(HXLOG_MDFA,"mdfdev:write .. adding filler frame m_bEndOfStreamSent:%d", m_bEndOfStreamSent);
> }
> }
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
> .
>
>
From jgordon at real.com Mon Jul 12 11:19:11 2010
From: jgordon at real.com (Jamie Gordon)
Date: Mon Jul 12 17:58:37 2010
Subject: [datatype-dev] bug9975 playback problem of a broken file
In-Reply-To: <20100709040751.4669595700@spamwall.internal.helixcommunity.org>
References: <20100709040751.4669595700@spamwall.internal.helixcommunity.org>
Message-ID: <4C3B6AAF.3080805@real.com>
> + if(status)
> + {
> + if(!(m_bIsDone&&m_LastError))
These should use the SUCCEEDED/FAILED macros
Otherwise looks good.
On 7/8/2010 8:39 PM, Henry Xing wrote:
> by: hxing@real.com
> Date: 07/09/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: no error message output when seek or end of the actual data
> length to a broken file
>
>
> Overview: to this broken file, the file length and stream length have
> the save value 1 hour 51 minutes, but the actual data length is about 7
> minutes. In my update when seek to the error position, the error message
> reported to hxplayer, in the original code, the error message will be
> ignored in SeekPlayer function. When play to the end of the data,
> according to the data length read is not equal to packet length, report
> error to hxplayer.
>
>
> Files Added:
> None
>
>
> Files Modified:
> client/core/hxplay.cpp
>
> client/core/hxflsrc.cpp
>
> datatype-restricted/rm/fileformat/intrstrm.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: 361atlas
>
>
>
From hxing at real.com Mon Jul 12 22:50:30 2010
From: hxing at real.com (Henry Xing)
Date: Tue Jul 13 05:29:25 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gYnVnOTk3NSBwbGF5YmFjayBwcm9ibGVt?=
=?gb2312?B?IG9mIGEgYnJva2VuIGZpbGU=?=
In-Reply-To: <4C3B6AAF.3080805@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07E7FE24D8@SEAMBX.corp.real.com>
Update using FAILED macro, please help to review again. If no problems I will check it into 361 branches.
Thanks a lot1
henry
-----ÓʼþÔ¼þ-----
·¢¼þÈË: Jamie Gordon
·¢ËÍʱ¼ä: 2010Äê7ÔÂ13ÈÕ 3:19
ÊÕ¼þÈË: Henry Xing
³ËÍ: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Ö÷Ìâ: Re: [datatype-dev] bug9975 playback problem of a broken file
> + if(status)
> + {
> + if(!(m_bIsDone&&m_LastError))
These should use the SUCCEEDED/FAILED macros
Otherwise looks good.
On 7/8/2010 8:39 PM, Henry Xing wrote:
> by: hxing@real.com
> Date: 07/09/2010
>
> Project: RealPlayer for Android Smartphones
>
>
> Synopsis: no error message output when seek or end of the actual data
> length to a broken file
>
>
> Overview: to this broken file, the file length and stream length have
> the save value 1 hour 51 minutes, but the actual data length is about 7
> minutes. In my update when seek to the error position, the error message
> reported to hxplayer, in the original code, the error message will be
> ignored in SeekPlayer function. When play to the end of the data,
> according to the data length read is not equal to packet length, report
> error to hxplayer.
>
>
> Files Added:
> None
>
>
> Files Modified:
> client/core/hxplay.cpp
>
> client/core/hxflsrc.cpp
>
> datatype-restricted/rm/fileformat/intrstrm.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: 361atlas
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_hxplay_cpp
Type: application/octet-stream
Size: 506 bytes
Desc: diff_hxplay_cpp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100712/114720e3/diff_hxplay_cpp.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_hxflsrc_cpp
Type: application/octet-stream
Size: 528 bytes
Desc: diff_hxflsrc_cpp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100712/114720e3/diff_hxflsrc_cpp.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_intrstrm_cpp
Type: application/octet-stream
Size: 894 bytes
Desc: diff_intrstrm_cpp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100712/114720e3/diff_intrstrm_cpp.obj
From sgarg at real.com Mon Jul 12 23:33:53 2010
From: sgarg at real.com (Sushant Garg)
Date: Tue Jul 13 06:13:04 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C355FA5.7080200@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com>
<4C355263.6080304@real.com> <4C355FA5.7080200@real.com>
Message-ID: <4C3C16E1.2060808@real.com>
We can not use code written for AVIADTS, therefore merged my changes to
Head too.
Regards,
Sushant
Sheldon Fu wrote:
> What's the stream format of X-HX-AAC-AVIADTS? We already added
> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
> carries ADTS frames as packets and first frame as OapqueData. What is
> different for AVIADTS? There might be a chance these two can be merged
> as one.
>
> And if AVIADTS is different and needed, this should go into Head too.
>
> fxd
>
> Sushant Garg wrote:
>
>> Thanks Jamie,
>>
>> Changes checked in to Atlas3410 & Atlas310.
>>
>> Regards,
>> Sushant
>>
>> Jamie Gordon wrote:
>>
>>
>>> ok
>>>
>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>
>>>
>>>
>>>> *Project: RealPlayer for Netbook*
>>>>
>>>> *Synopsis:*
>>>>
>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>
>>>> * *
>>>>
>>>> *Overview:*
>>>>
>>>> Added support to play AVI ADTS files.
>>>>
>>>> Created a new mime type for such files & handle their parsing in mp4
>>>> renderer.
>>>>
>>>>
>>>>
>>>> *Files Modified:
>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>
>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>
>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>
>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>
>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>
>>>>
>>>>
>>>> *Files Added: *
>>>>
>>>> None
>>>>
>>>>
>>>>
>>>> *Platforms and Profiles Affected:
>>>> *Linux
>>>>
>>>> *Distribution Libraries Affected:*
>>>> None.
>>>>
>>>> *Platforms and Profiles Build Verified:
>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>> *Profile:* helix-client-moblin
>>>> *Target:* mediasinkplayer
>>>>
>>>>
>>>> *Branch:*
>>>> Atlas3_4_10, Atlas310
>>>>
>>>>
>>>>
>>>> *Attachment:*
>>>>
>>>> diff.txt
>>>>
>>>>
>>>>
>>>> Thanks & Regards,
>>>>
>>>> Sushant
>>>>
>>>>
>>>>
>>>>
>>>>
>>> .
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>
>>
>>
>
> .
>
>
From jgordon at real.com Tue Jul 13 00:09:39 2010
From: jgordon at real.com (Jamie Gordon)
Date: Tue Jul 13 06:48:44 2010
Subject: =?GB2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gYnVnOTk3NSBwbGF5YmFjaw==?=
=?GB2312?B?IHByb2JsZW0gb2YgYSBicm9rZW4gZmlsZQ==?=
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07E7FE24D8@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA07E7FE24D8@SEAMBX.corp.real.com>
Message-ID: <4C3C1F43.5050304@real.com>
looks good
Henry Xing wrote:
> Update using FAILED macro, please help to review again. If no problems=
I will check it into 361 branches.
> Thanks a lot1
> henry
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Jamie Gordon=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C213=C8=D5 3:19
> =CA=D5=BC=FE=C8=CB: Henry Xing
> =B3=AD=CB=CD: android-port-dev@helixcommunity.org; datatype-dev@helixco=
mmunity.org
> =D6=F7=CC=E2: Re: [datatype-dev] bug9975 playback problem of a broken f=
ile
>=20
>> + if(status)
>> + {
>=20
>=20
>> + if(!(m_bIsDone&&m_LastError))
>=20
>=20
> These should use the SUCCEEDED/FAILED macros
>=20
> Otherwise looks good.
>=20
> On 7/8/2010 8:39 PM, Henry Xing wrote:
>> by: hxing@real.com
>> Date: 07/09/2010
>>
>> Project: RealPlayer for Android Smartphones
>>
>>
>> Synopsis: no error message output when seek or end of the actual data=20
>> length to a broken file
>>
>>
>> Overview: to this broken file, the file length and stream length have=20
>> the save value 1 hour 51 minutes, but the actual data length is about =
7=20
>> minutes. In my update when seek to the error position, the error messa=
ge=20
>> reported to hxplayer, in the original code, the error message will be=20
>> ignored in SeekPlayer function. When play to the end of the data,=20
>> according to the data length read is not equal to packet length, repor=
t=20
>> error to hxplayer.
>>
>> =20
>> Files Added:
>> None
>>
>>
>> Files Modified:
>> client/core/hxplay.cpp
>>
>> client/core/hxflsrc.cpp
>>
>> datatype-restricted/rm/fileformat/intrstrm.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: 361atlas
>>
>> =20
>>
From sfu at real.com Tue Jul 13 11:52:22 2010
From: sfu at real.com (Sheldon Fu)
Date: Tue Jul 13 18:30:45 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C3C16E1.2060808@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com>
<4C355263.6080304@real.com> <4C355FA5.7080200@real.com>
<4C3C16E1.2060808@real.com>
Message-ID: <4C3CC3F6.30904@real.com>
Care to explain why the difference and 'can not use'?
I looked at the change you made for AVIADTS. It seems that you are
passing the ADTS frames directly to the decoder -- no stripping of th
ADTS headers and without any codec config data. I don't think this will
work with the default raac software decoder
(datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
config data is null and even that passes, it will expect raw AU unit as
input, instead of ADTS frame. Have you tried your solution on a generic
Linux build?
fxd
Sushant Garg wrote:
> We can not use code written for AVIADTS, therefore merged my changes to
> Head too.
>
> Regards,
> Sushant
>
> Sheldon Fu wrote:
>
>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>> carries ADTS frames as packets and first frame as OapqueData. What is
>> different for AVIADTS? There might be a chance these two can be merged
>> as one.
>>
>> And if AVIADTS is different and needed, this should go into Head too.
>>
>> fxd
>>
>> Sushant Garg wrote:
>>
>>
>>> Thanks Jamie,
>>>
>>> Changes checked in to Atlas3410 & Atlas310.
>>>
>>> Regards,
>>> Sushant
>>>
>>> Jamie Gordon wrote:
>>>
>>>
>>>
>>>> ok
>>>>
>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> *Project: RealPlayer for Netbook*
>>>>>
>>>>> *Synopsis:*
>>>>>
>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>
>>>>> * *
>>>>>
>>>>> *Overview:*
>>>>>
>>>>> Added support to play AVI ADTS files.
>>>>>
>>>>> Created a new mime type for such files & handle their parsing in mp4
>>>>> renderer.
>>>>>
>>>>>
>>>>>
>>>>> *Files Modified:
>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>
>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>
>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>
>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>
>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>
>>>>>
>>>>>
>>>>> *Files Added: *
>>>>>
>>>>> None
>>>>>
>>>>>
>>>>>
>>>>> *Platforms and Profiles Affected:
>>>>> *Linux
>>>>>
>>>>> *Distribution Libraries Affected:*
>>>>> None.
>>>>>
>>>>> *Platforms and Profiles Build Verified:
>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>> *Profile:* helix-client-moblin
>>>>> *Target:* mediasinkplayer
>>>>>
>>>>>
>>>>> *Branch:*
>>>>> Atlas3_4_10, Atlas310
>>>>>
>>>>>
>>>>>
>>>>> *Attachment:*
>>>>>
>>>>> diff.txt
>>>>>
>>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>>
>>>>> Sushant
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> .
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>
>>>
>>>
>>>
>> .
>>
>>
>>
>
> .
>
>
From rnelson at real.com Wed Jul 14 07:34:51 2010
From: rnelson at real.com (Robert Nelson)
Date: Wed Jul 14 14:13:32 2010
Subject: [datatype-dev] CN: Fix build break when warning 4715 - Not all
control paths return a value is enabled
Message-ID:
Index: avi/filewriter/blist.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/filewriter/blist.cpp,v
retrieving revision 1.1.6.2
retrieving revision 1.1.6.3
diff -u -r1.1.6.2 -r1.1.6.3
--- avi/filewriter/blist.cpp 21 Sep 2007 05:59:47 -0000 1.1.6.2
+++ avi/filewriter/blist.cpp 14 Jul 2010 15:19:36 -0000 1.1.6.3
@@ -1,5 +1,5 @@
/* ***** BEGIN LICENSE BLOCK *****
- * Source last modified: $Id: blist.cpp,v 1.1.6.2 2007/09/21 05:59:47 gbajaj Exp $
+ * Source last modified: $Id: blist.cpp,v 1.1.6.3 2010/07/14 15:19:36 robertn Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
@@ -137,6 +137,11 @@
pCur->ppBlock[ idx ] = value;
}
+#if defined(_MSC_VER)
+#pragma warning(push)
+#pragma warning(disable : 4715)
+#endif
+
void *& CBList::operator[](int idx)
{
_memblock_t* pCur = m_pHead;
@@ -168,6 +173,10 @@
// this generates a warning that can't be easily worked around
}
+#if defined(_MSC_VER)
+#pragma warning(pop)
+#endif
+
void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
{
_memblock_t* pCur = m_pHead;
Index: mp4/filewriter/blist.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/blist.cpp,v
retrieving revision 1.2
retrieving revision 1.2.106.1
diff -u -r1.2 -r1.2.106.1
--- mp4/filewriter/blist.cpp 13 Feb 2004 21:48:24 -0000 1.2
+++ mp4/filewriter/blist.cpp 14 Jul 2010 15:19:37 -0000 1.2.106.1
@@ -122,6 +122,11 @@
pCur->ppBlock[ idx ] = value;
}
+#if defined(_MSC_VER)
+#pragma warning(push)
+#pragma warning(disable : 4715)
+#endif
+
void *& CBList::operator[](int idx)
{
_memblock_t* pCur = m_pHead;
@@ -153,6 +158,10 @@
// this generates a warning that can't be easily worked around
}
+#if defined(_MSC_VER)
+#pragma warning(pop)
+#endif
+
void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
{
_memblock_t* pCur = m_pHead;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/17c313f4/attachment-0001.html
From Shy.Ward at nokia.com Wed Jul 14 08:04:12 2010
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Wed Jul 14 14:43:09 2010
Subject: [datatype-dev] FW: CR : MMFControllerProxyServer and
HLX_MDF_VIDEO_SERV panics
when copying files to phone during video playback
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? diff.txt
? fileformat/Makefile
? fileformat/Umakefil.upp
? fileformat/armv5-rel32
? fileformat/mkvff_dll_stub.c
? fileformat/mkvff_ordinal.dat
? fileformat/mkvffdll.mak
? fileformat/mkvffdll.upp
? fileformat/mkvff{000a0000}.def
Index: fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.7
diff -w -u -b -r1.1.1.1.2.7 mkv_file_format.cpp
--- fileformat/mkv_file_format.cpp 29 Jun 2010 10:13:10 -0000 1.1.1.1.2.7
+++ fileformat/mkv_file_format.cpp 14 Jul 2010 16:02:31 -0000
@@ -524,7 +524,7 @@
if(m_pGetPacketReqQ)
{
- while(!m_pGetPacketReqQ->IsEmpty())
+ if(!m_pGetPacketReqQ->IsEmpty())
{
GetPacketInfo *req = (GetPacketInfo *) m_pGetPacketReqQ->RemoveHead();
retVal = SendpacketFromQ(req->m_uStreamNum);
@@ -636,6 +636,15 @@
{
m_pFormatResponse->PacketReady(retVal, pPacket);
}
+ else
+ {
+ // if this is a Error other that what we intended.
+ // eg. Read Error on GetPacket
+ // pass the error code to Core via PacketReady
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::Func GetPacket Failed Error %lu %lx", retVal, retVal);
+ m_pFormatResponse->PacketReady(retVal, pPacket);
+
+ }
HX_RELEASE(pPacket);
}
? libmatroska/Makefile
? libmatroska/Umakefil.upp
? libmatroska/armv5-rel32
Index: libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.9
diff -w -u -b -r1.1.1.1.2.9 Matroska.cpp
--- libmatroska/Matroska.cpp 29 Jun 2010 10:20:55 -0000 1.1.1.1.2.9
+++ libmatroska/Matroska.cpp 14 Jul 2010 16:02:33 -0000
@@ -756,7 +756,12 @@
{
pSimpleBlock = (KaxSimpleBlock*)pElement;
- pSimpleBlock->ReadData( m_pES->I_O() );
+ TInt res = pSimpleBlock->ReadData( m_pES->I_O() );
+ if (res == 0 )
+ {
+ HXLOGL2(HXLOG_MKVF, "MMatroskaSegment::GetNextPacket Read Failed. Read data of %d length", res);
+ return HXR_READ_ERROR;
+ }
pSimpleBlock->SetParent( *m_pCluster );
bKey = pSimpleBlock->IsKeyframe();
streamNumber = FindTrackIndex(pSimpleBlock->TrackNum());
Index: libmatroska/libebml/src/EbmlBinary.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/src/EbmlBinary.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlBinary.cpp
--- libmatroska/libebml/src/EbmlBinary.cpp 19 Oct 2009 14:53:48 -0000 1.1.1.1
+++ libmatroska/libebml/src/EbmlBinary.cpp 14 Jul 2010 16:02:33 -0000
@@ -87,8 +87,12 @@
return Size;
}
-// CHXSymbianString::TraceHeap ("EbmlBinary::ReadData"); // VAQUERO
+// CHXSymbianString::TraceHeap ("EbmlBinary::ReadData");
Data = (binary *)malloc(Size * sizeof(binary));
+ if(Data == NULL)
+ {
+ return 0;
+ }
assert(Data != NULL);
bValueIsSet = true;
return input.read(Data, Size);
Index: libmatroska/libmatroska/src/KaxBlock.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libmatroska/src/KaxBlock.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 KaxBlock.cpp
--- libmatroska/libmatroska/src/KaxBlock.cpp 19 Oct 2009 14:53:50 -0000 1.1.1.1
+++ libmatroska/libmatroska/src/KaxBlock.cpp 14 Jul 2010 16:02:34 -0000
@@ -641,12 +641,20 @@
uint64 KaxInternalBlock::ReadData(IOCallback & input, ScopeMode ReadFully)
{
uint64 Result;
-
FirstFrameLocation = input.getFilePointer(); // will be updated accordingly below
if (ReadFully == SCOPE_ALL_DATA)
{
Result = EbmlBinary::ReadData(input, ReadFully);
+ if (Result == 0)
+ {
+ if(Data != NULL)
+ {
+ free(Data);
+ }
+ return Result;
+ }
+
binary *cursor = Data;
uint8 BlockHeadSize = 4;
From jgordon at real.com Wed Jul 14 10:27:32 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 14 17:06:10 2010
Subject: [datatype-dev] CN: Fix build break when warning 4715 - Not all
control paths return a value is enabled
In-Reply-To:
References:
Message-ID: <4C3E0194.6080709@real.com>
If there are control paths that do not return a value, then surely they
should be fixed so that they return something instead of turning off the
warning/error, shouldn't they??
On 7/14/2010 8:34 AM, Robert Nelson wrote:
> Index: avi/filewriter/blist.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/avi/filewriter/blist.cpp,v
>
> retrieving revision 1.1.6.2
>
> retrieving revision 1.1.6.3
>
> diff -u -r1.1.6.2 -r1.1.6.3
>
> --- avi/filewriter/blist.cpp 21 Sep 2007 05:59:47 -0000 1.1.6.2
>
> +++ avi/filewriter/blist.cpp 14 Jul 2010 15:19:36 -0000 1.1.6.3
>
> @@ -1,5 +1,5 @@
>
> /* ***** BEGIN LICENSE BLOCK *****
>
> - * Source last modified: $Id: blist.cpp,v 1.1.6.2 2007/09/21 05:59:47
> gbajaj Exp $
>
> + * Source last modified: $Id: blist.cpp,v 1.1.6.3 2010/07/14 15:19:36
> robertn Exp $
>
> *
>
> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
>
> *
>
> @@ -137,6 +137,11 @@
>
> pCur->ppBlock[ idx ] = value;
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(push)
>
> +#pragma warning(disable : 4715)
>
> +#endif
>
> +
>
> void *& CBList::operator[](int idx)
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> @@ -168,6 +173,10 @@
>
> // this generates a warning that can't be easily worked around
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(pop)
>
> +#endif
>
> +
>
> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> Index: mp4/filewriter/blist.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mp4/filewriter/blist.cpp,v
>
> retrieving revision 1.2
>
> retrieving revision 1.2.106.1
>
> diff -u -r1.2 -r1.2.106.1
>
> --- mp4/filewriter/blist.cpp 13 Feb 2004 21:48:24 -0000 1.2
>
> +++ mp4/filewriter/blist.cpp 14 Jul 2010 15:19:37 -0000 1.2.106.1
>
> @@ -122,6 +122,11 @@
>
> pCur->ppBlock[ idx ] = value;
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(push)
>
> +#pragma warning(disable : 4715)
>
> +#endif
>
> +
>
> void *& CBList::operator[](int idx)
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> @@ -153,6 +158,10 @@
>
> // this generates a warning that can't be easily worked around
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(pop)
>
> +#endif
>
> +
>
> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>
> {
>
> _memblock_t* pCur = m_pHead;
>
>
>
From rnelson at real.com Wed Jul 14 11:19:15 2010
From: rnelson at real.com (Robert Nelson)
Date: Wed Jul 14 17:57:40 2010
Subject: [datatype-dev] CN: Fix build break when warning 4715 - Not all
control paths return a value is enabled
In-Reply-To: <4C3E0194.6080709@real.com>
References:
<4C3E0194.6080709@real.com>
Message-ID:
Yes they should, and the owner of the component should get right on that. :-)
In the meantime, my priority was fixing the broken build.
However the function signature doesn't lend itself to an easy value to return since it is a reference to a pointer.
In this case the code should also not be calling HX_ASSERT but rather calling something like abort so release builds don't run with bogus pointers (whatever happens to be in EAX on x86). But that also has issues since Microsoft left off the __declspec(noreturn) on the declaration of abort().
Ideally the code should also raise an exception, but since we tend to build with exception handling turned off, that isn't really an option either.
-----Original Message-----
From: Jamie Gordon
Sent: Wednesday, July 14, 2010 11:28 AM
To: Robert Nelson
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CN: Fix build break when warning 4715 - Not all control paths return a value is enabled
If there are control paths that do not return a value, then surely they
should be fixed so that they return something instead of turning off the
warning/error, shouldn't they??
On 7/14/2010 8:34 AM, Robert Nelson wrote:
> Index: avi/filewriter/blist.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/avi/filewriter/blist.cpp,v
>
> retrieving revision 1.1.6.2
>
> retrieving revision 1.1.6.3
>
> diff -u -r1.1.6.2 -r1.1.6.3
>
> --- avi/filewriter/blist.cpp 21 Sep 2007 05:59:47 -0000 1.1.6.2
>
> +++ avi/filewriter/blist.cpp 14 Jul 2010 15:19:36 -0000 1.1.6.3
>
> @@ -1,5 +1,5 @@
>
> /* ***** BEGIN LICENSE BLOCK *****
>
> - * Source last modified: $Id: blist.cpp,v 1.1.6.2 2007/09/21 05:59:47
> gbajaj Exp $
>
> + * Source last modified: $Id: blist.cpp,v 1.1.6.3 2010/07/14 15:19:36
> robertn Exp $
>
> *
>
> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
>
> *
>
> @@ -137,6 +137,11 @@
>
> pCur->ppBlock[ idx ] = value;
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(push)
>
> +#pragma warning(disable : 4715)
>
> +#endif
>
> +
>
> void *& CBList::operator[](int idx)
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> @@ -168,6 +173,10 @@
>
> // this generates a warning that can't be easily worked around
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(pop)
>
> +#endif
>
> +
>
> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> Index: mp4/filewriter/blist.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mp4/filewriter/blist.cpp,v
>
> retrieving revision 1.2
>
> retrieving revision 1.2.106.1
>
> diff -u -r1.2 -r1.2.106.1
>
> --- mp4/filewriter/blist.cpp 13 Feb 2004 21:48:24 -0000 1.2
>
> +++ mp4/filewriter/blist.cpp 14 Jul 2010 15:19:37 -0000 1.2.106.1
>
> @@ -122,6 +122,11 @@
>
> pCur->ppBlock[ idx ] = value;
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(push)
>
> +#pragma warning(disable : 4715)
>
> +#endif
>
> +
>
> void *& CBList::operator[](int idx)
>
> {
>
> _memblock_t* pCur = m_pHead;
>
> @@ -153,6 +158,10 @@
>
> // this generates a warning that can't be easily worked around
>
> }
>
>
>
> +#if defined(_MSC_VER)
>
> +#pragma warning(pop)
>
> +#endif
>
> +
>
> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>
> {
>
> _memblock_t* pCur = m_pHead;
>
>
>
From jgordon at real.com Wed Jul 14 13:16:44 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 14 19:55:22 2010
Subject: [datatype-dev] CN: Fix build break when warning 4715 - Not all
control paths return a value is enabled
In-Reply-To:
References:
<4C3E0194.6080709@real.com>
Message-ID: <4C3E293C.3090108@real.com>
Ugh that is ugly. Change looks good then. :)
On 7/14/2010 12:19 PM, Robert Nelson wrote:
> Yes they should, and the owner of the component should get right on that. :-)
>
> In the meantime, my priority was fixing the broken build.
>
> However the function signature doesn't lend itself to an easy value to return since it is a reference to a pointer.
>
> In this case the code should also not be calling HX_ASSERT but rather calling something like abort so release builds don't run with bogus pointers (whatever happens to be in EAX on x86). But that also has issues since Microsoft left off the __declspec(noreturn) on the declaration of abort().
>
> Ideally the code should also raise an exception, but since we tend to build with exception handling turned off, that isn't really an option either.
>
>
> -----Original Message-----
> From: Jamie Gordon
> Sent: Wednesday, July 14, 2010 11:28 AM
> To: Robert Nelson
> Cc: datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] CN: Fix build break when warning 4715 - Not all control paths return a value is enabled
>
> If there are control paths that do not return a value, then surely they
> should be fixed so that they return something instead of turning off the
> warning/error, shouldn't they??
>
> On 7/14/2010 8:34 AM, Robert Nelson wrote:
>> Index: avi/filewriter/blist.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/datatype/avi/filewriter/blist.cpp,v
>>
>> retrieving revision 1.1.6.2
>>
>> retrieving revision 1.1.6.3
>>
>> diff -u -r1.1.6.2 -r1.1.6.3
>>
>> --- avi/filewriter/blist.cpp 21 Sep 2007 05:59:47 -0000 1.1.6.2
>>
>> +++ avi/filewriter/blist.cpp 14 Jul 2010 15:19:36 -0000 1.1.6.3
>>
>> @@ -1,5 +1,5 @@
>>
>> /* ***** BEGIN LICENSE BLOCK *****
>>
>> - * Source last modified: $Id: blist.cpp,v 1.1.6.2 2007/09/21 05:59:47
>> gbajaj Exp $
>>
>> + * Source last modified: $Id: blist.cpp,v 1.1.6.3 2010/07/14 15:19:36
>> robertn Exp $
>>
>> *
>>
>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
>>
>> *
>>
>> @@ -137,6 +137,11 @@
>>
>> pCur->ppBlock[ idx ] = value;
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(push)
>>
>> +#pragma warning(disable : 4715)
>>
>> +#endif
>>
>> +
>>
>> void *& CBList::operator[](int idx)
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> @@ -168,6 +173,10 @@
>>
>> // this generates a warning that can't be easily worked around
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(pop)
>>
>> +#endif
>>
>> +
>>
>> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> Index: mp4/filewriter/blist.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/datatype/mp4/filewriter/blist.cpp,v
>>
>> retrieving revision 1.2
>>
>> retrieving revision 1.2.106.1
>>
>> diff -u -r1.2 -r1.2.106.1
>>
>> --- mp4/filewriter/blist.cpp 13 Feb 2004 21:48:24 -0000 1.2
>>
>> +++ mp4/filewriter/blist.cpp 14 Jul 2010 15:19:37 -0000 1.2.106.1
>>
>> @@ -122,6 +122,11 @@
>>
>> pCur->ppBlock[ idx ] = value;
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(push)
>>
>> +#pragma warning(disable : 4715)
>>
>> +#endif
>>
>> +
>>
>> void *& CBList::operator[](int idx)
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> @@ -153,6 +158,10 @@
>>
>> // this generates a warning that can't be easily worked around
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(pop)
>>
>> +#endif
>>
>> +
>>
>> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>>
>>
From rnelson at real.com Wed Jul 14 14:21:09 2010
From: rnelson at real.com (Robert Nelson)
Date: Wed Jul 14 20:59:44 2010
Subject: [datatype-dev] CN: Fix build break when warning 4715 - Not all
control paths return a value is enabled
In-Reply-To: <4C3E293C.3090108@real.com>
References:
<4C3E0194.6080709@real.com>
<4C3E293C.3090108@real.com>
Message-ID:
Btw, my suggestion for the owner of the component is to create an inline function like hxabort() to wrap abort() with the proper declspec(noreturn) and call that. Hopefully the inlining won't lose the noreturn attribute. If it does then it would have to be a noninlined function. I tried added a proper declaration for abort() but that just generated a conflicting declaration error.
-----Original Message-----
From: Jamie Gordon
Sent: Wednesday, July 14, 2010 2:17 PM
To: Robert Nelson
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CN: Fix build break when warning 4715 - Not all control paths return a value is enabled
Ugh that is ugly. Change looks good then. :)
On 7/14/2010 12:19 PM, Robert Nelson wrote:
> Yes they should, and the owner of the component should get right on that. :-)
>
> In the meantime, my priority was fixing the broken build.
>
> However the function signature doesn't lend itself to an easy value to return since it is a reference to a pointer.
>
> In this case the code should also not be calling HX_ASSERT but rather calling something like abort so release builds don't run with bogus pointers (whatever happens to be in EAX on x86). But that also has issues since Microsoft left off the __declspec(noreturn) on the declaration of abort().
>
> Ideally the code should also raise an exception, but since we tend to build with exception handling turned off, that isn't really an option either.
>
>
> -----Original Message-----
> From: Jamie Gordon
> Sent: Wednesday, July 14, 2010 11:28 AM
> To: Robert Nelson
> Cc: datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] CN: Fix build break when warning 4715 - Not all control paths return a value is enabled
>
> If there are control paths that do not return a value, then surely they
> should be fixed so that they return something instead of turning off the
> warning/error, shouldn't they??
>
> On 7/14/2010 8:34 AM, Robert Nelson wrote:
>> Index: avi/filewriter/blist.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/datatype/avi/filewriter/blist.cpp,v
>>
>> retrieving revision 1.1.6.2
>>
>> retrieving revision 1.1.6.3
>>
>> diff -u -r1.1.6.2 -r1.1.6.3
>>
>> --- avi/filewriter/blist.cpp 21 Sep 2007 05:59:47 -0000 1.1.6.2
>>
>> +++ avi/filewriter/blist.cpp 14 Jul 2010 15:19:36 -0000 1.1.6.3
>>
>> @@ -1,5 +1,5 @@
>>
>> /* ***** BEGIN LICENSE BLOCK *****
>>
>> - * Source last modified: $Id: blist.cpp,v 1.1.6.2 2007/09/21 05:59:47
>> gbajaj Exp $
>>
>> + * Source last modified: $Id: blist.cpp,v 1.1.6.3 2010/07/14 15:19:36
>> robertn Exp $
>>
>> *
>>
>> * Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
>>
>> *
>>
>> @@ -137,6 +137,11 @@
>>
>> pCur->ppBlock[ idx ] = value;
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(push)
>>
>> +#pragma warning(disable : 4715)
>>
>> +#endif
>>
>> +
>>
>> void *& CBList::operator[](int idx)
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> @@ -168,6 +173,10 @@
>>
>> // this generates a warning that can't be easily worked around
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(pop)
>>
>> +#endif
>>
>> +
>>
>> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> Index: mp4/filewriter/blist.cpp
>>
>> ===================================================================
>>
>> RCS file: /cvsroot/datatype/mp4/filewriter/blist.cpp,v
>>
>> retrieving revision 1.2
>>
>> retrieving revision 1.2.106.1
>>
>> diff -u -r1.2 -r1.2.106.1
>>
>> --- mp4/filewriter/blist.cpp 13 Feb 2004 21:48:24 -0000 1.2
>>
>> +++ mp4/filewriter/blist.cpp 14 Jul 2010 15:19:37 -0000 1.2.106.1
>>
>> @@ -122,6 +122,11 @@
>>
>> pCur->ppBlock[ idx ] = value;
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(push)
>>
>> +#pragma warning(disable : 4715)
>>
>> +#endif
>>
>> +
>>
>> void *& CBList::operator[](int idx)
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>> @@ -153,6 +158,10 @@
>>
>> // this generates a warning that can't be easily worked around
>>
>> }
>>
>>
>>
>> +#if defined(_MSC_VER)
>>
>> +#pragma warning(pop)
>>
>> +#endif
>>
>> +
>>
>> void CBList::DumpToBuffer( void* pBuf, bool bWordSwap )
>>
>> {
>>
>> _memblock_t* pCur = m_pHead;
>>
>>
>>
From xzhao at real.com Wed Jul 14 17:52:52 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Thu Jul 15 00:31:30 2010
Subject: [datatype-dev] CR: OMXV build buster fix
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6768@SEAMBX.corp.real.com>
Modified by: xzhao@real.com
Date:
Project: RealPlayer for Android Smartphones
Bug Number:
Bug URL:
Synopsis: OMXV build buster fix
Overview: In my last check in for render optimization, I forget two change point to be embraced within new feature macro "HELIX_FEATURE_USE_SITEBUFFERS", so those two points will break build without this macro defined. Thanks for Qiang help me find this.
Files Added:
NA
Files Modified:
COmxVideoDec.cpp
COmxVideoDec.h
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas
Profile: helix-client-android
Distribution Libraries Affected:
NA
Distribution library impact and planned action:
NA
Platforms and Profiles Build Verified:
Platform: hxclient_3_1_0_atlas_restricted
Profile: helix-client-android
Platforms and Profiles Functionality verified:
Platform: hxclient_3_1_0_atlas_restricted
Profile: helix-client-android
Branch: hxclient_3_1_0_atlas
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_omx2.diff
Type: text/x-patch
Size: 1144 bytes
Desc: datatype_omx2.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8d79d55d/datatype_omx2.bin
From Joeli at real.com Wed Jul 14 19:25:00 2010
From: Joeli at real.com (Joe Li)
Date: Thu Jul 15 02:04:06 2010
Subject: [datatype-dev] CR: MKV fileformat support for Lephone2
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: android-donut3230-arm-qsd_8x50.cf.diff
Type: application/octet-stream
Size: 901 bytes
Desc: android-donut3230-arm-qsd_8x50.cf.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/android-donut3230-arm-qsd_8x50.cf-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdbufdataf.cpp.diff
Type: application/octet-stream
Size: 727 bytes
Desc: fdbufdataf.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/fdbufdataf.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix-client-android-full.pf.diff
Type: application/octet-stream
Size: 532 bytes
Desc: helix-client-android-full.pf.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/helix-client-android-full.pf-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxclient_3_6_1_atlas.bif.diff
Type: application/octet-stream
Size: 2554 bytes
Desc: hxclient_3_6_1_atlas.bif.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/hxclient_3_6_1_atlas.bif-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxfiles.h.diff
Type: application/octet-stream
Size: 3626 bytes
Desc: hxfiles.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/hxfiles.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxiids.h.diff
Type: application/octet-stream
Size: 1168 bytes
Desc: hxiids.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/hxiids.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ihxtlogsystem.h.diff
Type: application/octet-stream
Size: 720 bytes
Desc: ihxtlogsystem.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/ihxtlogsystem.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkv.folder.diff
Type: application/octet-stream
Size: 19023 bytes
Desc: mkv.folder.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/mkv.folder-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recognizer.cpp.diff
Type: application/octet-stream
Size: 1732 bytes
Desc: recognizer.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/recognizer.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recognizer.h.diff
Type: application/octet-stream
Size: 662 bytes
Desc: recognizer.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/recognizer.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smplfsys.cpp.diff
Type: application/octet-stream
Size: 12218 bytes
Desc: smplfsys.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/smplfsys.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smplfsys.h.diff
Type: application/octet-stream
Size: 1705 bytes
Desc: smplfsys.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100714/8b447886/smplfsys.h-0001.obj
From Shy.Ward at nokia.com Thu Jul 15 10:04:25 2010
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Thu Jul 15 16:43:15 2010
Subject: [datatype-dev] [RESEND] CR : MMFControllerProxyServer and
HLX_MDF_VIDEO_SERV
panics when copying files to phone during video playback
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? diff.txt
? fileformat/Makefile
? fileformat/Umakefil.upp
? fileformat/armv5-rel32
? fileformat/mkvff_dll_stub.c
? fileformat/mkvff_ordinal.dat
? fileformat/mkvffdll.mak
? fileformat/mkvffdll.upp
? fileformat/mkvff{000a0000}.def
Index: fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.7
diff -w -u -b -r1.1.1.1.2.7 mkv_file_format.cpp
--- fileformat/mkv_file_format.cpp 29 Jun 2010 10:13:10 -0000 1.1.1.1.2.7
+++ fileformat/mkv_file_format.cpp 14 Jul 2010 16:02:31 -0000
@@ -524,7 +524,7 @@
if(m_pGetPacketReqQ)
{
- while(!m_pGetPacketReqQ->IsEmpty())
+ if(!m_pGetPacketReqQ->IsEmpty())
{
GetPacketInfo *req = (GetPacketInfo *) m_pGetPacketReqQ->RemoveHead();
retVal = SendpacketFromQ(req->m_uStreamNum);
@@ -636,6 +636,15 @@
{
m_pFormatResponse->PacketReady(retVal, pPacket);
}
+ else
+ {
+ // if this is a Error other that what we intended.
+ // eg. Read Error on GetPacket
+ // pass the error code to Core via PacketReady
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::Func GetPacket Failed Error %lu %lx", retVal, retVal);
+ m_pFormatResponse->PacketReady(retVal, pPacket);
+
+ }
HX_RELEASE(pPacket);
}
? libmatroska/Makefile
? libmatroska/Umakefil.upp
? libmatroska/armv5-rel32
Index: libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.9
diff -w -u -b -r1.1.1.1.2.9 Matroska.cpp
--- libmatroska/Matroska.cpp 29 Jun 2010 10:20:55 -0000 1.1.1.1.2.9
+++ libmatroska/Matroska.cpp 14 Jul 2010 16:02:33 -0000
@@ -756,7 +756,12 @@
{
pSimpleBlock = (KaxSimpleBlock*)pElement;
- pSimpleBlock->ReadData( m_pES->I_O() );
+ TInt res = pSimpleBlock->ReadData( m_pES->I_O() );
+ if (res == 0 )
+ {
+ HXLOGL2(HXLOG_MKVF, "MMatroskaSegment::GetNextPacket Read Failed. Read data of %d length", res);
+ return HXR_READ_ERROR;
+ }
pSimpleBlock->SetParent( *m_pCluster );
bKey = pSimpleBlock->IsKeyframe();
streamNumber = FindTrackIndex(pSimpleBlock->TrackNum());
Index: libmatroska/libebml/src/EbmlBinary.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libebml/src/EbmlBinary.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 EbmlBinary.cpp
--- libmatroska/libebml/src/EbmlBinary.cpp 19 Oct 2009 14:53:48 -0000 1.1.1.1
+++ libmatroska/libebml/src/EbmlBinary.cpp 14 Jul 2010 16:02:33 -0000
@@ -87,8 +87,12 @@
return Size;
}
-// CHXSymbianString::TraceHeap ("EbmlBinary::ReadData"); // VAQUERO
+// CHXSymbianString::TraceHeap ("EbmlBinary::ReadData");
Data = (binary *)malloc(Size * sizeof(binary));
+ if(Data == NULL)
+ {
+ return 0;
+ }
assert(Data != NULL);
bValueIsSet = true;
return input.read(Data, Size);
Index: libmatroska/libmatroska/src/KaxBlock.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/libmatroska/src/KaxBlock.cpp,v
retrieving revision 1.1.1.1
diff -w -u -b -r1.1.1.1 KaxBlock.cpp
--- libmatroska/libmatroska/src/KaxBlock.cpp 19 Oct 2009 14:53:50 -0000 1.1.1.1
+++ libmatroska/libmatroska/src/KaxBlock.cpp 14 Jul 2010 16:02:34 -0000
@@ -641,12 +641,20 @@
uint64 KaxInternalBlock::ReadData(IOCallback & input, ScopeMode ReadFully)
{
uint64 Result;
-
FirstFrameLocation = input.getFilePointer(); // will be updated accordingly below
if (ReadFully == SCOPE_ALL_DATA)
{
Result = EbmlBinary::ReadData(input, ReadFully);
+ if (Result == 0)
+ {
+ if(Data != NULL)
+ {
+ free(Data);
+ }
+ return Result;
+ }
+
binary *cursor = Data;
uint8 BlockHeadSize = 4;
-------------- next part --------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From sfu at real.com Thu Jul 15 12:55:05 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 15 19:32:46 2010
Subject: [datatype-dev] CR: MKV fileformat support for Lephone2
In-Reply-To:
References:
Message-ID: <4C3F75A9.10507@real.com>
These looks good to me.
fxd
Joe Li wrote:
>
> by: joeli@real.com
>
> Date: 07/15/2010
>
>
>
> Project: RealPlayer for Android Smartphones
>
>
>
> Synopsis: MKV fileformat support for Lephone2
>
>
>
> Overview:
>
>
>
> In order to support MKV fileformat in Android platform, we imported
> MKV feature from hxclient_3_1_0_atlas to
> hxclient_3_6_1_atlas_restricted, and made some changes.
>
> This CR just do the follow modification, and the other CR of memory
> leak issue and hxclient_4_2_0_brizo ?s Merge will be raised next week.
>
>
>
> Modification list:
>
> > 1. Add open source stlport5 for Android STL support; (source code in:
> /common/import/stlport5/, static lib in:
> /datatype/mkv/sitelib/stlport.a)
>
> > 2. Add fileobject2 interface for mkv fileformat;
>
> > 3. Add Mimetype interface for Mkv fileformat;
>
> > 4. Support MKV codec ID(video: V_MPEG4/ISO/AVC, V_MPEG4,
> V_MPEG4/ISO/SP, V_MPEG4/ISO/ASP, V_MPEG4/ISO/AP; audio: A_AAC, A_MPEG/L3)
>
>
>
> Files Added:
>
> common/import/stlport5/
>
> datatype/mkv/
>
>
>
>
>
> Files Modified:
>
> build/bif-cvs/helix/client/build/BIF/hxclient_3_6_1_atlas.bif
>
> build/umakepf/helix-client-android-full.pf
>
> build/umakecf/android-donut3230-arm-qsd_8x50.cf
>
> common/fileio/fdbufdataf.cpp
>
> common/system/recognizer.cpp
>
> common/system/pub/recognizer.h
>
> common/include/hxfiles.h
>
> common/include/hxiids.h
>
> common/include/ihxtlogsystem.h
>
> filesystem/local/full/smplfsys.h
>
> filesystem/local/full/smplfsys.cpp
>
>
>
>
>
>
>
>
>
> Image Size and Heap Use impact (Client -Only):
>
> None
>
>
>
>
>
> Platforms and Profiles Affected:
>
> Platform: 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: Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
>
>
>
>
> Platforms and Profiles Functionality verified:
>
> Platform: Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
>
>
>
>
> Branch for: 361atlas
>
>
>
>
>
> Thanks
>
> Joe
>
>
>
From sfu at real.com Thu Jul 15 12:58:04 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 15 19:36:07 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] [RESEND] CR :
MMFControllerProxyServer and
HLX_MDF_VIDEO_SERV panics when copying files to phone during video playback
In-Reply-To:
References:
Message-ID: <4C3F765C.70908@real.com>
Looks good.
fxd
Shy.Ward@nokia.com wrote:
>
> Any comments?
>
>
>
> Thanks,
>
> Shy
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Ward Shy (Nokia-MS/Dallas)
> *Sent:* Wednesday, July 14, 2010 11:04 AM
> *To:* nokia-private-dev@helixcommunity.org;
> datatype-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] FW: CR : MMFControllerProxyServer and
> HLX_MDF_VIDEO_SERV panics when copying files to phone during video
> playback
>
>
>
> "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-sanket.lopes@nokia.com
>
>
> Reviewed by: rajesh.rathinasmay@nokia.com
>
> Date: 07 /13 /2010
>
> Project:
>
> ErrorId: ou1cimx1#451231
>
>
>
> Synopsis: MMFControllerProxyServer and HLX_MDF_VIDEO_SERV panics when
> copying files to phone during video playback.
>
>
>
> Problem Statement: This was observed only for MKV Clips. While playing
> a MKV clip if we connect the device to PC in OVSuite mode and start
> copying data to the Mass storage. Small pauses were observed which was
> sometimes followed by a freeze and Crash.
>
>
>
> Overview: There were 2 issues here. Firstly, while coping data to mass
> storage the execution was entering a loop causing the File be read in
> buffers but these buffer were not getting used as a result they were
> not getting freed. At some point in time device used to run out of
> memory and malloc failed this was not handled and so crash was seen.
>
> Secondly, What caused the loop? In MKV file format, FUNC API has two
> loops the outer while loop was unintentionally getting into a Long run
> as it would run until the request is empty. Request Q is queued by
> ReadData and for every packet readdata queues here it schedules a call
> to process it, which would result in FUNC to run again. The crash was
> observed
>
>
>
> Solution: Changed the outer while condition to if case because FUNC is
> scheduled to run for every packet in the queue anyways. And handled
> the malloc failure
>
>
>
> Modified files:
>
> fileformat/mkv_file_format.cpp
>
> libmatroska/libmatroska/src/KaxBlock.cpp
>
> libmatroska/Matroska.cpp
>
> libmatroska/libebml/src/EbmlBinary.cpp
>
>
>
> Image size and heap use impact: None
>
>
>
> Module Release testing (STIF): Tested that all mkv clips used for TNE
> testing to make sure that Thumbnails are still generated for working
> files.
>
> Also, made sure that loading time between HXMMFCtrlImpl::MvpcPrepare()
> and HXMMFCtrlImpl:: OnLoadingComplete() is not impacted by this change
>
>
>
> Test case(s) added: None
>
>
>
> Memory leak check performed: No new leaks introduced
>
>
>
> Branch(es) : Cays 210, Brizo 420 and Head.
>
>
>
> Diff: Attached
>
>
>
From svaidhya at real.com Thu Jul 15 13:27:42 2010
From: svaidhya at real.com (Shantha Vaidhyanathan)
Date: Thu Jul 15 20:08:15 2010
Subject: [datatype-dev] CR: Bug 263889: client receives file not found error
when wav file is used as the SLTA source
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07E738BCA5@SEAMBX.corp.real.com>
Synopsis
======
Client receives file not found error when wav file is used as the SLTA source
Branches: 14.0 , HEAD
Suggested Reviewer: Jamie
Description
=========
The wav Fileformat does not add ASMRulebook to streamheader and the StreamGroupManager expects ASMRuleBook.
Added a default ASMRuleBook to the wavff.
Files Affected
==========
./datatype/wav/fileformat/wavffplin.cpp
Testing Performed
=============
Unit Tests:
None.
Integration Tests:
- Verified successful playback of a wav file through slta.
- Verified OD playback still works.
Leak Tests:
None.
Performance Tests:
- None
Platforms Tested: linux-rhel5-i686
Build verified: linux-rhel5-i686
Thanks
~Shantha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wvffplin.cpp.diff
Type: application/octet-stream
Size: 1258 bytes
Desc: wvffplin.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100715/db060978/wvffplin.cpp.obj
From jgordon at real.com Thu Jul 15 13:40:22 2010
From: jgordon at real.com (Jamie Gordon)
Date: Thu Jul 15 20:18:46 2010
Subject: [datatype-dev] Re: CR: Bug 263889: client receives file not found
error when wav file is used as the SLTA source
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07E738BCA5@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA07E738BCA5@SEAMBX.corp.real.com>
Message-ID: <4C3F8046.2000803@real.com>
ok
On 7/15/2010 2:27 PM, Shantha Vaidhyanathan wrote:
>
> Synopsis
> ======
> Client receives file not found error when wav file is used as the SLTA source
>
>
> Branches: 14.0 , HEAD
> Suggested Reviewer: Jamie
>
> Description
> =========
>
> The wav Fileformat does not add ASMRulebook to streamheader and the StreamGroupManager expects ASMRuleBook.
> Added a default ASMRuleBook to the wavff.
>
>
> Files Affected
> ==========
> ./datatype/wav/fileformat/wavffplin.cpp
>
>
> Testing Performed
> =============
> Unit Tests:
> None.
>
> Integration Tests:
> - Verified successful playback of a wav file through slta.
> - Verified OD playback still works.
>
> Leak Tests:
> None.
>
> Performance Tests:
> - None
>
> Platforms Tested: linux-rhel5-i686
> Build verified: linux-rhel5-i686
>
> Thanks
> ~Shantha
From ext-debashis.2.panigrahi at nokia.com Fri Jul 16 04:36:26 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Jul 16 11:15:24 2010
Subject: [datatype-dev] CR: ou1cimx1#473887: SPPR_REL: Video cannot be
displayed and only sound can be heard during playing a large size AVI
video
Message-ID: <20D73E2631F7914F868646E119DEC1CE27979E7ADF@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: Ashish.As.Gupta@nokia.com
RC Id: ou1cimx1#473887
Date: 07/15/2010
Project: SymbianMmf_wm
Synopsis: SPPR_REL: Video cannot be displayed and only sound can be heard during playing a large size AVI video
Overview:
The file concerned is having video codec ID as 'MP4V' which is not supported by avi fileformat as of now and so was being mapped to "video/x-pn-icm-plugin" mime type and hence InitializeRenderers(.) was failing with HXR_NO_RENDERER as it was unable to match any plugin to this mime type. Therefore partial playback (audio 'AC3' only) was happening.
Fix:
Adding the codec IDs 'MP4V' and 'mp4v' to the avi file format and setting it to correspond to "video/X-HX-DIVX" mime type ; just to enable matching of MPEG4 decoder to this mime type.
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-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS:
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.9.6.15
diff -u -w -r1.9.6.15 avistrm.cpp
--- avistrm.cpp 22 Jun 2010 05:04:11 -0000 1.9.6.15
+++ avistrm.cpp 15 Jul 2010 11:02:52 -0000
@@ -269,6 +269,8 @@
#define VIDEO_FORMAT_DX50 HX_MAKE4CC('0', '5', 'X', 'D')
#define VIDEO_FORMAT_FMP4 HX_MAKE4CC('4', 'P', 'M', 'F')
#define VIDEO_FORMAT_fmp4 HX_MAKE4CC('4', 'p', 'm', 'f')
+#define VIDEO_FORMAT_MP4V HX_MAKE4CC('V', '4', 'P', 'M')
+#define VIDEO_FORMAT_mp4v HX_MAKE4CC('v', '4', 'p', 'm')
#define VIDEO_FORMAT_H264 HX_MAKE4CC('4', '6', '2', 'H')
#define VIDEO_FORMAT_h264 HX_MAKE4CC('4', '6', '2', 'h')
#define VIDEO_FORMAT_AVC1 HX_MAKE4CC('1', 'C', 'V', 'A')
@@ -806,7 +808,9 @@
(m_header.ulHandler == VIDEO_FORMAT_xvid) ||
(m_header.ulHandler == VIDEO_FORMAT_DX50) ||
(m_header.ulHandler == VIDEO_FORMAT_FMP4) ||
- (m_header.ulHandler == VIDEO_FORMAT_fmp4))
+ (m_header.ulHandler == VIDEO_FORMAT_fmp4) ||
+ (m_header.ulHandler == VIDEO_FORMAT_MP4V) ||
+ (m_header.ulHandler == VIDEO_FORMAT_mp4v))
{
strcpy(szStreamName, "Video Track");
strcpy (szMimeType, "video/X-HX-DIVX");
From sfu at real.com Fri Jul 16 05:17:13 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Jul 16 12:00:02 2010
Subject: [Nokia-private-dev] [datatype-dev] CR: ou1cimx1#473887: SPPR_REL:
Video cannot be displayed and only sound can be heard during playing
a large size AVI video
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE27979E7ADF@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE27979E7ADF@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C405BD9.7010201@real.com>
Looks good.
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: Ashish.As.Gupta@nokia.com
>
> RC Id: ou1cimx1#473887
>
> Date: 07/15/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: SPPR_REL: Video cannot be displayed and only sound can be heard during playing a large size AVI video
>
> Overview:
> The file concerned is having video codec ID as 'MP4V' which is not supported by avi fileformat as of now and so was being mapped to "video/x-pn-icm-plugin" mime type and hence InitializeRenderers(.) was failing with HXR_NO_RENDERER as it was unable to match any plugin to this mime type. Therefore partial playback (audio 'AC3' only) was happening.
>
> Fix:
> Adding the codec IDs 'MP4V' and 'mp4v' to the avi file format and setting it to correspond to "video/X-HX-DIVX" mime type ; just to enable matching of MPEG4 decoder to this mime type.
>
> 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-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: avistrm.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
> retrieving revision 1.9.6.15
> diff -u -w -r1.9.6.15 avistrm.cpp
> --- avistrm.cpp 22 Jun 2010 05:04:11 -0000 1.9.6.15
> +++ avistrm.cpp 15 Jul 2010 11:02:52 -0000
> @@ -269,6 +269,8 @@
> #define VIDEO_FORMAT_DX50 HX_MAKE4CC('0', '5', 'X', 'D')
> #define VIDEO_FORMAT_FMP4 HX_MAKE4CC('4', 'P', 'M', 'F')
> #define VIDEO_FORMAT_fmp4 HX_MAKE4CC('4', 'p', 'm', 'f')
> +#define VIDEO_FORMAT_MP4V HX_MAKE4CC('V', '4', 'P', 'M')
> +#define VIDEO_FORMAT_mp4v HX_MAKE4CC('v', '4', 'p', 'm')
> #define VIDEO_FORMAT_H264 HX_MAKE4CC('4', '6', '2', 'H')
> #define VIDEO_FORMAT_h264 HX_MAKE4CC('4', '6', '2', 'h')
> #define VIDEO_FORMAT_AVC1 HX_MAKE4CC('1', 'C', 'V', 'A')
> @@ -806,7 +808,9 @@
> (m_header.ulHandler == VIDEO_FORMAT_xvid) ||
> (m_header.ulHandler == VIDEO_FORMAT_DX50) ||
> (m_header.ulHandler == VIDEO_FORMAT_FMP4) ||
> - (m_header.ulHandler == VIDEO_FORMAT_fmp4))
> + (m_header.ulHandler == VIDEO_FORMAT_fmp4) ||
> + (m_header.ulHandler == VIDEO_FORMAT_MP4V) ||
> + (m_header.ulHandler == VIDEO_FORMAT_mp4v))
> {
> strcpy(szStreamName, "Video Track");
> strcpy (szMimeType, "video/X-HX-DIVX");
>
> _______________________________________________
> 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 Fri Jul 16 08:43:08 2010
From: Alvaro.Vaquero at nokia.com (Alvaro.Vaquero@nokia.com)
Date: Fri Jul 16 15:21:43 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] [RESEND] CR :
MMFControllerProxyServer and
HLX_MDF_VIDEO_SERV panics when copying files to phone during video playback
In-Reply-To: <4C3F765C.70908@real.com>
References:
<4C3F765C.70908@real.com>
Message-ID: <4E98D139892C2A4583283B2C6216BA802E048BF5AE@NOK-EUMSG-03.mgdnok.nokia.com>
Checked in to Cayenne 210, Brizo 420 and HEAD. Thanks.
BR,
/Alvaro
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Thursday, July 15, 2010 3:58 PM
To: Ward Shy (Nokia-MS/Dallas)
Cc: nokia-private-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] [RESEND] CR : MMFControllerProxyServer and HLX_MDF_VIDEO_SERV panics when copying files to phone during video playback
Looks good.
fxd
Shy.Ward@nokia.com wrote:
>
> Any comments?
>
>
>
> Thanks,
>
> Shy
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Ward Shy (Nokia-MS/Dallas)
> *Sent:* Wednesday, July 14, 2010 11:04 AM
> *To:* nokia-private-dev@helixcommunity.org;
> datatype-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] FW: CR : MMFControllerProxyServer and
> HLX_MDF_VIDEO_SERV panics when copying files to phone during video
> playback
>
>
>
> "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-sanket.lopes@nokia.com
>
>
> Reviewed by: rajesh.rathinasmay@nokia.com
>
> Date: 07 /13 /2010
>
> Project:
>
> ErrorId: ou1cimx1#451231
>
>
>
> Synopsis: MMFControllerProxyServer and HLX_MDF_VIDEO_SERV panics when
> copying files to phone during video playback.
>
>
>
> Problem Statement: This was observed only for MKV Clips. While playing
> a MKV clip if we connect the device to PC in OVSuite mode and start
> copying data to the Mass storage. Small pauses were observed which was
> sometimes followed by a freeze and Crash.
>
>
>
> Overview: There were 2 issues here. Firstly, while coping data to mass
> storage the execution was entering a loop causing the File be read in
> buffers but these buffer were not getting used as a result they were
> not getting freed. At some point in time device used to run out of
> memory and malloc failed this was not handled and so crash was seen.
>
> Secondly, What caused the loop? In MKV file format, FUNC API has two
> loops the outer while loop was unintentionally getting into a Long run
> as it would run until the request is empty. Request Q is queued by
> ReadData and for every packet readdata queues here it schedules a call
> to process it, which would result in FUNC to run again. The crash was
> observed
>
>
>
> Solution: Changed the outer while condition to if case because FUNC is
> scheduled to run for every packet in the queue anyways. And handled
> the malloc failure
>
>
>
> Modified files:
>
> fileformat/mkv_file_format.cpp
>
> libmatroska/libmatroska/src/KaxBlock.cpp
>
> libmatroska/Matroska.cpp
>
> libmatroska/libebml/src/EbmlBinary.cpp
>
>
>
> Image size and heap use impact: None
>
>
>
> Module Release testing (STIF): Tested that all mkv clips used for TNE
> testing to make sure that Thumbnails are still generated for working
> files.
>
> Also, made sure that loading time between HXMMFCtrlImpl::MvpcPrepare()
> and HXMMFCtrlImpl:: OnLoadingComplete() is not impacted by this change
>
>
>
> Test case(s) added: None
>
>
>
> Memory leak check performed: No new leaks introduced
>
>
>
> Branch(es) : Cays 210, Brizo 420 and Head.
>
>
>
> Diff: Attached
>
>
>
From rnelson at real.com Fri Jul 16 16:02:15 2010
From: rnelson at real.com (Robert Nelson)
Date: Fri Jul 16 22:40:35 2010
Subject: [datatype-dev] CR: wmcode-audio on hxclient_3_1_0_Atlas branch
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: wmcode-audio.diff
Type: application/octet-stream
Size: 2085 bytes
Desc: wmcode-audio.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100716/fb4a20cf/wmcode-audio.obj
From Joeli at real.com Sun Jul 18 19:36:55 2010
From: Joeli at real.com (Joe Li)
Date: Mon Jul 19 02:14:50 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IE1LViBmaWxlZm9ybWF0IHN1cHBv?=
=?gb2312?B?cnQgZm9yIExlcGhvbmUy?=
In-Reply-To: <4C3F75A9.10507@real.com>
Message-ID:
VGhhbmtzLiAgQ29tbWl0dGVkIHRvIDM2MWF0bGFzDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8
/sjLOiBTaGVsZG9uIEZ1IA0Kt6LLzcqxvOQ6IDIwMTDE6jfUwjE2yNXQx8bazuUgNDo1NQ0KytW8
/sjLOiBKb2UgTGkNCrOty806IGFuZHJvaWQtcG9ydC1kZXZAaGVsaXhjb21tdW5pdHkub3JnOyBk
YXRhdHlwZS1kZXZAaGVsaXhjb21tdW5pdHkub3JnDQrW98ziOiBSZTogW2RhdGF0eXBlLWRldl0g
Q1I6IE1LViBmaWxlZm9ybWF0IHN1cHBvcnQgZm9yIExlcGhvbmUyDQoNClRoZXNlIGxvb2tzIGdv
b2QgdG8gbWUuDQoNCmZ4ZA0KDQpKb2UgTGkgd3JvdGU6DQo+DQo+IGJ5OiBqb2VsaUByZWFsLmNv
bQ0KPg0KPiBEYXRlOiAwNy8xNS8yMDEwDQo+DQo+ICANCj4NCj4gUHJvamVjdDogUmVhbFBsYXll
ciBmb3IgQW5kcm9pZCBTbWFydHBob25lcw0KPg0KPiAgDQo+DQo+IFN5bm9wc2lzOiBNS1YgZmls
ZWZvcm1hdCBzdXBwb3J0IGZvciBMZXBob25lMg0KPg0KPiAgDQo+DQo+IE92ZXJ2aWV3Og0KPg0K
PiAgDQo+DQo+IEluIG9yZGVyIHRvIHN1cHBvcnQgTUtWIGZpbGVmb3JtYXQgaW4gQW5kcm9pZCBw
bGF0Zm9ybSwgd2UgaW1wb3J0ZWQgDQo+IE1LViBmZWF0dXJlIGZyb20gaHhjbGllbnRfM18xXzBf
YXRsYXMgdG8gDQo+IGh4Y2xpZW50XzNfNl8xX2F0bGFzX3Jlc3RyaWN0ZWQsIGFuZCBtYWRlIHNv
bWUgY2hhbmdlcy4NCj4NCj4gVGhpcyBDUiBqdXN0IGRvIHRoZSBmb2xsb3cgbW9kaWZpY2F0aW9u
LCBhbmQgdGhlIG90aGVyIENSIG9mIG1lbW9yeSANCj4gbGVhayBpc3N1ZSBhbmQgaHhjbGllbnRf
NF8yXzBfYnJpem8goa5zIE1lcmdlIHdpbGwgYmUgcmFpc2VkIG5leHQgd2Vlay4NCj4NCj4gIA0K
Pg0KPiBNb2RpZmljYXRpb24gbGlzdDoNCj4NCj4gPiAxLiBBZGQgb3BlbiBzb3VyY2Ugc3RscG9y
dDUgZm9yIEFuZHJvaWQgU1RMIHN1cHBvcnQ7IChzb3VyY2UgY29kZSBpbjogDQo+IC9jb21tb24v
aW1wb3J0L3N0bHBvcnQ1LywgIHN0YXRpYyBsaWIgaW46IA0KPiAgL2RhdGF0eXBlL21rdi9zaXRl
bGliL3N0bHBvcnQuYSkNCj4NCj4gPiAyLiBBZGQgZmlsZW9iamVjdDIgaW50ZXJmYWNlIGZvciBt
a3YgZmlsZWZvcm1hdDsNCj4NCj4gPiAzLiBBZGQgTWltZXR5cGUgaW50ZXJmYWNlIGZvciBNa3Yg
ZmlsZWZvcm1hdDsNCj4NCj4gPiA0LiBTdXBwb3J0IE1LViBjb2RlYyBJRCh2aWRlbzogVl9NUEVH
NC9JU08vQVZDLCBWX01QRUc0LCANCj4gIFZfTVBFRzQvSVNPL1NQLCBWX01QRUc0L0lTTy9BU1As
IFZfTVBFRzQvSVNPL0FQOyBhdWRpbzogQV9BQUMsIEFfTVBFRy9MMykNCj4NCj4gIA0KPg0KPiBG
aWxlcyBBZGRlZDoNCj4NCj4gY29tbW9uL2ltcG9ydC9zdGxwb3J0NS8NCj4NCj4gZGF0YXR5cGUv
bWt2Lw0KPg0KPiAgDQo+DQo+ICANCj4NCj4gRmlsZXMgTW9kaWZpZWQ6DQo+DQo+IGJ1aWxkL2Jp
Zi1jdnMvaGVsaXgvY2xpZW50L2J1aWxkL0JJRi9oeGNsaWVudF8zXzZfMV9hdGxhcy5iaWYNCj4N
Cj4gYnVpbGQvdW1ha2VwZi9oZWxpeC1jbGllbnQtYW5kcm9pZC1mdWxsLnBmDQo+DQo+IGJ1aWxk
L3VtYWtlY2YvYW5kcm9pZC1kb251dDMyMzAtYXJtLXFzZF84eDUwLmNmDQo+DQo+IGNvbW1vbi9m
aWxlaW8vZmRidWZkYXRhZi5jcHANCj4NCj4gY29tbW9uL3N5c3RlbS9yZWNvZ25pemVyLmNwcA0K
Pg0KPiBjb21tb24vc3lzdGVtL3B1Yi9yZWNvZ25pemVyLmgNCj4NCj4gY29tbW9uL2luY2x1ZGUv
aHhmaWxlcy5oDQo+DQo+IGNvbW1vbi9pbmNsdWRlL2h4aWlkcy5oDQo+DQo+IGNvbW1vbi9pbmNs
dWRlL2loeHRsb2dzeXN0ZW0uaA0KPg0KPiBmaWxlc3lzdGVtL2xvY2FsL2Z1bGwvc21wbGZzeXMu
aA0KPg0KPiBmaWxlc3lzdGVtL2xvY2FsL2Z1bGwvc21wbGZzeXMuY3BwDQo+DQo+ICANCj4NCj4g
IA0KPg0KPiAgDQo+DQo+ICANCj4NCj4gSW1hZ2UgU2l6ZSBhbmQgSGVhcCBVc2UgaW1wYWN0IChD
bGllbnQgLU9ubHkpOg0KPg0KPiBOb25lDQo+DQo+ICANCj4NCj4gIA0KPg0KPiBQbGF0Zm9ybXMg
YW5kIFByb2ZpbGVzIEFmZmVjdGVkOg0KPg0KPiBQbGF0Zm9ybTogIFBsYXRmb3JtOiBhbmRyb2lk
LWRvbnV0MzIzMC1hcm0tcXNkXzh4NTANCj4NCj4gUHJvZmlsZTogaGVsaXgtY2xpZW50LWFuZHJv
aWQtZnVsbA0KPg0KPiAgDQo+DQo+ICANCj4NCj4gRGlzdHJpYnV0aW9uIExpYnJhcmllcyBBZmZl
Y3RlZDoNCj4NCj4gTm9uZQ0KPg0KPiAgDQo+DQo+IERpc3RyaWJ1dGlvbiBsaWJyYXJ5IGltcGFj
dCBhbmQgcGxhbm5lZCBhY3Rpb246DQo+DQo+IE5vbmUNCj4NCj4gIA0KPg0KPiBQbGF0Zm9ybXMg
YW5kIFByb2ZpbGVzIEJ1aWxkIFZlcmlmaWVkOg0KPg0KPiBQbGF0Zm9ybTogUGxhdGZvcm06IGFu
ZHJvaWQtZG9udXQzMjMwLWFybS1xc2RfOHg1MA0KPg0KPiBQcm9maWxlOiBoZWxpeC1jbGllbnQt
YW5kcm9pZC1mdWxsDQo+DQo+ICANCj4NCj4gIA0KPg0KPiBQbGF0Zm9ybXMgYW5kIFByb2ZpbGVz
IEZ1bmN0aW9uYWxpdHkgdmVyaWZpZWQ6DQo+DQo+IFBsYXRmb3JtOiBQbGF0Zm9ybTogYW5kcm9p
ZC1kb251dDMyMzAtYXJtLXFzZF84eDUwDQo+DQo+IFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRy
b2lkLWZ1bGwNCj4NCj4gIA0KPg0KPiAgDQo+DQo+IEJyYW5jaCBmb3I6IDM2MWF0bGFzDQo+DQo+
ICANCj4NCj4gIA0KPg0KPiBUaGFua3MNCj4NCj4gSm9lDQo+DQo+ICANCj4NCg0K
From ext-debashis.2.panigrahi at nokia.com Sun Jul 18 20:03:08 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Mon Jul 19 02:41:38 2010
Subject: [Nokia-private-dev] [datatype-dev] CR: ou1cimx1#473887:
SPPR_REL: Video cannot be displayed and only sound can be heard during
playing a large size AVI video
In-Reply-To: <4C405BD9.7010201@real.com>
References: <20D73E2631F7914F868646E119DEC1CE27979E7ADF@NOK-EUMSG-02.mgdnok.nokia.com>
<4C405BD9.7010201@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE27979E7F13@NOK-EUMSG-02.mgdnok.nokia.com>
Hi,
Checked in to 210CayS and 420Bizo
The changes were already present in HEAD as a part of Bug Number: 10439
Thanks and Regards,
Debashis.
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, July 16, 2010 6:47 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] [datatype-dev] CR: ou1cimx1#473887: SPPR_REL: Video cannot be displayed and only sound can be heard during playing a large size AVI video
Looks good.
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: Ashish.As.Gupta@nokia.com
>
> RC Id: ou1cimx1#473887
>
> Date: 07/15/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: SPPR_REL: Video cannot be displayed and only sound can be heard during playing a large size AVI video
>
> Overview:
> The file concerned is having video codec ID as 'MP4V' which is not supported by avi fileformat as of now and so was being mapped to "video/x-pn-icm-plugin" mime type and hence InitializeRenderers(.) was failing with HXR_NO_RENDERER as it was unable to match any plugin to this mime type. Therefore partial playback (audio 'AC3' only) was happening.
>
> Fix:
> Adding the codec IDs 'MP4V' and 'mp4v' to the avi file format and setting it to correspond to "video/X-HX-DIVX" mime type ; just to enable matching of MPEG4 decoder to this mime type.
>
> 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-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS:
> Index: avistrm.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
> retrieving revision 1.9.6.15
> diff -u -w -r1.9.6.15 avistrm.cpp
> --- avistrm.cpp 22 Jun 2010 05:04:11 -0000 1.9.6.15
> +++ avistrm.cpp 15 Jul 2010 11:02:52 -0000
> @@ -269,6 +269,8 @@
> #define VIDEO_FORMAT_DX50 HX_MAKE4CC('0', '5', 'X', 'D')
> #define VIDEO_FORMAT_FMP4 HX_MAKE4CC('4', 'P', 'M', 'F')
> #define VIDEO_FORMAT_fmp4 HX_MAKE4CC('4', 'p', 'm', 'f')
> +#define VIDEO_FORMAT_MP4V HX_MAKE4CC('V', '4', 'P', 'M')
> +#define VIDEO_FORMAT_mp4v HX_MAKE4CC('v', '4', 'p', 'm')
> #define VIDEO_FORMAT_H264 HX_MAKE4CC('4', '6', '2', 'H')
> #define VIDEO_FORMAT_h264 HX_MAKE4CC('4', '6', '2', 'h')
> #define VIDEO_FORMAT_AVC1 HX_MAKE4CC('1', 'C', 'V', 'A')
> @@ -806,7 +808,9 @@
> (m_header.ulHandler == VIDEO_FORMAT_xvid) ||
> (m_header.ulHandler == VIDEO_FORMAT_DX50) ||
> (m_header.ulHandler == VIDEO_FORMAT_FMP4) ||
> - (m_header.ulHandler == VIDEO_FORMAT_fmp4))
> + (m_header.ulHandler == VIDEO_FORMAT_fmp4) ||
> + (m_header.ulHandler == VIDEO_FORMAT_MP4V) ||
> + (m_header.ulHandler == VIDEO_FORMAT_mp4v))
> {
> strcpy(szStreamName, "Video Track");
> strcpy (szMimeType, "video/X-HX-DIVX");
>
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
> .
>
>
From Yury.Ramanovich at nokia.com Mon Jul 19 12:03:49 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Mon Jul 19 18:41:21 2010
Subject: [datatype-dev] CR needed: Symbian - 420 Brizo - ou1cimx1#474138 -
XPSPacketSink.lib is not linked with QT app
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
? diff.txt
? bif-cvs/helix
Index: umake/umake_symbianmmp.py
===================================================================
RCS file: /cvsroot/ribosome/build/umake/umake_symbianmmp.py,v
retrieving revision 1.24
diff -u -w -r1.24 umake_symbianmmp.py
--- umake/umake_symbianmmp.py 25 May 2010 23:48:48 -0000 1.24
+++ umake/umake_symbianmmp.py 15 Jul 2010 17:13:58 -0000
@@ -318,6 +318,13 @@
self.writeln("")
+ if ( type == "lib" and self.sbsv2 == 1 ):
+ ##
+ ## STDCPP
+ ##
+ if (project.symbianUtil.stdcppsupport == True):
+ self.writeln("STDCPP")
+
##
## Check for any resource files
##
Index: umakecf/symbian-armv5.cf
===================================================================
RCS file: /cvsroot/ribosome/build/umakecf/symbian-armv5.cf,v
retrieving revision 1.33
diff -u -w -r1.33 symbian-armv5.cf
--- umakecf/symbian-armv5.cf 10 May 2010 19:53:13 -0000 1.33
+++ umakecf/symbian-armv5.cf 15 Jul 2010 17:13:58 -0000
@@ -308,6 +308,11 @@
cmd_list.append(cmd)
arg_list = ["-r -v", target_path, objects]
+
+ if (project.symbianUtil.stdcppsupport == True):
+ stdcpp_tag_file = os.path.join(GetSDKPath('SYMBIANSDK'), 'epoc32\\tools\\tag\\tag_elf')
+ arg_list.append(stdcpp_tag_file)
+
cmd = 'armar.exe %s' % (string.join(arg_list))
cmd_list.append(cmd)
Index: umakecf/symbian-emulator-winscw.cf
===================================================================
RCS file: /cvsroot/ribosome/build/umakecf/symbian-emulator-winscw.cf,v
retrieving revision 1.30
diff -u -w -r1.30 symbian-emulator-winscw.cf
--- umakecf/symbian-emulator-winscw.cf 30 Apr 2010 21:49:10 -0000 1.30
+++ umakecf/symbian-emulator-winscw.cf 15 Jul 2010 17:13:58 -0000
@@ -318,6 +318,12 @@
"-library",
"-o %s" % (target_path),
objects]
+
+ if (project.symbianUtil.stdcppsupport == True):
+ stdcpp_tag_opt = '-l %s' % os.path.join(GetSDKPath('SYMBIANSDK'), 'epoc32\\tools\\tag')
+ stdcpp_tag_opt += " -search tag_coff"
+ arg_list.append(stdcpp_tag_opt)
+
cmd = "mwldsym2 %s" % (string.join(arg_list))
cmd_list.append(cmd)
Index: umakecf/symbian.cf
===================================================================
RCS file: /cvsroot/ribosome/build/umakecf/symbian.cf,v
retrieving revision 1.78
diff -u -w -r1.78 symbian.cf
--- umakecf/symbian.cf 30 Apr 2010 21:49:10 -0000 1.78
+++ umakecf/symbian.cf 15 Jul 2010 17:13:58 -0000
@@ -173,6 +173,7 @@
self.uid3 = 0
self.capabilities = 'CAP_ECOM_PLUGIN'
self.allowdlldata = False
+ self.stdcppsupport = False
self.ARMCCOptions = ""
self.frzfile = ""
self.UsePlatformDefFile = False
@@ -245,6 +246,11 @@
def Setallowdlldata(self):
self.allowdlldata = True
+ def SetStdCppSupport(self):
+ self.stdcppsupport = True
+ if not project.IsDefined('HELIX_CONFIG_SYMBIAN_GENERATE_MMP'):
+ project.AddDefines('__SYMBIAN_STDCPP_SUPPORT__')
+
def SetARMCCOptions(self, Options):
self.ARMCCOptions = Options
Index: CXPSPacketSink.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/CXPSPacketSink.cpp,v
retrieving revision 1.3.14.1
diff -u -w -r1.3.14.1 CXPSPacketSink.cpp
--- CXPSPacketSink.cpp 26 Feb 2010 21:41:59 -0000 1.3.14.1
+++ CXPSPacketSink.cpp 15 Jul 2010 17:14:56 -0000
@@ -135,7 +135,7 @@
{
if( (m_pPktServerCtx == NULL) && (m_pXPSSession == NULL) )
{
- m_pPktServerCtx = new CXPSPacketServerCtx();
+ m_pPktServerCtx = new (nothrow) CXPSPacketServerCtx();
m_pXPSSession = CXPSSession::New(NULL, pObserver);
if( (m_pPktServerCtx != NULL) && (m_pXPSSession != NULL) )
Index: CXPSPktQue.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/CXPSPktQue.cpp,v
retrieving revision 1.2
diff -u -w -r1.2 CXPSPktQue.cpp
--- CXPSPktQue.cpp 16 Apr 2008 15:57:50 -0000 1.2
+++ CXPSPktQue.cpp 15 Jul 2010 17:14:56 -0000
@@ -97,7 +97,7 @@
{
CXPSPktQue* pQue = NULL;
- pQue = new CXPSPktQue();
+ pQue = new (nothrow) CXPSPktQue();
return pQue;
}
@@ -108,7 +108,7 @@
TInt CXPSPktQue::Init()
{
TInt lRetval = KErrNone;
- m_pPktArray = new RPointerArray();
+ m_pPktArray = new (nothrow) RPointerArray();
if(m_pPktArray == NULL)
{
lRetval = KErrNoMemory;
Index: CXPSSession.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/CXPSSession.cpp,v
retrieving revision 1.7.4.1
diff -u -w -r1.7.4.1 CXPSSession.cpp
--- CXPSSession.cpp 26 Feb 2010 21:42:26 -0000 1.7.4.1
+++ CXPSSession.cpp 15 Jul 2010 17:14:56 -0000
@@ -139,7 +139,7 @@
XPS_LOG(_L("CXPSSession[%x]::ConfigSession StrmCnt::%d ->"), this, uStreamCnt);
m_uStreamCnt = uStreamCnt;
- m_arrXPSStreams = new CXPSStream[m_uStreamCnt] ;
+ m_arrXPSStreams = new (nothrow) CXPSStream[m_uStreamCnt] ;
if(m_arrXPSStreams && m_AccessMutex.Handle() > 0 )
{
@@ -455,7 +455,7 @@
if(unStreamId < m_uStreamCnt)
{
// Create XPSPacket
- CXPSPacket* pXPSPacket = new CXPSPacket(aHeaderInfo.iTimestamp,
+ CXPSPacket* pXPSPacket = new (nothrow) CXPSPacket(aHeaderInfo.iTimestamp,
aHeaderInfo.iSeqNum,
aPayloadData.Size(),
unStreamId,
Index: CXPSSession.h
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/CXPSSession.h,v
retrieving revision 1.5.10.1
diff -u -w -r1.5.10.1 CXPSSession.h
--- CXPSSession.h 26 Feb 2010 21:42:45 -0000 1.5.10.1
+++ CXPSSession.h 15 Jul 2010 17:14:56 -0000
@@ -67,7 +67,8 @@
#include
#include
-
+#include
+using namespace std;
#include "CXPSPacket.h"
#include "CXPSServerCmds.h"
Index: CXPSStream.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/CXPSStream.cpp,v
retrieving revision 1.8
diff -u -w -r1.8 CXPSStream.cpp
--- CXPSStream.cpp 11 May 2009 16:39:20 -0000 1.8
+++ CXPSStream.cpp 15 Jul 2010 17:14:56 -0000
@@ -205,7 +205,7 @@
m_uStreamId = uStreamId;
- m_pXPSPktQue = new CXPSPktQue();
+ m_pXPSPktQue = new (nothrow) CXPSPktQue();
// Creates the active obj on the caller's ActiveScheduler.
m_pNotifier = new CXPSPktRestoreNotifier(m_uStreamId, m_pXPSPktSinkObserver);
Index: XPSPacketSinkLib
===================================================================
RCS file: /cvsroot/datatype/xps/PacketSink/XPSPacketSinkLib,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 XPSPacketSinkLib
--- XPSPacketSinkLib 4 Oct 2006 15:28:18 -0000 1.1.1.1
+++ XPSPacketSinkLib 15 Jul 2010 17:14:56 -0000
@@ -66,6 +66,8 @@
project.AddModuleIncludes('datatype/xps/fileformat')
project.AddModuleIncludes('common/system/pub/platform/symbian')
+project.AddIncludes(os.path.join(GetSDKPath("SYMBIANSDK"), "epoc32\include\stdapis\stlportv5"))
+
project.AddSources("CXPSPacketServer.cpp")
project.AddSources("CXPSPacketSink.cpp")
project.AddSources("CXPSSession.cpp")
@@ -76,6 +78,8 @@
project.AddSources("../fileformat/CXPSPacket.cpp")
project.AddSources("../../../common/system/platform/symbian/CActiveObj.cpp")
+project.symbianUtil.SetStdCppSupport()
+
LibraryTarget('XPSPacketSink')
DependTarget()
From jgordon at real.com Mon Jul 19 16:06:56 2010
From: jgordon at real.com (Jamie Gordon)
Date: Mon Jul 19 22:44:29 2010
Subject: [datatype-dev] Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
In-Reply-To:
References:
Message-ID: <4C44E8A0.2050202@real.com>
ok
On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
> Modified by: _yury.ramanovich@nokia.com_
>
> Reviewed by:
>
> Date: 07/15/2010
>
> Project: symbian_client_apps
>
> ErrorId: ou1cimx1#474138
>
> Synopsis: XPSPacketSink.lib is not linked with QT app
>
> Overview: when XPSPacketSink.lib is linked with QT app (like FlashLite)
> that has STDCPP keyword in its .mmp file, checklib tool gives error:
> ?xpspacketsink.lib is incompatible with standard C++?. The reason for
> this error is the standard C++ operators new and new [] used throughout
> the xpspacketsink.lib code, but the library doesn?t declare itself as
> supporting standard C++ new and new[] behavior.
>
> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which effectively
> tags the lib as supporting standard C++ new and new[] operators during
> ?mmp helix build?. Also do the same for the winscw and armv5 ?CVS helix
> builds? via mwldsym2 and armar command line options and
> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be controlled by
> build system SymbianUtils.stdcppsupport flag, which will be set in
> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
> 2) use new (nothrow) operator for non-CBase heap allocations in
> xpspacketsink.lib source since we don?t handle bad_alloc exception.
>
> Files Added:
> None.
>
> Files Modified:
> /ribosome/build/umake/umake_symbianmmp.py
> /ribosome/build/umakecf/symbian-armv5.cf
> /ribosome/build/umakecf/symbian-emulator-winscw.cf
> /ribosome/build/umakecf/symbian.cf
> /datatype/xps/PacketSink/CXPSPacketSink.cpp
> /datatype/xps/PacketSink/CXPSPktQue.cpp
> /datatype/xps/PacketSink/CXPSSession.cpp
> /datatype/xps/PacketSink/CXPSSession.h
> /datatype/xps/PacketSink/CXPSStream.cpp
> /datatype/xps/PacketSink/XPSPacketSinkLib
>
>
> Image Size and Heap Use impact: minor
>
> Module Release testing : yes, XPSTestApp
>
> 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.
>
>
> BR
>
>
>
From jgordon at real.com Mon Jul 19 16:19:49 2010
From: jgordon at real.com (Jamie Gordon)
Date: Mon Jul 19 22:57:18 2010
Subject: [datatype-dev] CR: wmcode-audio on hxclient_3_1_0_Atlas branch
In-Reply-To:
References:
Message-ID: <4C44EBA5.2050300@real.com>
ok
On 7/16/2010 5:02 PM, Robert Nelson wrote:
> These updates are required to build with the Windows 7 version of the
> Platform SDK.
>
>
>
> This has been tested using VC9 using the standard (Vista) version of the
> SDK as well as VC9 using the Windows 7 version of the SDK.
>
>
>
> I don?t have the environments available to test for either VC6 or VC7.
>
>
>
From hxing at real.com Tue Jul 20 01:46:45 2010
From: hxing at real.com (hxing)
Date: Tue Jul 20 08:24:28 2010
Subject: [datatype-dev] new fix for bug10370 no audio when seek before start
to play
Message-ID: <20100720101517.1F5FFA3AB2@spamwall.internal.helixcommunity.org>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_aviffpln_cpp
Type: application/octet-stream
Size: 1287 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/89bab850/diff_aviffpln_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_aviffpln_h
Type: application/octet-stream
Size: 465 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/89bab850/diff_aviffpln_h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_avistrm_cpp
Type: application/octet-stream
Size: 2755 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/89bab850/diff_avistrm_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_avistrm_h
Type: application/octet-stream
Size: 719 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/89bab850/diff_avistrm_h-0001.obj
From ext-shashi.merapala at nokia.com Tue Jul 20 03:08:34 2010
From: ext-shashi.merapala at nokia.com (ext-shashi.merapala@nokia.com)
Date: Tue Jul 20 09:46:01 2010
Subject: [datatype-dev] CR: ou1cimx1#436751 - FL4.0 -XPS Streaming- After We
Pause and Resume playback it fails to play at EOF.
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
Pause and Resume playback it fails to play at EOF
Date: Tue, 6 Jul 2010 08:15:43 +0200
Size: 8003
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/a529805b/attachment-0002.mht
-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming-
After We Pause and Resume playback it fails to play at EOF
Date: Wed, 7 Jul 2010 10:43:52 +0200
Size: 6952
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100720/a529805b/attachment-0003.mht
From Yury.Ramanovich at nokia.com Tue Jul 20 10:04:12 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Tue Jul 20 16:41:53 2010
Subject: [datatype-dev] RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
In-Reply-To: <4C44E8A0.2050202@real.com>
References:
<4C44E8A0.2050202@real.com>
Message-ID:
Checked in to 420Brizo
BR
Yury
>-----Original Message-----
>From: ext Jamie Gordon [mailto:jgordon@real.com]
>Sent: Monday, July 19, 2010 7:07 PM
>To: Ramanovich Yury (Nokia-MS/Dallas)
>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>
>ok
>
>On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
>> Modified by: _yury.ramanovich@nokia.com_
>
>>
>> Reviewed by:
>>
>> Date: 07/15/2010
>>
>> Project: symbian_client_apps
>>
>> ErrorId: ou1cimx1#474138
>>
>> Synopsis: XPSPacketSink.lib is not linked with QT app
>>
>> Overview: when XPSPacketSink.lib is linked with QT app (like
>FlashLite)
>> that has STDCPP keyword in its .mmp file, checklib tool gives error:
>> "xpspacketsink.lib is incompatible with standard C++". The reason for
>> this error is the standard C++ operators new and new [] used
>throughout
>> the xpspacketsink.lib code, but the library doesn't declare itself as
>> supporting standard C++ new and new[] behavior.
>>
>> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which
>effectively
>> tags the lib as supporting standard C++ new and new[] operators during
>> "mmp helix build". Also do the same for the winscw and armv5 "CVS
>helix
>> builds" via mwldsym2 and armar command line options and
>> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be controlled
>by
>> build system SymbianUtils.stdcppsupport flag, which will be set in
>> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
>> 2) use new (nothrow) operator for non-CBase heap allocations in
>> xpspacketsink.lib source since we don't handle bad_alloc exception.
>>
>> Files Added:
>> None.
>>
>> Files Modified:
>> /ribosome/build/umake/umake_symbianmmp.py
>> /ribosome/build/umakecf/symbian-armv5.cf
>> /ribosome/build/umakecf/symbian-emulator-winscw.cf
>> /ribosome/build/umakecf/symbian.cf
>> /datatype/xps/PacketSink/CXPSPacketSink.cpp
>> /datatype/xps/PacketSink/CXPSPktQue.cpp
>> /datatype/xps/PacketSink/CXPSSession.cpp
>> /datatype/xps/PacketSink/CXPSSession.h
>> /datatype/xps/PacketSink/CXPSStream.cpp
>> /datatype/xps/PacketSink/XPSPacketSinkLib
>>
>>
>> Image Size and Heap Use impact: minor
>>
>> Module Release testing : yes, XPSTestApp
>>
>> 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.
>>
>>
>> BR
>>
>>
>>
From gahluwalia at real.com Tue Jul 20 23:40:21 2010
From: gahluwalia at real.com (Gurpreet)
Date: Wed Jul 21 06:17:43 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C3CC3F6.30904@real.com>
References: <4C330708.807@real.com>
<4C336DD2.8040901@real.com> <4C355263.6080304@real.com>
<4C355FA5.7080200@real.com> <4C3C16E1.2060808@real.com>
<4C3CC3F6.30904@real.com>
Message-ID: <4C46A465.9010101@real.com>
Hi,
I think these changes are for cases when we don't have Decoder Specific
Object in fileformat(i.e avi ff)
There is already change done in aac decoder to check for config.
If its null then default values are picked.
Correct configuration is later read from decoder when it is fed few frames.
I have attached the earlier diff for reference.
If these changes are considered to be safe then I would request that
these changes to be merged into atlas 3411 also.
Best Regards,
Gurpreet
On 7/14/2010 1:22 AM, Sheldon Fu wrote:
> Care to explain why the difference and 'can not use'?
>
> I looked at the change you made for AVIADTS. It seems that you are
> passing the ADTS frames directly to the decoder -- no stripping of th
> ADTS headers and without any codec config data. I don't think this will
> work with the default raac software decoder
> (datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
> config data is null and even that passes, it will expect raw AU unit as
> input, instead of ADTS frame. Have you tried your solution on a generic
> Linux build?
>
> fxd
>
> Sushant Garg wrote:
>
>> We can not use code written for AVIADTS, therefore merged my changes to
>> Head too.
>>
>> Regards,
>> Sushant
>>
>> Sheldon Fu wrote:
>>
>>
>>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>>> carries ADTS frames as packets and first frame as OapqueData. What is
>>> different for AVIADTS? There might be a chance these two can be merged
>>> as one.
>>>
>>> And if AVIADTS is different and needed, this should go into Head too.
>>>
>>> fxd
>>>
>>> Sushant Garg wrote:
>>>
>>>
>>>
>>>> Thanks Jamie,
>>>>
>>>> Changes checked in to Atlas3410& Atlas310.
>>>>
>>>> Regards,
>>>> Sushant
>>>>
>>>> Jamie Gordon wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> ok
>>>>>
>>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> *Project: RealPlayer for Netbook*
>>>>>>
>>>>>> *Synopsis:*
>>>>>>
>>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>>
>>>>>> * *
>>>>>>
>>>>>> *Overview:*
>>>>>>
>>>>>> Added support to play AVI ADTS files.
>>>>>>
>>>>>> Created a new mime type for such files& handle their parsing in mp4
>>>>>> renderer.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Files Modified:
>>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>>
>>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>>
>>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>>
>>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>>
>>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Files Added: *
>>>>>>
>>>>>> None
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Platforms and Profiles Affected:
>>>>>> *Linux
>>>>>>
>>>>>> *Distribution Libraries Affected:*
>>>>>> None.
>>>>>>
>>>>>> *Platforms and Profiles Build Verified:
>>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>>> *Profile:* helix-client-moblin
>>>>>> *Target:* mediasinkplayer
>>>>>>
>>>>>>
>>>>>> *Branch:*
>>>>>> Atlas3_4_10, Atlas310
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Attachment:*
>>>>>>
>>>>>> diff.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks& Regards,
>>>>>>
>>>>>> Sushant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
> .
>
>
-------------- next part --------------
Index: hxwrap/aacdecdll.cpp
===================================================================
RCS file: /cvsroot/datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp,v
retrieving revision 1.5.14.1
diff -u -r1.5.14.1 aacdecdll.cpp
--- hxwrap/aacdecdll.cpp 29 Jan 2009 05:36:14 -0000 1.5.14.1
+++ hxwrap/aacdecdll.cpp 9 Jun 2010 11:52:56 -0000
@@ -46,6 +46,10 @@
#include "aacdecdll.h"
#include "aacconstants.h"
+#define DUMMY_CHANNELS 2
+#define DUMMY_SAMPLE_RATE 44100
+#define DUMMY_FRAME_LENGTH 8192
+
const char* const CAACDec::m_pszCodecName = "RealAudio 10";
CAACDec::CAACDec()
@@ -198,6 +202,8 @@
return HXR_OK;
case eAACConfigAudioSpecificCfg:
+ if(config)
+ {
if (newBitstream(&pBs, 8*nBytes))
return HXR_FAIL;
@@ -256,6 +262,22 @@
}
AACSetRawBlockParams(m_hAACDecoder, 0, &m_aacFrameInfo);
+ }
+ else
+ {
+ // Use default dummy values for now, we will get actual values when
+ // decoder will parse first frame
+ m_ulChannels = DUMMY_CHANNELS;
+ m_ulCoreSampleRate = DUMMY_SAMPLE_RATE;
+ m_ulSampleRate = DUMMY_SAMPLE_RATE;
+ m_ulFrameLength = DUMMY_FRAME_LENGTH;
+ m_aacFrameInfo.nChans = m_ulChannels;
+ m_aacFrameInfo.sampRateCore = m_ulCoreSampleRate; /* sample rate of BASE layer */
+ m_ulMaxFrameLength = m_ulFrameLength;
+ m_hAACDecoder = (HAACDecoder *)AACInitDecoder();
+ if (!m_hAACDecoder)
+ return HXR_FAIL;
+ }
return HXR_OK;
From sfu at real.com Wed Jul 21 05:17:03 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Jul 21 11:52:51 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C46A465.9010101@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com> <4C355263.6080304@real.com> <4C355FA5.7080200@real.com> <4C3C16E1.2060808@real.com> <4C3CC3F6.30904@real.com>
<4C46A465.9010101@real.com>
Message-ID: <4C46F34F.90503@real.com>
I don't believe this is a good idea. Decoder needs enough information in
Init call to decide whether it can handle the stream or not. Without
setup info, it can not make that judgment. It will present problems when
there are multiple decoders (say a hw one and a software backup).
Also with the default dummy value approach, you will open and close and
reopen the audio device when the audio format is switched from default
to actual one -- adding delay to the play start and resource drain.
The AVI FF should be changed so that it pre-read the first ADTS frame
and use that as the decoder setup data (OpaqueData) as other FF does
(e.g. the raw .aac ff when the data is in adts frame format).
fxd
Gurpreet Ahluwalia wrote:
> Hi,
> I think these changes are for cases when we don't have Decoder Specific
> Object in fileformat(i.e avi ff)
>
> There is already change done in aac decoder to check for config.
> If its null then default values are picked.
> Correct configuration is later read from decoder when it is fed few frames.
> I have attached the earlier diff for reference.
>
> If these changes are considered to be safe then I would request that
> these changes to be merged into atlas 3411 also.
>
> Best Regards,
> Gurpreet
>
>
> On 7/14/2010 1:22 AM, Sheldon Fu wrote:
>
>> Care to explain why the difference and 'can not use'?
>>
>> I looked at the change you made for AVIADTS. It seems that you are
>> passing the ADTS frames directly to the decoder -- no stripping of th
>> ADTS headers and without any codec config data. I don't think this will
>> work with the default raac software decoder
>> (datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
>> config data is null and even that passes, it will expect raw AU unit as
>> input, instead of ADTS frame. Have you tried your solution on a generic
>> Linux build?
>>
>> fxd
>>
>> Sushant Garg wrote:
>>
>>
>>> We can not use code written for AVIADTS, therefore merged my changes to
>>> Head too.
>>>
>>> Regards,
>>> Sushant
>>>
>>> Sheldon Fu wrote:
>>>
>>>
>>>
>>>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>>>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>>>> carries ADTS frames as packets and first frame as OapqueData. What is
>>>> different for AVIADTS? There might be a chance these two can be merged
>>>> as one.
>>>>
>>>> And if AVIADTS is different and needed, this should go into Head too.
>>>>
>>>> fxd
>>>>
>>>> Sushant Garg wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks Jamie,
>>>>>
>>>>> Changes checked in to Atlas3410& Atlas310.
>>>>>
>>>>> Regards,
>>>>> Sushant
>>>>>
>>>>> Jamie Gordon wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ok
>>>>>>
>>>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> *Project: RealPlayer for Netbook*
>>>>>>>
>>>>>>> *Synopsis:*
>>>>>>>
>>>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>>>
>>>>>>> * *
>>>>>>>
>>>>>>> *Overview:*
>>>>>>>
>>>>>>> Added support to play AVI ADTS files.
>>>>>>>
>>>>>>> Created a new mime type for such files& handle their parsing in mp4
>>>>>>> renderer.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Files Modified:
>>>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>>>
>>>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>>>
>>>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>>>
>>>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>>>
>>>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Files Added: *
>>>>>>>
>>>>>>> None
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Platforms and Profiles Affected:
>>>>>>> *Linux
>>>>>>>
>>>>>>> *Distribution Libraries Affected:*
>>>>>>> None.
>>>>>>>
>>>>>>> *Platforms and Profiles Build Verified:
>>>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>>>> *Profile:* helix-client-moblin
>>>>>>> *Target:* mediasinkplayer
>>>>>>>
>>>>>>>
>>>>>>> *Branch:*
>>>>>>> Atlas3_4_10, Atlas310
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Attachment:*
>>>>>>>
>>>>>>> diff.txt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks& Regards,
>>>>>>>
>>>>>>> Sushant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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-shashi.merapala at nokia.com Wed Jul 21 05:19:36 2010
From: ext-shashi.merapala at nokia.com (ext-shashi.merapala@nokia.com)
Date: Wed Jul 21 11:57:23 2010
Subject: [datatype-dev] RESEND: [Nokia-private-dev] CR: ou1cimx1#436751 -
FL4.0 -XPS
Streaming- After We Pause and Resume playback it fails to play at EOF.
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
Pause and Resume playback it fails to play at EOF
Date: Tue, 6 Jul 2010 08:15:43 +0200
Size: 7973
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100721/47fea0f0/attachment-0002.mht
-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming-
After We Pause and Resume playback it fails to play at EOF
Date: Wed, 7 Jul 2010 10:43:52 +0200
Size: 6922
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100721/47fea0f0/attachment-0003.mht
-------------- 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 Jul 21 12:57:27 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 21 19:34:32 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: Linux Compatibility
Issues
In-Reply-To: <89F9BF23C080784180D44D7A8FEBA4292BC1653644@NOK-EUMSG-03.mgdnok.nokia.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC1653644@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4C475F37.5050102@real.com>
ok
On 7/21/2010 7:26 AM, ext-sanket.lopes@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with Real Networks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: ext-sanket.lopes@nokia.com
>
>
>
> Reviewed by: yury.ramanovich@nokia.com
>
>
>
> Date: 07/21/2010
>
>
>
> Project: Datatype
>
>
>
> Error Id: N/A
>
>
>
> Synopsis: Linux Compatibility Issues.
>
>
>
> Overview:
>
> Checksource Failure:
>
> Reference in metadata ->
> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaconfig.h
>
>
> ---------------------------------------------------------------------------------------^-------
>
> Actual case on disk ->
> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaConfig.h
>
>
>
> *helix/helix_ren/src/datatype/mdf/audio/dsp/mdfaudfmt.h:#include
> "gaconfig.h"*
>
>
>
> Files modified:
>
> /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h
>
>
>
> Files removed: None
>
>
>
> Image Size and Heap Use impact: None.
>
>
>
> Module Release testing (STIF) : N/A
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : N/A
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: 210 Cays
>
>
>
> Diff:
>
>
>
> Index: mdfaudfmt.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h,v
>
> retrieving revision 1.1.2.16
>
> diff -u -b -r1.1.2.16 mdfaudfmt.h
>
> --- mdfaudfmt.h 22 Jun 2010 06:49:37 -0000 1.1.2.16
>
> +++ mdfaudfmt.h 20 Jul 2010 21:02:35 -0000
>
> @@ -62,7 +62,7 @@
>
>
>
> //class CAudioSpecificConfig;
>
>
>
> -#include "gaconfig.h"
>
> +#include "gaConfig.h"
>
>
>
> #define KMMFFourCCCodeEAACP 0x43414520 // ' ' 'E' 'A' 'C'
>
>
>
From ext-sanket.lopes at nokia.com Fri Jul 2 08:07:18 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Thu Jul 22 05:54:19 2010
Subject: [datatype-dev] RESEND: CR: Provide support for playing
PlayReady encrypted media clips
In-Reply-To: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC13DA4C3@NOK-EUMSG-03.mgdnok.nokia.com>
Any comments ?
BR,
Sanket
From: nokia-private-dev-bounces@helixcommunity.org [mailto:nokia-private-dev-bounces@helixcommunity.org] On Behalf Of Lopes Sanket (EXT-Infovision/Dallas)
Sent: Wednesday, June 30, 2010 5:13 PM
To: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
"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-sanket.lopes@nokia.com
Reviewed by: anshuman.tewari@nokia.com
TSW Id:
Date: 06/30/2010
Project: symbian_client_apps
Synopsis: Provide support for playing PlayReady encrypted media clips on 420Brizo.
Overview: Microsoft PlayReady content access technology is a new content access technology designed for digital entertainment services, devices and applications. Playready DRM protected files have clear headers only the data is encrypted. So Helix needs to recognize the file by interpreting the headers correctly, then read the encrypted Data and get it decrypted from WmDrmServer and then pass for playing. With this CR we are only submitting changes required for Helix to support Playready. WmDrmServer code is not yet available and so this Helix implementation is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
Files modified & changes:
/cvsroot/client/medpltfm/chxmedpltfm.cpp,v
/cvsroot/client/common/system/hxcommn.cpp,v
/cvsroot/common/include/ihxpckts.h,v
/cvsroot/common/include/hxiids.h,v
/cvsroot/common/container/pub/old_hxpckts.h,v
/cvsroot/common/container/pub/chxpckts.h,v
/cvsroot/common/container/old_hxpckts.cpp,v
/cvsroot/common/container/chxpckts.cpp,v
/cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
/cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
/cvsroot/datatype/wm/common/pub/asf_guids.h,v
/cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
/cvsroot/datatype/wm/common/parse_video.cpp,v
/cvsroot/datatype/wm/common/parse_audio.cpp,v
/cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
/cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
/cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
/cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
/cvsroot/datatype/wm/fileformat/asf_index.cpp,v
/cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
/cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
/cvsroot/datatype/wm/wmdrm/guids.cpp,v
/cvsroot/datatype/wm/wmdrm/symbian.pcf,v
/cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
/cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Yes
Test case(s) Added : No
Memory leak check performed : No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-dsp
Platforms and Profiles Functionality verified: armv5
Branch: 420Bizo and HEAD
Diff attached:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100702/b4f0f71d/attachment-0001.html
From ext-sanket.lopes at nokia.com Tue Jul 6 10:36:54 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Thu Jul 22 05:54:21 2010
Subject: [datatype-dev] RESEND: RESEND: CR: Provide support for playing
PlayReady encrypted media clips
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC13DB08C@NOK-EUMSG-03.mgdnok.nokia.com>
Any comments for this?
Thanks,
Sanket
From: Lopes Sanket (EXT-Infovision/Dallas)
Sent: Friday, July 02, 2010 12:26 PM
To: Lopes Sanket (EXT-Infovision/Dallas); nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: RESEND: CR: Provide support for playing PlayReady encrypted media clips
Any comments ?
BR,
Sanket
From: nokia-private-dev-bounces@helixcommunity.org [mailto:nokia-private-dev-bounces@helixcommunity.org] On Behalf Of Lopes Sanket (EXT-Infovision/Dallas)
Sent: Wednesday, June 30, 2010 5:13 PM
To: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
"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-sanket.lopes@nokia.com
Reviewed by: anshuman.tewari@nokia.com
TSW Id:
Date: 06/30/2010
Project: symbian_client_apps
Synopsis: Provide support for playing PlayReady encrypted media clips on 420Brizo.
Overview: Microsoft PlayReady content access technology is a new content access technology designed for digital entertainment services, devices and applications. Playready DRM protected files have clear headers only the data is encrypted. So Helix needs to recognize the file by interpreting the headers correctly, then read the encrypted Data and get it decrypted from WmDrmServer and then pass for playing. With this CR we are only submitting changes required for Helix to support Playready. WmDrmServer code is not yet available and so this Helix implementation is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
Files modified & changes:
/cvsroot/client/medpltfm/chxmedpltfm.cpp,v
/cvsroot/client/common/system/hxcommn.cpp,v
/cvsroot/common/include/ihxpckts.h,v
/cvsroot/common/include/hxiids.h,v
/cvsroot/common/container/pub/old_hxpckts.h,v
/cvsroot/common/container/pub/chxpckts.h,v
/cvsroot/common/container/old_hxpckts.cpp,v
/cvsroot/common/container/chxpckts.cpp,v
/cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
/cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
/cvsroot/datatype/wm/common/pub/asf_guids.h,v
/cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
/cvsroot/datatype/wm/common/parse_video.cpp,v
/cvsroot/datatype/wm/common/parse_audio.cpp,v
/cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
/cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
/cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
/cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
/cvsroot/datatype/wm/fileformat/asf_index.cpp,v
/cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
/cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
/cvsroot/datatype/wm/wmdrm/guids.cpp,v
/cvsroot/datatype/wm/wmdrm/symbian.pcf,v
/cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
/cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Yes
Test case(s) Added : No
Memory leak check performed : No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-dsp
Platforms and Profiles Functionality verified: armv5
Branch: 420Bizo and HEAD
Diff attached:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100706/6a99a53f/attachment-0001.html
From ext-sanket.lopes at nokia.com Wed Jul 7 12:03:56 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Thu Jul 22 05:54:22 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: Provide support for
playing PlayReady encrypted media clips
In-Reply-To: <4C34A260.7080101@real.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
<4C34A260.7080101@real.com>
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC147EBD4@NOK-EUMSG-03.mgdnok.nokia.com>
Hi Jamie,
Replicated Data is stored as part of the each packet in Windows Media files it may or may not be present in all files. For Playready file it is guaranteed to be present and this holds sampleid, which is like a key required by the wmdrm to decrypt the contents.
You can always refer to ASF specification, however here is a snippet from the same
----------------------------------------------------------------------------------------------------------------------
4.1 Extended Stream Properties Object (optional, 1 per media stream)
The Extended Stream Properties Object defines additional optional properties and characteristics of a digital media stream that are not described in the Stream Properties Object.
Typically, the basic Stream Properties Object is present in the Header Object, and the Extended Stream Properties Object is present in the Header Extension Object. Sometimes, however, the Stream Properties Object for a stream may be embedded inside the Extended Stream Properties Object for that stream. This approach facilitates the creation of backward-compatible content and is appropriate for some of the scenarios discussed in section 8.
This object has an optional provision to include application-specific or implementation-specific data attached to the payloads of each digital media sample stored within a Data Packet. This data can be looked at as digital media sample properties and is stored in the Replicated Data field of a payload header. The Payload Extension Systems fields of the Extended Stream Properties Object describes what this data is and is necessary for that data to be parsed, if present.
----------------------------------------------------------------------------------------------------------------------
If we enable "HXASF_COPY_REPLICATED_DATA_INTO_PACKET" macro, it copies replicated data into the packet buffer even for non-playready contents (non-DRM WM clips) as well which we don't want. Otherwise WM DRM plugin needs to be loaded for all the clips and it has to chop-off replicated data from the buffer every time OnPacket() gets called for non-DRM protected clips.
Taking our current approach makes sure execution for regular wma files is not altered in any way.
Thanks,
Sanket
-----Original Message-----
From: ext Jamie Gordon [mailto:jgordon@real.com]
Sent: Wednesday, July 07, 2010 10:51 AM
To: Lopes Sanket (EXT-Infovision/Dallas)
Cc: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
What is the purpose of the "replicated data"? Why does it need to be
carried in the packets separately from the regular buffer?
On 6/30/2010 3:13 PM, ext-sanket.lopes@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-sanket.lopes@nokia.com
>
>
>
> Reviewed by: anshuman.tewari@nokia.com
>
>
>
> TSW Id:
>
>
>
> Date: 06/30/2010
>
>
>
> Project: symbian_client_apps
>
>
>
> Synopsis: Provide support for playing PlayReady encrypted media clips on
> 420Brizo.
>
>
>
> Overview: Microsoft PlayReady content access technology is a new content
> access technology designed for digital entertainment services, devices
> and applications. Playready DRM protected files have clear headers only
> the data is encrypted. So Helix needs to recognize the file by
> interpreting the headers correctly, then read the encrypted Data and get
> it decrypted from WmDrmServer and then pass for playing. With this CR we
> are only submitting changes required for Helix to support Playready.
> WmDrmServer code is not yet available and so this Helix implementation
> is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
>
>
>
>
>
> Files modified & changes:
>
> /cvsroot/client/medpltfm/chxmedpltfm.cpp,v
>
> /cvsroot/client/common/system/hxcommn.cpp,v
>
>
>
> /cvsroot/common/include/ihxpckts.h,v
>
> /cvsroot/common/include/hxiids.h,v
>
>
>
> /cvsroot/common/container/pub/old_hxpckts.h,v
>
> /cvsroot/common/container/pub/chxpckts.h,v
>
> /cvsroot/common/container/old_hxpckts.cpp,v
>
> /cvsroot/common/container/chxpckts.cpp,v
>
>
>
> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>
> /cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
>
> /cvsroot/datatype/wm/common/pub/asf_guids.h,v
>
> /cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
>
> /cvsroot/datatype/wm/common/parse_video.cpp,v
>
> /cvsroot/datatype/wm/common/parse_audio.cpp,v
>
> /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>
> /cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
>
>
>
> /cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
>
> /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
>
> /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
>
> /cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
>
> /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
>
>
>
> /cvsroot/datatype/wm/wmdrm/guids.cpp,v
>
> /cvsroot/datatype/wm/wmdrm/symbian.pcf,v
>
> /cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
>
> /cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
>
>
>
>
>
>
>
> Image Size and Heap Use impact: No major impact
>
>
>
> Module Release testing (STIF) : Yes
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : No additional leaks introduced.
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5
>
>
>
> Branch: 420Bizo and HEAD
>
>
>
> Diff attached:
>
>
>
From ext-sanket.lopes at nokia.com Wed Jul 7 15:43:14 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Thu Jul 22 05:54:23 2010
Subject: [datatype-dev] COMMIT: [Nokia-private-dev] CR: Provide support for
playing PlayReady encrypted media clips
In-Reply-To: <4C34F154.7010107@real.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC134E506@NOK-EUMSG-03.mgdnok.nokia.com>
<4C34A260.7080101@real.com>
<89F9BF23C080784180D44D7A8FEBA4292BC147EBD4@NOK-EUMSG-03.mgdnok.nokia.com>
<4C34F154.7010107@real.com>
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC147EC18@NOK-EUMSG-03.mgdnok.nokia.com>
Thanks Jamie,
Committed to $20_Brizo and HEAD
BR,
Sanket
-----Original Message-----
From: ext Jamie Gordon [mailto:jgordon@real.com]
Sent: Wednesday, July 07, 2010 4:28 PM
To: Lopes Sanket (EXT-Infovision/Dallas)
Cc: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
Ahh, I see. Looks good!
On 7/7/2010 1:03 PM, ext-sanket.lopes@nokia.com wrote:
> Hi Jamie,
>
> Replicated Data is stored as part of the each packet in Windows Media files it may or may not be present in all files. For Playready file it is guaranteed to be present and this holds sampleid, which is like a key required by the wmdrm to decrypt the contents.
>
> You can always refer to ASF specification, however here is a snippet from the same
> ----------------------------------------------------------------------------------------------------------------------
> 4.1 Extended Stream Properties Object (optional, 1 per media stream)
> The Extended Stream Properties Object defines additional optional properties and characteristics of a digital media stream that are not described in the Stream Properties Object.
>
> Typically, the basic Stream Properties Object is present in the Header Object, and the Extended Stream Properties Object is present in the Header Extension Object. Sometimes, however, the Stream Properties Object for a stream may be embedded inside the Extended Stream Properties Object for that stream. This approach facilitates the creation of backward-compatible content and is appropriate for some of the scenarios discussed in section 8.
>
> This object has an optional provision to include application-specific or implementation-specific data attached to the payloads of each digital media sample stored within a Data Packet. This data can be looked at as digital media sample properties and is stored in the Replicated Data field of a payload header. The Payload Extension Systems fields of the Extended Stream Properties Object describes what this data is and is necessary for that data to be parsed, if present.
> ----------------------------------------------------------------------------------------------------------------------
>
> If we enable "HXASF_COPY_REPLICATED_DATA_INTO_PACKET" macro, it copies replicated data into the packet buffer even for non-playready contents (non-DRM WM clips) as well which we don't want. Otherwise WM DRM plugin needs to be loaded for all the clips and it has to chop-off replicated data from the buffer every time OnPacket() gets called for non-DRM protected clips.
>
> Taking our current approach makes sure execution for regular wma files is not altered in any way.
>
>
> Thanks,
> Sanket
>
>
> -----Original Message-----
> From: ext Jamie Gordon [mailto:jgordon@real.com]
> Sent: Wednesday, July 07, 2010 10:51 AM
> To: Lopes Sanket (EXT-Infovision/Dallas)
> Cc: nokia-private-dev@helixcommunity.org; clientapps-dev@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: Provide support for playing PlayReady encrypted media clips
>
> What is the purpose of the "replicated data"? Why does it need to be
> carried in the packets separately from the regular buffer?
>
> On 6/30/2010 3:13 PM, ext-sanket.lopes@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-sanket.lopes@nokia.com
>>
>>
>>
>> Reviewed by: anshuman.tewari@nokia.com
>>
>>
>>
>> TSW Id:
>>
>>
>>
>> Date: 06/30/2010
>>
>>
>>
>> Project: symbian_client_apps
>>
>>
>>
>> Synopsis: Provide support for playing PlayReady encrypted media clips on
>> 420Brizo.
>>
>>
>>
>> Overview: Microsoft PlayReady content access technology is a new content
>> access technology designed for digital entertainment services, devices
>> and applications. Playready DRM protected files have clear headers only
>> the data is encrypted. So Helix needs to recognize the file by
>> interpreting the headers correctly, then read the encrypted Data and get
>> it decrypted from WmDrmServer and then pass for playing. With this CR we
>> are only submitting changes required for Helix to support Playready.
>> WmDrmServer code is not yet available and so this Helix implementation
>> is flagged behind HELIX_FEATURE_WMDRM_PLAYREADY_SUPPORT macro.
>>
>>
>>
>>
>>
>> Files modified & changes:
>>
>> /cvsroot/client/medpltfm/chxmedpltfm.cpp,v
>>
>> /cvsroot/client/common/system/hxcommn.cpp,v
>>
>>
>>
>> /cvsroot/common/include/ihxpckts.h,v
>>
>> /cvsroot/common/include/hxiids.h,v
>>
>>
>>
>> /cvsroot/common/container/pub/old_hxpckts.h,v
>>
>> /cvsroot/common/container/pub/chxpckts.h,v
>>
>> /cvsroot/common/container/old_hxpckts.cpp,v
>>
>> /cvsroot/common/container/chxpckts.cpp,v
>>
>>
>>
>> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>>
>> /cvsroot/datatype/wm/common/pub/hxasfdrm.h,v
>>
>> /cvsroot/datatype/wm/common/pub/asf_guids.h,v
>>
>> /cvsroot/datatype/wm/common/pub/asf_guid_enums.h,v
>>
>> /cvsroot/datatype/wm/common/parse_video.cpp,v
>>
>> /cvsroot/datatype/wm/common/parse_audio.cpp,v
>>
>> /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>>
>> /cvsroot/datatype/wm/common/asf_guid_enum_map.cpp,v
>>
>>
>>
>> /cvsroot/datatype/wm/fileformat/asf_depacketizer.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/asf_file_format_file.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
>>
>> /cvsroot/datatype/wm/fileformat/pub/asf_depacketizer.h,v
>>
>> /cvsroot/datatype/wm/fileformat/pub/asf_file_format_file.h,v
>>
>>
>>
>> /cvsroot/datatype/wm/wmdrm/guids.cpp,v
>>
>> /cvsroot/datatype/wm/wmdrm/symbian.pcf,v
>>
>> /cvsroot/datatype/wm/wmdrm/platform/symbian/symbian_wmdrmplugin.cpp,v
>>
>> /cvsroot/datatype/wm/wmdrm/pub/platform/symbian/symbian_wmdrmplugin.h,v
>>
>>
>>
>>
>>
>>
>>
>> Image Size and Heap Use impact: No major impact
>>
>>
>>
>> Module Release testing (STIF) : Yes
>>
>>
>>
>> Test case(s) Added : No
>>
>>
>>
>> Memory leak check performed : No additional leaks introduced.
>>
>>
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-dsp
>>
>>
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>>
>>
>> Branch: 420Bizo and HEAD
>>
>>
>>
>> Diff attached:
>>
>>
>>
From ext-sanket.lopes at nokia.com Wed Jul 21 06:26:18 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Thu Jul 22 05:54:24 2010
Subject: [datatype-dev] CR: Linux Compatibility Issues
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC1653644@NOK-EUMSG-03.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: ext-sanket.lopes@nokia.com
Reviewed by: yury.ramanovich@nokia.com
Date: 07/21/2010
Project: Datatype
Error Id: N/A
Synopsis: Linux Compatibility Issues.
Overview:
Checksource Failure:
Reference in metadata -> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaconfig.h
---------------------------------------------------------------------------------------^-------
Actual case on disk -> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaConfig.h
helix/helix_ren/src/datatype/mdf/audio/dsp/mdfaudfmt.h:#include "gaconfig.h"
Files modified:
/cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h
Files removed: None
Image Size and Heap Use impact: None.
Module Release testing (STIF) : N/A
Test case(s) Added : No
Memory leak check performed : N/A
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210 Cays
Diff:
Index: mdfaudfmt.h
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h,v
retrieving revision 1.1.2.16
diff -u -b -r1.1.2.16 mdfaudfmt.h
--- mdfaudfmt.h 22 Jun 2010 06:49:37 -0000 1.1.2.16
+++ mdfaudfmt.h 20 Jul 2010 21:02:35 -0000
@@ -62,7 +62,7 @@
//class CAudioSpecificConfig;
-#include "gaconfig.h"
+#include "gaConfig.h"
#define KMMFFourCCCodeEAACP 0x43414520 // ' ' 'E' 'A' 'C'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100721/e4382478/attachment-0001.html
From Joeli at real.com Thu Jul 22 03:24:40 2010
From: Joeli at real.com (Joe Li)
Date: Thu Jul 22 10:01:47 2010
Subject: [datatype-dev] CR: MKV Helix.4.2.0-Merge and memory leak issue for
Lephone2
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: pckunpck.cpp.diff
Type: application/octet-stream
Size: 763 bytes
Desc: pckunpck.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/2fd99817/pckunpck.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pckunpck.h.diff
Type: application/octet-stream
Size: 819 bytes
Desc: pckunpck.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/2fd99817/pckunpck.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkv.folder.diff
Type: application/octet-stream
Size: 24961 bytes
Desc: mkv.folder.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/2fd99817/mkv.folder-0001.obj
From ext-shashi.merapala at nokia.com Thu Jul 22 03:40:15 2010
From: ext-shashi.merapala at nokia.com (ext-shashi.merapala@nokia.com)
Date: Thu Jul 22 10:17:23 2010
Subject: [datatype-dev] URGENT: RESEND: [Nokia-private-dev] CR:
ou1cimx1#436751 - FL4.0
-XPS Streaming- After We Pause and Resume playback it fails to play at EOF.
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
Pause and Resume playback it fails to play at EOF
Date: Tue, 6 Jul 2010 08:15:43 +0200
Size: 7973
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/29fe601f/attachment-0002.mht
-------------- next part --------------
An embedded message was scrubbed...
From:
Subject: RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming-
After We Pause and Resume playback it fails to play at EOF
Date: Wed, 7 Jul 2010 10:43:52 +0200
Size: 6922
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/29fe601f/attachment-0003.mht
-------------- next part --------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From tseaward at real.com Thu Jul 22 08:27:50 2010
From: tseaward at real.com (Tony Seaward)
Date: Thu Jul 22 15:04:47 2010
Subject: [datatype-dev] Re: URGENT: RESEND: [Nokia-private-dev] CR:
ou1cimx1#436751 - FL4.0
-XPS Streaming- After We Pause and Resume playback it fails to play at EOF.
In-Reply-To:
References:
Message-ID: <4C487186.4070909@real.com>
We'll get on this immediately this AM.
Tony Seaward
Program Manager
RealNetworks
On 7/22/10 4:40 AM, ext-shashi.merapala@nokia.com wrote:
>
> Can someone please review this one ? This is urgent.
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Wednesday, July 21, 2010 6:50 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* RESEND: [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0
> -XPS Streaming- After We Pause and Resume playback it fails to play at
> EOF.
>
>
>
> Any feedback on this one ?
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Tuesday, July 20, 2010 4:39 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0 -XPS
> Streaming- After We Pause and Resume playback it fails to play at EOF.
>
>
>
> "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-shashi.merapala@nokia.com
>
>
>
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
>
>
>
> Date: 07/20/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Error Id: ou1cimx1#436751
>
>
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it
> fails to play at EOF.
>
>
>
> Overview: A CR of this error id had already been sent and reviewed. Kindly refer to the mail attachments. But, it had contained only a part fix.
> Hence, this mail shall take care of the other part of the fix after flash team has provided their part of fix.
>
> When the user seeks after the EOF had been set, and after Reset happens, application shall again send EOF to XPS Packet Sink. But, the CXPSClientStream has not registered for the second time EOF notification. Because of this, the EndStream call of CXPSFileFormat is not getting called and Helix tries to ReBuffer leading to the error.
>
>
> Solution: The change is to again register for the EOF notification in
> CXPSClientStream::Reset(). This enables to handle such cases where the
> user seeks after the EOF had been set.
>
>
>
> Diff below.
>
>
>
> Files added: None
>
>
>
> Files modified: \datatype\xps\fileformat\CXPSClientStream.cpp
>
>
> Image size and heap use impact: Negligible
>
>
>
> Module release testing (STIF): Done. Passed.
>
>
>
> Test case(s) added: No
>
>
>
> Memory leak check performed: NA
>
>
>
> Platforms and profiles build verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and profiles functionality verified: armv5, winscw
>
>
>
> Branch: 210CayS, HEAD, 420Brizo
>
>
>
> Index: CXPSClientStream.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/xps/fileformat/CXPSClientStream.cpp,v
>
> retrieving revision 1.1.1.1.2.6
>
> diff -u -w -r1.1.1.1.2.6 CXPSClientStream.cpp
>
> --- CXPSClientStream.cpp 13 Aug 2009 18:42:23 -0000 1.1.1.1.2.6
>
> +++ CXPSClientStream.cpp 20 Jul 2010 10:25:37 -0000
>
> @@ -408,6 +408,9 @@
>
> {
>
> m_pXPSClient->StreamResetDone(m_uStreamId);
>
> }
>
> +
>
> + // Enables to handle such cases where the user seeks after the
> EOF had been set.
>
> + RegisterForEndStream();
>
> }
>
>
>
> //
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/5488be10/attachment.html
From sfu at real.com Thu Jul 22 08:31:55 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 22 15:07:31 2010
Subject: [datatype-dev] Re: URGENT: RESEND: [Nokia-private-dev] CR:
ou1cimx1#436751 - FL4.0
-XPS Streaming- After We Pause and Resume playback it fails to play at EOF.
In-Reply-To:
References:
Message-ID: <4C48727B.9070401@real.com>
This looks good to me.
fxd
ext-shashi.merapala@nokia.com wrote:
>
> Can someone please review this one ? This is urgent.
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Wednesday, July 21, 2010 6:50 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* RESEND: [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0
> -XPS Streaming- After We Pause and Resume playback it fails to play at
> EOF.
>
>
>
> Any feedback on this one ?
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Tuesday, July 20, 2010 4:39 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0 -XPS
> Streaming- After We Pause and Resume playback it fails to play at EOF.
>
>
>
> "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-shashi.merapala@nokia.com
>
>
>
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
>
>
>
> Date: 07/20/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Error Id: ou1cimx1#436751
>
>
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it
> fails to play at EOF.
>
>
>
> Overview: A CR of this error id had already been sent and reviewed. Kindly refer to the mail attachments. But, it had contained only a part fix.
> Hence, this mail shall take care of the other part of the fix after flash team has provided their part of fix.
>
> When the user seeks after the EOF had been set, and after Reset happens, application shall again send EOF to XPS Packet Sink. But, the CXPSClientStream has not registered for the second time EOF notification. Because of this, the EndStream call of CXPSFileFormat is not getting called and Helix tries to ReBuffer leading to the error.
>
>
> Solution: The change is to again register for the EOF notification in
> CXPSClientStream::Reset(). This enables to handle such cases where the
> user seeks after the EOF had been set.
>
>
>
> Diff below.
>
>
>
> Files added: None
>
>
>
> Files modified: \datatype\xps\fileformat\CXPSClientStream.cpp
>
>
> Image size and heap use impact: Negligible
>
>
>
> Module release testing (STIF): Done. Passed.
>
>
>
> Test case(s) added: No
>
>
>
> Memory leak check performed: NA
>
>
>
> Platforms and profiles build verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and profiles functionality verified: armv5, winscw
>
>
>
> Branch: 210CayS, HEAD, 420Brizo
>
>
>
> Index: CXPSClientStream.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/xps/fileformat/CXPSClientStream.cpp,v
>
> retrieving revision 1.1.1.1.2.6
>
> diff -u -w -r1.1.1.1.2.6 CXPSClientStream.cpp
>
> --- CXPSClientStream.cpp 13 Aug 2009 18:42:23 -0000 1.1.1.1.2.6
>
> +++ CXPSClientStream.cpp 20 Jul 2010 10:25:37 -0000
>
> @@ -408,6 +408,9 @@
>
> {
>
> m_pXPSClient->StreamResetDone(m_uStreamId);
>
> }
>
> +
>
> + // Enables to handle such cases where the user seeks after the
> EOF had been set.
>
> + RegisterForEndStream();
>
> }
>
>
>
> //
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
> Pause and Resume playback it fails to play at EOF
> From:
> "ext-sowmya.kanni@nokia.com"
> Date:
> Mon, 5 Jul 2010 23:15:43 -0700
> To:
> "datatype-dev@helixcommunity.org"
>
> To:
> "datatype-dev@helixcommunity.org"
> CC:
> "nokia-private-dev@helixcommunity.org"
>
>
>
> "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-sowmya.kanni@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> RC Id: ou1cimx1#436751
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>
> Fix: This issue needs two fixes.
> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>
> Files modified & changes:
> /datatype/xps/fileformat/CXPSFileformat.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> Test case(s) Added : No
>
> Memory leak check performed : NA
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, 420Brizo and HEAD
>
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming-
> After We Pause and Resume playback it fails to play at EOF
> From:
> "ext-sowmya.kanni@nokia.com"
> Date:
> Wed, 7 Jul 2010 01:43:52 -0700
> To:
> Qiang Luo
>
> To:
> Qiang Luo
> CC:
> "nokia-private-dev@helixcommunity.org"
> ,
> "datatype-dev@helixcommunity.org"
>
>
>
> Thanks Qiang,
>
> Checked into 210CayS, 420Brizo and HEAD.
>
> -----Original Message-----
> From: ext Qiang Luo [mailto:qluo@real.com]
> Sent: Tuesday, July 06, 2010 7:10 PM
> To: Kanni Sowmya (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Looks good.
>
> Qiang
>
> On 7/5/2010 11:15 PM, ext-sowmya.kanni@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-sowmya.kanni@nokia.com
>>
>> Reviewed by: rajesh.rathinasamy@nokia.com
>>
>> RC Id: ou1cimx1#436751
>>
>> Date: 07/06/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>>
>> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>>
>> Fix: This issue needs two fixes.
>> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
>> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>>
>> Files modified& changes:
>> /datatype/xps/fileformat/CXPSFileformat.cpp
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : Done
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : NA
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch: 210CayS, 420Brizo and HEAD
>>
>>
>
>
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>
>
From Yury.Ramanovich at nokia.com Thu Jul 22 13:38:23 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Jul 22 20:15:20 2010
Subject: [datatype-dev] RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
References:
<4C44E8A0.2050202@real.com>
Message-ID:
Also need to add STDCPP for XPSRtpFlSrcLib.lib to fix build break.
Index: XPSRtpFlSrcLib
===================================================================
RCS file: /cvsroot/datatype/xps/test/XPSRtpFlSrcLib,v
retrieving revision 1.2.14.1
diff -u -w -r1.2.14.1 XPSRtpFlSrcLib
--- XPSRtpFlSrcLib 26 Feb 2010 21:44:54 -0000 1.2.14.1
+++ XPSRtpFlSrcLib 22 Jul 2010 21:04:06 -0000
@@ -71,6 +71,7 @@
project.AddSources("CXPSRtpFlSrc.cpp")
project.AddSources("CXPSRTPPktFlReader.cpp")
+project.symbianUtil.SetStdCppSupport()
LibraryTarget('XPSRtpFlSrcLib')
BR
Yury
>-----Original Message-----
>From: Ramanovich Yury (Nokia-MS/Dallas)
>Sent: Tuesday, July 20, 2010 1:04 PM
>To: 'ext Jamie Gordon'
>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>
>Checked in to 420Brizo
>
>BR
>Yury
>>-----Original Message-----
>>From: ext Jamie Gordon [mailto:jgordon@real.com]
>>Sent: Monday, July 19, 2010 7:07 PM
>>To: Ramanovich Yury (Nokia-MS/Dallas)
>>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>Subject: Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>
>>ok
>>
>>On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
>>> Modified by: _yury.ramanovich@nokia.com_
>>
>>>
>>> Reviewed by:
>>>
>>> Date: 07/15/2010
>>>
>>> Project: symbian_client_apps
>>>
>>> ErrorId: ou1cimx1#474138
>>>
>>> Synopsis: XPSPacketSink.lib is not linked with QT app
>>>
>>> Overview: when XPSPacketSink.lib is linked with QT app (like
>>FlashLite)
>>> that has STDCPP keyword in its .mmp file, checklib tool gives error:
>>> "xpspacketsink.lib is incompatible with standard C++". The reason for
>>> this error is the standard C++ operators new and new [] used
>>throughout
>>> the xpspacketsink.lib code, but the library doesn't declare itself as
>>> supporting standard C++ new and new[] behavior.
>>>
>>> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which
>>effectively
>>> tags the lib as supporting standard C++ new and new[] operators
>during
>>> "mmp helix build". Also do the same for the winscw and armv5 "CVS
>>helix
>>> builds" via mwldsym2 and armar command line options and
>>> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be controlled
>>by
>>> build system SymbianUtils.stdcppsupport flag, which will be set in
>>> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
>>> 2) use new (nothrow) operator for non-CBase heap allocations in
>>> xpspacketsink.lib source since we don't handle bad_alloc exception.
>>>
>>> Files Added:
>>> None.
>>>
>>> Files Modified:
>>> /ribosome/build/umake/umake_symbianmmp.py
>>> /ribosome/build/umakecf/symbian-armv5.cf
>>> /ribosome/build/umakecf/symbian-emulator-winscw.cf
>>> /ribosome/build/umakecf/symbian.cf
>>> /datatype/xps/PacketSink/CXPSPacketSink.cpp
>>> /datatype/xps/PacketSink/CXPSPktQue.cpp
>>> /datatype/xps/PacketSink/CXPSSession.cpp
>>> /datatype/xps/PacketSink/CXPSSession.h
>>> /datatype/xps/PacketSink/CXPSStream.cpp
>>> /datatype/xps/PacketSink/XPSPacketSinkLib
>>>
>>>
>>> Image Size and Heap Use impact: minor
>>>
>>> Module Release testing : yes, XPSTestApp
>>>
>>> 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.
>>>
>>>
>>> BR
>>>
>>>
>>>
From Yury.Ramanovich at nokia.com Thu Jul 22 14:24:32 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Jul 22 21:01:36 2010
Subject: [datatype-dev] RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
References:
<4C44E8A0.2050202@real.com>
Message-ID:
If there are no objections, I'm just going to go ahead and check this in to fix the build break in a few mins
BR
Yury
>-----Original Message-----
>From: Ramanovich Yury (Nokia-MS/Dallas)
>Sent: Thursday, July 22, 2010 4:38 PM
>To: Ramanovich Yury (Nokia-MS/Dallas); 'ext Jamie Gordon'
>Cc: 'ribosome-dev@helixcommunity.org'; 'datatype-dev@helixcommunity.org'
>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>
>Also need to add STDCPP for XPSRtpFlSrcLib.lib to fix build break.
>
>Index: XPSRtpFlSrcLib
>===================================================================
>RCS file: /cvsroot/datatype/xps/test/XPSRtpFlSrcLib,v
>retrieving revision 1.2.14.1
>diff -u -w -r1.2.14.1 XPSRtpFlSrcLib
>--- XPSRtpFlSrcLib 26 Feb 2010 21:44:54 -0000 1.2.14.1
>+++ XPSRtpFlSrcLib 22 Jul 2010 21:04:06 -0000
>@@ -71,6 +71,7 @@
> project.AddSources("CXPSRtpFlSrc.cpp")
> project.AddSources("CXPSRTPPktFlReader.cpp")
>
>+project.symbianUtil.SetStdCppSupport()
>
> LibraryTarget('XPSRtpFlSrcLib')
>
>
>BR
>Yury
>
>>-----Original Message-----
>>From: Ramanovich Yury (Nokia-MS/Dallas)
>>Sent: Tuesday, July 20, 2010 1:04 PM
>>To: 'ext Jamie Gordon'
>>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>
>>Checked in to 420Brizo
>>
>>BR
>>Yury
>>>-----Original Message-----
>>>From: ext Jamie Gordon [mailto:jgordon@real.com]
>>>Sent: Monday, July 19, 2010 7:07 PM
>>>To: Ramanovich Yury (Nokia-MS/Dallas)
>>>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>>Subject: Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>>
>>>ok
>>>
>>>On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
>>>> Modified by: _yury.ramanovich@nokia.com_
>>>
>>>>
>>>> Reviewed by:
>>>>
>>>> Date: 07/15/2010
>>>>
>>>> Project: symbian_client_apps
>>>>
>>>> ErrorId: ou1cimx1#474138
>>>>
>>>> Synopsis: XPSPacketSink.lib is not linked with QT app
>>>>
>>>> Overview: when XPSPacketSink.lib is linked with QT app (like
>>>FlashLite)
>>>> that has STDCPP keyword in its .mmp file, checklib tool gives error:
>>>> "xpspacketsink.lib is incompatible with standard C++". The reason
>for
>>>> this error is the standard C++ operators new and new [] used
>>>throughout
>>>> the xpspacketsink.lib code, but the library doesn't declare itself
>as
>>>> supporting standard C++ new and new[] behavior.
>>>>
>>>> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which
>>>effectively
>>>> tags the lib as supporting standard C++ new and new[] operators
>>during
>>>> "mmp helix build". Also do the same for the winscw and armv5 "CVS
>>>helix
>>>> builds" via mwldsym2 and armar command line options and
>>>> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be
>controlled
>>>by
>>>> build system SymbianUtils.stdcppsupport flag, which will be set in
>>>> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
>>>> 2) use new (nothrow) operator for non-CBase heap allocations in
>>>> xpspacketsink.lib source since we don't handle bad_alloc exception.
>>>>
>>>> Files Added:
>>>> None.
>>>>
>>>> Files Modified:
>>>> /ribosome/build/umake/umake_symbianmmp.py
>>>> /ribosome/build/umakecf/symbian-armv5.cf
>>>> /ribosome/build/umakecf/symbian-emulator-winscw.cf
>>>> /ribosome/build/umakecf/symbian.cf
>>>> /datatype/xps/PacketSink/CXPSPacketSink.cpp
>>>> /datatype/xps/PacketSink/CXPSPktQue.cpp
>>>> /datatype/xps/PacketSink/CXPSSession.cpp
>>>> /datatype/xps/PacketSink/CXPSSession.h
>>>> /datatype/xps/PacketSink/CXPSStream.cpp
>>>> /datatype/xps/PacketSink/XPSPacketSinkLib
>>>>
>>>>
>>>> Image Size and Heap Use impact: minor
>>>>
>>>> Module Release testing : yes, XPSTestApp
>>>>
>>>> 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.
>>>>
>>>>
>>>> BR
>>>>
>>>>
>>>>
From Yury.Ramanovich at nokia.com Thu Jul 22 14:40:12 2010
From: Yury.Ramanovich at nokia.com (Yury.Ramanovich@nokia.com)
Date: Thu Jul 22 21:17:07 2010
Subject: [datatype-dev] RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
References:
<4C44E8A0.2050202@real.com>
Message-ID:
Checked in to 420Brizo
BR
Yury
>-----Original Message-----
>From: Ramanovich Yury (Nokia-MS/Dallas)
>Sent: Thursday, July 22, 2010 5:25 PM
>To: Ramanovich Yury (Nokia-MS/Dallas); 'ext Jamie Gordon'
>Cc: 'ribosome-dev@helixcommunity.org'; 'datatype-dev@helixcommunity.org'
>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>
>If there are no objections, I'm just going to go ahead and check this in
>to fix the build break in a few mins
>
>BR
>Yury
>
>>-----Original Message-----
>>From: Ramanovich Yury (Nokia-MS/Dallas)
>>Sent: Thursday, July 22, 2010 4:38 PM
>>To: Ramanovich Yury (Nokia-MS/Dallas); 'ext Jamie Gordon'
>>Cc: 'ribosome-dev@helixcommunity.org'; 'datatype-
>dev@helixcommunity.org'
>>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>
>>Also need to add STDCPP for XPSRtpFlSrcLib.lib to fix build break.
>>
>>Index: XPSRtpFlSrcLib
>>===================================================================
>>RCS file: /cvsroot/datatype/xps/test/XPSRtpFlSrcLib,v
>>retrieving revision 1.2.14.1
>>diff -u -w -r1.2.14.1 XPSRtpFlSrcLib
>>--- XPSRtpFlSrcLib 26 Feb 2010 21:44:54 -0000 1.2.14.1
>>+++ XPSRtpFlSrcLib 22 Jul 2010 21:04:06 -0000
>>@@ -71,6 +71,7 @@
>> project.AddSources("CXPSRtpFlSrc.cpp")
>> project.AddSources("CXPSRTPPktFlReader.cpp")
>>
>>+project.symbianUtil.SetStdCppSupport()
>>
>> LibraryTarget('XPSRtpFlSrcLib')
>>
>>
>>BR
>>Yury
>>
>>>-----Original Message-----
>>>From: Ramanovich Yury (Nokia-MS/Dallas)
>>>Sent: Tuesday, July 20, 2010 1:04 PM
>>>To: 'ext Jamie Gordon'
>>>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>>Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>>
>>>Checked in to 420Brizo
>>>
>>>BR
>>>Yury
>>>>-----Original Message-----
>>>>From: ext Jamie Gordon [mailto:jgordon@real.com]
>>>>Sent: Monday, July 19, 2010 7:07 PM
>>>>To: Ramanovich Yury (Nokia-MS/Dallas)
>>>>Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>>>Subject: Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>>>ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>>>
>>>>ok
>>>>
>>>>On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
>>>>> Modified by: _yury.ramanovich@nokia.com_
>>>>
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Date: 07/15/2010
>>>>>
>>>>> Project: symbian_client_apps
>>>>>
>>>>> ErrorId: ou1cimx1#474138
>>>>>
>>>>> Synopsis: XPSPacketSink.lib is not linked with QT app
>>>>>
>>>>> Overview: when XPSPacketSink.lib is linked with QT app (like
>>>>FlashLite)
>>>>> that has STDCPP keyword in its .mmp file, checklib tool gives
>error:
>>>>> "xpspacketsink.lib is incompatible with standard C++". The reason
>>for
>>>>> this error is the standard C++ operators new and new [] used
>>>>throughout
>>>>> the xpspacketsink.lib code, but the library doesn't declare itself
>>as
>>>>> supporting standard C++ new and new[] behavior.
>>>>>
>>>>> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which
>>>>effectively
>>>>> tags the lib as supporting standard C++ new and new[] operators
>>>during
>>>>> "mmp helix build". Also do the same for the winscw and armv5 "CVS
>>>>helix
>>>>> builds" via mwldsym2 and armar command line options and
>>>>> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be
>>controlled
>>>>by
>>>>> build system SymbianUtils.stdcppsupport flag, which will be set in
>>>>> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
>>>>> 2) use new (nothrow) operator for non-CBase heap allocations in
>>>>> xpspacketsink.lib source since we don't handle bad_alloc exception.
>>>>>
>>>>> Files Added:
>>>>> None.
>>>>>
>>>>> Files Modified:
>>>>> /ribosome/build/umake/umake_symbianmmp.py
>>>>> /ribosome/build/umakecf/symbian-armv5.cf
>>>>> /ribosome/build/umakecf/symbian-emulator-winscw.cf
>>>>> /ribosome/build/umakecf/symbian.cf
>>>>> /datatype/xps/PacketSink/CXPSPacketSink.cpp
>>>>> /datatype/xps/PacketSink/CXPSPktQue.cpp
>>>>> /datatype/xps/PacketSink/CXPSSession.cpp
>>>>> /datatype/xps/PacketSink/CXPSSession.h
>>>>> /datatype/xps/PacketSink/CXPSStream.cpp
>>>>> /datatype/xps/PacketSink/XPSPacketSinkLib
>>>>>
>>>>>
>>>>> Image Size and Heap Use impact: minor
>>>>>
>>>>> Module Release testing : yes, XPSTestApp
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> BR
>>>>>
>>>>>
>>>>>
From Joeli at real.com Thu Jul 22 22:20:32 2010
From: Joeli at real.com (Joe Li)
Date: Fri Jul 23 04:56:59 2010
Subject: [datatype-dev] CR: MKV Helix.4.2.0-Merge and memory leak issue for
Lephone2
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkv.folder.diff
Type: application/octet-stream
Size: 27055 bytes
Desc: mkv.folder.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/d9ee71a1/mkv.folder-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pckunpck.cpp.diff
Type: application/octet-stream
Size: 763 bytes
Desc: pckunpck.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/d9ee71a1/pckunpck.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pckunpck.h.diff
Type: application/octet-stream
Size: 819 bytes
Desc: pckunpck.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100722/d9ee71a1/pckunpck.h-0001.obj
From ext-shashi.merapala at nokia.com Thu Jul 22 23:17:28 2010
From: ext-shashi.merapala at nokia.com (ext-shashi.merapala@nokia.com)
Date: Fri Jul 23 05:55:03 2010
Subject: [datatype-dev] RE: URGENT: RESEND: [Nokia-private-dev] CN:
ou1cimx1#436751 - FL4.0
-XPS Streaming- After We Pause and Resume playback it fails to play at EOF.
In-Reply-To: <4C48727B.9070401@real.com>
References:
<4C48727B.9070401@real.com>
Message-ID:
Thanks fxd for the review. The changes are committed to 210CayS, HEAD, & 420Brizo.
Thanks & Warm Regards,
Shashi Kiran Merapala
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Thursday, July 22, 2010 10:02 PM
To: Merapala Shashi (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: URGENT: RESEND: [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF.
This looks good to me.
fxd
ext-shashi.merapala@nokia.com wrote:
>
> Can someone please review this one ? This is urgent.
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Wednesday, July 21, 2010 6:50 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* RESEND: [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0
> -XPS Streaming- After We Pause and Resume playback it fails to play at
> EOF.
>
>
>
> Any feedback on this one ?
>
>
>
> Thanks & Warm Regards,
>
> Shashi Kiran Merapala
>
>
>
> *From:* nokia-private-dev-bounces@helixcommunity.org
> [mailto:nokia-private-dev-bounces@helixcommunity.org] *On Behalf Of
> *Merapala Shashi (EXT-Sasken/Bangalore)
> *Sent:* Tuesday, July 20, 2010 4:39 PM
> *To:* datatype-dev@helixcommunity.org
> *Cc:* nokia-private-dev@helixcommunity.org
> *Subject:* [Nokia-private-dev] CR: ou1cimx1#436751 - FL4.0 -XPS
> Streaming- After We Pause and Resume playback it fails to play at EOF.
>
>
>
> "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-shashi.merapala@nokia.com
>
>
>
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
>
>
>
> Date: 07/20/2010
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Error Id: ou1cimx1#436751
>
>
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it
> fails to play at EOF.
>
>
>
> Overview: A CR of this error id had already been sent and reviewed. Kindly refer to the mail attachments. But, it had contained only a part fix.
> Hence, this mail shall take care of the other part of the fix after flash team has provided their part of fix.
>
> When the user seeks after the EOF had been set, and after Reset happens, application shall again send EOF to XPS Packet Sink. But, the CXPSClientStream has not registered for the second time EOF notification. Because of this, the EndStream call of CXPSFileFormat is not getting called and Helix tries to ReBuffer leading to the error.
>
>
> Solution: The change is to again register for the EOF notification in
> CXPSClientStream::Reset(). This enables to handle such cases where the
> user seeks after the EOF had been set.
>
>
>
> Diff below.
>
>
>
> Files added: None
>
>
>
> Files modified: \datatype\xps\fileformat\CXPSClientStream.cpp
>
>
> Image size and heap use impact: Negligible
>
>
>
> Module release testing (STIF): Done. Passed.
>
>
>
> Test case(s) added: No
>
>
>
> Memory leak check performed: NA
>
>
>
> Platforms and profiles build verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and profiles functionality verified: armv5, winscw
>
>
>
> Branch: 210CayS, HEAD, 420Brizo
>
>
>
> Index: CXPSClientStream.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/xps/fileformat/CXPSClientStream.cpp,v
>
> retrieving revision 1.1.1.1.2.6
>
> diff -u -w -r1.1.1.1.2.6 CXPSClientStream.cpp
>
> --- CXPSClientStream.cpp 13 Aug 2009 18:42:23 -0000 1.1.1.1.2.6
>
> +++ CXPSClientStream.cpp 20 Jul 2010 10:25:37 -0000
>
> @@ -408,6 +408,9 @@
>
> {
>
> m_pXPSClient->StreamResetDone(m_uStreamId);
>
> }
>
> +
>
> + // Enables to handle such cases where the user seeks after the
> EOF had been set.
>
> + RegisterForEndStream();
>
> }
>
>
>
> //
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [datatype-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We
> Pause and Resume playback it fails to play at EOF
> From:
> "ext-sowmya.kanni@nokia.com"
> Date:
> Mon, 5 Jul 2010 23:15:43 -0700
> To:
> "datatype-dev@helixcommunity.org"
>
> To:
> "datatype-dev@helixcommunity.org"
> CC:
> "nokia-private-dev@helixcommunity.org"
>
>
>
> "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-sowmya.kanni@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
>
> RC Id: ou1cimx1#436751
>
> Date: 07/06/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>
> Fix: This issue needs two fixes.
> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>
> Files modified & changes:
> /datatype/xps/fileformat/CXPSFileformat.cpp
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done
>
> Test case(s) Added : No
>
> Memory leak check performed : NA
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 210CayS, 420Brizo and HEAD
>
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming-
> After We Pause and Resume playback it fails to play at EOF
> From:
> "ext-sowmya.kanni@nokia.com"
> Date:
> Wed, 7 Jul 2010 01:43:52 -0700
> To:
> Qiang Luo
>
> To:
> Qiang Luo
> CC:
> "nokia-private-dev@helixcommunity.org"
> ,
> "datatype-dev@helixcommunity.org"
>
>
>
> Thanks Qiang,
>
> Checked into 210CayS, 420Brizo and HEAD.
>
> -----Original Message-----
> From: ext Qiang Luo [mailto:qluo@real.com]
> Sent: Tuesday, July 06, 2010 7:10 PM
> To: Kanni Sowmya (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR: :ou1cimx1436751:FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>
> Looks good.
>
> Qiang
>
> On 7/5/2010 11:15 PM, ext-sowmya.kanni@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-sowmya.kanni@nokia.com
>>
>> Reviewed by: rajesh.rathinasamy@nokia.com
>>
>> RC Id: ou1cimx1#436751
>>
>> Date: 07/06/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: FL4.0 -XPS Streaming- After We Pause and Resume playback it fails to play at EOF
>>
>> Overview: XPS streams the packets well in advance. So, EndStream call will be sent from app to Helix before pause. Helix assumes that it has received all the packets and stream ended. So When resumed, XPS sends all the packets to Helix from the point it was resumed, but Helix fails in sending them to the renderer.
>>
>> Fix: This issue needs two fixes.
>> 1. One from helix side which requires StreamEnd variable to be reset when the player is seeked back. This allows Helix to handle the rest of the packets sent from seek position.
>> 2. The other fix is from the Flash App side which needs to send the EndStream call for the second time while resumed and played till EOF.
>>
>> Files modified& changes:
>> /datatype/xps/fileformat/CXPSFileformat.cpp
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : Done
>>
>> Test case(s) Added : No
>>
>> Memory leak check performed : NA
>>
>> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch: 210CayS, 420Brizo and HEAD
>>
>>
>
>
> _______________________________________________
> 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 Jul 23 02:44:44 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Fri Jul 23 09:21:51 2010
Subject: [datatype-dev] CR : ou1cimx1#482778 : Metadata is not returned
properly for certain video formats
In-Reply-To:
References:
<888A0A0FAF11234F9E0D17809A78D7E41DC1C5398C@NOK-EUMSG-03.mgdnok.nokia.com>
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
Reviewed by: yury.ramanovich@nokia.com
girish.shetty@nokia.com
RC Id : ou1cimx1#482778
Date: 07/22/2010
Project: SymbianMmf_wm
Synopsis: Metadata is not returned properly for certain video formats
Overview: Application looks for property "FramesPerMSecond" in stream header to extract frame rate for video clip. For AVI, MKV and Real media file format this property was not set. Application also needs to identify key frame based on ASM rules. For AVI FF this was not set.
Fix:? 1. Property "FramesPerMSecond" is set for AVI, MKV and RM FF.
2. Added ASM rules for AVI FF. The last input to IHXPacket::Set() is "0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk)" , as second statement won't get evaluated so removing it.
Files modified & changes:
/cvsroot/datatype/avi/fileformat/avistrm.cpp
/cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp
/cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp
/cvsroot/rarvcode-formprot/fileformat/rmffplin.h
?????
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done. Also tested for metadata and thumbnails.
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, 420Bizo and HEAD
Diff attached.
Changes for RM FF On Brizo and head is slightly different from Cays210. Attaching the diff for these branches as diff_rmff_Brizo420.txt.
-------------- next part --------------
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.9.6.15
diff -u -w -r1.9.6.15 avistrm.cpp
--- avistrm.cpp 22 Jun 2010 05:04:11 -0000 1.9.6.15
+++ avistrm.cpp 22 Jul 2010 11:28:20 -0000
@@ -76,6 +76,7 @@
static const char HX_THIS_FILE[] = __FILE__;
#endif
+#define ONE_MILLION 1000000
// Operational defines:
#define DEFAULT_NON_LOCAL_PACKET_SIZE 1500
@@ -895,6 +896,10 @@
pHeader->SetPropertyULONG32("SamplesPerSecond", (UINT32) m_fSamplesPerSecond);
+ // Set frames per million second from fps.
+ INT64 lFramesPerMSec = ONE_MILLION*m_fSamplesPerSecond;
+ pHeader->SetPropertyULONG32("FramesPerMSecond",INT64_TO_ULONG32(lFramesPerMSec));
+
break;
}
case AVI_AUDS_TYPE:
@@ -1596,7 +1601,8 @@
ulTime = (UINT32) ((m_ulMinReadChunk / m_fChunksPerSecond) * 1000);
}
- // TODO: Set correct ASM rules
+
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -1608,14 +1614,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].bKeyChunk);
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
#ifdef USE_SIMPLE_SEGMENT_PAYLOAD
@@ -1717,7 +1723,7 @@
HXLOGL4(HXLOG_AVIX,"CAVIStream[%p]::GetNextPacket()\tstream %d\tpacket time: %lu\t minreadchunk: %lu\n", this, m_usStream, ulTime, m_ulMinReadChunk);
- // TODO: Set correct ASM rules
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -1729,14 +1735,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].bKeyChunk);
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
@@ -2311,7 +2317,7 @@
ulTime = (UINT32) ((m_ulMaxReadChunk / m_fChunksPerSecond) * 1000);
}
- // TODO: Set correct ASM rules
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -2323,14 +2329,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
#ifdef USE_SIMPLE_SEGMENT_PAYLOAD
-------------- next part --------------
? Makefile
? Umakefil.upp
? armv5-rel32
? diff_mkvff.txt
? mkvff_dll_stub.c
? mkvff_ordinal.dat
? mkvffdll.mak
? mkvffdll.upp
? mkvff{000a0000}.def
Index: mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.8
diff -u -w -r1.1.1.1.2.8 mkv_file_format.cpp
--- mkv_file_format.cpp 10 Jul 2010 05:50:35 -0000 1.1.1.1.2.8
+++ mkv_file_format.cpp 22 Jul 2010 11:30:44 -0000
@@ -82,6 +82,9 @@
#define DEFAULT_RTP_SAMPLES 90000
+#define ONE_THOUSAND 1000
+#define ONE_MILLION 1000000
+
#define CONVERT_TO_MILI_SECOND 1000000 // MKV file format duration are in nanoseconds.
#define MKV_ABSVAL(val) (((val) < 0) ? (-(val)) : (val))
#define MKV_BFRAME_MAXIMUMDEPTH 16
@@ -814,7 +817,19 @@
if(trk->video.uFPS > 0.0)
{
pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS / 1000);
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): video.uFPS %d",
+ trk->video.uFPS / 1000);
+ }
+ else if(trk->uDefaultDuration)
+ {
+ // uDefaultDuration is in nanoseconds
+ INT64 lFramesPerMSec = (INT64)ONE_MILLION*ONE_THOUSAND*CONVERT_TO_MILI_SECOND/
+ (trk->uDefaultDuration);
+ pHdr->SetPropertyULONG32("FramesPerMSecond", INT64_TO_ULONG32(lFramesPerMSec ));
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): framesPerMSec %d",
+ INT64_TO_ULONG32(lFramesPerMSec ));
}
+
}
return HXR_OK;
-------------- next part --------------
? Makefile
? Umakefil.upp
? armv5-rel32
? diff.txt
? diff_rmffplin.txt
Index: rmffplin.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp,v
retrieving revision 1.49.6.4
diff -u -w -r1.49.6.4 rmffplin.cpp
--- rmffplin.cpp 22 Jun 2007 15:10:16 -0000 1.49.6.4
+++ rmffplin.cpp 22 Jul 2010 11:27:03 -0000
@@ -149,6 +149,7 @@
#define RMFF_AU_STRING "FileFormat/RealMedia"
#define MAX_UINT32_STRING_SIZE 10
+#define ONE_MILLION 1000
const float CRealMediaFileFormat::INTERFRAME_DROP_POINT = 0.8f;
@@ -231,6 +232,7 @@
#endif /* end #if defined(HELIX_FEATURE_PROGRESSIVE_DOWNLD_STATUS). */
, m_bKeyFrameMode(FALSE)
, m_lPlaybackVelocity(HX_PLAYBACK_VELOCITY_NORMAL)
+ , m_ulFramesPerMSecond(0)
{
};
@@ -1262,6 +1264,20 @@
m_StreamHeaders.RemoveAll();
}
+ // Check if mime type is video set FramesperMsecond if it is greater than zero.
+ IHXBuffer* pBuffer = NULL;
+ const char* pMimeType = NULL;
+ pHeader->GetPropertyCString("MimeType", pBuffer);
+ if(pBuffer)
+ {
+ pMimeType = (const char*) pBuffer->GetBuffer();
+ if( pMimeType && (::strncasecmp( pMimeType, "video/", 6) == 0) && m_ulFramesPerMSecond > 0)
+ {
+ pHeader->SetPropertyULONG32("FramesPerMSecond", m_ulFramesPerMSecond);
+ }
+ HX_RELEASE(pBuffer);
+ }
+
// Send the header with whatever status we have
m_pFFResponse->StreamHeaderReady(pnr, pHeader);
@@ -4411,6 +4427,8 @@
char szFPS[128]; /* Flawfinder: ignore */
sprintf(szFPS, "%.1f", fps); /* Flawfinder: ignore */
+ // save frames rate information
+ m_ulFramesPerMSecond = fps*ONE_MILLION;
// add this codec to the AllCodecs list (if its not already in there)
if (strstr(pAllFrameRates, szFPS) == 0)
{
Index: rmffplin.h
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/rmffplin.h,v
retrieving revision 1.18
diff -u -w -r1.18 rmffplin.h
--- rmffplin.h 27 Apr 2005 19:12:18 -0000 1.18
+++ rmffplin.h 22 Jul 2010 11:27:04 -0000
@@ -247,6 +247,7 @@
HXBOOL m_bFoundBufferFile;
HXBOOL m_bKeyFrameMode;
INT32 m_lPlaybackVelocity;
+ UINT32 m_ulFramesPerMSecond;
static const char* const zm_pDescription;
static const char* const zm_pCopyright;
-------------- next part --------------
Index: rmffplin.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp,v
retrieving revision 1.65
diff -u -w -r1.65 rmffplin.cpp
--- rmffplin.cpp 23 Jun 2009 22:11:20 -0000 1.65
+++ rmffplin.cpp 23 Jul 2010 10:42:18 -0000
@@ -4449,6 +4449,8 @@
// Set the src frames per million seconds
pHeader->SetPropertyULONG32("SrcFramesPerMSecond", ulFramesPerMSecond);
}
+ // Set FramesPerMSecond
+ pHeader->SetPropertyULONG32("FramesPerMSecond", (UINT32) (fFramesPerSec * 1000000.0));
}
}
From sfu at real.com Fri Jul 23 05:51:52 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Jul 23 12:27:40 2010
Subject: [datatype-dev] CR: MKV Helix.4.2.0-Merge and memory leak issue
for Lephone2
In-Reply-To:
References:
Message-ID: <4C499E78.70909@real.com>
Looks ok.
Can you produce a diff of mkv modules against 420 and Head to see what
is still different? If there are fixes beyond what is in 420 already, we
(or Nokia) may want to consider roll the fixes into 420 too.
If there are new code/fix not in the Head, you will want to merge to
Head. In general, any fix/change on the branch should go to Head also.
fxd
Joe Li wrote:
>
> Update the source code.
>
> -----------------------------------------------------------------------=
-
>
> *=B7=A2=BC=FE=C8=CB:* Joe Li
> *=B7=A2=CB=CD=CA=B1=BC=E4:* 2010=C4=EA7=D4=C222=C8=D5=D0=C7=C6=DA=CB=C4=
19:25
> *=CA=D5=BC=FE=C8=CB:* 'android-port-dev@helixcommunity.org';
> 'datatype-dev@helixcommunity.org'
> *=D6=F7=CC=E2:* CR: MKV Helix.4.2.0-Merge and memory leak issue for Lep=
hone2
>
> by: joeli@real.com
>
> Date: 07/22/2010
>
> Project: RealPlayer for Android Smartphones
>
> Synopsis: MKV Helix.4.2.0-Merge and memory leak issue for Lephone2
>
> Overview:
>
> This CR is the complement of [CR: MKV fileformat support for Lephone2].
>
> Its modification included the follow items:
>
> 1. hxclient_4_2_0_brizo =A1=AEs Merge;
>
> 2. memory leak issue;
>
> 3. dll unload issue;
>
> 4. seek with Mosaic issue
>
> Files Added:
>
> None
>
> Files Modified:
>
> common/util/pub/pckunpck.h
>
> common/util/pckunpck.cpp
>
> datatype/mkv/fileformat/pub/mkv_file_format.h
>
> datatype/mkv/fileformat/mkv_file_format.cpp
>
> datatype/mkv/libmatroska/Matroska.h
>
> datatype/mkv/libmatroska/Matroska.cpp
>
> datatype/mkv/libmatroska/MatroskaExports.cpp
>
> datatype/mkv/libmatroska/MatroskaExports.h
>
> datatype/mkv/libmatroska/libebml/src/EbmlBinary.cpp
>
> datatype/mkv/libmatroska/libmatroska/src/KaxBlock.cpp
>
> Image Size and Heap Use impact (Client -Only):
>
> None
>
> Platforms and Profiles Affected:
>
> Platform: 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: Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> Platforms and Profiles Functionality verified:
>
> Platform: Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
> Branch for: 361atlas
>
> Thanks
>
> Joe
>
From Joeli at real.com Fri Jul 23 06:26:45 2010
From: Joeli at real.com (Joe Li)
Date: Fri Jul 23 13:03:32 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IE1LViBIZWxpeC40LjIuMC1NZXJn?=
=?gb2312?B?ZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9yCUxlcGhvbmUy?=
In-Reply-To: <4C499E78.70909@real.com>
Message-ID:
SSBjaGVja2VkIHRoZSA0MjAgYW5kIDQyMC5yZXN0cmljdCBiZWZvcmUuDQpUaGVyZSBmb2xsb3cg
aXNzdWVzIGFyZSBuZXcgY29kZXMuIEkgdGhpbmsgaXQgbmVlZCB0byBtZXJnZSBpbnRvIDQyMCBh
bmQgSGVhZC4NCj4+IDIuIG1lbW9yeSBsZWFrIGlzc3VlOw0KPj4gMy4gZGxsIHVubG9hZCBpc3N1
ZTsNCj4+IDQuIHNlZWsgd2l0aCBNb3NhaWMgaXNzdWUNCg0KVGhhbmtzIGFsbA0KSm9lDQoNCi0t
LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBTaGVsZG9uIEZ1IA0Kt6LLzcqxvOQ6IDIwMTDE6jfU
wjIzyNXQx8bazuUgMjE6NTINCsrVvP7IyzogSm9lIExpDQqzrcvNOiBhbmRyb2lkLXBvcnQtZGV2
QGhlbGl4Y29tbXVuaXR5Lm9yZzsgZGF0YXR5cGUtZGV2QGhlbGl4Y29tbXVuaXR5Lm9yZw0K1vfM
4jogUmU6IFtkYXRhdHlwZS1kZXZdIENSOiBNS1YgSGVsaXguNC4yLjAtTWVyZ2UgYW5kIG1lbW9y
eSBsZWFrIGlzc3VlIGZvciBMZXBob25lMg0KDQpMb29rcyBvay4NCg0KQ2FuIHlvdSBwcm9kdWNl
IGEgZGlmZiBvZiBta3YgbW9kdWxlcyBhZ2FpbnN0IDQyMCBhbmQgSGVhZCB0byBzZWUgd2hhdA0K
aXMgc3RpbGwgZGlmZmVyZW50PyBJZiB0aGVyZSBhcmUgZml4ZXMgYmV5b25kIHdoYXQgaXMgaW4g
NDIwIGFscmVhZHksIHdlDQoob3IgTm9raWEpIG1heSB3YW50IHRvIGNvbnNpZGVyIHJvbGwgdGhl
IGZpeGVzIGludG8gNDIwIHRvby4NCg0KSWYgdGhlcmUgYXJlIG5ldyBjb2RlL2ZpeCBub3QgaW4g
dGhlIEhlYWQsIHlvdSB3aWxsIHdhbnQgdG8gbWVyZ2UgdG8NCkhlYWQuIEluIGdlbmVyYWwsIGFu
eSBmaXgvY2hhbmdlIG9uIHRoZSBicmFuY2ggc2hvdWxkIGdvIHRvIEhlYWQgYWxzby4NCg0KZnhk
DQoNCkpvZSBMaSB3cm90ZToNCj4NCj4gVXBkYXRlIHRoZSBzb3VyY2UgY29kZS4NCj4NCj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+DQo+ICq3orz+yMs6KiBKb2UgTGkNCj4gKreiy83KsbzkOiogMjAxMMTq
N9TCMjLI1dDHxtrLxCAxOToyNQ0KPiAqytW8/sjLOiogJ2FuZHJvaWQtcG9ydC1kZXZAaGVsaXhj
b21tdW5pdHkub3JnJzsNCj4gJ2RhdGF0eXBlLWRldkBoZWxpeGNvbW11bml0eS5vcmcnDQo+ICrW
98ziOiogQ1I6IE1LViBIZWxpeC40LjIuMC1NZXJnZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9y
IExlcGhvbmUyDQo+DQo+IGJ5OiBqb2VsaUByZWFsLmNvbQ0KPg0KPiBEYXRlOiAwNy8yMi8yMDEw
DQo+DQo+IFByb2plY3Q6IFJlYWxQbGF5ZXIgZm9yIEFuZHJvaWQgU21hcnRwaG9uZXMNCj4NCj4g
U3lub3BzaXM6IE1LViBIZWxpeC40LjIuMC1NZXJnZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9y
IExlcGhvbmUyDQo+DQo+IE92ZXJ2aWV3Og0KPg0KPiBUaGlzIENSIGlzIHRoZSBjb21wbGVtZW50
IG9mIFtDUjogTUtWIGZpbGVmb3JtYXQgc3VwcG9ydCBmb3IgTGVwaG9uZTJdLg0KPg0KPiBJdHMg
bW9kaWZpY2F0aW9uIGluY2x1ZGVkIHRoZSBmb2xsb3cgaXRlbXM6DQo+DQo+IDEuIGh4Y2xpZW50
XzRfMl8wX2JyaXpvIKGucyBNZXJnZTsNCj4NCj4gMi4gbWVtb3J5IGxlYWsgaXNzdWU7DQo+DQo+
IDMuIGRsbCB1bmxvYWQgaXNzdWU7DQo+DQo+IDQuIHNlZWsgd2l0aCBNb3NhaWMgaXNzdWUNCj4N
Cj4gRmlsZXMgQWRkZWQ6DQo+DQo+IE5vbmUNCj4NCj4gRmlsZXMgTW9kaWZpZWQ6DQo+DQo+IGNv
bW1vbi91dGlsL3B1Yi9wY2t1bnBjay5oDQo+DQo+IGNvbW1vbi91dGlsL3Bja3VucGNrLmNwcA0K
Pg0KPiBkYXRhdHlwZS9ta3YvZmlsZWZvcm1hdC9wdWIvbWt2X2ZpbGVfZm9ybWF0LmgNCj4NCj4g
ZGF0YXR5cGUvbWt2L2ZpbGVmb3JtYXQvbWt2X2ZpbGVfZm9ybWF0LmNwcA0KPg0KPiBkYXRhdHlw
ZS9ta3YvbGlibWF0cm9za2EvTWF0cm9za2EuaA0KPg0KPiBkYXRhdHlwZS9ta3YvbGlibWF0cm9z
a2EvTWF0cm9za2EuY3BwDQo+DQo+IGRhdGF0eXBlL21rdi9saWJtYXRyb3NrYS9NYXRyb3NrYUV4
cG9ydHMuY3BwDQo+DQo+IGRhdGF0eXBlL21rdi9saWJtYXRyb3NrYS9NYXRyb3NrYUV4cG9ydHMu
aA0KPg0KPiBkYXRhdHlwZS9ta3YvbGlibWF0cm9za2EvbGliZWJtbC9zcmMvRWJtbEJpbmFyeS5j
cHANCj4NCj4gZGF0YXR5cGUvbWt2L2xpYm1hdHJvc2thL2xpYm1hdHJvc2thL3NyYy9LYXhCbG9j
ay5jcHANCj4NCj4gSW1hZ2UgU2l6ZSBhbmQgSGVhcCBVc2UgaW1wYWN0IChDbGllbnQgLU9ubHkp
Og0KPg0KPiBOb25lDQo+DQo+IFBsYXRmb3JtcyBhbmQgUHJvZmlsZXMgQWZmZWN0ZWQ6DQo+DQo+
IFBsYXRmb3JtOiBQbGF0Zm9ybTogYW5kcm9pZC1kb251dDMyMzAtYXJtLXFzZF84eDUwDQo+DQo+
IFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRyb2lkLWZ1bGwNCj4NCj4gRGlzdHJpYnV0aW9uIExp
YnJhcmllcyBBZmZlY3RlZDoNCj4NCj4gTm9uZQ0KPg0KPiBEaXN0cmlidXRpb24gbGlicmFyeSBp
bXBhY3QgYW5kIHBsYW5uZWQgYWN0aW9uOg0KPg0KPiBOb25lDQo+DQo+IFBsYXRmb3JtcyBhbmQg
UHJvZmlsZXMgQnVpbGQgVmVyaWZpZWQ6DQo+DQo+IFBsYXRmb3JtOiBQbGF0Zm9ybTogYW5kcm9p
ZC1kb251dDMyMzAtYXJtLXFzZF84eDUwDQo+DQo+IFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRy
b2lkLWZ1bGwNCj4NCj4gUGxhdGZvcm1zIGFuZCBQcm9maWxlcyBGdW5jdGlvbmFsaXR5IHZlcmlm
aWVkOg0KPg0KPiBQbGF0Zm9ybTogUGxhdGZvcm06IGFuZHJvaWQtZG9udXQzMjMwLWFybS1xc2Rf
OHg1MA0KPg0KPiBQcm9maWxlOiBoZWxpeC1jbGllbnQtYW5kcm9pZC1mdWxsDQo+DQo+IEJyYW5j
aCBmb3I6IDM2MWF0bGFzDQo+DQo+IFRoYW5rcw0KPg0KPiBKb2UNCj4NCg0K
From sfu at real.com Fri Jul 23 06:38:36 2010
From: sfu at real.com (Sheldon Fu)
Date: Fri Jul 23 13:14:21 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR : ou1cimx1#482778 :
Metadata is not returned properly for certain video formats
In-Reply-To:
References: <888A0A0FAF11234F9E0D17809A78D7E41DC1C5398C@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4C49A96C.1070705@real.com>
if(trk->video.uFPS > 0.0)
{
pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS / 1000);
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): video.uFPS %d",
+ trk->video.uFPS / 1000);
+ }
This doesn't seem to be correct. uFPS is uint32 so it shouldn't be
compared to 0.0 and if 'trk->video.uFPS / 1000' is the correct way to
convert to frames per million second then uFPS will be 'frames per
billion second' and that will overflow uint32 with a framerate of just 5
fps. Should here be "video.uFPS * 1000000"?
Also in rm change, the following is a confusing macro define mathematically:
+#define ONE_MILLION 1000
And in SureStream RM, there could be multiple video streams with
different framerates. I believe the following change will use the frame
rate of the LAST stream. This is probably not the stream to be picked by
default for local playback.
@@ -4411,6 +4427,8 @@
char szFPS[128]; /* Flawfinder: ignore */
sprintf(szFPS, "%.1f", fps); /* Flawfinder: ignore */
+ // save frames rate information
+ m_ulFramesPerMSecond = fps*ONE_MILLION;
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
>
> Reviewed by: yury.ramanovich@nokia.com
> girish.shetty@nokia.com
>
> RC Id : ou1cimx1#482778
>
> Date: 07/22/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Metadata is not returned properly for certain video formats
>
> Overview: Application looks for property "FramesPerMSecond" in stream header to extract frame rate for video clip. For AVI, MKV and Real media file format this property was not set. Application also needs to identify key frame based on ASM rules. For AVI FF this was not set.
>
> Fix: 1. Property "FramesPerMSecond" is set for AVI, MKV and RM FF.
> 2. Added ASM rules for AVI FF. The last input to IHXPacket::Set() is "0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk)" , as second statement won't get evaluated so removing it.
>
> Files modified & changes:
> /cvsroot/datatype/avi/fileformat/avistrm.cpp
> /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp
> /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp
> /cvsroot/rarvcode-formprot/fileformat/rmffplin.h
>
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done. Also tested for metadata and thumbnails.
>
> 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, 420Bizo and HEAD
>
> Diff attached.
> Changes for RM FF On Brizo and head is slightly different from Cays210. Attaching the diff for these branches as diff_rmff_Brizo420.txt.
>
>
From ext-g.manikanda at nokia.com Fri Jul 23 07:37:29 2010
From: ext-g.manikanda at nokia.com (ext-g.manikanda@nokia.com)
Date: Fri Jul 23 14:13:55 2010
Subject: [datatype-dev] CR: ou1cimx1#477224 Fusion: Crashes occur when
trying to resume the playback in multiple instances of video player
Message-ID: <20D73E2631F7914F868646E119DEC1CE284F46FBAA@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.10
diff -u -w -r1.1.1.1.2.10 Matroska.cpp
--- Matroska.cpp 16 Jul 2010 16:38:28 -0000 1.1.1.1.2.10
+++ Matroska.cpp 23 Jul 2010 11:55:04 -0000
@@ -30,12 +30,14 @@
#include "ihxpckts.h"
#include "hxtlogutil.h"
+#include "hxcom.h"
#include "Matroska.h"
using namespace LIBEBML_NAMESPACE;
using namespace LIBMATROSKA_NAMESPACE;
using namespace std;
+UINT32 MatroskaSegment::EbmlGlobal_Context_Ref=0;
#define TIMECODESCALE 1000000
@@ -1179,6 +1181,10 @@
MatroskaSegment* MatroskaSegment::Init(IOCallback& io)
{
+ //Allocating memory for Global pointers , assumed following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ if (CanAllocateGlobalContext())
+ {
InitGlobalContext();
EbmlCrc32::InitCallback();
EbmlDummy::InitCallback();
@@ -1206,7 +1212,7 @@
KaxTrackTranslate::InitCallback();
KaxTracks::InitCallback();
KaxTrackVideo::InitCallback();
-
+ }
EbmlStream *es = new EbmlStream(io);
if(es)
{
@@ -1222,6 +1228,10 @@
void MatroskaSegment::Release()
{
+ //Releasing memory for global pointers, assumed Following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ if(CanReleaseGlobalContext())
+ {
DeleteGlobalContext();
EbmlCrc32::DeleteCallback();
EbmlDummy::DeleteCallback();
@@ -1250,8 +1260,24 @@
KaxTracks::DeleteCallback();
KaxTrackVideo::DeleteCallback();
}
+}
+HXBOOL MatroskaSegment::CanAllocateGlobalContext()
+{
+ HXBOOL uCanAllocate =EbmlGlobal_Context_Ref?FALSE:TRUE;
+ InterlockedIncrement(&EbmlGlobal_Context_Ref);
+ return uCanAllocate;
+}
+HXBOOL MatroskaSegment::CanReleaseGlobalContext()
+{
+ HXBOOL uCanRelease = TRUE;
+ if ( InterlockedDecrement(&EbmlGlobal_Context_Ref) > 0 )
+ {
+ uCanRelease = FALSE;
+ }
+ return uCanRelease;
+}
HX_RESULT MatroskaSegment::VerifyHeader()
{
HXBOOL retVal = HXR_OK;
-------------- next part --------------
Index: 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
--- Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ Matroska.h 23 Jul 2010 15:17:55 -0000
@@ -44,7 +44,6 @@
UINT64 m_uDuration;
UINT64 m_uStartPos;
char *m_pSegTitle;
-
char *m_pTagTitle;
char *m_pTagAuthor;
char *m_pTagCopyright;
@@ -83,5 +82,9 @@
HX_RESULT ParseStreams( KaxTracks *tracks);
HX_RESULT ParseCues( KaxCues *pCues, EbmlElement* & pElementLevel2, int& level );
HX_RESULT ParseTags( KaxTags *tags);
+ private:
+ static UINT32 EbmlGlobal_Context_Ref;
+ static HXBOOL CanAllocateGlobalContext();
+ static HXBOOL CanReleaseGlobalContext();
};
#endif
From jgordon at real.com Fri Jul 23 09:34:45 2010
From: jgordon at real.com (Jamie Gordon)
Date: Fri Jul 23 16:11:24 2010
Subject: [datatype-dev] Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
In-Reply-To:
References:
<4C44E8A0.2050202@real.com>
Message-ID: <4C49D2B5.6000307@real.com>
ok
On 7/22/2010 2:38 PM, Yury.Ramanovich@nokia.com wrote:
> Also need to add STDCPP for XPSRtpFlSrcLib.lib to fix build break.
>
> Index: XPSRtpFlSrcLib
> ===================================================================
> RCS file: /cvsroot/datatype/xps/test/XPSRtpFlSrcLib,v
> retrieving revision 1.2.14.1
> diff -u -w -r1.2.14.1 XPSRtpFlSrcLib
> --- XPSRtpFlSrcLib 26 Feb 2010 21:44:54 -0000 1.2.14.1
> +++ XPSRtpFlSrcLib 22 Jul 2010 21:04:06 -0000
> @@ -71,6 +71,7 @@
> project.AddSources("CXPSRtpFlSrc.cpp")
> project.AddSources("CXPSRTPPktFlReader.cpp")
>
> +project.symbianUtil.SetStdCppSupport()
>
> LibraryTarget('XPSRtpFlSrcLib')
>
>
> BR
> Yury
>
>> -----Original Message-----
>> From: Ramanovich Yury (Nokia-MS/Dallas)
>> Sent: Tuesday, July 20, 2010 1:04 PM
>> To: 'ext Jamie Gordon'
>> Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>> Subject: RE: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>> ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>
>> Checked in to 420Brizo
>>
>> BR
>> Yury
>>> -----Original Message-----
>>> From: ext Jamie Gordon [mailto:jgordon@real.com]
>>> Sent: Monday, July 19, 2010 7:07 PM
>>> To: Ramanovich Yury (Nokia-MS/Dallas)
>>> Cc: ribosome-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>>> Subject: Re: [Ribosome-dev] CR needed: Symbian - 420 Brizo -
>>> ou1cimx1#474138 - XPSPacketSink.lib is not linked with QT app
>>>
>>> ok
>>>
>>> On 7/19/2010 1:03 PM, Yury.Ramanovich@nokia.com wrote:
>>>> Modified by: _yury.ramanovich@nokia.com_
>>>
>>>> Reviewed by:
>>>>
>>>> Date: 07/15/2010
>>>>
>>>> Project: symbian_client_apps
>>>>
>>>> ErrorId: ou1cimx1#474138
>>>>
>>>> Synopsis: XPSPacketSink.lib is not linked with QT app
>>>>
>>>> Overview: when XPSPacketSink.lib is linked with QT app (like
>>> FlashLite)
>>>> that has STDCPP keyword in its .mmp file, checklib tool gives error:
>>>> "xpspacketsink.lib is incompatible with standard C++". The reason for
>>>> this error is the standard C++ operators new and new [] used
>>> throughout
>>>> the xpspacketsink.lib code, but the library doesn't declare itself as
>>>> supporting standard C++ new and new[] behavior.
>>>>
>>>> Solution: 1) add STDCPP keyword to xpspacketsink.mmp, which
>>> effectively
>>>> tags the lib as supporting standard C++ new and new[] operators
>> during
>>>> "mmp helix build". Also do the same for the winscw and armv5 "CVS
>>> helix
>>>> builds" via mwldsym2 and armar command line options and
>>>> __SYMBIAN_STDCPP_SUPPORT__ define. The lib tagging will be controlled
>>> by
>>>> build system SymbianUtils.stdcppsupport flag, which will be set in
>>>> datatype/xps/PacketSink/XPSPacketSinkLib umakefile.
>>>> 2) use new (nothrow) operator for non-CBase heap allocations in
>>>> xpspacketsink.lib source since we don't handle bad_alloc exception.
>>>>
>>>> Files Added:
>>>> None.
>>>>
>>>> Files Modified:
>>>> /ribosome/build/umake/umake_symbianmmp.py
>>>> /ribosome/build/umakecf/symbian-armv5.cf
>>>> /ribosome/build/umakecf/symbian-emulator-winscw.cf
>>>> /ribosome/build/umakecf/symbian.cf
>>>> /datatype/xps/PacketSink/CXPSPacketSink.cpp
>>>> /datatype/xps/PacketSink/CXPSPktQue.cpp
>>>> /datatype/xps/PacketSink/CXPSSession.cpp
>>>> /datatype/xps/PacketSink/CXPSSession.h
>>>> /datatype/xps/PacketSink/CXPSStream.cpp
>>>> /datatype/xps/PacketSink/XPSPacketSinkLib
>>>>
>>>>
>>>> Image Size and Heap Use impact: minor
>>>>
>>>> Module Release testing : yes, XPSTestApp
>>>>
>>>> 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.
>>>>
>>>>
>>>> BR
>>>>
>>>>
>>>>
From ext-sudhir.1.mishra at nokia.com Fri Jul 23 13:44:54 2010
From: ext-sudhir.1.mishra at nokia.com (ext-sudhir.1.mishra@nokia.com)
Date: Fri Jul 23 20:21:13 2010
Subject: [datatype-dev] URGENT CR: Helix controller crashes when trying to
stream DVBH in background.
Message-ID: <0D5D8A0728D4FC43BB0A2393C9AE8F172DD70DF58D@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; Ashish.As.Gupta@nokia.com
RC Id: ou1cimx1#490618
Date: 07/23/2010
Project: SymbianMmf_wm
Synopsis: Helix controller crashes when trying to stream DVBH in background.
Overview:
This error addresses two faults:
1. The buffer corruption in cxpsclientstream where ProcessXPSBuffer() call resulted in re-entrant GetPacket calls.
2. The crash resulting from un-ordered XPS packets, causing the filler count to wrap around. This was resulting in call to GenerateLostPackets() multiple times and pushing a packet into the queue each time until it results in an exception.
Fix:
1. Modified XPS client stream to ensure Getpacket() doesn't get invoked until all outstanding GetPacket() calls are addressed.
2. Carrying out a wrap-around of lIndex if it is negative such that it doesn't cause filler count to wrap and cause the loop to run for a long time in InsertFillers() and thereby stopping the generation of a lost packet each time.
Files modified & changes:
datatype/xps/fileformat/CXPSFileformat.cpp
datatype/xps/fileformat/CXPSClientStream.cpp
datatype/xps/fileformat/ CXPSClientStream.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and Profiles Functionality verified: armv5, winscw
Branch: 210CayS, 420Bizo and HEAD
CVS Diff on 210CayS: Attached
-------------- next part --------------
Index: CXPSClientStream.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/fileformat/CXPSClientStream.cpp,v
retrieving revision 1.1.1.1.2.6
diff -u -w -r1.1.1.1.2.6 CXPSClientStream.cpp
--- CXPSClientStream.cpp 13 Aug 2009 18:42:23 -0000 1.1.1.1.2.6
+++ CXPSClientStream.cpp 22 Jul 2010 13:04:17 -0000
@@ -87,6 +87,8 @@
,m_HdrPtr(NULL, 0)
,m_PyldPtr(NULL, 0)
,m_bPktBufferInvalid(EFalse)
+ ,m_bXPSBufferInprocess(EFalse)
+ ,m_bXPSGetpacketOutstanding(EFalse)
{
}
@@ -265,6 +267,8 @@
{
if(!(m_pGetPktActiveObj->IsActive()))
{
+ if(!m_bXPSBufferInprocess)
+ {
TIpcArgs args;
TPtr8 HdrBufPtr = m_pHdrBuf->Des();
@@ -285,8 +289,18 @@
// Activate the active obj for async call
m_pGetPktActiveObj->Activate();
m_pXPSClient->SendAsyncCmd(XPS_GetPacket, args, m_pGetPktActiveObj->Status());
+ m_bXPSGetpacketOutstanding = EFalse;
HXLOGL2(HXLOG_SXPS, "CXPSClientStream[%d]::GetPacket Sent to Server",m_uStreamId);
}
+ else
+ {
+ // This flag ensures we send GetPacket() only if all outstanding GetPacket() calls
+ // are addressed. Otherwise it may result in GetPacket() re-entrancy at
+ // ProcessXPSBuffers() and further buffer corruption.
+ m_bXPSGetpacketOutstanding = ETrue;
+ HXLOGL3(HXLOG_SXPS, "CXPSClientStream[%d]::GetPacket tobe Sent to Server",m_uStreamId);
+ }
+ }
}
//
@@ -315,7 +329,7 @@
Parser.Val(iNewPktCnt);
- HXLOGL2(HXLOG_SXPS, "CXPSClientStream [%lu]::ProcessXPSBuffer Cnt:%lu", m_uStreamId, iNewPktCnt);
+ m_bXPSBufferInprocess = ETrue;
while(iPktIndex < iNewPktCnt)
{
@@ -335,13 +349,18 @@
} // End of while(iPktIndex > iNewPktCnt)
- if(lValidPkts == 0)
+ m_bXPSBufferInprocess = EFalse;
+
+ HXLOGL2(HXLOG_SXPS, "CXPSClientStream [%lu]::ProcessXPSBuffer Cnt:%lu, m_bXPSGetpacketOutstanding: %d,
+ lValidPkts:%d", m_uStreamId, iNewPktCnt, m_bXPSGetpacketOutstanding, lValidPkts);
+
+ if(lValidPkts == 0 || m_bXPSGetpacketOutstanding)
{
// All packets in the package from server were invalid packets.
// Means that there is msg pending from caller, but no pkt to give.
// If next client GetPkt msg is not sent internally, the pkts for this
// stream would never start again. So re-issue the getPkt msg
- HXLOGL1(HXLOG_SXPS, "CXPSClientStream [%lu]::ProcessXPSBuffer Pckg INVALID, retry GetPkt",
+ HXLOGL3(HXLOG_SXPS, "CXPSClientStream [%lu]::ProcessXPSBuffer Pckg INVALID, retry GetPkt",
m_uStreamId);
GetPacket();
}
Index: CXPSClientStream.h
===================================================================
RCS file: /cvsroot/datatype/xps/fileformat/CXPSClientStream.h,v
retrieving revision 1.1.1.1.2.2
diff -u -w -r1.1.1.1.2.2 CXPSClientStream.h
--- CXPSClientStream.h 12 Nov 2007 19:00:45 -0000 1.1.1.1.2.2
+++ CXPSClientStream.h 22 Jul 2010 13:04:17 -0000
@@ -136,6 +136,8 @@
CActiveObj* m_pEndStreamActiveObj;
TBool m_bPktBufferInvalid;
+ TBool m_bXPSBufferInprocess;
+ TBool m_bXPSGetpacketOutstanding;
};
#endif // End of #ifndef _CXPSCLIENTSTREAM_H_
Index: CXPSFileformat.cpp
===================================================================
RCS file: /cvsroot/datatype/xps/fileformat/CXPSFileformat.cpp,v
retrieving revision 1.1.1.1.2.19
diff -u -w -r1.1.1.1.2.19 CXPSFileformat.cpp
--- CXPSFileformat.cpp 7 Jul 2010 06:44:37 -0000 1.1.1.1.2.19
+++ CXPSFileformat.cpp 22 Jul 2010 13:04:18 -0000
@@ -1351,18 +1351,14 @@
UINT32 CMediaStream::GetInsertIndex(UINT32 ulCurrSeqNo)
{
INT32 lIndex = 0;
+ UINT32 ulBaseSeq = 0;
HX_ASSERT(m_pQue);
if(m_ulLastPktSeqNoDispatched != MAX_UINT32)
{
- UINT32 ulBaseSeq = (m_ulLastPktSeqNoDispatched + 1);
+ ulBaseSeq = (m_ulLastPktSeqNoDispatched + 1);
lIndex = ulCurrSeqNo - ulBaseSeq;
- if(lIndex < 0)
- {
- // Wrap around (wrap around value 65535)
- lIndex = (INT32)(WRAP_SEQ_NO - ulBaseSeq + ulCurrSeqNo);
- }
}
else
{
@@ -1373,10 +1369,15 @@
{
CMediaStreamElem* pElem = NULL;
pElem = (CMediaStreamElem*) m_pQue->front();
- UINT32 ulBaseSeq = pElem->SeqNo();
+ ulBaseSeq = pElem->SeqNo();
lIndex = ulCurrSeqNo - ulBaseSeq;
}
+ }
+ if(lIndex < 0)
+ {
+ // Wrap around (wrap around value 65535)
+ lIndex = (INT32)(WRAP_SEQ_NO - ulBaseSeq + ulCurrSeqNo);
}
return (UINT32) lIndex;
From jgordon at real.com Fri Jul 23 14:57:59 2010
From: jgordon at real.com (Jamie Gordon)
Date: Fri Jul 23 21:34:22 2010
Subject: [datatype-dev] URGENT CR: Helix controller crashes when trying
to stream DVBH in background.
In-Reply-To: <0D5D8A0728D4FC43BB0A2393C9AE8F172DD70DF58D@NOK-EUMSG-02.mgdnok.nokia.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DD70DF58D@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C4A1E77.3030602@real.com>
ok
On 7/23/2010 2:44 PM, 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: rajesh.rathinasamy@nokia.com; Ashish.As.Gupta@nokia.com
>
> RC Id: ou1cimx1#490618
>
> Date: 07/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Helix controller crashes when trying to stream DVBH in background.
>
> Overview:
> This error addresses two faults:
> 1. The buffer corruption in cxpsclientstream where ProcessXPSBuffer() call resulted in re-entrant GetPacket calls.
> 2. The crash resulting from un-ordered XPS packets, causing the filler count to wrap around. This was resulting in call to GenerateLostPackets() multiple times and pushing a packet into the queue each time until it results in an exception.
>
> Fix:
> 1. Modified XPS client stream to ensure Getpacket() doesn't get invoked until all outstanding GetPacket() calls are addressed.
> 2. Carrying out a wrap-around of lIndex if it is negative such that it doesn't cause filler count to wrap and cause the loop to run for a long time in InsertFillers() and thereby stopping the generation of a lost packet each time.
>
> Files modified & changes:
> datatype/xps/fileformat/CXPSFileformat.cpp
> datatype/xps/fileformat/CXPSClientStream.cpp
> datatype/xps/fileformat/ CXPSClientStream.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS: Attached
>
From Joeli at real.com Fri Jul 23 18:21:00 2010
From: Joeli at real.com (Joe Li)
Date: Sat Jul 24 00:57:40 2010
Subject: =?gb2312?B?tPC4tDogW2RhdGF0eXBlLWRldl0gQ1I6IE1LViBIZWxpeC40LjIuMC1NZXJn?=
=?gb2312?B?ZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9yCUxlcGhvbmUy?=
In-Reply-To: <4C499E78.70909@real.com>
Message-ID:
VGhhbmtzLiAgQ29tbWl0dGVkIHRvIDM2MWF0bGFzDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8
/sjLOiBTaGVsZG9uIEZ1IA0Kt6LLzcqxvOQ6IDIwMTDE6jfUwjIzyNXQx8bazuUgMjE6NTINCsrV
vP7IyzogSm9lIExpDQqzrcvNOiBhbmRyb2lkLXBvcnQtZGV2QGhlbGl4Y29tbXVuaXR5Lm9yZzsg
ZGF0YXR5cGUtZGV2QGhlbGl4Y29tbXVuaXR5Lm9yZw0K1vfM4jogUmU6IFtkYXRhdHlwZS1kZXZd
IENSOiBNS1YgSGVsaXguNC4yLjAtTWVyZ2UgYW5kIG1lbW9yeSBsZWFrIGlzc3VlIGZvciBMZXBo
b25lMg0KDQpMb29rcyBvay4NCg0KQ2FuIHlvdSBwcm9kdWNlIGEgZGlmZiBvZiBta3YgbW9kdWxl
cyBhZ2FpbnN0IDQyMCBhbmQgSGVhZCB0byBzZWUgd2hhdA0KaXMgc3RpbGwgZGlmZmVyZW50PyBJ
ZiB0aGVyZSBhcmUgZml4ZXMgYmV5b25kIHdoYXQgaXMgaW4gNDIwIGFscmVhZHksIHdlDQoob3Ig
Tm9raWEpIG1heSB3YW50IHRvIGNvbnNpZGVyIHJvbGwgdGhlIGZpeGVzIGludG8gNDIwIHRvby4N
Cg0KSWYgdGhlcmUgYXJlIG5ldyBjb2RlL2ZpeCBub3QgaW4gdGhlIEhlYWQsIHlvdSB3aWxsIHdh
bnQgdG8gbWVyZ2UgdG8NCkhlYWQuIEluIGdlbmVyYWwsIGFueSBmaXgvY2hhbmdlIG9uIHRoZSBi
cmFuY2ggc2hvdWxkIGdvIHRvIEhlYWQgYWxzby4NCg0KZnhkDQoNCkpvZSBMaSB3cm90ZToNCj4N
Cj4gVXBkYXRlIHRoZSBzb3VyY2UgY29kZS4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ICq3
orz+yMs6KiBKb2UgTGkNCj4gKreiy83KsbzkOiogMjAxMMTqN9TCMjLI1dDHxtrLxCAxOToyNQ0K
PiAqytW8/sjLOiogJ2FuZHJvaWQtcG9ydC1kZXZAaGVsaXhjb21tdW5pdHkub3JnJzsNCj4gJ2Rh
dGF0eXBlLWRldkBoZWxpeGNvbW11bml0eS5vcmcnDQo+ICrW98ziOiogQ1I6IE1LViBIZWxpeC40
LjIuMC1NZXJnZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9yIExlcGhvbmUyDQo+DQo+IGJ5OiBq
b2VsaUByZWFsLmNvbQ0KPg0KPiBEYXRlOiAwNy8yMi8yMDEwDQo+DQo+IFByb2plY3Q6IFJlYWxQ
bGF5ZXIgZm9yIEFuZHJvaWQgU21hcnRwaG9uZXMNCj4NCj4gU3lub3BzaXM6IE1LViBIZWxpeC40
LjIuMC1NZXJnZSBhbmQgbWVtb3J5IGxlYWsgaXNzdWUgZm9yIExlcGhvbmUyDQo+DQo+IE92ZXJ2
aWV3Og0KPg0KPiBUaGlzIENSIGlzIHRoZSBjb21wbGVtZW50IG9mIFtDUjogTUtWIGZpbGVmb3Jt
YXQgc3VwcG9ydCBmb3IgTGVwaG9uZTJdLg0KPg0KPiBJdHMgbW9kaWZpY2F0aW9uIGluY2x1ZGVk
IHRoZSBmb2xsb3cgaXRlbXM6DQo+DQo+IDEuIGh4Y2xpZW50XzRfMl8wX2JyaXpvIKGucyBNZXJn
ZTsNCj4NCj4gMi4gbWVtb3J5IGxlYWsgaXNzdWU7DQo+DQo+IDMuIGRsbCB1bmxvYWQgaXNzdWU7
DQo+DQo+IDQuIHNlZWsgd2l0aCBNb3NhaWMgaXNzdWUNCj4NCj4gRmlsZXMgQWRkZWQ6DQo+DQo+
IE5vbmUNCj4NCj4gRmlsZXMgTW9kaWZpZWQ6DQo+DQo+IGNvbW1vbi91dGlsL3B1Yi9wY2t1bnBj
ay5oDQo+DQo+IGNvbW1vbi91dGlsL3Bja3VucGNrLmNwcA0KPg0KPiBkYXRhdHlwZS9ta3YvZmls
ZWZvcm1hdC9wdWIvbWt2X2ZpbGVfZm9ybWF0LmgNCj4NCj4gZGF0YXR5cGUvbWt2L2ZpbGVmb3Jt
YXQvbWt2X2ZpbGVfZm9ybWF0LmNwcA0KPg0KPiBkYXRhdHlwZS9ta3YvbGlibWF0cm9za2EvTWF0
cm9za2EuaA0KPg0KPiBkYXRhdHlwZS9ta3YvbGlibWF0cm9za2EvTWF0cm9za2EuY3BwDQo+DQo+
IGRhdGF0eXBlL21rdi9saWJtYXRyb3NrYS9NYXRyb3NrYUV4cG9ydHMuY3BwDQo+DQo+IGRhdGF0
eXBlL21rdi9saWJtYXRyb3NrYS9NYXRyb3NrYUV4cG9ydHMuaA0KPg0KPiBkYXRhdHlwZS9ta3Yv
bGlibWF0cm9za2EvbGliZWJtbC9zcmMvRWJtbEJpbmFyeS5jcHANCj4NCj4gZGF0YXR5cGUvbWt2
L2xpYm1hdHJvc2thL2xpYm1hdHJvc2thL3NyYy9LYXhCbG9jay5jcHANCj4NCj4gSW1hZ2UgU2l6
ZSBhbmQgSGVhcCBVc2UgaW1wYWN0IChDbGllbnQgLU9ubHkpOg0KPg0KPiBOb25lDQo+DQo+IFBs
YXRmb3JtcyBhbmQgUHJvZmlsZXMgQWZmZWN0ZWQ6DQo+DQo+IFBsYXRmb3JtOiBQbGF0Zm9ybTog
YW5kcm9pZC1kb251dDMyMzAtYXJtLXFzZF84eDUwDQo+DQo+IFByb2ZpbGU6IGhlbGl4LWNsaWVu
dC1hbmRyb2lkLWZ1bGwNCj4NCj4gRGlzdHJpYnV0aW9uIExpYnJhcmllcyBBZmZlY3RlZDoNCj4N
Cj4gTm9uZQ0KPg0KPiBEaXN0cmlidXRpb24gbGlicmFyeSBpbXBhY3QgYW5kIHBsYW5uZWQgYWN0
aW9uOg0KPg0KPiBOb25lDQo+DQo+IFBsYXRmb3JtcyBhbmQgUHJvZmlsZXMgQnVpbGQgVmVyaWZp
ZWQ6DQo+DQo+IFBsYXRmb3JtOiBQbGF0Zm9ybTogYW5kcm9pZC1kb251dDMyMzAtYXJtLXFzZF84
eDUwDQo+DQo+IFByb2ZpbGU6IGhlbGl4LWNsaWVudC1hbmRyb2lkLWZ1bGwNCj4NCj4gUGxhdGZv
cm1zIGFuZCBQcm9maWxlcyBGdW5jdGlvbmFsaXR5IHZlcmlmaWVkOg0KPg0KPiBQbGF0Zm9ybTog
UGxhdGZvcm06IGFuZHJvaWQtZG9udXQzMjMwLWFybS1xc2RfOHg1MA0KPg0KPiBQcm9maWxlOiBo
ZWxpeC1jbGllbnQtYW5kcm9pZC1mdWxsDQo+DQo+IEJyYW5jaCBmb3I6IDM2MWF0bGFzDQo+DQo+
IFRoYW5rcw0KPg0KPiBKb2UNCj4NCg0K
From ext-g.manikanda at nokia.com Fri Jul 23 22:41:39 2010
From: ext-g.manikanda at nokia.com (ext-g.manikanda@nokia.com)
Date: Sat Jul 24 05:18:02 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur
when trying to
resume the playback in multiple instances of video player
Message-ID: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.10
diff -u -w -r1.1.1.1.2.10 Matroska.cpp
--- Matroska.cpp 16 Jul 2010 16:38:28 -0000 1.1.1.1.2.10
+++ Matroska.cpp 23 Jul 2010 11:55:04 -0000
@@ -30,12 +30,14 @@
#include "ihxpckts.h"
#include "hxtlogutil.h"
+#include "hxcom.h"
#include "Matroska.h"
using namespace LIBEBML_NAMESPACE;
using namespace LIBMATROSKA_NAMESPACE;
using namespace std;
+UINT32 MatroskaSegment::EbmlGlobal_Context_Ref=0;
#define TIMECODESCALE 1000000
@@ -1179,6 +1181,10 @@
MatroskaSegment* MatroskaSegment::Init(IOCallback& io)
{
+ //Allocating memory for Global pointers , assumed following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ if (CanAllocateGlobalContext())
+ {
InitGlobalContext();
EbmlCrc32::InitCallback();
EbmlDummy::InitCallback();
@@ -1206,7 +1212,7 @@
KaxTrackTranslate::InitCallback();
KaxTracks::InitCallback();
KaxTrackVideo::InitCallback();
-
+ }
EbmlStream *es = new EbmlStream(io);
if(es)
{
@@ -1222,6 +1228,10 @@
void MatroskaSegment::Release()
{
+ //Releasing memory for global pointers, assumed Following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ if(CanReleaseGlobalContext())
+ {
DeleteGlobalContext();
EbmlCrc32::DeleteCallback();
EbmlDummy::DeleteCallback();
@@ -1250,8 +1260,24 @@
KaxTracks::DeleteCallback();
KaxTrackVideo::DeleteCallback();
}
+}
+HXBOOL MatroskaSegment::CanAllocateGlobalContext()
+{
+ HXBOOL uCanAllocate =EbmlGlobal_Context_Ref?FALSE:TRUE;
+ InterlockedIncrement(&EbmlGlobal_Context_Ref);
+ return uCanAllocate;
+}
+HXBOOL MatroskaSegment::CanReleaseGlobalContext()
+{
+ HXBOOL uCanRelease = TRUE;
+ if ( InterlockedDecrement(&EbmlGlobal_Context_Ref) > 0 )
+ {
+ uCanRelease = FALSE;
+ }
+ return uCanRelease;
+}
HX_RESULT MatroskaSegment::VerifyHeader()
{
HXBOOL retVal = HXR_OK;
-------------- next part --------------
Index: 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
--- Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ Matroska.h 23 Jul 2010 15:17:55 -0000
@@ -44,7 +44,6 @@
UINT64 m_uDuration;
UINT64 m_uStartPos;
char *m_pSegTitle;
-
char *m_pTagTitle;
char *m_pTagAuthor;
char *m_pTagCopyright;
@@ -83,5 +82,9 @@
HX_RESULT ParseStreams( KaxTracks *tracks);
HX_RESULT ParseCues( KaxCues *pCues, EbmlElement* & pElementLevel2, int& level );
HX_RESULT ParseTags( KaxTags *tags);
+ private:
+ static UINT32 EbmlGlobal_Context_Ref;
+ static HXBOOL CanAllocateGlobalContext();
+ static HXBOOL CanReleaseGlobalContext();
};
#endif
-------------- next part --------------
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From ext-debashis.2.panigrahi at nokia.com Fri Jul 23 23:26:10 2010
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Sat Jul 24 06:02:39 2010
Subject: [datatype-dev] URGENT CR: Helix controller crashes when trying
to stream DVBH in background.
In-Reply-To: <4C4A1E77.3030602@real.com>
References: <0D5D8A0728D4FC43BB0A2393C9AE8F172DD70DF58D@NOK-EUMSG-02.mgdnok.nokia.com>
<4C4A1E77.3030602@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE284F818816@NOK-EUMSG-02.mgdnok.nokia.com>
Hi,
Checked in to 210CayS, 420Bizo and HEAD
Thanks and Regards,
Debashis.
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Jamie Gordon
Sent: Saturday, July 24, 2010 4:28 AM
To: Mishra Sudhir.1 (EXT-Sasken/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] URGENT CR: Helix controller crashes when trying to stream DVBH in background.
ok
On 7/23/2010 2:44 PM, 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: rajesh.rathinasamy@nokia.com; Ashish.As.Gupta@nokia.com
>
> RC Id: ou1cimx1#490618
>
> Date: 07/23/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Helix controller crashes when trying to stream DVBH in background.
>
> Overview:
> This error addresses two faults:
> 1. The buffer corruption in cxpsclientstream where ProcessXPSBuffer() call resulted in re-entrant GetPacket calls.
> 2. The crash resulting from un-ordered XPS packets, causing the filler count to wrap around. This was resulting in call to GenerateLostPackets() multiple times and pushing a packet into the queue each time until it results in an exception.
>
> Fix:
> 1. Modified XPS client stream to ensure Getpacket() doesn't get invoked until all outstanding GetPacket() calls are addressed.
> 2. Carrying out a wrap-around of lIndex if it is negative such that it doesn't cause filler count to wrap and cause the loop to run for a long time in InsertFillers() and thereby stopping the generation of a lost packet each time.
>
> Files modified & changes:
> datatype/xps/fileformat/CXPSFileformat.cpp
> datatype/xps/fileformat/CXPSClientStream.cpp
> datatype/xps/fileformat/ CXPSClientStream.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : No
>
> Memory leak check performed : Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 210CayS, 420Bizo and HEAD
>
> CVS Diff on 210CayS: Attached
>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From flan at real.com Sun Jul 25 19:39:33 2010
From: flan at real.com (Frank Lan)
Date: Mon Jul 26 02:15:44 2010
Subject: [datatype-dev] RE: [Android-port-dev] new fix for bug10370 no audio
when seek before start to play
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07E833E216@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA07E833E216@SEAMBX.corp.real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA07E841EE74@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_avistrm_h
Type: application/octet-stream
Size: 894 bytes
Desc: diff_avistrm_h
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100725/65aa3c67/diff_avistrm_h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_aviffpln_cpp
Type: application/octet-stream
Size: 1285 bytes
Desc: diff_aviffpln_cpp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100725/65aa3c67/diff_aviffpln_cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_aviffpln_h
Type: application/octet-stream
Size: 465 bytes
Desc: diff_aviffpln_h
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100725/65aa3c67/diff_aviffpln_h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_avistrm_cpp
Type: application/octet-stream
Size: 2923 bytes
Desc: diff_avistrm_cpp
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100725/65aa3c67/diff_avistrm_cpp-0001.obj
From xzhao at real.com Mon Jul 26 03:20:26 2010
From: xzhao at real.com (Xiaolu Zhao)
Date: Mon Jul 26 09:56:32 2010
Subject: [datatype-dev] CR: When play a mov file whose audio is pcm a-law
and video is MPEG4, it's very unsmooth
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6776@SEAMBX.corp.real.com>
Modified by: xzhao@real.com
Date: 2010-07-26
Project: RealPlayer for Android Smartphones
Bug Number: 10135
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=10135
Synopsis: MP4 fileformat can not play stream containing pcm(alaw or mulaw) audio smoothly
Overview: Originally, submitter report that "When play a mov file whose audio is pcm a-law and video is MPEG4, it's very unsmooth", but I found that the un-smoothness only is because of the pcm-alaw audio stream, no matter whether there is a video stream. Not only pcm-alaw has problem, but also pcm-mulaw audio stream.
The root cause for this problem is because mp4 fileformat read pcm audio stream in a un-efficient way. It read pcm audio stream sample by sample(2 bytes each time), and accumulate them for a packet, then it return back. Because of low reading efficiency, audio driver will starve and CPU occupation is very high. On Le-phone, CPU occupation almost 100% when playing such stream. On PC(Duo CPU 3.0GHz), CPU occupation is about 25-28%, while playing encoded content(audio AAC encoded, no video, in mov container), CPU occupation is only 14-15%.
The solution is to let mp4 fileformat read PCM sample in bunch. Bunch size will be set to half of chunk size for PCM-like stream. This way, a chunk of PCM data will only need 2 read, instead of hundreds of times. Use generic size to differentiate encoded stream(like AAC) and non-encoded stream(like PCM). With this patch, the CPU occupation will less than 50% on Le-phone.
Thank you for Gordon and Eric's hints.
Files Added:
NA
Files Modified:
qtatmmgs_inline.h
qttrack.cpp
qtatmmgs.h
Image Size and Heap Use impact (Client-Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
Profile: helix-client-android and helix-client-all-defines
Distribution Libraries Affected:
NA
Distribution library impact and planned action:
NA
Platforms and Profiles Build Verified:
Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
Profile: helix-client-android and helix-client-all-defines
Platforms and Profiles Functionality verified:
Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
Profile: helix-client-android and helix-client-all-defines
Branch: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_mp4_fileformat.diff
Type: text/x-patch
Size: 5993 bytes
Desc: datatype_mp4_fileformat.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100726/62b099c7/datatype_mp4_fileformat.bin
From ehyche at real.com Mon Jul 26 04:56:07 2010
From: ehyche at real.com (Eric Hyche)
Date: Mon Jul 26 11:32:10 2010
Subject: [datatype-dev] Re: CR: When play a mov file whose audio is pcm
a-law and video is MPEG4, it's very unsmooth
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6776@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F7BD6776@SEAMBX.corp.real.com>
Message-ID:
@@ -115,8 +115,8 @@
{
if (m_ulSamplesLeftInEntry > 0)
{
- m_ulSampleNumber++;
- m_ulSamplesLeftInEntry--;
+ m_ulSampleNumber += nCount;
+ m_ulSamplesLeftInEntry -= nCount;
return AdvanceSyncSampleNumber();
}
You should check here to make sure that m_ulSamplesLeftInEntry <= nCount, otherwise there is nothing to prevent m_ulSamplesLeftInEntry from wrapping around 0 and becoming a huge 32-bit number, which would cause major problems.
+ m_uBunchSize = (m_SampleSize.IsGenericSize())? m_SampleToChunk.GetChunkSampleCount()/2 : 1;
What causes IsGenericSize() to return TRUE?
Also, the setting of m_uBunchSize seems very arbitrary. Why is m_SampleToChunk.GetChunkSampleCount()/2 the right number for all fixed-sample size streams? I think we either need to restrict this fix to this particular datatype's 4cc, or we need to come up with a solution that really handles all datatype cases.
Eric
On Jul 26, 2010, at 7:20 AM, Xiaolu Zhao wrote:
> Modified by: xzhao@real.com
> Date: 2010-07-26
> Project: RealPlayer for Android Smartphones
>
> Bug Number: 10135
>
> Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=10135
>
> Synopsis: MP4 fileformat can not play stream containing pcm(alaw or mulaw) audio smoothly
>
> Overview: Originally, submitter report that "When play a mov file whose audio is pcm a-law and video is MPEG4, it's very unsmooth", but I found that the un-smoothness only is because of the pcm-alaw audio stream, no matter whether there is a video stream. Not only pcm-alaw has problem, but also pcm-mulaw audio stream.
>
> The root cause for this problem is because mp4 fileformat read pcm audio stream in a un-efficient way. It read pcm audio stream sample by sample(2 bytes each time), and accumulate them for a packet, then it return back. Because of low reading efficiency, audio driver will starve and CPU occupation is very high. On Le-phone, CPU occupation almost 100% when playing such stream. On PC(Duo CPU 3.0GHz), CPU occupation is about 25-28%, while playing encoded content(audio AAC encoded, no video, in mov container), CPU occupation is only 14-15%.
>
> The solution is to let mp4 fileformat read PCM sample in bunch. Bunch size will be set to half of chunk size for PCM-like stream. This way, a chunk of PCM data will only need 2 read, instead of hundreds of times. Use generic size to differentiate encoded stream(like AAC) and non-encoded stream(like PCM). With this patch, the CPU occupation will less than 50% on Le-phone.
>
> Thank you for Gordon and Eric's hints.
>
> Files Added:
> NA
>
> Files Modified:
> qtatmmgs_inline.h
> qttrack.cpp
> qtatmmgs.h
>
> Image Size and Heap Use impact (Client-Only):
> None
>
> Platforms and Profiles Affected:
> Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
> Profile: helix-client-android and helix-client-all-defines
>
> Distribution Libraries Affected:
> NA
>
> Distribution library impact and planned action:
> NA
>
> Platforms and Profiles Build Verified:
> Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
> Profile: helix-client-android and helix-client-all-defines
>
> Platforms and Profiles Functionality verified:
> Platform: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
> Profile: helix-client-android and helix-client-all-defines
>
> Branch: hxclient_3_1_0_atlas and hxclient_3_6_1_atlas
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
> Best Regards
> Zhao Xiaolu
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
From sfu at real.com Mon Jul 26 10:03:11 2010
From: sfu at real.com (Sheldon Fu)
Date: Mon Jul 26 16:37:19 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur
when trying to resume the playback in multiple instances of video
player
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C4DCDDF.3040800@real.com>
+HXBOOL MatroskaSegment::CanAllocateGlobalContext()
+{
+ HXBOOL uCanAllocate =EbmlGlobal_Context_Ref?FALSE:TRUE;
+ InterlockedIncrement(&EbmlGlobal_Context_Ref);
+ return uCanAllocate;
+}
This is not thread-safe. Two threads can both hit the first line at the
same time and they will both have uCanAllocate to be true. You need to
use the return value of InterlockedIncrement() to set uCanAllocate (the
thread that increase the counter from 0 to 1 is the one that is
'earlier' and the one supposed to do initialization) like what you do in
CanRelease.
Further more, even if the above is fixed, it is still not safe because
the thread that is deemed 'not to allocate global' may actually move
ahead while the 'allocate global' thread suspended right after or in
CanAllocateGlobalContext call. Then the code further done will run
without globals to be initialized.
The correct logic has to: 1. pick a thread as 'first' to initialize the
globals. 2. other thread(s) not picked as first will have to WAIT until
the globals are initialized by the first thread.
This is better solved by a mutex rather than atomic counter I think.
If Symbian support initialization of static object in shared lib, you
can also have a global object variable defined and in its constructor to
initialize the globals --- basically initializing globals once at DLL
load time.
fxd
ext-g.manikanda@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-g.manikanda@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
> , girish.shetty@nokia.com
>
>
> Date: 07 / 23 /2010
>
> Project:
>
> ErrorId: ou1cimx1#477224
>
> Synopsis: Fusion: Crashes occur when trying to resume the playback in
> multiple instances of video player
>
> Overview: While playing first instance of MKV Videoplayback, MKV
> Fileformat plugin is allocating global pointers in
> MatroskaSegment::Init() (for example EbmlGlobal_ContextList global
> Pointer in InitGlobalContext() and EbmlCrc32::InitCallback()
> functions. Playing second instance of MKV file, All global pointers
> are reallocated again (First instance's global pointer's address were
> lost).These global pointers were shared across between two different
> instance of mkv playbak. When First instance closes playback
> MatroskaSegment::Release() is deleting global pointers , Hence other
> instance panics while resume or closing playback.
>
> Solution: Adding global variable reference count and make decision
> for allocating and deallocating global pointers across different mkv
> instances.
>
> Modified files:
>
> \datatype\mkv\libmatroska\Matroska.h
> \datatype\mkv\libmatroska\Matroska.cpp
>
>
> Image size and heap use impact: None
>
> Module Release testing (STIF): Done
>
> TNE testing: TNE testing for MKV fileformat done.
>
> Test case(s) added: None
>
> Memory leak check performed: NA
>
> Branch(es) : cays 210, Brizo 420 and Head.
>
> Diff: Attached
>
>
>
From ext-asheesh.srivastava at nokia.com Mon Jul 26 11:40:16 2010
From: ext-asheesh.srivastava at nokia.com (ext-asheesh.srivastava@nokia.com)
Date: Mon Jul 26 18:16:17 2010
Subject: [datatype-dev] CR: URGENT: No Audio when playing WMA clips when
used with DSP decoder
Message-ID: <9934DA2840283045BD072C97E0BD844A3958A207CA@NOK-EUMSG-03.mgdnok.nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
? Makefile
? Umakefil.upp
? armv5-rel32
? diff.txt
? diff12.txt
? diff_old.txt
? dspmdfaud_dll_stub.c
? dspmdfaud_ordinal.dat
? dspmdfaud{000a0000}.def
Index: mdfauddevice.cpp
===================================================================
RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp,v
retrieving revision 1.19.4.7
diff -u -b -r1.19.4.7 mdfauddevice.cpp
--- mdfauddevice.cpp 8 Jun 2010 08:40:06 -0000 1.19.4.7
+++ mdfauddevice.cpp 26 Jul 2010 19:27:07 -0000
@@ -762,16 +762,20 @@
//
HX_RESULT CHXMDFAudioDevice::CheckFormat(const HXAudioFormat* pAudioFormat)
{
- HXLOGL4(HXLOG_MDFA,"mdfdev:ChkFormat <>");
+ HXLOGL4(HXLOG_MDFA,"mdfdev:ChkFormat <");
HX_RESULT res = HXR_FAIL;
- if (pAudioFormat) {
+ if (pAudioFormat)
+ {
+ //we use 16-bit per sample to generate dummy PCM data .
if (m_pAudioFormat->m_uChannels == pAudioFormat->uChannels &&
- m_pAudioFormat->m_uBitsPerSample == pAudioFormat->uBitsPerSample &&
- m_pAudioFormat->m_ulSamplesPerSec == pAudioFormat->ulSamplesPerSec) {
+ 16 == pAudioFormat->uBitsPerSample &&
+ m_pAudioFormat->m_ulSamplesPerSec == pAudioFormat->ulSamplesPerSec)
+ {
res = HXR_OK;
}
}
+ HXLOGL4(HXLOG_MDFA,"mdfdev:ChkFormat >");
return res;
}
Index: wmaformat.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/audio/renderer/wmaformat.cpp,v
retrieving revision 1.9.10.1
diff -u -b -r1.9.10.1 wmaformat.cpp
--- wmaformat.cpp 19 Apr 2010 09:48:01 -0000 1.9.10.1
+++ wmaformat.cpp 25 Jul 2010 23:52:35 -0000
@@ -601,8 +601,7 @@
bLastPacketInQueue = FALSE;
}
// Set the next frame time
- UINT32 ulNextFrameTimeInMs = m_TSConverter.Convert(ulNextDecodeStartTimeInSamples);
- pDecoder->SetNextFrameTime(ulNextFrameTimeInMs);
+ pDecoder->SetNextFrameTime(pAssembledFrame->m_ulTime);
+
// Decode the encoded audio frame
// The bFlushCodec argument is
From qluo at real.com Mon Jul 26 12:24:00 2010
From: qluo at real.com (Qiang Luo)
Date: Mon Jul 26 18:59:37 2010
Subject: [datatype-dev] CR: URGENT: No Audio when playing WMA clips when
used with DSP decoder
In-Reply-To: <9934DA2840283045BD072C97E0BD844A3958A207CA@NOK-EUMSG-03.mgdnok.nokia.com>
References: <9934DA2840283045BD072C97E0BD844A3958A207CA@NOK-EUMSG-03.mgdnok.nokia.com>
Message-ID: <4C4DEEE0.6090609@real.com>
Looks good.
Qiang
On 7/26/2010 12:40 PM, ext-asheesh.srivastava@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-asheesh.srivastava@nokia.com_
>
> Reviewed by:
> RC Id : issues. Common RC will be created soon.>
> Date: 07/26/2010
> Project: phonon_backend, symbian_client_apps
> Synopsis: No Audio for WMA clip which has Bits/Sample more than ?16?
> when used with DSP decoders
> Overview: Recently we switched to DSP decoder for WMA audio by
> enabling UseWMACMMFHWDeviceAudioCodec flag.
> Clips which have more than 16 bits/Sample [e.g. Windows Media Audio
> (WMA) Professional V10, WMA9P]in their audio stream header are played
> without audio (partial playback).
> This was happening because of the following reasons ?
>
> 1. MDF audio decoder initializes audio device with the audio format
> present in the stream header ( bits/sample = 24)
> 2. During WMA renderer setup, it initializes the WMA audio format
> during which WMA audio format updates the whole audio format
> except bits/sample, with the same values audio decoder was
> opened. So WMA audio device dishonors bits/sample present in
> stream header and initializes it with ?16?. It does so because
> symbian platform only supports 16-bit PCM data.
> 3. While audio player set up, it sets up the audio session to get
> the audio device format which eventually calls CheckFormat() of
> MDF audio device.
> 4. In MDF Audio device CheckFormat() function, it checks if the
> passed audio format is same as the one using which this device
> was opened.
> 5. Because WMA audio format had already over-written the value of
> Bits/sample, condition gets failed and hence no audio.
>
> Solution:
> Because on symbian platform we use 16-bit per sample to generate dummy
> PCM data, we need to modify MDF audio device?s CheckFormat() so that
> it checks bits/sample value against 16.
> Even after fixing the CheckFormat() function, audio was playing in
> ?stop and go? fashion.
> It was happening because CWMAudioFormat::DecodeAudioData() was setting
> wrong ?next frame time? in the MDF audio decoder.
> Fixed it by setting ?pAssembledFrame->m_ulTime? in decoder?s
> SetNextFrameTime() function instead of one computed using no. of
> samples produced. (same as Cays 210 does.)
> Files modified & changes:
> /cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
> /cvsroot/datatype/wm/audio/renderer/wmaformat.cpp
> Image Size and Heap Use impact: No major impact
> Module Release testing (STIF) : Done.
> Test case(s) Added : No
> Memory leak check performed : Passed, No additional leaks introduced.
> Platforms and Profiles Build Verified: helix-client-s60-52-ng,
> helix-client-symbian-4
> Platforms and Profiles Functionality verified: armv5
> Branch: 420Bizo and HEAD
> Diff:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100726/324bc3a0/attachment.html
From ext-asheesh.srivastava at nokia.com Mon Jul 26 13:08:15 2010
From: ext-asheesh.srivastava at nokia.com (ext-asheesh.srivastava@nokia.com)
Date: Mon Jul 26 19:44:09 2010
Subject: [datatype-dev] CR: URGENT: No Audio when playing WMA clips when
used with DSP decoder
In-Reply-To: <4C4DEEE0.6090609@real.com>
References: <9934DA2840283045BD072C97E0BD844A3958A207CA@NOK-EUMSG-03.mgdnok.nokia.com>
<4C4DEEE0.6090609@real.com>
Message-ID: <9934DA2840283045BD072C97E0BD844A3958A2080D@NOK-EUMSG-03.mgdnok.nokia.com>
Thanks Qiang.
Changes committed to Brizo420 and HEAD.
Regards,
- Asheesh
From: ext Qiang Luo [mailto:qluo@real.com]
Sent: Monday, July 26, 2010 3:24 PM
To: Srivastava Asheesh (EXT-InfoVision/Dallas)
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: URGENT: No Audio when playing WMA clips when used with DSP decoder
Looks good.
Qiang
On 7/26/2010 12:40 PM, ext-asheesh.srivastava@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-asheesh.srivastava@nokia.com
Reviewed by:
RC Id :
Date: 07/26/2010
Project: phonon_backend, symbian_client_apps
Synopsis: No Audio for WMA clip which has Bits/Sample more than '16' when used with DSP decoders
Overview: Recently we switched to DSP decoder for WMA audio by enabling UseWMACMMFHWDeviceAudioCodec flag.
Clips which have more than 16 bits/Sample [e.g. Windows Media Audio (WMA) Professional V10, WMA9P]in their audio stream header are played without audio (partial playback).
This was happening because of the following reasons -
1. MDF audio decoder initializes audio device with the audio format present in the stream header ( bits/sample = 24)
2. During WMA renderer setup, it initializes the WMA audio format during which WMA audio format updates the whole audio format except bits/sample, with the same values audio decoder was opened. So WMA audio device dishonors bits/sample present in stream header and initializes it with '16'. It does so because symbian platform only supports 16-bit PCM data.
3. While audio player set up, it sets up the audio session to get the audio device format which eventually calls CheckFormat() of MDF audio device.
4. In MDF Audio device CheckFormat() function, it checks if the passed audio format is same as the one using which this device was opened.
5. Because WMA audio format had already over-written the value of Bits/sample, condition gets failed and hence no audio.
Solution:
Because on symbian platform we use 16-bit per sample to generate dummy PCM data, we need to modify MDF audio device's CheckFormat() so that it checks bits/sample value against 16.
Even after fixing the CheckFormat() function, audio was playing in 'stop and go' fashion.
It was happening because CWMAudioFormat::DecodeAudioData() was setting wrong 'next frame time' in the MDF audio decoder.
Fixed it by setting 'pAssembledFrame->m_ulTime' in decoder's SetNextFrameTime() function instead of one computed using no. of samples produced. (same as Cays 210 does.)
Files modified & changes:
/cvsroot/datatype/mdf/audio/dsp/mdfauddevice.cpp
/cvsroot/datatype/wm/audio/renderer/wmaformat.cpp
Image Size and Heap Use impact: No major impact
Module Release testing (STIF) : Done.
Test case(s) Added : No
Memory leak check performed : Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-s60-52-ng, helix-client-symbian-4
Platforms and Profiles Functionality verified: armv5
Branch: 420Bizo and HEAD
Diff:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20100726/7a245b8b/attachment-0001.html
From jgordon at real.com Tue Jul 27 18:40:24 2010
From: jgordon at real.com (Jamie Gordon)
Date: Wed Jul 28 01:15:46 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur
when trying to resume the playback in multiple instances of video
player
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C4F9898.2020904@real.com>
ok
ext-g.manikanda@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-g.manikanda@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
> , girish.shetty@nokia.com
>
>
> Date: 07 / 23 /2010
>
> Project:
>
> ErrorId: ou1cimx1#477224
>
> Synopsis: Fusion: Crashes occur when trying to resume the playback in
> multiple instances of video player
>
> Overview: While playing first instance of MKV Videoplayback, MKV
> Fileformat plugin is allocating global pointers in
> MatroskaSegment::Init() (for example EbmlGlobal_ContextList global
> Pointer in InitGlobalContext() and EbmlCrc32::InitCallback()
> functions. Playing second instance of MKV file, All global pointers are
> reallocated again (First instance's global pointer's address were
> lost).These global pointers were shared across between two different
> instance of mkv playbak. When First instance closes playback
> MatroskaSegment::Release() is deleting global pointers , Hence other
> instance panics while resume or closing playback.
>
> Solution: Adding global variable reference count and make decision for
> allocating and deallocating global pointers across different mkv instances.
>
> Modified files:
>
> \datatype\mkv\libmatroska\Matroska.h
> \datatype\mkv\libmatroska\Matroska.cpp
>
>
> Image size and heap use impact: None
>
> Module Release testing (STIF): Done
>
> TNE testing: TNE testing for MKV fileformat done.
>
> Test case(s) added: None
>
> Memory leak check performed: NA
>
> Branch(es) : cays 210, Brizo 420 and Head.
>
> Diff: Attached
>
>
>
From ext-anugrah.2.kashari at nokia.com Wed Jul 28 04:39:59 2010
From: ext-anugrah.2.kashari at nokia.com (ext-anugrah.2.kashari@nokia.com)
Date: Wed Jul 28 11:15:47 2010
Subject: [datatype-dev] RE: [Nokia-private-dev] CR : ou1cimx1#482778 :
Metadata is not returned properly for certain video formats
In-Reply-To: <4C49A96C.1070705@real.com>
References:
<888A0A0FAF11234F9E0D17809A78D7E41DC1C5398C@NOK-EUMSG-03.mgdnok.nokia.com>
<4C49A96C.1070705@real.com>
Message-ID:
Hi Sheldon,
I have taken your suggestions. Please find the new diff.
For RM FF I have taken changes from HEAD. Changes are similar to https://helixcommunity.org/viewcvs/rarvcode-formprot/fileformat/rmffplin.cpp?r1=1.41.4.9&r2=1.41.4.9.2.1 .
For MKV FF these changes were legacy code so I had not changed anything but just added a log. I do feel libmatroska returns "FrameRate " in float and unit is frames per second. So I have changed video.uFPS to float.
Thanks,
Anugrah K
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, July 23, 2010 8:09 PM
To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR : ou1cimx1#482778 : Metadata is not returned properly for certain video formats
if(trk->video.uFPS > 0.0)
{
pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS / 1000);
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): video.uFPS %d",
+ trk->video.uFPS / 1000);
+ }
This doesn't seem to be correct. uFPS is uint32 so it shouldn't be
compared to 0.0 and if 'trk->video.uFPS / 1000' is the correct way to
convert to frames per million second then uFPS will be 'frames per
billion second' and that will overflow uint32 with a framerate of just 5
fps. Should here be "video.uFPS * 1000000"?
Also in rm change, the following is a confusing macro define mathematically:
+#define ONE_MILLION 1000
And in SureStream RM, there could be multiple video streams with
different framerates. I believe the following change will use the frame
rate of the LAST stream. This is probably not the stream to be picked by
default for local playback.
@@ -4411,6 +4427,8 @@
char szFPS[128]; /* Flawfinder: ignore */
sprintf(szFPS, "%.1f", fps); /* Flawfinder: ignore */
+ // save frames rate information
+ m_ulFramesPerMSecond = fps*ONE_MILLION;
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
>
> Reviewed by: yury.ramanovich@nokia.com
> girish.shetty@nokia.com
>
> RC Id : ou1cimx1#482778
>
> Date: 07/22/2010
>
> Project: SymbianMmf_wm
>
> Synopsis: Metadata is not returned properly for certain video formats
>
> Overview: Application looks for property "FramesPerMSecond" in stream header to extract frame rate for video clip. For AVI, MKV and Real media file format this property was not set. Application also needs to identify key frame based on ASM rules. For AVI FF this was not set.
>
> Fix: 1. Property "FramesPerMSecond" is set for AVI, MKV and RM FF.
> 2. Added ASM rules for AVI FF. The last input to IHXPacket::Set() is "0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk)" , as second statement won't get evaluated so removing it.
>
> Files modified & changes:
> /cvsroot/datatype/avi/fileformat/avistrm.cpp
> /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp
> /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp
> /cvsroot/rarvcode-formprot/fileformat/rmffplin.h
>
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF) : Done. Also tested for metadata and thumbnails.
>
> 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, 420Bizo and HEAD
>
> Diff attached.
> Changes for RM FF On Brizo and head is slightly different from Cays210. Attaching the diff for these branches as diff_rmff_Brizo420.txt.
>
>
-------------- next part --------------
Index: rmffplin.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp,v
retrieving revision 1.49.6.4
diff -u -w -r1.49.6.4 rmffplin.cpp
--- rmffplin.cpp 22 Jun 2007 15:10:16 -0000 1.49.6.4
+++ rmffplin.cpp 26 Jul 2010 10:16:47 -0000
@@ -149,6 +149,7 @@
#define RMFF_AU_STRING "FileFormat/RealMedia"
#define MAX_UINT32_STRING_SIZE 10
+#define ONE_MILLION 1000000
const float CRealMediaFileFormat::INTERFRAME_DROP_POINT = 0.8f;
@@ -4090,7 +4091,7 @@
// Extract all meta information that we care about
// from the stream headers
- AddStreamSpecificMetaInfo();
+ AddStreamSpecificMetaInfo(bAddAllInfo);
// Finally, add the specific information that was requested
// to the header
@@ -4146,9 +4147,9 @@
*
*/
HX_RESULT
-CRealMediaFileFormat::AddStreamSpecificMetaInfo()
+CRealMediaFileFormat::AddStreamSpecificMetaInfo(HXBOOL bAddAllInfo)
{
- AddTypeSpecificStats();
+ AddTypeSpecificStats(bAddAllInfo);
// Add other header values to be determined
@@ -4156,7 +4157,7 @@
}
HX_RESULT
-CRealMediaFileFormat::AddTypeSpecificStats()
+CRealMediaFileFormat::AddTypeSpecificStats(HXBOOL bAddAllInfo)
{
HX_RESULT hResult = HXR_OK;
UINT32 ulHeight = 0;
@@ -4190,6 +4191,10 @@
continue;
}
+ // Get the average bitrate
+ UINT32 ulAvgBitRate = 0;
+ pHeader->GetPropertyULONG32("AvgBitRate", ulAvgBitRate);
+
// Get the type specific information
hResult = pHeader->GetPropertyBuffer("OpaqueData", pData);
if (HXR_OK != hResult)
@@ -4206,6 +4211,12 @@
if (!strcasecmp((char*)pMime->GetBuffer(), REALAUDIO_MIME_TYPE) ||
!strcasecmp((char*)pMime->GetBuffer(), REALAUDIO_ENCRYPTED_MIME_TYPE))
{
+ CHXString strCodec;
+ CHXString strInterleaver;
+ UINT32 ulSampleRate = 0;
+ UINT32 ulBitsPerSample = 0;
+ UINT32 ulNumChannels = 0;
+
if (RM_MULTIHEADER_OBJECT == uID)
{
// Unpack the multistream header
@@ -4235,6 +4246,21 @@
{
// Now add codec to list of all possible codecs
AddToAllCodecList(pAllAudioCodecs, ulAllAudioCodecsBufLen, StreamParam.codecID);
+ // Compute the encoded bitrate of this substream
+ UINT32 ulEncBitRate = StreamParam.ulBytesPerMin * 8 / 60;
+ // We only save the stream src properties for the highest bitrate substream.
+ // Is this substream the highest bitrate?
+ if (ulEncBitRate > ulAvgBitRate)
+ {
+ // Save the bitrate, codec, interleaver, sample rate,
+ // bits per sample, and number of channels
+ ulAvgBitRate = ulEncBitRate;
+ strCodec = (const char*) StreamParam.codecID;
+ strInterleaver = (const char*) StreamParam.interleaverID;
+ ulSampleRate = StreamParam.ulSampleRate;
+ ulBitsPerSample = (UINT32) StreamParam.uSampleSize;
+ ulNumChannels = (UINT32) StreamParam.uChannels;
+ }
}
pCursor += ulHeaderSize;
@@ -4262,13 +4288,34 @@
{
// Now add codec to list of all possible codecs
AddToAllCodecList(pAllAudioCodecs, ulAllAudioCodecsBufLen, StreamParam.codecID);
+ // Save the bitrate, codec, interleaver, sample rate,
+ // bits per sample, and number of channels
+ ulAvgBitRate = StreamParam.ulBytesPerMin * 8 / 60;
+ strCodec = (const char*) StreamParam.codecID;
+ strInterleaver = (const char*) StreamParam.interleaverID;
+ ulSampleRate = StreamParam.ulSampleRate;
+ ulBitsPerSample = (UINT32) StreamParam.uSampleSize;
+ ulNumChannels = (UINT32) StreamParam.uChannels;
+ }
}
+ // Are we supposed to save all meta info?
+ if (bAddAllInfo)
+ {
+ // Add the source properties
+ SetCStringPropertyCCF(pHeader, "SrcCodec", (const char*) strCodec, m_pContext);
+ SetCStringPropertyCCF(pHeader, "SrcInterleaver", (const char*) strInterleaver, m_pContext);
+ pHeader->SetPropertyULONG32("SrcBitRate", ulAvgBitRate);
+ pHeader->SetPropertyULONG32("SrcSamplesPerSecond", ulSampleRate);
+ pHeader->SetPropertyULONG32("SrcBitsPerSample", ulBitsPerSample);
+ pHeader->SetPropertyULONG32("SrcNumChannels", ulNumChannels);
}
}
// Handle Video Stream
else if (!strcasecmp((char*)pMime->GetBuffer(), REALVIDEO_MIME_TYPE) ||
!strcasecmp((char*)pMime->GetBuffer(), REALVIDEO_ENCRYPTED_MIME_TYPE))
{
+ UINT32 ulSubMOFTag = 0;
+ float fFramesPerSec = 0.0;
if (RM_MULTIHEADER_OBJECT == uID)
{
// Unpack the multistream header
@@ -4309,6 +4356,10 @@
{
ulHeight = v.uiHeight;
ulWidth = v.uiWidth;
+ // Save the submoftag
+ ulSubMOFTag = v.submoftag;
+ // Save the frame rate
+ fFramesPerSec = FIXED_TO_FLOAT(v.framesPerSecond);
}
if (HX_MEDIA_VIDEO == v.moftag)
@@ -4348,12 +4399,39 @@
ulHeight = v.uiHeight;
ulWidth = v.uiWidth;
+ // Save the submoftag
+ ulSubMOFTag = v.submoftag;
+
if (HX_MEDIA_VIDEO == v.moftag)
{
float fps = FIXED_TO_FLOAT (v.framesPerSecond);
AddToAllFrameRatesList(pAllFrameRates, ulAllFrameRatesBufLen, fps);
+ // Save the frame rate
+ fFramesPerSec = fps;
}
}
+ // Are we supposed to output all meta info?
+ if (bAddAllInfo)
+ {
+ // Get the submoftag as a string
+ char szCodec4CC[5];
+ szCodec4CC[0] = (char) ((ulSubMOFTag & 0xFF000000) >> 24);
+ szCodec4CC[1] = (char) ((ulSubMOFTag & 0x00FF0000) >> 16);
+ szCodec4CC[2] = (char) ((ulSubMOFTag & 0x0000FF00) >> 8);
+ szCodec4CC[3] = (char) (ulSubMOFTag & 0x000000FF);
+ szCodec4CC[4] = '\0';
+ // Add the source properties
+ SetCStringPropertyCCF(pHeader, "SrcCodec", (const char*) szCodec4CC, m_pContext);
+ pHeader->SetPropertyULONG32("SrcBitRate", ulAvgBitRate);
+ pHeader->SetPropertyULONG32("SrcWidth", ulWidth);
+ pHeader->SetPropertyULONG32("SrcHeight", ulHeight);
+ // Compute the frame rate in frames per million seconds
+ UINT32 ulFramesPerMSecond = (UINT32) (fFramesPerSec * 1000000.0);
+ // Set the src frames per million seconds
+ pHeader->SetPropertyULONG32("SrcFramesPerMSecond", ulFramesPerMSecond);
+ }
+ // Set FramesPerMSecond
+ pHeader->SetPropertyULONG32("FramesPerMSecond", (UINT32) (fFramesPerSec *ONE_MILLION));
}
}
Index: rmffplin.h
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/rmffplin.h,v
retrieving revision 1.18
diff -u -w -r1.18 rmffplin.h
--- rmffplin.h 27 Apr 2005 19:12:18 -0000 1.18
+++ rmffplin.h 26 Jul 2010 10:16:47 -0000
@@ -304,8 +304,8 @@
IHXValues* pHeaderSource);
HX_RESULT AddMetaInfo (IHXValues* pHeader,
const char* pRequestedInfo);
- HX_RESULT AddStreamSpecificMetaInfo ();
- HX_RESULT AddTypeSpecificStats ();
+ HX_RESULT AddStreamSpecificMetaInfo (HXBOOL bAddAllInfo);
+ HX_RESULT AddTypeSpecificStats (HXBOOL bAddAllInfo);
HX_RESULT ExtractMetaInfo (IHXValues* pHeader,
RMFFPLINLogicalStream* pLogicalStream);
-------------- next part --------------
Index: fileformat/mkv_file_format.cpp
===================================================================
RCS file: /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp,v
retrieving revision 1.1.1.1.2.8
diff -u -w -r1.1.1.1.2.8 mkv_file_format.cpp
--- fileformat/mkv_file_format.cpp 10 Jul 2010 05:50:35 -0000 1.1.1.1.2.8
+++ fileformat/mkv_file_format.cpp 26 Jul 2010 10:21:54 -0000
@@ -82,6 +82,9 @@
#define DEFAULT_RTP_SAMPLES 90000
+#define ONE_THOUSAND 1000
+#define ONE_MILLION 1000000
+
#define CONVERT_TO_MILI_SECOND 1000000 // MKV file format duration are in nanoseconds.
#define MKV_ABSVAL(val) (((val) < 0) ? (-(val)) : (val))
#define MKV_BFRAME_MAXIMUMDEPTH 16
@@ -813,8 +816,20 @@
pHdr->SetPropertyULONG32("Height", trk->video.uHeight);
if(trk->video.uFPS > 0.0)
{
- pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS / 1000);
+ pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS*ONE_MILLION);
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): video.uFPS %d",
+ trk->video.uFPS*ONE_MILLION);
+ }
+ else if(trk->uDefaultDuration)
+ {
+ // uDefaultDuration is in nanoseconds
+ INT64 lFramesPerMSec = (INT64)ONE_MILLION*ONE_THOUSAND*CONVERT_TO_MILI_SECOND/
+ (trk->uDefaultDuration);
+ pHdr->SetPropertyULONG32("FramesPerMSecond", INT64_TO_ULONG32(lFramesPerMSec ));
+ HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): framesPerMSec %d",
+ INT64_TO_ULONG32(lFramesPerMSec ));
}
+
}
return HXR_OK;
? libmatroska/Makefile
? libmatroska/Umakefil.upp
? libmatroska/armv5-rel32
Index: libmatroska/Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.9
diff -u -w -r1.1.1.1.2.9 Matroska.cpp
--- libmatroska/Matroska.cpp 29 Jun 2010 10:20:55 -0000 1.1.1.1.2.9
+++ libmatroska/Matroska.cpp 26 Jul 2010 10:22:01 -0000
@@ -499,7 +499,7 @@
else if( EbmlId( *ve ) == KaxVideoFrameRate::ClassInfos->GlobalId )
{
KaxVideoFrameRate &vfps = *(KaxVideoFrameRate*)ve;
- tk->video.uFPS = uint32( float(vfps) );
+ tk->video.uFPS = float(vfps);
}
else if( EbmlId( *ve ) == KaxVideoDisplayUnit::ClassInfos->GlobalId )
{
Index: libmatroska/mkvtypes.h
===================================================================
RCS file: /cvsroot/xiph/matroskalib/mkvtypes.h,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 mkvtypes.h
--- libmatroska/mkvtypes.h 19 Oct 2009 14:53:47 -0000 1.1.1.1
+++ libmatroska/mkvtypes.h 26 Jul 2010 10:22:01 -0000
@@ -39,7 +39,7 @@
struct VideoFormat
{
- UINT32 uFPS;
+ float uFPS;
UINT32 uWidth;
UINT32 uHeight;
UINT32 uXOffset;
-------------- next part --------------
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.9.6.15
diff -u -w -r1.9.6.15 avistrm.cpp
--- avistrm.cpp 22 Jun 2010 05:04:11 -0000 1.9.6.15
+++ avistrm.cpp 22 Jul 2010 11:28:20 -0000
@@ -76,6 +76,7 @@
static const char HX_THIS_FILE[] = __FILE__;
#endif
+#define ONE_MILLION 1000000
// Operational defines:
#define DEFAULT_NON_LOCAL_PACKET_SIZE 1500
@@ -895,6 +896,10 @@
pHeader->SetPropertyULONG32("SamplesPerSecond", (UINT32) m_fSamplesPerSecond);
+ // Set frames per million second from fps.
+ INT64 lFramesPerMSec = ONE_MILLION*m_fSamplesPerSecond;
+ pHeader->SetPropertyULONG32("FramesPerMSecond",INT64_TO_ULONG32(lFramesPerMSec));
+
break;
}
case AVI_AUDS_TYPE:
@@ -1596,7 +1601,8 @@
ulTime = (UINT32) ((m_ulMinReadChunk / m_fChunksPerSecond) * 1000);
}
- // TODO: Set correct ASM rules
+
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -1608,14 +1614,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].bKeyChunk);
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
#ifdef USE_SIMPLE_SEGMENT_PAYLOAD
@@ -1717,7 +1723,7 @@
HXLOGL4(HXLOG_AVIX,"CAVIStream[%p]::GetNextPacket()\tstream %d\tpacket time: %lu\t minreadchunk: %lu\n", this, m_usStream, ulTime, m_ulMinReadChunk);
- // TODO: Set correct ASM rules
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -1729,14 +1735,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !m_chunkPrefetchArray[m_ulMinReadChunk % MAX_CHUNK_PREFETCH].bKeyChunk);
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
@@ -2311,7 +2317,7 @@
ulTime = (UINT32) ((m_ulMaxReadChunk / m_fChunksPerSecond) * 1000);
}
- // TODO: Set correct ASM rules
+ HXBOOL bKeyChunk = IsKeyChunk(m_usStream, m_ulMinReadChunk);
if (m_bEndianSwap16)
{
// How inefficient:
@@ -2323,14 +2329,14 @@
pSwappedBuffer->Set(pUnswappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize());
SwapWordBytes((unsigned short*) pSwappedBuffer->GetBuffer(), pUnswappedBuffer->GetSize() / 2);
pNewPacket->Set(pSwappedBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
HX_RELEASE(pSwappedBuffer);
}
}
else
{
pNewPacket->Set(pBuffer, ulTime, m_usStream,
- HX_ASM_SWITCH_OFF, 0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk));
+ bKeyChunk ? (HX_ASM_SWITCH_OFF|HX_ASM_SWITCH_ON) : HX_ASM_SWITCH_OFF, 0 );
}
#ifdef USE_SIMPLE_SEGMENT_PAYLOAD
From sfu at real.com Wed Jul 28 05:01:43 2010
From: sfu at real.com (Sheldon Fu)
Date: Wed Jul 28 11:35:33 2010
Subject: [datatype-dev] Re: [Nokia-private-dev] CR : ou1cimx1#482778 :
Metadata is not returned properly for certain video formats
In-Reply-To:
References: <888A0A0FAF11234F9E0D17809A78D7E41DC1C5398C@NOK-EUMSG-03.mgdnok.nokia.com>
<4C49A96C.1070705@real.com>
Message-ID: <4C502A37.5090908@real.com>
Looks good to me.
video.uFPS should be named video.fFPS now but if it is part of mkv lib
api and used in other places, it might be too much trouble to change it.
fxd
ext-anugrah.2.kashari@nokia.com wrote:
> Hi Sheldon,
>
> I have taken your suggestions. Please find the new diff.
> For RM FF I have taken changes from HEAD. Changes are similar to https://helixcommunity.org/viewcvs/rarvcode-formprot/fileformat/rmffplin.cpp?r1=1.41.4.9&r2=1.41.4.9.2.1 .
>
> For MKV FF these changes were legacy code so I had not changed anything but just added a log. I do feel libmatroska returns "FrameRate " in float and unit is frames per second. So I have changed video.uFPS to float.
>
> Thanks,
> Anugrah K
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Friday, July 23, 2010 8:09 PM
> To: Kashari Anugrah.2 (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: Re: [Nokia-private-dev] CR : ou1cimx1#482778 : Metadata is not returned properly for certain video formats
>
>
> if(trk->video.uFPS > 0.0)
> {
> pHdr->SetPropertyULONG32("FramesPerMSecond", trk->video.uFPS / 1000);
> + HXLOGL2(HXLOG_MKVF, "CMKVFileFormat::SetTypeSpecificProperties(): video.uFPS %d",
> + trk->video.uFPS / 1000);
> + }
>
> This doesn't seem to be correct. uFPS is uint32 so it shouldn't be
> compared to 0.0 and if 'trk->video.uFPS / 1000' is the correct way to
> convert to frames per million second then uFPS will be 'frames per
> billion second' and that will overflow uint32 with a framerate of just 5
> fps. Should here be "video.uFPS * 1000000"?
>
> Also in rm change, the following is a confusing macro define mathematically:
>
> +#define ONE_MILLION 1000
>
>
> And in SureStream RM, there could be multiple video streams with
> different framerates. I believe the following change will use the frame
> rate of the LAST stream. This is probably not the stream to be picked by
> default for local playback.
>
> @@ -4411,6 +4427,8 @@
> char szFPS[128]; /* Flawfinder: ignore */
> sprintf(szFPS, "%.1f", fps); /* Flawfinder: ignore */
>
> + // save frames rate information
> + m_ulFramesPerMSecond = fps*ONE_MILLION;
>
>
> 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
>>
>> Reviewed by: yury.ramanovich@nokia.com
>> girish.shetty@nokia.com
>>
>> RC Id : ou1cimx1#482778
>>
>> Date: 07/22/2010
>>
>> Project: SymbianMmf_wm
>>
>> Synopsis: Metadata is not returned properly for certain video formats
>>
>> Overview: Application looks for property "FramesPerMSecond" in stream header to extract frame rate for video clip. For AVI, MKV and Real media file format this property was not set. Application also needs to identify key frame based on ASM rules. For AVI FF this was not set.
>>
>> Fix: 1. Property "FramesPerMSecond" is set for AVI, MKV and RM FF.
>> 2. Added ASM rules for AVI FF. The last input to IHXPacket::Set() is "0 && !IsKeyChunk(m_usStream, m_ulMinReadChunk)" , as second statement won't get evaluated so removing it.
>>
>> Files modified & changes:
>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>> /cvsroot/datatype/mkv/fileformat/mkv_file_format.cpp
>> /cvsroot/rarvcode-formprot/fileformat/rmffplin.cpp
>> /cvsroot/rarvcode-formprot/fileformat/rmffplin.h
>>
>>
>> Image Size and Heap Use impact: No major impact
>>
>> Module Release testing (STIF) : Done. Also tested for metadata and thumbnails.
>>
>> 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, 420Bizo and HEAD
>>
>> Diff attached.
>> Changes for RM FF On Brizo and head is slightly different from Cays210. Attaching the diff for these branches as diff_rmff_Brizo420.txt.
>>
>>
>>
>
>
From gahluwalia at real.com Thu Jul 29 01:52:42 2010
From: gahluwalia at real.com (Gurpreet)
Date: Thu Jul 29 08:28:07 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C46F34F.90503@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com> <4C355263.6080304@real.com> <4C355FA5.7080200@real.com> <4C3C16E1.2060808@real.com> <4C3CC3F6.30904@real.com>
<4C46A465.9010101@real.com> <4C46F34F.90503@real.com>
Message-ID: <4C514F6A.9090609@real.com>
Hi Sheldon,
I have made changes as per your suggestions.
Now we send the first audio frame in case of aac as opaque data.
First frame is fetched for cases when avi stream setformat function
returns HXR_REQUEST_FIRST_FRAME.
This is a new return value added to hxresult.h.
After setting format in avi stream, avi fileformat will fetch first
frame depending on the result.
For fetching first frame.
We save the current file offset, state and stream number for which we
need the first frame.
We then find movi list chunk and then descend into it.
Read the data for the stream we are looking for.
If we find the frame then we call SetOpaque on avistream.
then we move back original offset and state.
Changes in mp4ff are merge from head.
Best Regards,
Gurpreet
On 7/21/2010 6:47 PM, Sheldon Fu wrote:
> I don't believe this is a good idea. Decoder needs enough information in
> Init call to decide whether it can handle the stream or not. Without
> setup info, it can not make that judgment. It will present problems when
> there are multiple decoders (say a hw one and a software backup).
>
> Also with the default dummy value approach, you will open and close and
> reopen the audio device when the audio format is switched from default
> to actual one -- adding delay to the play start and resource drain.
>
> The AVI FF should be changed so that it pre-read the first ADTS frame
> and use that as the decoder setup data (OpaqueData) as other FF does
> (e.g. the raw .aac ff when the data is in adts frame format).
>
> fxd
>
> Gurpreet Ahluwalia wrote:
>
>> Hi,
>> I think these changes are for cases when we don't have Decoder Specific
>> Object in fileformat(i.e avi ff)
>>
>> There is already change done in aac decoder to check for config.
>> If its null then default values are picked.
>> Correct configuration is later read from decoder when it is fed few frames.
>> I have attached the earlier diff for reference.
>>
>> If these changes are considered to be safe then I would request that
>> these changes to be merged into atlas 3411 also.
>>
>> Best Regards,
>> Gurpreet
>>
>>
>> On 7/14/2010 1:22 AM, Sheldon Fu wrote:
>>
>>
>>> Care to explain why the difference and 'can not use'?
>>>
>>> I looked at the change you made for AVIADTS. It seems that you are
>>> passing the ADTS frames directly to the decoder -- no stripping of th
>>> ADTS headers and without any codec config data. I don't think this will
>>> work with the default raac software decoder
>>> (datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
>>> config data is null and even that passes, it will expect raw AU unit as
>>> input, instead of ADTS frame. Have you tried your solution on a generic
>>> Linux build?
>>>
>>> fxd
>>>
>>> Sushant Garg wrote:
>>>
>>>
>>>
>>>> We can not use code written for AVIADTS, therefore merged my changes to
>>>> Head too.
>>>>
>>>> Regards,
>>>> Sushant
>>>>
>>>> Sheldon Fu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>>>>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>>>>> carries ADTS frames as packets and first frame as OapqueData. What is
>>>>> different for AVIADTS? There might be a chance these two can be merged
>>>>> as one.
>>>>>
>>>>> And if AVIADTS is different and needed, this should go into Head too.
>>>>>
>>>>> fxd
>>>>>
>>>>> Sushant Garg wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Thanks Jamie,
>>>>>>
>>>>>> Changes checked in to Atlas3410& Atlas310.
>>>>>>
>>>>>> Regards,
>>>>>> Sushant
>>>>>>
>>>>>> Jamie Gordon wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ok
>>>>>>>
>>>>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> *Project: RealPlayer for Netbook*
>>>>>>>>
>>>>>>>> *Synopsis:*
>>>>>>>>
>>>>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>>>>
>>>>>>>> * *
>>>>>>>>
>>>>>>>> *Overview:*
>>>>>>>>
>>>>>>>> Added support to play AVI ADTS files.
>>>>>>>>
>>>>>>>> Created a new mime type for such files& handle their parsing in mp4
>>>>>>>> renderer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Files Modified:
>>>>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>>>>
>>>>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>>>>
>>>>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>>>>
>>>>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>>>>
>>>>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Files Added: *
>>>>>>>>
>>>>>>>> None
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Platforms and Profiles Affected:
>>>>>>>> *Linux
>>>>>>>>
>>>>>>>> *Distribution Libraries Affected:*
>>>>>>>> None.
>>>>>>>>
>>>>>>>> *Platforms and Profiles Build Verified:
>>>>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>>>>> *Profile:* helix-client-moblin
>>>>>>>> *Target:* mediasinkplayer
>>>>>>>>
>>>>>>>>
>>>>>>>> *Branch:*
>>>>>>>> Atlas3_4_10, Atlas310
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Attachment:*
>>>>>>>>
>>>>>>>> diff.txt
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks& Regards,
>>>>>>>>
>>>>>>>> Sushant
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>> .
>>>
>>>
>>>
>>>
>>
>>
> .
>
>
-------------- next part --------------
Index: audio/renderer/mp4audio.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp,v
retrieving revision 1.23.16.2
diff -u -r1.23.16.2 mp4audio.cpp
--- audio/renderer/mp4audio.cpp 2 Nov 2009 07:45:26 -0000 1.23.16.2
+++ audio/renderer/mp4audio.cpp 29 Jul 2010 09:32:19 -0000
@@ -97,6 +97,7 @@
"audio/mpeg4-simple-A2",
"audio/mpeg4-generic",
"audio/X-HX-AAC-GENERIC",
+ "audio/X-HX-AAC-ADTS",
#endif /* #if defined(HELIX_FEATURE_AUDIO_CODEC_AAC) || defined(HELIX_FEATURE_AUDIO_CODEC_RAAC) */
#if defined(HELIX_FEATURE_AUDIO_CODEC_AMRNB)
"audio/X-RN-3GPP-AMR",
Index: audio/renderer/raacdecinfo.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp,v
retrieving revision 1.6
diff -u -r1.6 raacdecinfo.cpp
--- audio/renderer/raacdecinfo.cpp 14 Mar 2005 19:17:42 -0000 1.6
+++ audio/renderer/raacdecinfo.cpp 29 Jul 2010 09:32:19 -0000
@@ -39,7 +39,10 @@
HXBOOL CRAACDecInfo::IsMatch(const char* pMimeType, IMP4APayloadFormat* pRssm)
{
return CAACDecInfo::IsMatch(pMimeType, pRssm) ||
- (!strcasecmp("audio/X-HX-AAC-GENERIC", pMimeType));
+ (!strcasecmp("audio/X-HX-AAC-GENERIC", pMimeType) ||
+ !strcasecmp("audio/X-HX-AAC-ADTS", pMimeType)
+ );
+
}
const char* CRAACDecInfo::GetLibName(void)
Index: payload/mp4apyld.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/mp4apyld.cpp,v
retrieving revision 1.14.14.1
diff -u -r1.14.14.1 mp4apyld.cpp
--- payload/mp4apyld.cpp 4 Jul 2008 07:15:23 -0000 1.14.14.1
+++ payload/mp4apyld.cpp 29 Jul 2010 09:32:19 -0000
@@ -60,7 +60,7 @@
#include "hxrendr.h"
#include "hxformt.h"
#include "hxengin.h"
-
+#include "aacconstants.h"
#include "mp4-latm-depack.h"
#include "mp4desc.h"
@@ -86,6 +86,7 @@
, m_ulSamplesPerSecond (1000)
, m_ulRTPSamplesPerSecond(0)
, m_PayloadID (PYID_X_HX_MP4_RAWAU)
+ , m_ulADTSCurrentPacketOffset(0)
{
;
}
@@ -286,6 +287,10 @@
{
m_PayloadID = PYID_X_HX_AAC_GENERIC;
}
+ else if (strcasecmp(pMimeTypeData, "audio/X-HX-AAC-ADTS") == 0)
+ {
+ m_PayloadID = PYID_X_HX_AAC_ADTS;
+ }
else if (strcasecmp(pMimeTypeData, "audio/X-HX-3GPP-QCELP") == 0)
{
m_PayloadID = PYID_X_HX_3GPP_QCELP;
@@ -310,6 +315,9 @@
case PYID_X_HX_AAC_GENERIC:
retVal = SetAssemblerAACGenericHeader(pHeader);
break;
+ case PYID_X_HX_AAC_ADTS:
+ retVal = SetAssemblerAACADTSHeader(pHeader);
+ break;
case PYID_X_HX_3GPP_QCELP:
retVal = SetAssemblerQCELPHeader(pHeader);
break;
@@ -378,6 +386,42 @@
return retVal;
}
+HX_RESULT MP4APayloadFormat::SetAssemblerAACADTSHeader(IHXValues* pHeader)
+{
+ IHXBuffer *pBuffer = NULL;
+ UCHAR *pBuf = NULL;
+ HX_RESULT retVal = HXR_FAIL;
+
+ //OpaqueData is simply the first ADTS frame
+ retVal = m_pStreamHeader->GetPropertyBuffer("OpaqueData",pBuffer);
+
+ if (SUCCEEDED(retVal))
+ {
+ m_pAudioConfig = NULL;
+ m_ulAudioConfigSize = pBuffer->GetSize();
+ if (m_ulAudioConfigSize)
+ {
+ pBuf = pBuffer->GetBuffer();
+ m_unAudioConfigType = eAACConfigADTS;
+ m_pAudioConfig = new UINT8[m_ulAudioConfigSize];
+ if (!m_pAudioConfig)
+ {
+ retVal = HXR_OUTOFMEMORY;
+ }
+ else
+ {
+ memcpy(m_pAudioConfig, pBuf, m_ulAudioConfigSize);
+ }
+ }
+ else
+ {
+ m_unAudioConfigType = 0;
+ }
+ }
+ HX_RELEASE(pBuffer);
+ return retVal;
+}
+
HX_RESULT MP4APayloadFormat::SetAssemblerHXHeader(IHXValues* pHeader)
{
ES_Descriptor ESDesc;
@@ -639,6 +683,7 @@
case PYID_X_HX_MP4_RAWAU:
case PYID_X_HX_QT_RAWAU:
case PYID_X_HX_AAC_GENERIC:
+ case PYID_X_HX_AAC_ADTS:
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
break;
@@ -799,6 +844,10 @@
retVal = CreateRawAUMediaPacket(pOutMediaPacket);
break;
+ case PYID_X_HX_AAC_ADTS:
+ retVal = CreateMediaPacketADTS(pOutMediaPacket);
+ break;
+
case PYID_MP4A_LATM:
if (m_OutMediaPacketQueue.IsEmpty())
{
@@ -992,6 +1041,36 @@
return pMediaPacket;
}
+CMediaPacket* MP4APayloadFormat::BuildMediaPacket(UINT8* pBuf, UINT32 ulSize,
+ ULONG32 ulTime,
+ ULONG32 ulFlags)
+{
+ CMediaPacket* pMediaPacket = NULL;
+
+ UINT32 ulAllocSize = ulSize;
+
+#ifdef _OVERALLOC_CODEC_DATA
+ ulAllocSize += _OVERALLOC_CODEC_DATA;
+#endif
+
+ UINT8* pData = new UINT8 [ulAllocSize];
+
+ if (pData)
+ {
+ memcpy(pData, pBuf, ulSize); /* Flawfinder: ignore */
+
+ ulFlags &= (~MDPCKT_USES_IHXBUFFER_FLAG);
+ pMediaPacket = new CMediaPacket(pData,
+ pData,
+ ulAllocSize,
+ ulSize,
+ ulTime,
+ ulFlags,
+ NULL);
+ }
+ return pMediaPacket;
+}
+
STDMETHODIMP
MP4APayloadFormat::Flush()
{
@@ -1051,3 +1130,121 @@
return ulTime;
}
+
+HX_RESULT MP4APayloadFormat::CreateMediaPacketADTS(CMediaPacket* &pOutMediaPacket)
+{
+ CMediaPacket* pMediaPacket;
+ IHXPacket* pPacket = NULL;
+ HX_RESULT retVal = HXR_OK;
+
+ if (m_InputPackets.IsEmpty())
+ {
+ if (m_bFlushed)
+ {
+ // We have used up all available input
+ retVal = HXR_STREAM_DONE;
+ }
+ else
+ {
+ // We don't have enough input
+ // data to produce a packet
+ retVal = HXR_INCOMPLETE;
+ }
+ }
+ else
+ {
+ ULONG32 ulFlags = 0;
+ IHXBuffer* pBuffer = NULL;
+ pPacket = (IHXPacket*) m_InputPackets.RemoveHead();
+
+ if (!pPacket->IsLost())
+ {
+ pBuffer = pPacket->GetBuffer();
+
+ if (pBuffer)
+ {
+ if (m_bPriorLoss)
+ {
+ ulFlags |= MDPCKT_FOLLOWS_LOSS_FLAG;
+ m_bPriorLoss = FALSE;
+ }
+
+ // ADTS AUs can be aggregated into one packets
+ // we'll extract one AU here
+ UINT8* pAU = pBuffer->GetBuffer() + m_ulADTSCurrentPacketOffset;
+ UINT32 ulSize = pBuffer->GetSize() - m_ulADTSCurrentPacketOffset;
+
+ if (pAU[0] != 0xFF || (pAU[1] & 0xF0) != 0xF0 || ulSize < 7)
+ {
+ //error, treat the packet as lost
+ m_bPriorLoss = TRUE;
+ retVal = HXR_INCOMPLETE;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+
+ UINT32 ulProtectionAbsent = pAU[1]& 1;
+ UINT32 ulFrameLength = ((pAU[3]&0x3) << 11) + (pAU[4] << 3) + (pAU[5] >> 5);
+
+ if (ulFrameLength > ulSize)
+ {
+ //error, treat the packet as lost
+ m_bPriorLoss = TRUE;
+ retVal = HXR_INCOMPLETE;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+ //skp ADTS header
+ UINT32 ulOffset = ulProtectionAbsent ? 7 : 9;
+ pMediaPacket = BuildMediaPacket(pAU + ulOffset, ulFrameLength - ulOffset,
+ GetPacketTime(pPacket),
+ ulFlags);
+
+ if (ulFrameLength < ulSize)
+ {
+ //there is another AU in the buffer, put the packet back on the list
+ m_ulADTSCurrentPacketOffset += ulFrameLength;
+ HX_ADDREF(pPacket);
+ m_InputPackets.AddHead(pPacket);
+ }
+ else
+ {
+ //we are done with this packet
+ m_ulADTSCurrentPacketOffset = 0;
+ }
+ }
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+ retVal = HXR_OUTOFMEMORY;
+ if (pMediaPacket)
+ {
+ pOutMediaPacket = pMediaPacket;
+ retVal = HXR_OK;
+ }
+ }
+
+ pBuffer->Release();
+ }
+ else
+ {
+ m_bPriorLoss = TRUE;
+ retVal = HXR_INCOMPLETE;
+ }
+
+ pPacket->Release();
+ }
+ else
+ {
+ m_bPriorLoss = TRUE;
+ retVal = HXR_INCOMPLETE;
+ }
+ }
+
+ return retVal;
+}
+
+
Index: payload/pub/mp4apyld.h
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/pub/mp4apyld.h,v
retrieving revision 1.7.16.1
diff -u -r1.7.16.1 mp4apyld.h
--- payload/pub/mp4apyld.h 4 Jul 2008 07:15:23 -0000 1.7.16.1
+++ payload/pub/mp4apyld.h 29 Jul 2010 09:32:19 -0000
@@ -103,11 +103,12 @@
PYID_MPEG4_SIMPLE_A2,
PYID_MP4A_LATM,
PYID_X_HX_AAC_GENERIC,
+ PYID_X_HX_AAC_ADTS,
PYID_X_HX_3GPP_QCELP
} PayloadID;
inline HX_RESULT CreateRawAUMediaPacket(CMediaPacket* &pOutMediaPacket);
-
+ inline HX_RESULT CreateMediaPacketADTS(CMediaPacket* &pOutMediaPacket);
inline HX_RESULT SetPacketizerHeader(IHXValues* pHeader);
inline HX_RESULT SetAssemblerHeader(IHXValues* pHeader);
@@ -115,7 +116,7 @@
HX_RESULT SetAssemblerLATMHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerAACGenericHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerQCELPHeader(IHXValues* pHeader);
-
+ HX_RESULT SetAssemblerAACADTSHeader(IHXValues* pHeader);
HX_RESULT SetAssemblerLATMConfig(IHXValues* pHeader);
HX_RESULT OnFrame(ULONG32 ulTime,
const UINT8* pData,
@@ -133,6 +134,10 @@
inline CMediaPacket* BuildMediaPacket(IHXBuffer* pBuffer,
ULONG32 ulTime,
ULONG32 ulFlags);
+ inline CMediaPacket* BuildMediaPacket(UINT8* pBuf,
+ UINT32 ulSize,
+ ULONG32 ulTime,
+ ULONG32 ulFlags);
inline ULONG32 GetPacketTime(IHXPacket* pPacket);
void FlushPackets(ULONG32 ulCount);
@@ -153,6 +158,7 @@
MP4LATMDepack* m_pLATMDepack;
#endif /* #if defined(HELIX_FEATURE_AUDIO_MPEG4_DEPACK_LATM) */
+ UINT32 m_ulADTSCurrentPacketOffset;
UINT8* m_pAudioConfig;
ULONG32 m_ulAudioConfigSize;
UINT8 m_unAudioConfigType;
-------------- next part --------------
Index: aviffpln.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/aviffpln.cpp,v
retrieving revision 1.6.2.8
diff -u -r1.6.2.8 aviffpln.cpp
--- aviffpln.cpp 17 Dec 2009 21:47:19 -0000 1.6.2.8
+++ aviffpln.cpp 29 Jul 2010 09:25:45 -0000
@@ -207,6 +207,8 @@
, m_pszAuthor(NULL)
, m_pszCopyright(NULL)
, m_state(AS_InitPending)
+ , m_uLastOffset(0)
+ , m_iStreamNum(-1)
{
g_nRefCount_avif++; // DLL Ref Counting
@@ -861,7 +863,6 @@
{
//HX_TRACE("CAVIFileFormat::RIFFFindChunkDone(""%lx, %lu)\n\tstate=%lu\n",
// status, len, m_state);
-
switch (m_state)
{
case AS_HDRLFind:
@@ -924,6 +925,50 @@
}
break;
+ case AS_FFREAD:
+ if (FAILED(status))
+ {
+ //Failed to find the chunk go back to original position
+ m_pGeneralReader->FileSeek(m_uLastOffset);
+ }
+ else
+ {
+ // Search for first frame for the choosen stream
+ UINT32 ulChunkId = m_pGeneralReader->GetChunkType();
+ UINT16 StreamId = ((char) (ulChunkId >> 24) - '0')*10 + ((char) (ulChunkId >> 16) - '0');
+ if (StreamId == m_iStreamNum)
+ {
+ //Found the first frame, Read it and set it as opaque data
+ m_pGeneralReader->Read(m_pGeneralReader->GetChunkRawSize());
+ }
+ else
+ {
+ m_pGeneralReader->FindNextChunk();
+ }
+ }
+ break;
+ case AS_FFFRAME:
+ if (FAILED(status))
+ {
+ // Failed to find movi, go back to original position
+ m_state = AS_FFREAD;
+ m_pGeneralReader->FileSeek(m_uLastOffset);
+ }
+ else
+ {
+ if (m_pGeneralReader->GetChunkType() == AVI_LIST_OBJECT &&
+ m_pGeneralReader->GetListType() == AVI_MOVI_TYPE)
+ {
+ m_pGeneralReader->Descend();
+ }
+ else
+ {
+ m_state = AS_FFFRAME;
+ m_pGeneralReader->FindChunk(AVI_LIST_OBJECT, TRUE);
+ }
+
+ }
+ break;
case AS_STRLScan:
if (FAILED(status))
@@ -1053,6 +1098,20 @@
m_pGeneralReader->FindChunk(AVI_AVIH_OBJECT, TRUE);
}
break;
+ case AS_FFFRAME:
+ if ( status != HXR_OK )
+ {
+ // Failed to descend into movi, goto original position
+ m_state = AS_FFREAD;
+ m_pGeneralReader->FileSeek(m_uLastOffset);
+ }
+ else
+ {
+ //Found movi chunk, now fetch the first frame of the required stream
+ m_state = AS_FFREAD;
+ m_pGeneralReader->FindNextChunk();
+ }
+ break;
case AS_STRLDescend:
if ( status != HXR_OK )
{
@@ -1144,7 +1203,6 @@
{
//HX_TRACE("CAVIFileFormat::RIFFReadDone(%lx)\n\tstate=%lu\n", status, m_state);
HX_ASSERT(SUCCEEDED(status));
-
if (m_state < AS_AVIHRead ||
m_state > AS_INFORead)
{
@@ -1204,7 +1262,14 @@
{
CAVIStream* pStream = (CAVIStream*) m_streamArray[m_usStreamTarget -1];
HX_ASSERT(pStream);
- pStream->SetFormat(pBuffer);
+ if(pStream->SetFormat(pBuffer) == HXR_REQUEST_FIRST_FRAME)
+ {
+ m_uLastOffset = m_pGeneralReader->GetCurrentFileOffset();
+ m_iStreamNum = m_usStreamTarget -1;
+ m_state = AS_FFFRAME;
+ m_pGeneralReader->FindChunk(AVI_LIST_OBJECT, TRUE);
+ return HXR_OK;
+ }
}
break;
case AVI_STRD_CHUNK:
@@ -1215,7 +1280,6 @@
}
break;
}
-
m_state = AS_STRLScan;
m_pGeneralReader->FindNextChunk();
break;
@@ -1226,6 +1290,16 @@
m_state = AS_INFOScan;
m_pGeneralReader->FindNextChunk();
break;
+ case AS_FFREAD:
+ {
+ // We have read the first frame, set that to the stream as opaque data
+ CAVIStream* pStream = (CAVIStream*) m_streamArray[m_iStreamNum];
+ HX_ASSERT(pStream);
+ pStream->SetOpaque(pBuffer);
+ // Now seek back to from where we have started
+ m_pGeneralReader->FileSeek(m_uLastOffset);
+ }
+ break;
default:
HX_ASSERT(FALSE);
@@ -1311,9 +1385,18 @@
CAVIFileFormat::RIFFSeekDone(HX_RESULT status)
{
//HX_TRACE("CAVIFileFormat::RIFFSeekDone(%lx)\n\tstate=%lu\n", status, m_state);
- HX_ASSERT(FALSE);
-
- return HXR_UNEXPECTED;
+ if(m_state == AS_FFREAD)
+ {
+ // We have reached original positon after finding first frame
+ // Now continue from where we have left
+ m_state = AS_STRLScan;
+ m_pGeneralReader->FindNextChunk();
+ }
+ else
+ {
+ HX_ASSERT(FALSE);
+ }
+ return HXR_OK;
}
STDMETHODIMP
Index: avistrm.cpp
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/avistrm.cpp,v
retrieving revision 1.10.2.15.6.1
diff -u -r1.10.2.15.6.1 avistrm.cpp
--- avistrm.cpp 22 Jun 2010 06:46:14 -0000 1.10.2.15.6.1
+++ avistrm.cpp 29 Jul 2010 09:25:47 -0000
@@ -203,6 +203,7 @@
#define WAVE_FORMAT_PHILIPS_LPCBB 0x0098 /* Philips Speech Processing */
#define WAVE_FORMAT_PACKED 0x0099 /* Studer Professional Audio AG */
#define WAVE_FORMAT_MALDEN_PHONYTALK 0x00A0 /* Malden Electronics Ltd. */
+#define WAVE_FORMAT_AAC 0x00FF /* ADTS AAC*/
#define WAVE_FORMAT_RHETOREX_ADPCM 0x0100 /* Rhetorex Inc. */
#define WAVE_FORMAT_IRAT 0x0101 /* BeCubed Software Inc. */
#define WAVE_FORMAT_VIVO_G723 0x0111 /* Vivo Software */
@@ -328,6 +329,7 @@
, m_bMp3FirstPacket(TRUE)
, m_LastPacketSize(0xFFFFFFFF)
, m_bVariablePKtSize(FALSE)
+ , m_pOpaqueBuffer(NULL)
{
HX_ASSERT_VALID_PTR(m_pOuter);
HX_ASSERT_VALID_PTR(m_pContext);
@@ -352,6 +354,7 @@
//
CAVIStream::~CAVIStream()
{
+ HX_RELEASE(m_pOpaqueBuffer);
//HX_TRACE("CAVIFileFormat::CAVIStream::~CAVIStream()\n");
/* HX_RELEASE(m_pReader);
HX_DELETE(m_pFormat);
@@ -427,7 +430,7 @@
{
//HX_TRACE("CAVIFileFormat::CAVIStream::SetFormat()\n");
HX_ASSERT(pFormat);
- HX_RESULT result = HXR_FAIL;
+ HX_RESULT result = HXR_OK;
UCHAR* buf;
ULONG32 len;
@@ -523,13 +525,17 @@
bi->usSize = 0;
}
bi->usSize = LE16_TO_HOST(bi->usSize);
-
+ //For ADTS AAC we need to send first frame as opaque data to decoder
+ if(bi->usFormatTag == WAVE_FORMAT_AAC)
+ {
+ result = HXR_REQUEST_FIRST_FRAME;
+ }
break;
}
}
}
- return HXR_OK;
+ return result;
}
/////////////////////////////////////////////////////////////////////////
@@ -550,7 +556,9 @@
HX_RESULT CAVIStream::SetOpaque(IHXBuffer* pOpaque)
{
//HX_TRACE("CAVIFileFormat::CAVIStream::SetOpaque()\n");
- return HXR_NOTIMPL;
+ m_pOpaqueBuffer = pOpaque;
+ HX_ADDREF(m_pOpaqueBuffer);
+ return HXR_OK;
}
/////////////////////////////////////////////////////////////////////////
@@ -888,6 +896,12 @@
}
}
break;
+ case WAVE_FORMAT_AAC:
+ {
+ pMimeType = "audio/X-HX-AAC-ADTS";
+ }
+ break;
default:
{
pMimeType = szMimeTypeACM;
@@ -1010,9 +1024,17 @@
}
// Set opaque data:
- if ( pOpaqueData )
+ if (m_pOpaqueBuffer || pOpaqueData)
{
- pHeader->SetPropertyBuffer ("OpaqueData", pOpaqueData);
+ if(m_pOpaqueBuffer)
+ {
+ pHeader->SetPropertyBuffer ("OpaqueData", m_pOpaqueBuffer);
+ HX_RELEASE(m_pOpaqueBuffer);
+ }
+ else
+ {
+ pHeader->SetPropertyBuffer ("OpaqueData", pOpaqueData);
+ }
}
// Stream name and MIME type:
Index: pub/aviffpln.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/aviffpln.h,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 aviffpln.h
--- pub/aviffpln.h 3 Dec 2008 01:35:00 -0000 1.5.2.2
+++ pub/aviffpln.h 29 Jul 2010 09:25:47 -0000
@@ -321,6 +320,8 @@
char* m_pszCopyright;
const char* m_pURL;
+ UINT32 m_uLastOffset;
+ INT32 m_iStreamNum;
#pragma pack(1)
typedef struct tag_MainHeader
@@ -364,6 +365,8 @@
, AS_STRLRead
, AS_STRLAscend
, AS_HDRLAscend
+ , AS_FFFRAME
+ , AS_FFREAD
, AS_INFOFind
, AS_INFODescend
, AS_INFOScan
Index: pub/avistrm.h
===================================================================
RCS file: /cvsroot/datatype/avi/fileformat/pub/avistrm.h,v
retrieving revision 1.7.2.6.8.1
diff -u -r1.7.2.6.8.1 avistrm.h
--- pub/avistrm.h 22 Jun 2010 06:46:15 -0000 1.7.2.6.8.1
+++ pub/avistrm.h 29 Jul 2010 09:25:47 -0000
@@ -314,7 +314,7 @@
IUnknown* m_pContext;
IHXCommonClassFactory* m_pCommonClassFactory;
-
+ IHXBuffer* m_pOpaqueBuffer;
private:
INT32 m_lRefCount;
UINT32 m_LastPacketSize;
-------------- next part --------------
Index: hxresult.h
===================================================================
RCS file: /cvsroot/common/include/hxresult.h,v
retrieving revision 1.51.2.3
diff -u -r1.51.2.3 hxresult.h
--- hxresult.h 23 Jul 2009 20:36:45 -0000 1.51.2.3
+++ hxresult.h 29 Jul 2010 09:37:20 -0000
@@ -177,6 +177,7 @@
#define HXR_DEVVIDEO_RESOURCE_LOST MAKE_HX_RESULT(1,SS_GLO,39) // 80040027
#define HXR_DEVVIDEO_RESOURCE_RESTORED MAKE_HX_RESULT(1,SS_GLO,40) // 80040028
#define HXR_NOT_SUPPORTED_FOR_LINEAR_FILE_SYSTEMS MAKE_HX_RESULT(1,SS_GLO,41) // 80040029
+#define HXR_REQUEST_FIRST_FRAME MAKE_HX_RESULT(1,SS_GLO,41) // 80040030
#define HXR_BUFFERING MAKE_HX_RESULT(0,SS_NET,0) // 00040040
#define HXR_PAUSED MAKE_HX_RESULT(0,SS_NET,1) // 00040041
From sfu at real.com Thu Jul 29 05:12:06 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 29 11:45:25 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C514F6A.9090609@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com> <4C355263.6080304@real.com> <4C355FA5.7080200@real.com> <4C3C16E1.2060808@real.com> <4C3CC3F6.30904@real.com>
<4C46A465.9010101@real.com> <4C46F34F.90503@real.com>
<4C514F6A.9090609@real.com>
Message-ID: <4C517E26.4010800@real.com>
This looks good.
The new logic is generic enough so that it should be able to handle
other payload types that may need to read first chunk data to collect
enough information to initialize. We've actually had a similar problem
regarding MP3 -- the MP3 samples per frame value needs to be set before
the playback starts (because a seek can be issued before play and the
samples per frame value is needed to calculate seek position). I think
the logic here can be used to solve that problem too (up to the dev of
that bug to have a second look)
fxd
Gurpreet Ahluwalia wrote:
> Hi Sheldon,
>
> I have made changes as per your suggestions.
> Now we send the first audio frame in case of aac as opaque data.
> First frame is fetched for cases when avi stream setformat function
> returns HXR_REQUEST_FIRST_FRAME.
> This is a new return value added to hxresult.h.
> After setting format in avi stream, avi fileformat will fetch first
> frame depending on the result.
> For fetching first frame.
> We save the current file offset, state and stream number for which we
> need the first frame.
> We then find movi list chunk and then descend into it.
> Read the data for the stream we are looking for.
> If we find the frame then we call SetOpaque on avistream.
> then we move back original offset and state.
>
> Changes in mp4ff are merge from head.
>
> Best Regards,
> Gurpreet
>
>
>
> On 7/21/2010 6:47 PM, Sheldon Fu wrote:
>
>> I don't believe this is a good idea. Decoder needs enough information in
>> Init call to decide whether it can handle the stream or not. Without
>> setup info, it can not make that judgment. It will present problems when
>> there are multiple decoders (say a hw one and a software backup).
>>
>> Also with the default dummy value approach, you will open and close and
>> reopen the audio device when the audio format is switched from default
>> to actual one -- adding delay to the play start and resource drain.
>>
>> The AVI FF should be changed so that it pre-read the first ADTS frame
>> and use that as the decoder setup data (OpaqueData) as other FF does
>> (e.g. the raw .aac ff when the data is in adts frame format).
>>
>> fxd
>>
>> Gurpreet Ahluwalia wrote:
>>
>>
>>> Hi,
>>> I think these changes are for cases when we don't have Decoder Specific
>>> Object in fileformat(i.e avi ff)
>>>
>>> There is already change done in aac decoder to check for config.
>>> If its null then default values are picked.
>>> Correct configuration is later read from decoder when it is fed few frames.
>>> I have attached the earlier diff for reference.
>>>
>>> If these changes are considered to be safe then I would request that
>>> these changes to be merged into atlas 3411 also.
>>>
>>> Best Regards,
>>> Gurpreet
>>>
>>>
>>> On 7/14/2010 1:22 AM, Sheldon Fu wrote:
>>>
>>>
>>>
>>>> Care to explain why the difference and 'can not use'?
>>>>
>>>> I looked at the change you made for AVIADTS. It seems that you are
>>>> passing the ADTS frames directly to the decoder -- no stripping of th
>>>> ADTS headers and without any codec config data. I don't think this will
>>>> work with the default raac software decoder
>>>> (datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
>>>> config data is null and even that passes, it will expect raw AU unit as
>>>> input, instead of ADTS frame. Have you tried your solution on a generic
>>>> Linux build?
>>>>
>>>> fxd
>>>>
>>>> Sushant Garg wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> We can not use code written for AVIADTS, therefore merged my changes to
>>>>> Head too.
>>>>>
>>>>> Regards,
>>>>> Sushant
>>>>>
>>>>> Sheldon Fu wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>>>>>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>>>>>> carries ADTS frames as packets and first frame as OapqueData. What is
>>>>>> different for AVIADTS? There might be a chance these two can be merged
>>>>>> as one.
>>>>>>
>>>>>> And if AVIADTS is different and needed, this should go into Head too.
>>>>>>
>>>>>> fxd
>>>>>>
>>>>>> Sushant Garg wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks Jamie,
>>>>>>>
>>>>>>> Changes checked in to Atlas3410& Atlas310.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sushant
>>>>>>>
>>>>>>> Jamie Gordon wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> ok
>>>>>>>>
>>>>>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> *Project: RealPlayer for Netbook*
>>>>>>>>>
>>>>>>>>> *Synopsis:*
>>>>>>>>>
>>>>>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>>>>>
>>>>>>>>> * *
>>>>>>>>>
>>>>>>>>> *Overview:*
>>>>>>>>>
>>>>>>>>> Added support to play AVI ADTS files.
>>>>>>>>>
>>>>>>>>> Created a new mime type for such files& handle their parsing in mp4
>>>>>>>>> renderer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Files Modified:
>>>>>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>>>>>
>>>>>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>>>>>
>>>>>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>>>>>
>>>>>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>>>>>
>>>>>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Files Added: *
>>>>>>>>>
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Platforms and Profiles Affected:
>>>>>>>>> *Linux
>>>>>>>>>
>>>>>>>>> *Distribution Libraries Affected:*
>>>>>>>>> None.
>>>>>>>>>
>>>>>>>>> *Platforms and Profiles Build Verified:
>>>>>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>>>>>> *Profile:* helix-client-moblin
>>>>>>>>> *Target:* mediasinkplayer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Branch:*
>>>>>>>>> Atlas3_4_10, Atlas310
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Attachment:*
>>>>>>>>>
>>>>>>>>> diff.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks& Regards,
>>>>>>>>>
>>>>>>>>> Sushant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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-g.manikanda at nokia.com Thu Jul 29 06:19:04 2010
From: ext-g.manikanda at nokia.com (ext-g.manikanda@nokia.com)
Date: Thu Jul 29 12:54:20 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur
when trying to resume the playback in multiple instances of video
player
In-Reply-To: <4C4DCDDF.3040800@real.com>
References: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
<4C4DCDDF.3040800@real.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE284F941770@NOK-EUMSG-02.mgdnok.nokia.com>
Hi Sheldon,
Incorporated review comments ,Please find modified diffs attached.
Chages are:
- Allocating global pointers in libMatroska library at loadtime and deallocating all allocated global pointers library at unload time .
- Removed all reference count related changes .
Regards,
Manikandan.G
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Monday, July 26, 2010 11:33 PM
To: Manikanda G (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; Mishra Sudhir.1 (EXT-Sasken/Dallas)
Subject: Re: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur when trying to resume the playback in multiple instances of video player
+HXBOOL MatroskaSegment::CanAllocateGlobalContext()
+{
+ HXBOOL uCanAllocate =EbmlGlobal_Context_Ref?FALSE:TRUE;
+ InterlockedIncrement(&EbmlGlobal_Context_Ref);
+ return uCanAllocate;
+}
This is not thread-safe. Two threads can both hit the first line at the same time and they will both have uCanAllocate to be true. You need to use the return value of InterlockedIncrement() to set uCanAllocate (the thread that increase the counter from 0 to 1 is the one that is 'earlier' and the one supposed to do initialization) like what you do in CanRelease.
Further more, even if the above is fixed, it is still not safe because the thread that is deemed 'not to allocate global' may actually move ahead while the 'allocate global' thread suspended right after or in CanAllocateGlobalContext call. Then the code further done will run without globals to be initialized.
The correct logic has to: 1. pick a thread as 'first' to initialize the globals. 2. other thread(s) not picked as first will have to WAIT until the globals are initialized by the first thread.
This is better solved by a mutex rather than atomic counter I think.
If Symbian support initialization of static object in shared lib, you can also have a global object variable defined and in its constructor to initialize the globals --- basically initializing globals once at DLL load time.
fxd
ext-g.manikanda@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-g.manikanda@nokia.com
>
>
> Reviewed by: rajesh.rathinasamy@nokia.com
> , girish.shetty@nokia.com
>
>
> Date: 07 / 23 /2010
>
> Project:
>
> ErrorId: ou1cimx1#477224
>
> Synopsis: Fusion: Crashes occur when trying to resume the playback in
> multiple instances of video player
>
> Overview: While playing first instance of MKV Videoplayback, MKV
> Fileformat plugin is allocating global pointers in
> MatroskaSegment::Init() (for example EbmlGlobal_ContextList global
> Pointer in InitGlobalContext() and EbmlCrc32::InitCallback()
> functions. Playing second instance of MKV file, All global pointers
> are reallocated again (First instance's global pointer's address were
> lost).These global pointers were shared across between two different
> instance of mkv playbak. When First instance closes playback
> MatroskaSegment::Release() is deleting global pointers , Hence other
> instance panics while resume or closing playback.
>
> Solution: Adding global variable reference count and make decision
> for allocating and deallocating global pointers across different mkv
> instances.
>
> Modified files:
>
> \datatype\mkv\libmatroska\Matroska.h
> \datatype\mkv\libmatroska\Matroska.cpp
>
>
> Image size and heap use impact: None
>
> Module Release testing (STIF): Done
>
> TNE testing: TNE testing for MKV fileformat done.
>
> Test case(s) added: None
>
> Memory leak check performed: NA
>
> Branch(es) : cays 210, Brizo 420 and Head.
>
> Diff: Attached
>
>
>
-------------- next part --------------
Index: Matroska.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/Matroska.cpp,v
retrieving revision 1.1.1.1.2.10
diff -u -w -r1.1.1.1.2.10 Matroska.cpp
--- Matroska.cpp 16 Jul 2010 16:38:28 -0000 1.1.1.1.2.10
+++ Matroska.cpp 29 Jul 2010 10:07:00 -0000
@@ -39,6 +39,8 @@
#define TIMECODESCALE 1000000
+MatrokaSegmentGlobalInit EBMLGlobal_Init;
+
//MatroskaSegment
MatroskaSegment::MatroskaSegment( EbmlStream* & estream )
:m_pSegment(NULL)
@@ -1179,33 +1181,7 @@
MatroskaSegment* MatroskaSegment::Init(IOCallback& io)
{
- InitGlobalContext();
- EbmlCrc32::InitCallback();
- EbmlDummy::InitCallback();
- EbmlHead::InitCallback();
- EVersion::InitCallback();
- EbmlVoid::InitCallback();
- KaxAttachments::InitCallback();
- KaxAttached::InitCallback();
- KaxBlock::InitCallback();
- KaxReferenceBlock::InitCallback();
- KaxChapters::InitCallback();
- KaxCluster::InitCallback();
- KaxClusterTimecode::InitCallback();
- KaxContentEncodings::InitCallback();
- KaxCues::InitCallback();
- KaxCuePoint::InitCallback();
- KaxInfo::InitCallback();
- KaxChapterTranslate::InitCallback();
- KaxSeekHead::InitCallback();
- KaxSegment::InitCallback();
- KaxTag::InitCallback();
- KaxTagMultiComment::InitCallback();
- KaxTags::InitCallback();
- KaxTrackAudio::InitCallback();
- KaxTrackTranslate::InitCallback();
- KaxTracks::InitCallback();
- KaxTrackVideo::InitCallback();
+//Allocating memory for Global pointers in DLL LoadTime MatrokaSegmentGlobalInit()
EbmlStream *es = new EbmlStream(io);
if(es)
@@ -1220,38 +1196,6 @@
return NULL;
}
-void MatroskaSegment::Release()
-{
- DeleteGlobalContext();
- EbmlCrc32::DeleteCallback();
- EbmlDummy::DeleteCallback();
- EbmlHead::DeleteCallback();
- EVersion::DeleteCallback();
- EbmlVoid::DeleteCallback();
- KaxAttachments::DeleteCallback();
- KaxAttached::DeleteCallback();
- KaxBlock::DeleteCallback();
- KaxReferenceBlock::DeleteCallback();
- KaxChapters::DeleteCallback();
- KaxCluster::DeleteCallback();
- KaxClusterTimecode::DeleteCallback();
- KaxContentEncodings::DeleteCallback();
- KaxCues::DeleteCallback();
- KaxCuePoint::DeleteCallback();
- KaxInfo::DeleteCallback();
- KaxChapterTranslate::DeleteCallback();
- KaxSeekHead::DeleteCallback();
- KaxSegment::DeleteCallback();
- KaxTag::DeleteCallback();
- KaxTagMultiComment::DeleteCallback();
- KaxTags::DeleteCallback();
- KaxTrackAudio::DeleteCallback();
- KaxTrackTranslate::DeleteCallback();
- KaxTracks::DeleteCallback();
- KaxTrackVideo::DeleteCallback();
-}
-
-
HX_RESULT MatroskaSegment::VerifyHeader()
{
HXBOOL retVal = HXR_OK;
@@ -1906,3 +1850,69 @@
return HXR_OK;
}
+MatrokaSegmentGlobalInit::MatrokaSegmentGlobalInit()
+{
+ //Allocating memory for Global pointers in DLL LoadTime , assumed following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ InitGlobalContext();
+ EbmlCrc32::InitCallback();
+ EbmlDummy::InitCallback();
+ EbmlHead::InitCallback();
+ EVersion::InitCallback();
+ EbmlVoid::InitCallback();
+ KaxAttachments::InitCallback();
+ KaxAttached::InitCallback();
+ KaxBlock::InitCallback();
+ KaxReferenceBlock::InitCallback();
+ KaxChapters::InitCallback();
+ KaxCluster::InitCallback();
+ KaxClusterTimecode::InitCallback();
+ KaxContentEncodings::InitCallback();
+ KaxCues::InitCallback();
+ KaxCuePoint::InitCallback();
+ KaxInfo::InitCallback();
+ KaxChapterTranslate::InitCallback();
+ KaxSeekHead::InitCallback();
+ KaxSegment::InitCallback();
+ KaxTag::InitCallback();
+ KaxTagMultiComment::InitCallback();
+ KaxTags::InitCallback();
+ KaxTrackAudio::InitCallback();
+ KaxTrackTranslate::InitCallback();
+ KaxTracks::InitCallback();
+ KaxTrackVideo::InitCallback();
+
+}
+
+MatrokaSegmentGlobalInit::~MatrokaSegmentGlobalInit()
+{
+ //Releasing memory for global pointers, assumed Following global pointers shall only contain read only data
+ //as it could be shared by multiple instance of MKVFileFormat.
+ DeleteGlobalContext();
+ EbmlCrc32::DeleteCallback();
+ EbmlDummy::DeleteCallback();
+ EbmlHead::DeleteCallback();
+ EVersion::DeleteCallback();
+ EbmlVoid::DeleteCallback();
+ KaxAttachments::DeleteCallback();
+ KaxAttached::DeleteCallback();
+ KaxBlock::DeleteCallback();
+ KaxReferenceBlock::DeleteCallback();
+ KaxChapters::DeleteCallback();
+ KaxCluster::DeleteCallback();
+ KaxClusterTimecode::DeleteCallback();
+ KaxContentEncodings::DeleteCallback();
+ KaxCues::DeleteCallback();
+ KaxCuePoint::DeleteCallback();
+ KaxInfo::DeleteCallback();
+ KaxChapterTranslate::DeleteCallback();
+ KaxSeekHead::DeleteCallback();
+ KaxSegment::DeleteCallback();
+ KaxTag::DeleteCallback();
+ KaxTagMultiComment::DeleteCallback();
+ KaxTags::DeleteCallback();
+ KaxTrackAudio::DeleteCallback();
+ KaxTrackTranslate::DeleteCallback();
+ KaxTracks::DeleteCallback();
+ KaxTrackVideo::DeleteCallback();
+}
-------------- next part --------------
Index: MatroskaExports.cpp
===================================================================
RCS file: /cvsroot/xiph/matroskalib/MatroskaExports.cpp,v
retrieving revision 1.1.1.1.2.3
diff -u -w -r1.1.1.1.2.3 MatroskaExports.cpp
--- MatroskaExports.cpp 27 Apr 2010 05:22:38 -0000 1.1.1.1.2.3
+++ MatroskaExports.cpp 29 Jul 2010 10:04:10 -0000
@@ -18,7 +18,7 @@
if(m_pSeg)
{
delete m_pSeg;
- MatroskaSegment::Release();
+
}
}
-------------- next part --------------
Index: 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
--- Matroska.h 6 Nov 2009 19:59:16 -0000 1.1.1.1.2.1
+++ Matroska.h 29 Jul 2010 07:43:17 -0000
@@ -65,8 +65,6 @@
HX_RESULT VerifyHeader();
static MatroskaSegment* Init(IOCallback& io);
- static void Release();
-
MKVTrack* FindTrack(UINT32 tkNumber);
MKVTrack* GetTrack(UINT32 trkNum);
int FindTrackIndex(UINT32 tkNumber);
@@ -84,4 +82,12 @@
HX_RESULT ParseCues( KaxCues *pCues, EbmlElement* & pElementLevel2, int& level );
HX_RESULT ParseTags( KaxTags *tags);
};
+class MatrokaSegmentGlobalInit
+{
+
+public:
+
+ MatrokaSegmentGlobalInit();
+ ~MatrokaSegmentGlobalInit();
+};
#endif
From sfu at real.com Thu Jul 29 06:54:31 2010
From: sfu at real.com (Sheldon Fu)
Date: Thu Jul 29 13:27:51 2010
Subject: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur
when trying to resume the playback in multiple instances of video
player
In-Reply-To: <20D73E2631F7914F868646E119DEC1CE284F941770@NOK-EUMSG-02.mgdnok.nokia.com>
References: <20D73E2631F7914F868646E119DEC1CE284F818815@NOK-EUMSG-02.mgdnok.nokia.com>
<4C4DCDDF.3040800@real.com>
<20D73E2631F7914F868646E119DEC1CE284F941770@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <4C519627.7030600@real.com>
Looks good.
fxd
ext-g.manikanda@nokia.com wrote:
> Hi Sheldon,
>
> Incorporated review comments ,Please find modified diffs attached.
>
> Chages are:
> - Allocating global pointers in libMatroska library at loadtime and deallocating all allocated global pointers library at unload time .
> - Removed all reference count related changes .
>
> Regards,
> Manikandan.G
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Monday, July 26, 2010 11:33 PM
> To: Manikanda G (EXT-Sasken/Bangalore)
> Cc: datatype-dev@helixcommunity.org; Mishra Sudhir.1 (EXT-Sasken/Dallas)
> Subject: Re: [datatype-dev] URGENT CR: ou1cimx1#477224 Fusion: Crashes occur when trying to resume the playback in multiple instances of video player
>
> +HXBOOL MatroskaSegment::CanAllocateGlobalContext()
> +{
> + HXBOOL uCanAllocate =EbmlGlobal_Context_Ref?FALSE:TRUE;
> + InterlockedIncrement(&EbmlGlobal_Context_Ref);
> + return uCanAllocate;
> +}
>
> This is not thread-safe. Two threads can both hit the first line at the same time and they will both have uCanAllocate to be true. You need to use the return value of InterlockedIncrement() to set uCanAllocate (the thread that increase the counter from 0 to 1 is the one that is 'earlier' and the one supposed to do initialization) like what you do in CanRelease.
>
> Further more, even if the above is fixed, it is still not safe because the thread that is deemed 'not to allocate global' may actually move ahead while the 'allocate global' thread suspended right after or in CanAllocateGlobalContext call. Then the code further done will run without globals to be initialized.
>
> The correct logic has to: 1. pick a thread as 'first' to initialize the globals. 2. other thread(s) not picked as first will have to WAIT until the globals are initialized by the first thread.
>
> This is better solved by a mutex rather than atomic counter I think.
>
> If Symbian support initialization of static object in shared lib, you can also have a global object variable defined and in its constructor to initialize the globals --- basically initializing globals once at DLL load time.
>
> fxd
>
>
> ext-g.manikanda@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-g.manikanda@nokia.com
>>
>>
>> Reviewed by: rajesh.rathinasamy@nokia.com
>> , girish.shetty@nokia.com
>>
>>
>> Date: 07 / 23 /2010
>>
>> Project:
>>
>> ErrorId: ou1cimx1#477224
>>
>> Synopsis: Fusion: Crashes occur when trying to resume the playback in
>> multiple instances of video player
>>
>> Overview: While playing first instance of MKV Videoplayback, MKV
>> Fileformat plugin is allocating global pointers in
>> MatroskaSegment::Init() (for example EbmlGlobal_ContextList global
>> Pointer in InitGlobalContext() and EbmlCrc32::InitCallback()
>> functions. Playing second instance of MKV file, All global pointers
>> are reallocated again (First instance's global pointer's address were
>> lost).These global pointers were shared across between two different
>> instance of mkv playbak. When First instance closes playback
>> MatroskaSegment::Release() is deleting global pointers , Hence other
>> instance panics while resume or closing playback.
>>
>> Solution: Adding global variable reference count and make decision
>> for allocating and deallocating global pointers across different mkv
>> instances.
>>
>> Modified files:
>>
>> \datatype\mkv\libmatroska\Matroska.h
>> \datatype\mkv\libmatroska\Matroska.cpp
>>
>>
>> Image size and heap use impact: None
>>
>> Module Release testing (STIF): Done
>>
>> TNE testing: TNE testing for MKV fileformat done.
>>
>> Test case(s) added: None
>>
>> Memory leak check performed: NA
>>
>> Branch(es) : cays 210, Brizo 420 and Head.
>>
>> Diff: Attached
>>
>>
>>
>>
>
>
From ping at real.com Thu Jul 29 22:32:11 2010
From: ping at real.com (Henry Ping)
Date: Fri Jul 30 05:06:57 2010
Subject: [datatype-dev] CR: Fixed missing InitDone callback inside MP3 Meta
file format plugin
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507F903AFCF@SEAMBX.corp.real.com>
This causes DTDriver freezes(idling) while it's waiting for the InitDone() callback after calling InitFileFormat(). This issue is observed when DTDriver is used to generate thumbnail from an M3U file.
For Altas_3_1_0 and HEAD
Diffs:
Index: mp3mfpln.cpp
===================================================================
RCS file: /cvsroot/datatype/mp3/mp3metaff/mp3mfpln.cpp,v
retrieving revision 1.7.8.1
diff -u -u -w -4 -r1.7.8.1 mp3mfpln.cpp
--- mp3mfpln.cpp 13 May 2010 06:43:08 -0000 1.7.8.1
+++ mp3mfpln.cpp 30 Jul 2010 06:25:40 -0000
@@ -672,8 +672,12 @@
pGroupMgr->SetCurrentGroup(unPlaylistGroup);
}
HX_RELEASE(pGroupMgr);
}
+ else
+ {
+ m_pFFResponse->InitDone(HXR_FAIL);
+ }
return(HXR_OK);
}
Henry
From gahluwalia at real.com Thu Jul 29 23:31:01 2010
From: gahluwalia at real.com (Gurpreet)
Date: Fri Jul 30 06:06:15 2010
Subject: [datatype-dev] CN: Fix for bug 10321: : AAC codec in AVI container
can't be played successfully.
In-Reply-To: <4C517E26.4010800@real.com>
References: <4C330708.807@real.com> <4C336DD2.8040901@real.com> <4C355263.6080304@real.com> <4C355FA5.7080200@real.com> <4C3C16E1.2060808@real.com> <4C3CC3F6.30904@real.com>
<4C46A465.9010101@real.com> <4C46F34F.90503@real.com>
<4C514F6A.9090609@real.com> <4C517E26.4010800@real.com>
Message-ID: <4C527FB5.8030909@real.com>
Thanks Sheldon,
This is checked into atlas 3411.
Best Regards,
Gurpreet
On 7/29/2010 6:42 PM, Sheldon Fu wrote:
> This looks good.
>
> The new logic is generic enough so that it should be able to handle
> other payload types that may need to read first chunk data to collect
> enough information to initialize. We've actually had a similar problem
> regarding MP3 -- the MP3 samples per frame value needs to be set before
> the playback starts (because a seek can be issued before play and the
> samples per frame value is needed to calculate seek position). I think
> the logic here can be used to solve that problem too (up to the dev of
> that bug to have a second look)
>
> fxd
>
> Gurpreet Ahluwalia wrote:
>
>> Hi Sheldon,
>>
>> I have made changes as per your suggestions.
>> Now we send the first audio frame in case of aac as opaque data.
>> First frame is fetched for cases when avi stream setformat function
>> returns HXR_REQUEST_FIRST_FRAME.
>> This is a new return value added to hxresult.h.
>> After setting format in avi stream, avi fileformat will fetch first
>> frame depending on the result.
>> For fetching first frame.
>> We save the current file offset, state and stream number for which we
>> need the first frame.
>> We then find movi list chunk and then descend into it.
>> Read the data for the stream we are looking for.
>> If we find the frame then we call SetOpaque on avistream.
>> then we move back original offset and state.
>>
>> Changes in mp4ff are merge from head.
>>
>> Best Regards,
>> Gurpreet
>>
>>
>>
>> On 7/21/2010 6:47 PM, Sheldon Fu wrote:
>>
>>
>>> I don't believe this is a good idea. Decoder needs enough information in
>>> Init call to decide whether it can handle the stream or not. Without
>>> setup info, it can not make that judgment. It will present problems when
>>> there are multiple decoders (say a hw one and a software backup).
>>>
>>> Also with the default dummy value approach, you will open and close and
>>> reopen the audio device when the audio format is switched from default
>>> to actual one -- adding delay to the play start and resource drain.
>>>
>>> The AVI FF should be changed so that it pre-read the first ADTS frame
>>> and use that as the decoder setup data (OpaqueData) as other FF does
>>> (e.g. the raw .aac ff when the data is in adts frame format).
>>>
>>> fxd
>>>
>>> Gurpreet Ahluwalia wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> I think these changes are for cases when we don't have Decoder Specific
>>>> Object in fileformat(i.e avi ff)
>>>>
>>>> There is already change done in aac decoder to check for config.
>>>> If its null then default values are picked.
>>>> Correct configuration is later read from decoder when it is fed few frames.
>>>> I have attached the earlier diff for reference.
>>>>
>>>> If these changes are considered to be safe then I would request that
>>>> these changes to be merged into atlas 3411 also.
>>>>
>>>> Best Regards,
>>>> Gurpreet
>>>>
>>>>
>>>> On 7/14/2010 1:22 AM, Sheldon Fu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Care to explain why the difference and 'can not use'?
>>>>>
>>>>> I looked at the change you made for AVIADTS. It seems that you are
>>>>> passing the ADTS frames directly to the decoder -- no stripping of th
>>>>> ADTS headers and without any codec config data. I don't think this will
>>>>> work with the default raac software decoder
>>>>> (datatype/aac/fixpt/decoder). The decoder will fail InitDecoder if
>>>>> config data is null and even that passes, it will expect raw AU unit as
>>>>> input, instead of ADTS frame. Have you tried your solution on a generic
>>>>> Linux build?
>>>>>
>>>>> fxd
>>>>>
>>>>> Sushant Garg wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> We can not use code written for AVIADTS, therefore merged my changes to
>>>>>> Head too.
>>>>>>
>>>>>> Regards,
>>>>>> Sushant
>>>>>>
>>>>>> Sheldon Fu wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> What's the stream format of X-HX-AAC-AVIADTS? We already added
>>>>>>> X-HX-AAC-ADTS on Head for mpeg2ts http live streaming support. It
>>>>>>> carries ADTS frames as packets and first frame as OapqueData. What is
>>>>>>> different for AVIADTS? There might be a chance these two can be merged
>>>>>>> as one.
>>>>>>>
>>>>>>> And if AVIADTS is different and needed, this should go into Head too.
>>>>>>>
>>>>>>> fxd
>>>>>>>
>>>>>>> Sushant Garg wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Thanks Jamie,
>>>>>>>>
>>>>>>>> Changes checked in to Atlas3410& Atlas310.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sushant
>>>>>>>>
>>>>>>>> Jamie Gordon wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> ok
>>>>>>>>>
>>>>>>>>> On 7/6/2010 3:35 AM, Sushant Garg wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> *Project: RealPlayer for Netbook*
>>>>>>>>>>
>>>>>>>>>> *Synopsis:*
>>>>>>>>>>
>>>>>>>>>> Fix for bug 10321: : AAC codec in AVI container can't be played successfully.
>>>>>>>>>>
>>>>>>>>>> * *
>>>>>>>>>>
>>>>>>>>>> *Overview:*
>>>>>>>>>>
>>>>>>>>>> Added support to play AVI ADTS files.
>>>>>>>>>>
>>>>>>>>>> Created a new mime type for such files& handle their parsing in mp4
>>>>>>>>>> renderer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Files Modified:
>>>>>>>>>> */cvsroot/datatype/mp4/audio/renderer/mp4audio.cpp
>>>>>>>>>>
>>>>>>>>>> /cvsroot/datatype/mp4/audio/renderer/raacdecinfo.cpp
>>>>>>>>>>
>>>>>>>>>> /cvsroot/datatype/mp4/payload/mp4apyld.cpp
>>>>>>>>>>
>>>>>>>>>> /cvsroot/datatype/mp4/payload/pub/mp4apyld.h
>>>>>>>>>>
>>>>>>>>>> /cvsroot/datatype/avi/fileformat/avistrm.cpp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Files Added: *
>>>>>>>>>>
>>>>>>>>>> None
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Platforms and Profiles Affected:
>>>>>>>>>> *Linux
>>>>>>>>>>
>>>>>>>>>> *Distribution Libraries Affected:*
>>>>>>>>>> None.
>>>>>>>>>>
>>>>>>>>>> *Platforms and Profiles Build Verified:
>>>>>>>>>> Bif:* realplay_gtk_atlas_restricted_gold_1.2
>>>>>>>>>> *Profile:* helix-client-moblin
>>>>>>>>>> *Target:* mediasinkplayer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Branch:*
>>>>>>>>>> Atlas3_4_10, Atlas310
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Attachment:*
>>>>>>>>>>
>>>>>>>>>> diff.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks& Regards,
>>>>>>>>>>
>>>>>>>>>> Sushant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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 jgordon at real.com Fri Jul 30 09:56:13 2010
From: jgordon at real.com (Jamie Gordon)
Date: Fri Jul 30 16:30:54 2010
Subject: [datatype-dev] CR: Fixed missing InitDone callback inside MP3
Meta file format plugin
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44507F903AFCF@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507F903AFCF@SEAMBX.corp.real.com>
Message-ID: <4C53123D.2090304@real.com>
ok
On 7/29/2010 11:32 PM, Henry Ping wrote:
> This causes DTDriver freezes(idling) while it's waiting for the InitDone() callback after calling InitFileFormat(). This issue is observed when DTDriver is used to generate thumbnail from an M3U file.
>
> For Altas_3_1_0 and HEAD
>
> Diffs:
>
> Index: mp3mfpln.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/mp3/mp3metaff/mp3mfpln.cpp,v
> retrieving revision 1.7.8.1
> diff -u -u -w -4 -r1.7.8.1 mp3mfpln.cpp
> --- mp3mfpln.cpp 13 May 2010 06:43:08 -0000 1.7.8.1
> +++ mp3mfpln.cpp 30 Jul 2010 06:25:40 -0000
> @@ -672,8 +672,12 @@
> pGroupMgr->SetCurrentGroup(unPlaylistGroup);
> }
> HX_RELEASE(pGroupMgr);
> }
> + else
> + {
> + m_pFFResponse->InitDone(HXR_FAIL);
> + }
>
> return(HXR_OK);
> }
>
> Henry
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From ext-sanket.lopes at nokia.com Fri Jul 23 07:01:49 2010
From: ext-sanket.lopes at nokia.com (ext-sanket.lopes@nokia.com)
Date: Mon Aug 2 01:41:19 2010
Subject: [datatype-dev] COMMIT: [Nokia-private-dev] CR: Linux Compatibility
Issues
In-Reply-To: <4C475F37.5050102@real.com>
References: <89F9BF23C080784180D44D7A8FEBA4292BC1653644@NOK-EUMSG-03.mgdnok.nokia.com>
<4C475F37.5050102@real.com>
Message-ID: <89F9BF23C080784180D44D7A8FEBA4292BC1653FD7@NOK-EUMSG-03.mgdnok.nokia.com>
Thanks Jamie,
Committed to 210Cays
Br,
Sanket
-----Original Message-----
From: ext Jamie Gordon [mailto:jgordon@real.com]
Sent: Wednesday, July 21, 2010 3:57 PM
To: Lopes Sanket (EXT-Infovision/Dallas)
Cc: nokia-private-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: Linux Compatibility Issues
ok
On 7/21/2010 7:26 AM, ext-sanket.lopes@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with Real Networks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: ext-sanket.lopes@nokia.com
>
>
>
> Reviewed by: yury.ramanovich@nokia.com
>
>
>
> Date: 07/21/2010
>
>
>
> Project: Datatype
>
>
>
> Error Id: N/A
>
>
>
> Synopsis: Linux Compatibility Issues.
>
>
>
> Overview:
>
> Checksource Failure:
>
> Reference in metadata ->
> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaconfig.h
>
>
> ---------------------------------------------------------------------------------------^-------
>
> Actual case on disk ->
> Y:/sf/mw/helix/helix_ren/src/datatype/mp4/common/pub/gaConfig.h
>
>
>
> *helix/helix_ren/src/datatype/mdf/audio/dsp/mdfaudfmt.h:#include
> "gaconfig.h"*
>
>
>
> Files modified:
>
> /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h
>
>
>
> Files removed: None
>
>
>
> Image Size and Heap Use impact: None.
>
>
>
> Module Release testing (STIF) : N/A
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : N/A
>
>
>
> Platforms and Profiles Build Verified: helix-client-s60-52-mmf-mdf-dsp
>
>
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
>
>
> Branch: 210 Cays
>
>
>
> Diff:
>
>
>
> Index: mdfaudfmt.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/mdf/audio/dsp/mdfaudfmt.h,v
>
> retrieving revision 1.1.2.16
>
> diff -u -b -r1.1.2.16 mdfaudfmt.h
>
> --- mdfaudfmt.h 22 Jun 2010 06:49:37 -0000 1.1.2.16
>
> +++ mdfaudfmt.h 20 Jul 2010 21:02:35 -0000
>
> @@ -62,7 +62,7 @@
>
>
>
> //class CAudioSpecificConfig;
>
>
>
> -#include "gaconfig.h"
>
> +#include "gaConfig.h"
>
>
>
> #define KMMFFourCCCodeEAACP 0x43414520 // ' ' 'E' 'A' 'C'
>
>
>
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.