From ehyche at real.com Tue Sep 2 06:06:10 2008
From: ehyche at real.com (Eric Hyche)
Date: Tue Sep 2 04:27:29 2008
Subject: [datatype-dev] RE: sample encoded file in .rm container encoded
using either raac or racp codec
In-Reply-To:
References:
Message-ID: <00aa01c90cfc$ac656d70$05304850$@com>
Arun,
Creating these files is very easy. Simply install RealPlayer 11 for Windows, import
some audio file in some other format (.mp3, .wma, .wav, etc.) into your library,
right-click on that library entry, choose "Convert Media Format...", and then
choose RealAudio 10 as the destination format.
Doing these steps, you should be able to create whatever raac-in-rm files you need.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Senior Technical Lead
RealNetworks, Inc.
>-----Original Message-----
>From: arunr@tataelxsi.co.in [mailto:arunr@tataelxsi.co.in]
>Sent: Monday, September 01, 2008 2:30 AM
>To: datatype-dev@helixcommunity.org
>Subject: sample encoded file in .rm container encoded using either raac or racp codec
>
>Hi..
>
>If anyone is having a sample encoded .rm file(coded using raac or racp codecs) , pls send me. I am in
>desperate need of it.
>
>Regards
>Arun
>
>The information contained in this electronic message and any attachments to this message are intended
>for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged
>information. If you are not the intended recipient, you should not disseminate, distribute or copy
>this e-mail. Please notify the sender immediately and destroy all copies of this message and any
>attachments contained in it.
From arunr at tataelxsi.co.in Tue Sep 2 21:09:50 2008
From: arunr at tataelxsi.co.in (arunr@tataelxsi.co.in)
Date: Tue Sep 2 19:30:21 2008
Subject: [datatype-dev] RE: sample encoded file in .rm container encoded
using either raac or racp codec
In-Reply-To: <00aa01c90cfc$ac656d70$05304850$@com>
Message-ID:
Hi Eric,
I have installed real player 11 basic version which I guess don't have
support for conversion. And for premium version I need to give my credit
card number(just for the 14 days trail version). And I cant do that now. I
need just one stream to test the authenticity(ie having valid aac codec) of
the code. If it is a valid code, we would buy the premium version.
Regards
Arun
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Tuesday, September 02, 2008 6:36 PM
To: arunr@tataelxsi.co.in; datatype-dev@helixcommunity.org
Subject: RE: sample encoded file in .rm container encoded using either raac
or racp codec
Arun,
Creating these files is very easy. Simply install RealPlayer 11 for Windows,
import some audio file in some other format (.mp3, .wma, .wav, etc.) into
your library, right-click on that library entry, choose "Convert Media
Format...", and then choose RealAudio 10 as the destination format.
Doing these steps, you should be able to create whatever raac-in-rm files
you need.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Senior Technical Lead
RealNetworks, Inc.
>-----Original Message-----
>From: arunr@tataelxsi.co.in [mailto:arunr@tataelxsi.co.in]
>Sent: Monday, September 01, 2008 2:30 AM
>To: datatype-dev@helixcommunity.org
>Subject: sample encoded file in .rm container encoded using either raac
>or racp codec
>
>Hi..
>
>If anyone is having a sample encoded .rm file(coded using raac or racp
>codecs) , pls send me. I am in desperate need of it.
>
>Regards
>Arun
>
>The information contained in this electronic message and any
>attachments to this message are intended for the exclusive use of the
>addressee(s) and may contain proprietary, confidential or privileged
>information. If you are not the intended recipient, you should not
>disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments
contained in it.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
From Shy.Ward at nokia.com Wed Sep 3 09:02:05 2008
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Wed Sep 3 07:23:53 2008
Subject: [datatype-dev] RESEND: CR: Symbian MetaData Engine Port for HEAD
Branch
Message-ID: <0265888D9A65AC4E87B50F72993F813602016B9B@daebe104.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_build.diff
Type: application/octet-stream
Size: 621 bytes
Desc: common_build.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/common_build-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.diff
Type: application/octet-stream
Size: 794 bytes
Desc: log.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/log-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata.diff
Type: application/octet-stream
Size: 9700 bytes
Desc: metadata.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/metadata-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ribosome.diff
Type: application/octet-stream
Size: 1424 bytes
Desc: ribosome.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/ribosome-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicntx.diff
Type: application/octet-stream
Size: 3349 bytes
Desc: minicntx.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/minicntx-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtdriver.diff
Type: application/octet-stream
Size: 3055 bytes
Desc: dtdriver.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/dtdriver-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.diff
Type: application/octet-stream
Size: 1017 bytes
Desc: client.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080903/4bb71229/client-0001.obj
From arunr at tataelxsi.co.in Wed Sep 3 20:38:06 2008
From: arunr at tataelxsi.co.in (arunr@tataelxsi.co.in)
Date: Wed Sep 3 18:58:22 2008
Subject: [datatype-dev] RE: sample encoded file in .rm container encoded
using either raac or racp codec
Message-ID:
Eric,
I got a convertor from helix community which converts the aac stream to rm
container format. And the rm aac code is also working fine.
Thanks and Regards
Arun
-----Original Message-----
From: arunr@tataelxsi.co.in [mailto:arunr@tataelxsi.co.in]
Sent: Wednesday, September 03, 2008 9:40 AM
To: 'ehyche@real.com'; 'datatype-dev@helixcommunity.org'
Subject: RE: sample encoded file in .rm container encoded using either raac
or racp codec
Hi Eric,
I have installed real player 11 basic version which I guess don't have
support for conversion. And for premium version I need to give my credit
card number(just for the 14 days trail version). And I cant do that now. I
need just one stream to test the authenticity(ie having valid aac codec) of
the code. If it is a valid code, we would buy the premium version.
Regards
Arun
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Tuesday, September 02, 2008 6:36 PM
To: arunr@tataelxsi.co.in; datatype-dev@helixcommunity.org
Subject: RE: sample encoded file in .rm container encoded using either raac
or racp codec
Arun,
Creating these files is very easy. Simply install RealPlayer 11 for Windows,
import some audio file in some other format (.mp3, .wma, .wav, etc.) into
your library, right-click on that library entry, choose "Convert Media
Format...", and then choose RealAudio 10 as the destination format.
Doing these steps, you should be able to create whatever raac-in-rm files
you need.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Senior Technical Lead
RealNetworks, Inc.
>-----Original Message-----
>From: arunr@tataelxsi.co.in [mailto:arunr@tataelxsi.co.in]
>Sent: Monday, September 01, 2008 2:30 AM
>To: datatype-dev@helixcommunity.org
>Subject: sample encoded file in .rm container encoded using either raac
>or racp codec
>
>Hi..
>
>If anyone is having a sample encoded .rm file(coded using raac or racp
>codecs) , pls send me. I am in desperate need of it.
>
>Regards
>Arun
>
>The information contained in this electronic message and any
>attachments to this message are intended for the exclusive use of the
>addressee(s) and may contain proprietary, confidential or privileged
>information. If you are not the intended recipient, you should not
>disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments
contained in it.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
From Shy.Ward at nokia.com Thu Sep 4 14:37:06 2008
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Thu Sep 4 12:59:19 2008
Subject: [datatype-dev] RESEND: RESEND: CR: Symbian MetaData Engine Port for
HEAD Branch
Message-ID: <0265888D9A65AC4E87B50F72993F813602017110@daebe104.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_build.diff
Type: application/octet-stream
Size: 621 bytes
Desc: common_build.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/common_build-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.diff
Type: application/octet-stream
Size: 794 bytes
Desc: log.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/log-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata.diff
Type: application/octet-stream
Size: 9700 bytes
Desc: metadata.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/metadata-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ribosome.diff
Type: application/octet-stream
Size: 1424 bytes
Desc: ribosome.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/ribosome-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicntx.diff
Type: application/octet-stream
Size: 3349 bytes
Desc: minicntx.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/minicntx-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtdriver.diff
Type: application/octet-stream
Size: 3055 bytes
Desc: dtdriver.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/dtdriver-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.diff
Type: application/octet-stream
Size: 1017 bytes
Desc: client.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080904/96a044c2/client-0001.obj
-------------- next part --------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From gwright at real.com Thu Sep 4 17:00:52 2008
From: gwright at real.com (Greg Wright)
Date: Thu Sep 4 15:23:45 2008
Subject: [datatype-dev] Re: [Ribosome-dev] RESEND: RESEND: CR: Symbian
MetaData Engine Port for HEAD Branch
In-Reply-To: <0265888D9A65AC4E87B50F72993F813602017110@daebe104.NOE.Nokia.com>
References: <0265888D9A65AC4E87B50F72993F813602017110@daebe104.NOE.Nokia.com>
Message-ID: <48C076B4.6080705@real.com>
Looks good.
--greg.
Shy.Ward@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: shy.ward@nokia.com
>
> Reviewed by:
>
> Date: August-29-2008
>
> Project: SymbianMmf
>
> ErrorId*:* N/A
>
>
> Synopsis: Symbian MetaData Engine Port for HEAD Branch
>
> Overview: The Symbian Metadata engine currently does not work with
> the head using the new media platform. This CR provides the
> changes necessary.
>
> Previously the metadata engine used the prefs object as it's
> context and for simplicity this approach has reused in that, the
> mediaplatform will be initialized with the prefs object as it's
> external context and the mini cntx will be retrieved from the
> mediaplatform.
>
> A new flag has been introduced in helix-s60-metadataengine.pf:
> HELIX_CONFIG_USE_EXTERNAL_CONTEXT. This is used in the minictx to
> prevent a new scheduler
>
> from being created and it's associated services.
>
> The metadataenigne is now doing an ADDREF on the source sink; this
> fixes a problem where ffdriver::drive method would become stuck in an
> infinite loop.
>
> Other minor compilation errors have been addressed in this CR:
> writeable static data in merge_sort_src_handler.cpp &
> hxloghelper.cpp has been fixed
>
>
> Open Issues:
> Logging needs to be enabled on the Metadata engine and currently
> there is a problem reading the metadata for real media. These
> issues will be addressed later and will be added to the product
> backlog.
>
>
> Files Modified:
> ribosome/build/umakepf/helix-s60-metadataengine.pf
> ribosome/build/umakepf/helix-s60-metadataengine.pfi
> datatype/tools/metadataeng/engine/Umakefil
> datatype/tools/metadataeng/engine/metadataengbase.cpp
> datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng.cpp
>
> datatype/tools/metadataeng/engine/pub/metadataengbase.h
> datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadataeng.h
>
> client/common/container/hxpluginmanager.cpp
> common/log/logutil/hxloghelper.cpp
> datatype/tools/dtdriver/engine/ffdriver.cpp
> datatype/tools/dtdriver/engine/merge_sort_src_handler.cpp
> datatype/tools/dtdriver/engine/pub/merge_sort_src_handler.h
> datatype/tools/minicntx/minicntx
> datatype/tools/minicntx/minicntx.cpp
> common/build/BIF/helix.bif
>
> New files added:
> None.
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Passed, no RM metadata test cases
> ran
>
> Test case(s) Added : No.
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: HEAD
>
>
> <> <> <> <>
> <> <> <>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ribosome-dev mailing list
> Ribosome-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/ribosome-dev
From Shy.Ward at nokia.com Fri Sep 5 11:55:19 2008
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Fri Sep 5 10:16:03 2008
Subject: [datatype-dev] CN: Symbian MetaData Engine Port for HEAD Branch
In-Reply-To: <48C076B4.6080705@real.com>
References: <0265888D9A65AC4E87B50F72993F813602017110@daebe104.NOE.Nokia.com>
<48C076B4.6080705@real.com>
Message-ID: <0265888D9A65AC4E87B50F72993F8136020173B8@daebe104.NOE.Nokia.com>
Thanks, checked into HEAD.
Shy
-----Original Message-----
From: ext Greg Wright [mailto:gwright@real.com]
Sent: Thursday, September 04, 2008 7:01 PM
To: Ward Shy (Nokia-D-MSW/Dallas)
Cc: nokia-private-dev@helixcommunity.org;
ribosome-dev@helixcommunity.org; common-dev@helixcommunity.org;
datatype-dev@helixcommunity.org; client-dev@helixcommunity.org
Subject: Re: [Ribosome-dev] RESEND: RESEND: CR: Symbian MetaData Engine
Port for HEAD Branch
Looks good.
--greg.
Shy.Ward@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: shy.ward@nokia.com
>
> Reviewed by:
>
> Date: August-29-2008
>
> Project: SymbianMmf
>
> ErrorId*:* N/A
>
>
> Synopsis: Symbian MetaData Engine Port for HEAD Branch
>
> Overview: The Symbian Metadata engine currently does not work
with
> the head using the new media platform. This CR provides the
> changes necessary.
>
> Previously the metadata engine used the prefs object as it's
> context and for simplicity this approach has reused in that, the
> mediaplatform will be initialized with the prefs object as it's
> external context and the mini cntx will be retrieved from the
> mediaplatform.
>
> A new flag has been introduced in helix-s60-metadataengine.pf:
> HELIX_CONFIG_USE_EXTERNAL_CONTEXT. This is used in the minictx to
> prevent a new scheduler
>
> from being created and it's associated services.
>
> The metadataenigne is now doing an ADDREF on the source sink;
> this fixes a problem where ffdriver::drive method would become stuck
> in an infinite loop.
>
> Other minor compilation errors have been addressed in this CR:
> writeable static data in merge_sort_src_handler.cpp &
> hxloghelper.cpp has been fixed
>
>
> Open Issues:
> Logging needs to be enabled on the Metadata engine and currently
> there is a problem reading the metadata for real media. These
> issues will be addressed later and will be added to the product
> backlog.
>
>
> Files Modified:
> ribosome/build/umakepf/helix-s60-metadataengine.pf
> ribosome/build/umakepf/helix-s60-metadataengine.pfi
> datatype/tools/metadataeng/engine/Umakefil
> datatype/tools/metadataeng/engine/metadataengbase.cpp
>
> datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataeng
> .cpp
>
> datatype/tools/metadataeng/engine/pub/metadataengbase.h
>
> datatype/tools/metadataeng/engine/pub/platform/symbian/symbian_metadat
> aeng.h
>
> client/common/container/hxpluginmanager.cpp
> common/log/logutil/hxloghelper.cpp
> datatype/tools/dtdriver/engine/ffdriver.cpp
> datatype/tools/dtdriver/engine/merge_sort_src_handler.cpp
> datatype/tools/dtdriver/engine/pub/merge_sort_src_handler.h
> datatype/tools/minicntx/minicntx
> datatype/tools/minicntx/minicntx.cpp
> common/build/BIF/helix.bif
>
> New files added:
> None.
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Passed, no RM metadata test
cases
> ran
>
> Test case(s) Added : No.
>
> Platforms and Profiles Build Verified:
helix-client-s60-32-mmf-mdf-arm
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: HEAD
>
>
> <> <> <> <>
> <> <> <>
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Ribosome-dev mailing list
> Ribosome-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/ribosome-dev
From jrathore at real.com Fri Sep 5 14:44:34 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Fri Sep 5 13:05:00 2008
Subject: [datatype-dev] CR:[#8529]Fix for playback of AAC files which hang
at the last second.
Message-ID: <008001c90fa0$968173e0$f58016ac@corp.real.com>
Modified by: jrathore@real.com
Date: 09/05/08
Project: RealPlayer for MID
Synopsis: Fix for playback of AAC files which hang at the last second.
Overview: Files ripped as AAC from CDs sometimes have "APE" Tag tacked at
the end of file. This tag contains metadata information like Title, Artist,
and Year etc. When AAC file format encounters this non-AAC data, it returns
HXR_INVALID_FILE error but this error gets masked/ignored on its way up and
the file format never issues a StreamDone() and never throws an error. This
fix, first checks if its an "APE" tag and if true, calls StreamDone()
because this tag is always at the end of file. If not, then code has been
added to report the HXR_INVALID_FILE error.
Files Added: None
Files Modified:
aacff.cpp (/datatype/aac/fileformat/aacff.cpp)
aacff.h (/datatype/aac/fileformat/pub/aacff.h)
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
Platforms and Profiles Build and Functionality Verified:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
target(s): splay
Branch: hxclient_3_1_0_atlas, HEAD
Copyright assignment: I am a RealNetworks employee.
Files Attached: aacff.diff
-Jyotsana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aacff.diff
Type: application/octet-stream
Size: 2205 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080905/b53b12b2/aacff.obj
From ehyche at real.com Mon Sep 8 05:44:25 2008
From: ehyche at real.com (Eric Hyche)
Date: Mon Sep 8 04:04:09 2008
Subject: [datatype-dev] CR:[#8529]Fix for playback of AAC files which
hang at the last second.
In-Reply-To: <008001c90fa0$968173e0$f58016ac@corp.real.com>
References: <008001c90fa0$968173e0$f58016ac@corp.real.com>
Message-ID: <005501c911b0$a1808300$e4818900$@com>
Looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Jyotsana Rathore
>Sent: Friday, September 05, 2008 5:45 PM
>To: midplayer-private-dev@helixcommunity.org; datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR:[#8529]Fix for playback of AAC files which hang at the last second.
>
>Modified by: jrathore@real.com
>Date: 09/05/08
>Project: RealPlayer for MID
>
>Synopsis: Fix for playback of AAC files which hang at the last second.
>
>Overview: Files ripped as AAC from CDs sometimes have "APE" Tag tacked at the end of file. This tag
>contains metadata information like Title, Artist, and Year etc. When AAC file format encounters this
>non-AAC data, it returns HXR_INVALID_FILE error but this error gets masked/ignored on its way up and
>the file format never issues a StreamDone() and never throws an error. This fix, first checks if its
>an "APE" tag and if true, calls StreamDone() because this tag is always at the end of file. If not,
>then code has been added to report the HXR_INVALID_FILE error.
>
>Files Added: None
>
>Files Modified:
>aacff.cpp (/datatype/aac/fileformat/aacff.cpp)
>aacff.h (/datatype/aac/fileformat/pub/aacff.h)
>
>Image Size and Heap Use impact (Client -Only): None
>
>Platforms and Profiles Affected:
>Platform: win32-i386-vc7
>Profile: helix-client-all-defines
>
>Platforms and Profiles Build and Functionality Verified:
>Platform: win32-i386-vc7
>Profile: helix-client-all-defines
>target(s): splay
>
>Branch: hxclient_3_1_0_atlas, HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>Files Attached: aacff.diff
>
>-Jyotsana
From hayoung.choi at ap.real.com Mon Sep 8 14:39:52 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Mon Sep 8 13:02:35 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
# -*- python -*-
#
# ***** BEGIN LICENSE BLOCK *****
# Source last modified: $Id: Umakefil,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file,
# are subject to the current version of the RealNetworks Public
# Source License (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the current version of the RealNetworks Community
# Source License (the "RCSL") available at
# http://www.helixcommunity.org/content/rcsl, in which case the RCSL
# will apply. You may also obtain the license terms directly from
# RealNetworks. You may not use this file except in compliance with
# the RPSL or, if you have a valid RCSL with RealNetworks applicable
# to this file, the RCSL. Please see the applicable RPSL or RCSL for
# the rights, obligations and limitations governing use of the
# contents of the file.
#
# Alternatively, the contents of this file may be used under the
# terms of the GNU General Public License Version 2 (the
# "GPL") in which case the provisions of the GPL are applicable
# instead of those above. If you wish to allow use of your version of
# this file only under the terms of the GPL, and not to allow others
# to use your version of this file under the terms of either the RPSL
# or RCSL, indicate your decision by deleting the provisions above
# and replace them with the notice and other provisions required by
# the GPL. If you do not delete the provisions above, a recipient may
# use your version of this file under the terms of any one of the
# RPSL, the RCSL or the GPL.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the
# portions it created.
#
# This file, and the files included with this file, is distributed
# and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
# KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
# ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
# ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,1)
project.AddSources("dlliids.cpp",
"pngwrpln.cpp",
"pngwrtr.cpp"
)
project.AddModuleIncludes( "common/include",
"common/dbgtool/pub",
"common/container/pub",
"common/runtime/pub",
"common/util/pub",
"datatype/image/png/import/libpng",
"common/import/zlib/pub"
)
project.AddModuleLibraries( "common/container[contlib]",
"datatype/common/filewriter[wrtrlib]",
"common/util[utillib]",
"common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"datatype/image/png/import/libpng[libpng]",
"common/import/zlib[zlib]"
)
project.ExportFunction("RMACreateInstance",
"IUnknown** ppObj",
"common/include",
"hxcom.h")
DLLTarget('pngwrtr')
DependTarget()
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: dlliids.cpp,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#define INITGUID 1
#include "hxcom.h"
#include "hxfwrtr.h"
#include "hxiids.h"
#include "hxpiids.h"
#undef INITGUID
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrpln.cpp,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#include "pngwrtr.h"
#include "pngwrpln.h"
/****************************************************************************
* DLL Interface
*/
/****************************************************************************
* RMACreateInstance()
* Purpose:
* Function implemented by all plugin DLL's to create an instance of
* any of the objects supported by the DLL. This method is similar to
* Window's CoCreateInstance() in its purpose, except that it only
* creates objects from this plugin DLL.
*
* NOTE: Aggregation is never used. Therefore and outer unknown is
* not passed to this function, and you do not need to code for this
* situation.
*/
STDAPI ENTRYPOINT(RMACreateInstance)
(
IUnknown** /*OUT*/ ppIUnknown
)
{
*ppIUnknown = (IUnknown*)(IHXPlugin*) new CPNGFileWriter();
if (*ppIUnknown)
{
(*ppIUnknown)->AddRef();
return HXR_OK;
}
return HXR_OUTOFMEMORY;
}
/****************************************************************************
* CanUnload()
* Purpose:
* Function implemented by all plugin DLL's if it returns HXR_OK
* then the pluginhandler can unload the DLL
*/
STDAPI ENTRYPOINT(CanUnload)(void)
{
return (g_nRefCount_pngwr ? HXR_FAIL : HXR_OK);
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrpln.h,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifndef _PNGWRPLN_H
#define _PNGWRPLN_H
/****************************************************************************
* Includes
*/
#include "hxtypes.h"
#endif // _PNGWRPLN_H
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrtr.cpp,v 1.6 2007/09/10 00:03:56 milko Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#define VIDEO_MIME_PREFIX "video"
#define VIDEO_MIME_PREFIX_SIZE (sizeof(VIDEO_MIME_PREFIX) - 1)
#define AUDIO_MIME_PREFIX "audio"
#define AUDIO_MIME_PREFIX_SIZE (sizeof(AUDIO_MIME_PREFIX) - 1)
#define SUPLEMENTED_MIME_POSTFIX "-RN"
#define ENCRYPTED_MIME_EXTENSION "-encrypted"
#define ENCRYPTED_MIME_EXTENSION_SIZE (sizeof(ENCRYPTED_MIME_EXTENSION) - 1)
#define MIN_RESCHED_TIME 2 // in milliseconds
/****************************************************************************
* Includes
*/
#include "pngwrpln.h"
#include "pngwrtr.ver"
#include "hxmime.h"
#include "hxstring.h"
#include "hlxclib/string.h"
#include "hxstrutl.h"
#include "hxbuffer.h"
#include "hxver.h"
#include "chxpckts.h"
#include "pckunpck.h"
#include "rmfftype.h"
#include "netbyte.h"
#include "mimechk.h"
#include "pngwrtr.h"
#include "hlxclib/fcntl.h"
#if defined(_WIN32)
#include
#endif
INT32 g_nRefCount_pngwr = 0;
/****************************************************************************
* CPNGFileWriter class
*/
const char* CPNGFileWriter::zm_pDescription = "Helix Portable File Writer Plugin";
const char* CPNGFileWriter::zm_pCopyright = HXVER_COPYRIGHT;
const char* CPNGFileWriter::zm_pMoreInfoURL = HXVER_MOREINFO;
const char* CPNGFileWriter::zm_pFileMimeTypes[] = {NULL};
const char* CPNGFileWriter::zm_pFileExtensions[] = {"png", NULL};
const char* CPNGFileWriter::zm_pFileOpenNames[] = {"PNG Image Files (*.png)", NULL};
/****************************************************************************
* Constructor/Destructor
*/
CPNGFileWriter::CPNGFileWriter(IUnknown* pUnknown)
: m_pContext(pUnknown)
, m_pRequest(NULL)
, m_pMonitor(NULL)
, m_pAdviser(NULL)
, m_pProperties(NULL)
, m_hOutFile(0)
, m_State(Offline)
, m_bClosing(TRUE)
, m_pCurrentStreamHeader(NULL)
, m_pFileHeader(NULL)
, m_bStreamDone(FALSE)
, m_bSwapEndianess(FALSE)
, m_ulBitsPerSample(0)
, m_ulFileSize(0)
, m_ulDataChunkSizeOffset(0)
, m_ulDataSize(0)
, m_ulChannels(0)
, m_uStreamCount(0)
, m_pScheduler(NULL)
, m_CallbackHandle(0)
, m_ulVolumeTag(0)
, m_lRefCount(0)
, fp(NULL)
, m_ulWidth(0)
, m_ulHeight(0)
, m_ulIndex(0)
, m_uMaximumImageOutputFiles(0)
{
InterlockedIncrement(&g_nRefCount_pngwr);
if (m_pContext)
{
m_pContext->AddRef();
}
}
CPNGFileWriter::~CPNGFileWriter(void)
{
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pProperties);
HX_RELEASE(m_pContext);
HX_RELEASE(m_pScheduler);
HX_RELEASE(m_pFileHeader);
HX_RELEASE(m_pCurrentStreamHeader);
InterlockedDecrement(&g_nRefCount_pngwr);
}
/************************************************************************
* IHXPlugin methods
*/
/************************************************************************
* CPNGFileWriter::InitPlugin
* Purpose:
* Initializes the plugin for use. This interface must always be
* called before any other method is called. This is primarily needed
* so that the plugin can have access to the context for creation of
* IHXBuffers and IMalloc.
*/
STDMETHODIMP CPNGFileWriter::InitPlugin(IUnknown* /*IN*/ pContext)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_pFileHeader == NULL)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = HXR_INVALID_PARAMETER;
if (pContext)
{
HX_RELEASE(m_pContext);
m_pContext = pContext;
m_pContext->AddRef();
retVal = HXR_OK;
}
else if (m_pContext)
{
retVal = HXR_OK;
}
}
return retVal;
}
/************************************************************************
* CPNGFileWriter::GetPluginInfo
* Purpose:
* Returns the basic information about this plugin. Including:
*
* bLoadMultiple whether or not this plugin DLL can be loaded
* multiple times. All File Formats must set
* this value to TRUE.
* pDescription which is used in about UIs (can be NULL)
* pCopyright which is used in about UIs (can be NULL)
* pMoreInfoURL which is used in about UIs (can be NULL)
*/
STDMETHODIMP CPNGFileWriter::GetPluginInfo
(
REF(HXBOOL) bLoadMultiple,
REF(const char*) pDescription,
REF(const char*) pCopyright,
REF(const char*) pMoreInfoURL,
REF(ULONG32) ulVersionNumber
)
{
bLoadMultiple = TRUE; // Must be true for file formats.
pDescription = zm_pDescription;
pCopyright = zm_pCopyright;
pMoreInfoURL = zm_pMoreInfoURL;
ulVersionNumber = TARVER_ULONG32_VERSION;
return HXR_OK;
}
/****************************************************************************
* IHXFileWriter methods
*/
/************************************************************************
* GetFileFormatInfo
* Purpose:
* If this object is a file format object this method returns
* information vital to the instantiation of file format plugins.
* If this object is not a file format object, it should return
* HXR_UNEXPECTED.
*/
STDMETHODIMP CPNGFileWriter::GetFileFormatInfo
(
REF(const char**) /*OUT*/ pFileMimeTypes,
REF(const char**) /*OUT*/ pFileExtensions,
REF(const char**) /*OUT*/ pFileOpenNames
)
{
pFileMimeTypes = zm_pFileMimeTypes;
pFileExtensions = zm_pFileExtensions;
pFileOpenNames = zm_pFileOpenNames;
return HXR_OK;
}
/****************************************************************************
* InitFileWriter
*/
STDMETHODIMP CPNGFileWriter::InitFileWriter
(
IHXRequest* pRequest,
IHXFileWriterMonitor* pMonitor,
IHXPropertyAdviser* pAdviser
)
{
HX_RESULT retVal = HXR_UNEXPECTED;
IHXValues* pProperties = NULL;
if (m_pFileHeader == NULL)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = HXR_FAIL;
if (m_pContext)
{
HX_RELEASE(m_pScheduler);
// we may not need a scheduler
retVal = m_pContext->QueryInterface(IID_IHXScheduler,
(void**) &m_pScheduler);
}
}
if (SUCCEEDED(retVal))
{
if (pRequest)
{
pRequest->AddRef();
pRequest->GetRequestHeaders(pProperties);
}
if (pMonitor)
{
pMonitor->AddRef();
}
if (pAdviser)
{
pAdviser->AddRef();
}
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
HX_RELEASE(m_pProperties);
m_pRequest = pRequest;
m_pMonitor = pMonitor;
m_pAdviser = pAdviser;
m_pProperties = pProperties;
m_ulVolumeTag = 0;
m_bClosing = FALSE;
}
return retVal;
}
/****************************************************************************
* Close
*/
STDMETHODIMP CPNGFileWriter::Close(void)
{
UINT16 uIdx;
HX_RESULT retVal = HXR_OK;
if (!m_bClosing)
{
m_bClosing = TRUE;
// No more information will be sent
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
for (uIdx = 0; uIdx < m_uStreamCount; uIdx++)
{
StreamDone(uIdx);
}
m_State = Offline;
m_uStreamCount = 0;
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pProperties);
HX_RELEASE(m_pContext);
HX_RELEASE(m_pFileHeader);
HX_RELEASE(m_pCurrentStreamHeader);
m_bClosing = FALSE;
}
return retVal;
}
/****************************************************************************
* Abort
*/
STDMETHODIMP CPNGFileWriter::Abort(void)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_CallbackHandle && m_pScheduler)
{
m_pScheduler->Remove(m_CallbackHandle);
m_CallbackHandle = 0;
}
return retVal;
}
/****************************************************************************
* SetProperties
*/
STDMETHODIMP CPNGFileWriter::SetProperties(IHXValues* pProperties)
{
IHXValues* pNewPorperties = NULL;
HX_RESULT retVal = HXR_OK;
pNewPorperties = CloneHeader(pProperties, m_pContext);
HX_RELEASE(m_pProperties);
m_pProperties = pNewPorperties;
return retVal;
}
/****************************************************************************
* SetFileHeader
*/
STDMETHODIMP CPNGFileWriter::SetFileHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_INVALID_PARAMETER;
HX_ASSERT(pHeader);
if (pHeader)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
HX_RELEASE(m_pFileHeader);
m_pFileHeader = pHeader;
m_pFileHeader->AddRef();
UINT32 count = 0;
m_pFileHeader->GetPropertyULONG32("StreamCount", count);
m_uStreamCount = (UINT16) count;
// only suport a single stream
if (m_uStreamCount != 1)
{
retVal = HXR_UNEXPECTED;
}
}
ULONG32 maxImageOutputFiles = 0;
retVal = m_pProperties->GetPropertyULONG32("MaximumImageOutputFiles", maxImageOutputFiles);
if (SUCCEEDED(retVal))
{
m_uMaximumImageOutputFiles = (INT16) maxImageOutputFiles;
}
return retVal;
}
/****************************************************************************
* SetStreamHeader
*/
STDMETHODIMP CPNGFileWriter::SetStreamHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_UNEXPECTED;
// Check input parameters
if (m_pFileHeader != NULL && m_uStreamCount == 1)
{
retVal = HXR_OK;
}
// Perform addtion or modification
if (SUCCEEDED(retVal))
{
m_pCurrentStreamHeader = pHeader;
m_pCurrentStreamHeader->AddRef();
if (IsPNGCompatibleStream(m_pCurrentStreamHeader))
{
/* if (SUCCEEDED(retVal))
{*/
/*retVal = CreatePNGFile();
if (retVal == HXR_OK)
{*/
//retVal = WritePNGFileHeader();
//}
//}
}
//inform core that we are ready for SetPackets
m_pMonitor->OnPacketsReady(retVal);
m_State = PacketsReady;
retVal = m_pCurrentStreamHeader->GetPropertyULONG32("Width", m_ulWidth);
if (SUCCEEDED(retVal))
{
retVal = m_pCurrentStreamHeader->GetPropertyULONG32("Height", m_ulHeight);
}
ULONG32 ulTemp = 0;
m_pCurrentStreamHeader->GetPropertyULONG32("", ulTemp);
}
return retVal;
}
/****************************************************************************
* SetPacket
*/
STDMETHODIMP CPNGFileWriter::SetPacket(IHXPacket* pPacket)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_State == PacketsReady && pPacket->GetStreamNumber() == 0)
{
retVal = HXR_OK;
// send the packet to deinterleaver, if it is our stream
if (pPacket)
{
retVal = HXR_FAIL;
if (!m_bStreamDone)
{
IHXBuffer* pBuffer = pPacket->GetBuffer();
if (pBuffer)
{
if (m_uMaximumImageOutputFiles-- > 0)
{
retVal = CreatePNGFile();
if (SUCCEEDED(retVal))
{
retVal = WritePNGFileHeader();
}
if (SUCCEEDED(retVal))
{
retVal = WritePNGPacket(pBuffer);
}
if (SUCCEEDED(retVal))
{
retVal = ClosePNGFile();
}
}
else
{
// no more thumbnail needed
retVal = HXR_OK;
}
pBuffer->Release();
}
}
}
}
return retVal;
}
/****************************************************************************
* StreamDone
*/
STDMETHODIMP CPNGFileWriter::StreamDone(UINT16 unStreamNumber)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_State != Offline && !m_bStreamDone)
{
m_bStreamDone = TRUE;
//close PNG file, no matter error or not
ClosePNGFile();
// all streams are done, set complete
m_pMonitor->OnVolumeCompletion(HXR_OK, m_ulVolumeTag);
m_pMonitor->OnCompletion(HXR_OK);
}
return retVal;
}
/****************************************************************************
* IHXFileWriterMonitor
*/
/****************************************************************************
* OnStatus
*/
STDMETHODIMP CPNGFileWriter::OnStatus(HX_RESULT status, IHXValues* pInfoList)
{
HX_RESULT retVal = HXR_OK;
if (m_pMonitor)
{
retVal = m_pMonitor->OnStatus(status, pInfoList);
}
return retVal;
}
/****************************************************************************
* OnVolumeInitiation
*/
STDMETHODIMP CPNGFileWriter::OnVolumeInitiation(HX_RESULT status,
const char* pName,
REF(ULONG32) ulTag)
{
HX_RESULT retVal = HXR_OK;
m_ulVolumeTag++;
if (m_pMonitor)
{
ulTag = m_ulVolumeTag;
AddRef();
retVal = m_pMonitor->OnVolumeInitiation(status, pName, ulTag);
if (retVal == HXR_OK)
{
m_ulVolumeTag = ulTag;
}
Release();
}
else
{
ulTag = m_ulVolumeTag;
}
return retVal;
}
/****************************************************************************
* OnPacketsReady
*/
STDMETHODIMP CPNGFileWriter::OnPacketsReady(HX_RESULT status)
{
HX_RESULT retVal = HXR_OK;
if (SUCCEEDED(status) && (m_State != PacketsReady))
{
/*
ULONG32 ulMaxDepth = DLFT_MERGESORTER_DEPTH;
ULONG32 ulMaxTimespan = DFLT_MERGESORTER_TIMESPAN;
m_ulMergeSorterMaxDepletionRate = DFLT_MERGESORTER_DEPLETIONRATE;
GetPropertyULONG32("MergeSorterMaxDepth", ulMaxDepth);
GetPropertyULONG32("MergeSorterMaxTimespan", ulMaxTimespan);
GetPropertyULONG32("MergeSorterMaxDepletionRate",
m_ulMergeSorterMaxDepletionRate);
ulMaxTimespan &= 0x7FFFFFFF;
if (m_ulMergeSorterMaxDepletionRate == 0)
{
m_ulMergeSorterMaxDepletionRate = 1;
}
status = m_MergeSorter.Init(m_uStreamCount,
ulMaxDepth,
(LONG32) ulMaxTimespan);
*/
}
if (SUCCEEDED(status))
{
m_State = PacketsReady;
}
if (m_pMonitor)
{
retVal = m_pMonitor->OnPacketsReady(status);
}
return retVal;
}
/****************************************************************************
* OnVolumeCompletion
*/
STDMETHODIMP CPNGFileWriter::OnVolumeCompletion(HX_RESULT status,
ULONG32 ulTag)
{
HX_RESULT retVal = HXR_OK;
if (m_pMonitor)
{
retVal = m_pMonitor->OnVolumeCompletion(status, ulTag);
}
return retVal;
}
/****************************************************************************
* OnCompletion
*/
STDMETHODIMP CPNGFileWriter::OnCompletion(HX_RESULT status)
{
HX_RESULT retVal = HXR_OK;
m_State = Offline;
if (m_pMonitor)
{
retVal = m_pMonitor->OnCompletion(status);
}
return retVal;
}
/****************************************************************************
* IHXPropertyAdviser Merhods
*/
/****************************************************************************
* GetPropertyULONG32
*/
STDMETHODIMP CPNGFileWriter::GetPropertyULONG32(const char* pPropertyName,
REF(ULONG32) ulPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (strcmp(pPropertyName, "IsFullyNative") == 0)
{
ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
ulPropertyValue = 0;
retVal = HXR_OK;
}
else if (strcmp(pPropertyName, "IsNativeStream") == 0)
{
UINT16 uStreamNum = (UINT16) ulPropertyValue;
if ((uStreamNum < m_uStreamCount) && m_pCurrentStreamHeader)
{
//ulPropertyValue = m_pStreamHeaderInfo[uStreamNum].m_bIsNativeStream ? 1 : 0;
ulPropertyValue = 0;
retVal = HXR_OK;
}
}
else
{
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyULONG32(pPropertyName,
ulPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyULONG32(pPropertyName,
ulPropertyValue);
}
}
}
return retVal;
}
/****************************************************************************
* GetPropertyBuffer
*/
STDMETHODIMP CPNGFileWriter::GetPropertyBuffer(const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyBuffer(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyBuffer(pPropertyName,
pPropertyValue);
}
}
return retVal;
}
/****************************************************************************
* GetPropertyCString
*/
STDMETHODIMP CPNGFileWriter::GetPropertyCString(const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyCString(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyCString(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (strcmp(pPropertyName, "FileExtension") == 0)
{
IHXBuffer* pExtensionBuffer = NULL;
const char* pzExtension = ".png";
ULONG32 ulContainerFormatEnabled = TRUE;
GetPropertyULONG32( "EnableContainerFormat",
ulContainerFormatEnabled);
// Report the extension
retVal = CreateAndSetBufferCCF(pExtensionBuffer, (UINT8*) pzExtension,
strlen(pzExtension)+1, m_pContext);
if (SUCCEEDED(retVal))
{
pExtensionBuffer->AddRef();
pPropertyValue = pExtensionBuffer;
}
HX_RELEASE(pExtensionBuffer);
}
}
}
return retVal;
}
/****************************************************************************
* GetPropertySet
*/
STDMETHODIMP CPNGFileWriter::GetPropertySet(const char* pPropertySetName,
REF(IHXValues*) pPropertySet)
{
IHXValues* pSet = NULL;
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertySet(pPropertySetName,
pPropertySet);
}
if (FAILED(retVal))
{
if (strcmp(pPropertySetName, SUPLEMENTED_STRM_HEADER_SET) == 0)
{
pSet = pPropertySet;
retVal = SuplementStreamHeader(pSet);
}
else if (strcmp(pPropertySetName, STRM_HEADER_SET) == 0)
{
ULONG32 ulStreamNumber;
retVal = HXR_INVALID_PARAMETER;
if (pPropertySet)
{
retVal = pPropertySet->GetPropertyULONG32("StreamNumber",
ulStreamNumber);
}
if (SUCCEEDED(retVal))
{
retVal = HXR_INVALID_PARAMETER;
if ((ulStreamNumber < m_uStreamCount) &&
(m_pCurrentStreamHeader != NULL))
{
retVal = HXR_OK;
pSet = m_pCurrentStreamHeader;
}
}
}
else if (strcmp(pPropertySetName, FILE_HEADER_SET) == 0)
{
retVal = HXR_OK;
pSet = m_pFileHeader;
}
else if (strcmp(pPropertySetName, FWRT_PROPERTY_SET) == 0)
{
retVal = HXR_OK;
pSet = m_pProperties;
}
if (SUCCEEDED(retVal))
{
if (pSet)
{
pSet->AddRef();
if (pPropertySet)
{
pPropertySet->Release();
}
pPropertySet = pSet;
}
}
}
return retVal;
}
/****************************************************************************
* SuplementStreamHeader
*/
HX_RESULT CPNGFileWriter::SuplementStreamHeader(IHXValues* pHeader)
{
const char* pMimeTypeChars;
IHXBuffer* pMimeType = NULL;
HX_RESULT retVal = HXR_INVALID_PARAMETER;
UINT8* pSuplement = NULL;
ULONG32 ulSuplementSize = 0;
const char* pMimeTypeExtension = NULL;
if (pHeader)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = pHeader->GetPropertyCString("MimeType", pMimeType);
}
if (SUCCEEDED(retVal))
{
retVal = HXR_FAIL;
pMimeTypeChars = (const char*) pMimeType->GetBuffer();
if (strncmp(pMimeTypeChars,
AUDIO_MIME_PREFIX,
AUDIO_MIME_PREFIX_SIZE) == 0)
{
ULONG32 ulNumChannels = 0;
ULONG32 ulSampleRate = 0;
pHeader->GetPropertyULONG32("NumChannels", ulNumChannels);
if (ulNumChannels == 0)
{
pHeader->GetPropertyULONG32("Channels", ulNumChannels);
}
pHeader->GetPropertyULONG32("SampleRate", ulSampleRate);
if (ulSampleRate == 0)
{
pHeader->GetPropertyULONG32("SamplesPerSecond", ulSampleRate);
}
if ((ulNumChannels != 0) ||
(ulSampleRate != 0))
{
HXBOOL bMakeSuplement = TRUE;
/*** MBO - always create OpaqueData for MP3
if ((strcasecmp(pMimeTypeChars, "audio/X-MP3-draft-00") == 0) ||
(strcasecmp(pMimeTypeChars, "audio/MPEG-ELEMENTARY") == 0))
{
if ((ulNumChannels == 2) ||
(ulSampleRate == 44100))
{
bMakeSuplement = FALSE;
}
}
***/
if (bMakeSuplement)
{
AudioTypeSpecificData audioData;
memset(&audioData, 0, sizeof(audioData));
audioData.numChannels = (UINT16) ulNumChannels;
audioData.sampleRate = (UINT16) ulSampleRate;
pSuplement = new UINT8 [audioData.static_size()];
retVal = HXR_OUTOFMEMORY;
if (pSuplement)
{
audioData.pack(pSuplement, ulSuplementSize);
pMimeTypeExtension = SUPLEMENTED_MIME_POSTFIX;
retVal = HXR_OK;
}
}
}
}
}
// Add Mime Type Extension
if (SUCCEEDED(retVal) &&
pMimeTypeExtension)
{
HXBOOL bEncryptedMimeType;
CHXString strNewMimeType = pMimeTypeChars;
IHXBuffer* pNewMimeType = NULL;
bEncryptedMimeType = decryptMimeType(strNewMimeType);
strNewMimeType += pMimeTypeExtension;
if (bEncryptedMimeType)
{
encryptMimeType(strNewMimeType);
}
retVal = CreateBufferCCF(pNewMimeType, m_pContext);
if (SUCCEEDED(retVal))
{
retVal = pNewMimeType->SetSize(strNewMimeType.GetLength() + 1);
}
if (SUCCEEDED(retVal))
{
const char* pNewMimeTypeChars = (const char*) strNewMimeType;
strcpy((char*) pNewMimeType->GetBuffer(), pNewMimeTypeChars);
}
if (SUCCEEDED(retVal))
{
pHeader->SetPropertyCString("MimeType", pNewMimeType);
}
HX_RELEASE(pNewMimeType);
}
// Add the Suplement (OpaqueData)
if (SUCCEEDED(retVal) &&
pSuplement &&
(ulSuplementSize > 0))
{
IHXBuffer* pOpaqueData = NULL;
retVal = CreateAndSetBufferCCF(pOpaqueData, pSuplement, ulSuplementSize, m_pContext);
if (SUCCEEDED(retVal))
{
pHeader->SetPropertyBuffer("OpaqueData", pOpaqueData);
}
HX_RELEASE(pOpaqueData);
}
HX_RELEASE(pMimeType);
HX_VECTOR_DELETE(pSuplement);
return retVal;
}
/****************************************************************************
* IsStreamHeaderChangable
*/
HXBOOL CPNGFileWriter::IsStreamHeaderChangable(IHXValues* pNewHeader,
IHXValues* pOldHeader)
{
IHXBuffer* pBufferNew = NULL;
IHXBuffer* pBufferOld = NULL;
HXBOOL bRetVal = FALSE;
HX_ASSERT(pNewHeader);
HX_ASSERT(pOldHeader);
pNewHeader->GetPropertyCString("MimeType", pBufferNew);
pOldHeader->GetPropertyCString("MimeType", pBufferOld);
if (pNewHeader && pOldHeader)
{
if (strcasecmp((char*) pBufferNew->GetBuffer(),
(char*) pBufferOld->GetBuffer()) == 0)
{
bRetVal = TRUE;
}
}
HX_RELEASE(pBufferNew);
HX_RELEASE(pBufferOld);
return bRetVal;
}
/****************************************************************************
* IsSupportedMimeType
*/
HXBOOL CPNGFileWriter::IsSupportedMimeType(IHXBuffer* pMimeType)
{
char* pMimeTypeData;
HXBOOL bRetVal = FALSE;
HX_ASSERT(pMimeType);
pMimeTypeData = (char*)pMimeType->GetBuffer();
//clean up trailing space, may not need this
if (strlen(pMimeTypeData) != 0)
{
char *p = pMimeTypeData + strlen(pMimeTypeData)-1;
while (p>pMimeTypeData && *p == ' ') *(p--)=0;
}
HX_ASSERT(pMimeTypeData);
if (strcasecmp("video/X-HX-RGB", pMimeTypeData) == 0)
{
/*m_ulBitsPerSample = 16;
m_bSwapEndianess = TRUE;*/
bRetVal = TRUE;
}
return bRetVal;
}
/****************************************************************************
* IsPNGCompabitleStream
*/
HXBOOL CPNGFileWriter::IsPNGCompatibleStream(IHXValues* pHeader)
{
IHXBuffer* pBuffer = NULL;
HX_RESULT theErr = HXR_OK;
HXBOOL bCompatible = TRUE;
//do we support this mime type?
theErr = pHeader->GetPropertyCString("MimeType", pBuffer);
if (theErr == HXR_OK)
{
bCompatible = IsSupportedMimeType(pBuffer);
}
else
{
bCompatible = FALSE;
}
HX_RELEASE(pBuffer);
return bCompatible;
}
HX_RESULT CPNGFileWriter::CreatePNGFile(void)
{
HX_RESULT theErr = HXR_OK;
char* pURL;
char *pfilename;
if (m_pRequest->GetURL((const char *&)pURL) != HXR_OK)
{
theErr = HXR_FAIL;
}
if (theErr == HXR_OK)
{
char* temp;
//a very limited URL to filename converter
if( strnicmp(pURL, "file://",strlen("file://"))==0 )
{
pfilename = pURL+strlen("file://");
}
else
{
char str_index[5] = {0, };
temp = (char *)malloc(strlen(pfilename)+1000);
memset(temp, '\0', strlen(pfilename)+1000);
char* token;
pfilename = pURL;
token = strtok(pfilename, ".");
if (token != NULL)
{
strncat(temp, token, strlen(pfilename)+1000);
_itoa(m_ulIndex++, str_index, 10);
if (!strcmp(str_index, "0") == 0)
{
strncat(temp, "_", strlen(pfilename)+1000);
strncat(temp, str_index, strlen(pfilename)+1000);
}
strncat(temp, ".png", strlen(pfilename)+1000);
}
}
/*m_hOutFile = open(pfilename, O_CREAT|O_RDWR|O_TRUNC|O_BINARY, S_IREAD|S_IWRITE);
if (m_hOutFile == -1)
{
theErr = HXR_FAIL;
}*/
if (fp == NULL)
{
fp = fopen(temp/*pfilename*/, "wb");
if (temp)
{
free(temp);
}
}
if (!fp)
{
// Couldn't open file for writing
return HXR_FAIL;
}
/* Create and initialize the png_struct with the desired error handler
* functions. If you want to use the default stderr and longjump method,
* you can supply NULL for the last three parameters. We also check that
* the library version is compatible with the one used at compile time,
* in case we are using dynamically linked libraries. REQUIRED.
*/
png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING,
NULL, // pointer to user error struct
NULL, // point to user error function
NULL); // point to user warning function
if (png_ptr == NULL)
{
theErr = HXR_FAIL;
}
/* Allocate/initialize the image information data. REQUIRED */
info_ptr = png_create_info_struct(png_ptr);
if (info_ptr == NULL)
{
png_destroy_write_struct(&png_ptr, (png_infopp)NULL);
theErr = HXR_FAIL;
}
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(png_ptr)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&png_ptr, &info_ptr);
theErr = HXR_FAIL;
}
/* set up the output control if you are using standard C streams */
png_init_io(png_ptr, fp);
}
return theErr;
}
HX_RESULT CPNGFileWriter::WritePNGFileHeader(void)
{
HX_RESULT theErr = HXR_OK;
if(!fp || m_pCurrentStreamHeader==NULL )
{
return HXR_FAIL;
}
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(png_ptr)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&png_ptr, &info_ptr);
return HXR_FAIL;
}
/* Set the image information here. Width and height are up to 2^31,
* bit_depth is one of 1, 2, 4, 8, or 16, but valid values also depend on
* the color_type selected. color_type is one of PNG_COLOR_TYPE_GRAY,
* PNG_COLOR_TYPE_GRAY_ALPHA, PNG_COLOR_TYPE_PALETTE, PNG_COLOR_TYPE_RGB,
* or PNG_COLOR_TYPE_RGB_ALPHA. interlace is either PNG_INTERLACE_NONE or
* PNG_INTERLACE_ADAM7, and the compression_type and filter_type MUST
* currently be PNG_COMPRESSION_TYPE_BASE and PNG_FILTER_TYPE_BASE. REQUIRED
*/
png_set_IHDR(png_ptr, info_ptr, m_ulWidth, m_ulHeight, 8 /*bit_depth*/, PNG_COLOR_TYPE_RGB,
PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
/* Write the file header information. REQUIRED */
png_write_info(png_ptr, info_ptr);
return theErr;
}
HX_RESULT CPNGFileWriter::WritePNGPacket(IHXBuffer* pBuffer)
{
HX_RESULT retVal = HXR_FAIL;
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(png_ptr)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&png_ptr, &info_ptr);
return HXR_FAIL;
}
/* flip the RGB pixels to BGR (or RGBA to BGRA) */
if (PNG_COLOR_TYPE_RGB & PNG_COLOR_MASK_COLOR)
{
png_set_bgr(png_ptr);
}
const int bytes_per_pixel = 3;
UCHAR* tmp = pBuffer->GetBuffer();
//png_byte image[height][width*bytes_per_pixel];
//png_byte *image = (png_byte*)malloc(height * width*bytes_per_pixel);
//png_byte* row_pointers[height];
png_byte **row_pointers = new png_byte*[m_ulHeight];
for (int k = 0; k < m_ulHeight; k++) {
//row_pointers[k] = image[k];
row_pointers[k] = (png_byte*)(&(tmp[k*m_ulWidth*bytes_per_pixel]));
}
png_write_image(png_ptr, row_pointers);
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(png_ptr)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&png_ptr, &info_ptr);
return HXR_FAIL;
}
png_write_end(png_ptr, NULL); // NULL because we don't need to
// write any comments, etc.
if (row_pointers)
{
delete []row_pointers;
/*for (int i=0; i < height; i++)
{
delete row_pointers[i];
}*/
}
return HXR_OK;
}
void CPNGFileWriter::EncryptPNGPacket(UINT8* pBuffer, UINT32 size)
{
//size -= size % AES_BLOCK_SIZE;
//use overlapped encryption to handle non-aligned data
//int ret;
//AESEncryptWithKey(pBuffer, size, m_ContentKey, &ret);
for (unsigned int i=0 ; i 0)
{
return m_lRefCount;
}
delete this;
return 0;
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrtr.h,v 1.5 2007/09/10 00:03:56 milko Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifndef _PNGWRTR_H_
#define _PNGWRTR_H_
/****************************************************************************
* Defines
*/
#define FILE_HEADER_SET "FileHeader"
#define STRM_HEADER_SET "StreamHeader"
#define FWRT_PROPERTY_SET "Properties"
#define SUPLEMENTED_STRM_HEADER_SET "SuplementedStreamHeader"
/****************************************************************************
* Includes
*/
#include "hxtypes.h"
#include "hxcom.h"
#include "hxfwrtr.h"
#include "hxplugn.h"
#include "hxengin.h"
#include "cstrmsrt.h"
#include "png.h"
class CDeInterleaver;
class CStreamParam;
/****************************************************************************
* Globals
*/
extern INT32 g_nRefCount_pngwr;
/****************************************************************************
* CPNGFileWriter Class
*/
class CPNGFileWriter : public IHXPlugin,
public IHXFileWriter,
public IHXFileWriterMonitor,
public IHXPropertyAdviser,
public IHXCallback
{
public:
/*
* Constructor/Desctructor
*/
CPNGFileWriter(IUnknown* pContext = NULL);
/*
* IUnknown methods
*/
STDMETHOD(QueryInterface) (THIS_
REFIID riid,
void** ppvObj);
STDMETHOD_(ULONG32,AddRef) (THIS);
STDMETHOD_(ULONG32,Release) (THIS);
/*
* IHXPlugin methods
*/
STDMETHOD(GetPluginInfo) (THIS_
REF(HXBOOL) bLoadMultiple,
REF(const char*) pDescription,
REF(const char*) pCopyright,
REF(const char*) pMoreInfoURL,
REF(ULONG32) ulVersionNumber
);
STDMETHOD(InitPlugin) (THIS_
IUnknown* /*IN*/ pContext);
/*
* IHXFileWriter methods
*/
STDMETHOD(GetFileFormatInfo)(THIS_
REF(const char**) /*OUT*/ pFileMimeTypes,
REF(const char**) /*OUT*/ pFileExtensions,
REF(const char**) /*OUT*/ pFileOpenNames
);
STDMETHOD(InitFileWriter) (THIS_
IHXRequest* pRequest,
IHXFileWriterMonitor* pMonitor,
IHXPropertyAdviser* pAdviser
);
STDMETHOD(Close) (THIS);
STDMETHOD(Abort) (THIS);
STDMETHOD(SetFileHeader) (THIS_
IHXValues* pHeader
);
STDMETHOD(SetStreamHeader) (THIS_
IHXValues* pHeader
);
STDMETHOD(SetProperties) (THIS_
IHXValues* pProperties
);
STDMETHOD(SetPacket) (THIS_
IHXPacket* pPacket
);
STDMETHOD(StreamDone) (THIS_
UINT16 unStreamNumber
);
/*
* IHXFileWriterMonitor methods
*/
STDMETHOD(OnStatus) (THIS_
HX_RESULT status,
IHXValues* pInfoList
);
STDMETHOD(OnVolumeInitiation) (THIS_
HX_RESULT status,
const char* pFileName,
REF(ULONG32) ulTag
);
STDMETHOD(OnPacketsReady) (THIS_
HX_RESULT status
);
STDMETHOD(OnVolumeCompletion) (THIS_
HX_RESULT status,
ULONG32 ulTag
);
STDMETHOD(OnCompletion) (THIS_
HX_RESULT status
);
/*
* IHXPropertyAdviser methods
*/
STDMETHOD(GetPropertyULONG32) (THIS_
const char* pPropertyName,
REF(ULONG32) ulPropertyValue
);
STDMETHOD(GetPropertyBuffer) (THIS_
const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue
);
STDMETHOD(GetPropertyCString) (THIS_
const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue
);
STDMETHOD(GetPropertySet) (THIS_
const char* pPropertySetName,
REF(IHXValues*) pPropertySet
);
/*
* IHXCallback methods
*/
STDMETHOD(Func) (THIS);
private:
typedef enum
{
Offline,
PacketsReady,
Finishing
} WriterState;
static const char* zm_pDescription;
static const char* zm_pCopyright;
static const char* zm_pMoreInfoURL;
static const char* zm_pFileMimeTypes[];
static const char* zm_pFileExtensions[];
static const char* zm_pFileOpenNames[];
HX_RESULT SuplementStreamHeader(IHXValues* pHeader);
HXBOOL IsStreamHeaderChangable(IHXValues* pNewHeader,
IHXValues* pOldHeader);
HXBOOL IsSupportedMimeType(IHXBuffer* pMimeType);
HXBOOL IsPNGCompatibleStream(IHXValues* pStreamHeader);
HX_RESULT CreatePNGFile(void);
HX_RESULT WritePNGFileHeader(void);
HX_RESULT WritePNGPacket(IHXBuffer* pBuffer);
void EncryptPNGPacket(UINT8* pBuffer, UINT32 size);
HX_RESULT ClosePNGFile(void);
IUnknown* m_pContext;
IHXRequest* m_pRequest;
IHXFileWriterMonitor* m_pMonitor;
IHXPropertyAdviser* m_pAdviser;
IHXValues* m_pProperties;
int m_hOutFile;
WriterState m_State;
HXBOOL m_bClosing;
IHXValues* m_pCurrentStreamHeader;
IHXValues* m_pFileHeader;
HXBOOL m_bStreamDone;
HXBOOL m_bSwapEndianess;
UINT32 m_ulBitsPerSample;
UINT32 m_ulFileSize;
UINT32 m_ulDataChunkSizeOffset;
UINT32 m_ulDataSize;
UINT32 m_ulChannels;
UINT16 m_uStreamCount;
IHXScheduler* m_pScheduler;
CallbackHandle m_CallbackHandle;
ULONG32 m_ulVolumeTag;
LONG32 m_lRefCount;
FILE* fp;
png_structp png_ptr;
png_infop info_ptr;
ULONG32 m_ulWidth;
ULONG32 m_ulHeight;
ULONG32 m_ulIndex;
INT16 m_uMaximumImageOutputFiles;
~CPNGFileWriter();
};
#endif /* _PNGWRTR_H_ */
-------------- next part --------------
#$Id: Umakefil,v 1.22 2008/08/22 06:56:11 hychoi Exp $
UmakefileVersion(2,0)
project.AddModuleIncludes("common/include",
"producersdk/include",
"video/include",
"common/log/logobserverfile/pub")
project.AddModuleLibraries( "datatype/tools/dtdriver/common[dtdrcomlib]",
"datatype/tools/dtdriver/engine[dtdrengine]",
"datatype/tools/dtdriver/decoder/common[dtdrdeclib]",
"datatype/tools/dtdriver/decoder/audio[dtdrauddec]",
"datatype/tools/dtdriver/decoder/video[dtdrviddec]",
"datatype/tools/minicntx",
"datatype/common/filewriter[wrtrlib]",
"datatype/image/png/filewriter[pngwrtr]",
"client/medpltfm[hxmedpltfmlib]",
"client/common/netio[netioclntlib]",
"client/common/container[contclntlib]",
"client/common/system[sysclntlib]",
"client/common/util[utlclntlib]",
"common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"common/lang/xml[xmllib]",
"common/util[utillib]",
"common/container[contlib]",
"common/system[syslib]",
"video/vidutil[vidutillib]",
"common/fileio[fileiolib]",
"common/log/logutil[logutillib]")
if project.IsDefined("HELIX_FEATURE_MINICONTEXT_PLAYBACK_NET"):
project.AddModuleLibraries( "client/netwksvc[netsvclib]",
"common/netio[netiolib]",
"client/common/netio[netioclntlib]",
"protocol/http[httplib]",
"protocol/common/util[protutillib]")
if project.IsDefined("HELIX_FEATURE_MINICONTEXT_XMLPARSER"):
project.AddModuleLibraries( "common/lang/xml[xmllib]")
if project.IsDefined("HELIX_FEATURE_MISU"):
project.AddModuleLibraries( "client/videosvc[vidsvclib]")
if project.IsDefined("HELIX_FEATURE_DTDR_MIXER"):
project.AddModuleLibraries("client/audiosvc[audsvclib]")
if ('HELIX_FEATURE_GAINTOOL' in project.defines):
project.AddModuleLibraries("audio/gaintool[audgainlib]" )
if ('HELIX_FEATURE_CROSSFADE' in project.defines):
project.AddModuleLibraries("audio/crossfade[audxfadelib]")
if ('HELIX_FEATURE_LIMITER' in project.defines):
project.AddModuleLibraries('audio/limiter[audlimiter]')
if ('HELIX_FEATURE_RESAMPLER' in project.defines):
if ('HELIX_CONFIG_FIXEDPOINT' in project.defines):
project.AddModuleLibraries('audio/fixptresampler[fixptresampler]')
else:
project.AddModuleLibraries('audio/resampler[audresamplib]')
if project.IsDefined("HELIX_FEATURE_DTDR_MP3SRCHANDLER"):
project.AddModuleLibraries('datatype_rn/mp3/codec/encoder/srchndlr[mp3srchndlr]')
if project.BuildOption("nodll"):
## Add local file system
static_plugin_list = ["smplfsys"]
project.AddModuleLibraries("common/fileio[fileiolib]")
# Add RAM file format and renderer
if project.IsDefined("HELIX_FEATURE_META"):
static_plugin_list[-1:-1] = ["ramffpln"]
## Add realmedia file format
if project.IsDefined("HELIX_FEATURE_AUDIO_REAL") or \
project.IsDefined("HELIX_FEATURE_VIDEO_REAL"):
static_plugin_list[-1:-1] = ["rmffdll"]
project.AddModuleLibraries("datatype/common/util[dtutillib]")
project.AddLibraries(GetSDKPath("rmcom_lib"),
GetSDKPath("rmacom_lib"),
GetSDKPath("rmvidpyld_lib"),
GetSDKPath("rmff_lib"))
## Add realaudio renderer
if project.IsDefined("HELIX_FEATURE_AUDIO_REAL"):
static_plugin_list[-1:-1] = ["rarender"]
project.AddLibraries(GetSDKPath("rmarend_lib"),
GetSDKPath("rmacom_lib"))
## Add gecko realmedia codec
if project.IsDefined("HELIX_FEATURE_AUDIO_CODEC_GECKO"):
static_plugin_list[-1:-1] = ["cook"]
if not project.IsDefined("HELIX_FEATURE_FIXEDPOINT"):
project.AddLibraries(GetSDKPath("ra8lbrdec_flt_lib"))
else:
project.AddLibraries(GetSDKPath("ra8lbrdec_fix_lib"))
project.AddModuleLibraries("datatype/rm/audio/codec/common[racompat]")
## Add sipro realmedia codec
if project.IsDefined("HELIX_FEATURE_AUDIO_CODEC_SIPRO"):
static_plugin_list[-1:-1] = ["sipr"]
project.AddLibraries(GetSDKPath("sipro_lib"))
## Add realvideo renderer
if project.IsDefined("HELIX_FEATURE_VIDEO_REAL"):
project.AddModuleLibraries("datatype/common/vidrend[vidrend]",
"datatype_dist/rm/video/common[rvcomlib]",
"datatype/common/util[dtutillib]",
"datatype_dist/rm/video/payload[rvpyldlib]",
"datatype_dist/rm/video/codec/common[rvcodcomlib]")
project.AddLibraries(GetSDKPath("rmvidcom_lib"),
GetSDKPath("rmvidpyld_lib"),
GetSDKPath("rvcodcom_lib"))
project.AddModuleLibraries("datatype/common/vidrend[vidrend]",
"datatype/common/util[dtutillib]")
static_plugin_list[-1:-1] = ["rvxrend"]
## Add RV10 codec
if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV10"):
static_plugin_list[-1:-1] = ["rv10", "drv1"]
## Add RV20 codec
if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV20"):
project.AddLibraries(GetSDKPath("rvg2dec_libs")+"[rv20lib]",
GetSDKPath("rvg2dec_libs")+"[drv2lib]")
static_plugin_list[-1:-1] = ["rv20", "drv2"]
if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV30") or \
project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV40"):
static_plugin_list[-1:-1] = ["drvc"]
project.AddLibraries(GetSDKPath("rv89combo_libs")+"[drvclib]")
if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV30"):
static_plugin_list[-1:-1] = ["rv30"]
project.AddLibraries(GetSDKPath("rv89combo_libs")+"[rv3xlib]")
project.AddModuleLibraries("datatype/rm/video/codec/rv89combo[rv30]")
if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_RV40"):
static_plugin_list[-1:-1] = ["rv40"]
project.AddLibraries(GetSDKPath("rv89combo_libs")+"[rv4xlib]")
project.AddModuleLibraries("datatype/rm/video/codec/rv89combo[rv40]")
## Add mp3 file format and renderer
if project.IsDefined("HELIX_FEATURE_AUDIO_MPA_LAYER3") or \
project.IsDefined("HELIX_FEATURE_AUDIO_MPA_LAYER2") or \
project.IsDefined("HELIX_FEATURE_AUDIO_MPA_LAYER1"):
static_plugin_list[-1:-1] = ["mp3render"]
project.AddModuleLibraries("datatype/common/util[dtutillib]",
"datatype/mp3/codec[mp3codec]",
"datatype/mp3/common[mp3lib]",
"datatype/mp3/payload[mp3payld]")
static_plugin_list[-1:-1] = ["mp3fformat"]
project.AddModuleLibraries("datatype/mp3/common[mp3lib]")
## Add mpeg4 file format
if project.IsDefined("HELIX_FEATURE_VIDEO_H263") or \
project.IsDefined("HELIX_FEATURE_VIDEO_MPEG4") or \
project.IsDefined("HELIX_FEATURE_AUDIO_MPEG4"):
static_plugin_list[-1:-1] = ["qtffplin"]
project.AddModuleLibraries("protocol/common/util[protutillib]",
"protocol/sdp[sdplib]",
"protocol/rtsp[rtsplib]",
"datatype/common/util[dtutillib]",
"datatype/common/audrend",
"datatype/rm/common[rmcommonlib]",
"datatype/mp4/common[mp4comlib]",
"datatype/mp4/payload[mp4pyldlib]",
"datatype/amr/common[amrcomlib]")
## Add mpeg 4 audio renderer
if project.IsDefined("HELIX_FEATURE_AUDIO_MPEG4"):
static_plugin_list[-1:-1] = ["mp4arend"]
project.AddModuleLibraries("datatype/amr/common[amrcomlib]")
## To-do need to specify linking of AMR and AAC decoders
# Video not support yet
## Add h.263 renderer
if project.IsDefined("HELIX_FEATURE_VIDEO_H263"):
project.AddModuleLibraries("datatype/h263/payload[h263pyldlib]")
static_plugin_list[-1:-1] = ["h263rend"]
## Add MPEG4 renderer
if project.IsDefined("HELIX_FEATURE_VIDEO_MPEG4"):
static_plugin_list[-1:-1] = ["mp4xrend"]
## To-do need to specify linking of H263 decoder
CreateStaticPluginTable(static_plugin_list)
project.AddSources( "main.cpp",
"dlliids.cpp")
project.AddDefines( 'HELIX_FEATURE_VIDREND_UNTIMED_DECODE',
'HELIX_FEATURE_ALLOW_DEPRECATED_SMARTPOINTERS' )
ProgramTarget('dtdrive')
DependTarget()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp.diff
Type: application/octet-stream
Size: 2528 bytes
Desc: main.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080909/25fbb188/main.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.cpp.diff
Type: application/octet-stream
Size: 2238 bytes
Desc: ffdriver.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080909/25fbb188/ffdriver.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.h.diff
Type: application/octet-stream
Size: 1007 bytes
Desc: ffdriver.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080909/25fbb188/ffdriver.h-0001.obj
From jrathore at real.com Mon Sep 8 15:02:05 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Mon Sep 8 13:21:49 2008
Subject: [datatype-dev] CR:[#8529]Fix for playback of AAC files which
hang at the last second.
In-Reply-To: <005501c911b0$a1808300$e4818900$@com>
References: <008001c90fa0$968173e0$f58016ac@corp.real.com>
<005501c911b0$a1808300$e4818900$@com>
Message-ID: <00d001c911fe$87fadd60$f58016ac@corp.real.com>
Thanks Eric.
Checked into HEAD, 310_atlas and 341_atlas
-Jyotsana
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Monday, September 08, 2008 5:44 AM
To: 'Jyotsana Rathore'; midplayer-private-dev@helixcommunity.org;
datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR:[#8529]Fix for playback of AAC files which
hang at the last second.
Looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Jyotsana Rathore
>Sent: Friday, September 05, 2008 5:45 PM
>To: midplayer-private-dev@helixcommunity.org;
datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR:[#8529]Fix for playback of AAC files which hang
at the last second.
>
>Modified by: jrathore@real.com
>Date: 09/05/08
>Project: RealPlayer for MID
>
>Synopsis: Fix for playback of AAC files which hang at the last second.
>
>Overview: Files ripped as AAC from CDs sometimes have "APE" Tag tacked at
the end of file. This tag
>contains metadata information like Title, Artist, and Year etc. When AAC
file format encounters this
>non-AAC data, it returns HXR_INVALID_FILE error but this error gets
masked/ignored on its way up and
>the file format never issues a StreamDone() and never throws an error. This
fix, first checks if its
>an "APE" tag and if true, calls StreamDone() because this tag is always at
the end of file. If not,
>then code has been added to report the HXR_INVALID_FILE error.
>
>Files Added: None
>
>Files Modified:
>aacff.cpp (/datatype/aac/fileformat/aacff.cpp)
>aacff.h (/datatype/aac/fileformat/pub/aacff.h)
>
>Image Size and Heap Use impact (Client -Only): None
>
>Platforms and Profiles Affected:
>Platform: win32-i386-vc7
>Profile: helix-client-all-defines
>
>Platforms and Profiles Build and Functionality Verified:
>Platform: win32-i386-vc7
>Profile: helix-client-all-defines
>target(s): splay
>
>Branch: hxclient_3_1_0_atlas, HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>Files Attached: aacff.diff
>
>-Jyotsana
From ehyche at real.com Tue Sep 9 07:07:59 2008
From: ehyche at real.com (Eric Hyche)
Date: Tue Sep 9 05:27:30 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
In-Reply-To:
References:
Message-ID: <004801c91285$787ae4c0$6970ae40$@com>
Hayoung,
Here is my review:
1) dlliids.cpp - looks good.
2) ffdriver.h
+#define MAXNUMIMAGEOUTPUTFILES_OPTION_NAME "MaximumImageOutputFiles"
Option string should "MaximumNumImageOutputFiles".
+ HXBOOL m_bThumbnail;
+ ULONG32 m_ulMaxOutFiles;
Best I can tell from looking at the ffdriver.cpp changes, there
is no need for these two variables. They do not appear to be
needed in the ffdriver.cpp changes.
3) ffdriver.cpp
-
+#include "ciddefs.h"
This will become unnecessary with my comment regarding color conversion
below.
+ , m_bThumbnail(FALSE)
+ , m_ulMaxOutFiles(0)
Again, these don't appear to be needed.
+ else if (strcmp(pOptName, MAXNUMIMAGEOUTPUTFILES_OPTION_NAME) == 0)
+ {
+ m_bThumbnail = TRUE;
+ //ULONG32 retVal = m_pOptions-
>GetPropertyULONG32(MAXNUMIMAGEOUTPUTFILES_OPTION_NAME, m_ulMaxOutFiles);
+ }
This doesn't appear to be needed.
+ const char** ppszMimeTypes = NULL;
+ const char** ppszExtensions = NULL;
+ const char** ppszOpenNames = NULL;
+ m_pFileWriter->GetFileFormatInfo(ppszMimeTypes, ppszExtensions,
ppszOpenNames);
+
+ if (strcmp(*ppszExtensions, "png") == 0)
+ {
+ m_pOptions->SetPropertyULONG32(COLORCONVERT_OPTION_NAME, CID_RGB24);
+ }
+
After further discussions with Milko, we decided the best place
to handle color conversion for the PNG file writer would be
in the PNG file writer itself. That does not mean that
your changes in the video decoder are unnecessary - it
is still a very useful thing to have the ability to color
convert the output.
Therefore, after you get the initial checkin of the PNG file
writer completed, we will want to add the ability to color convert
(if necessary) in the PNG file writer. So if the PNG file writer
detects that it is getting a color format that is not RGB, then
it color converts there (in a similar way to what you added in
vdecoder.cpp) to RGB.
But for now (this checkin), we will just not worry about color
conversion, since the color conversion can be manually set
by the user.
So the above change can be removed.
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulMaxOutFiles = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(MAXNUMIMAGEOUTPUTFILES_OPTION_NAME, ulMaxOutFiles)))
+ {
+ retVal = pNewProps->SetPropertyULONG32("MaximumImageOutputFiles", ulMaxOutFiles);
+ }
+ }
We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
places instead of using the string "MaximumImageOutputFiles"
in the SetPropertyULONG32.
4) main.cpp
These changes look good. Please also add a usage string for the "MOF" dtdrive.exe
command-line option, similar to the one you added for the "CC" command-line option.
5) datatype/tools/dtdriver/engine/Umakefil
You included the whole file - do you have a diff for this file?
6) pngwrpln.h
It doesn't look like this file is necessary.
7) pngwrpln.cpp
>STDAPI ENTRYPOINT(RMACreateInstance)
This should be:
STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(HXCreateInstance)
>STDAPI ENTRYPOINT(CanUnload)(void)
>{
> return (g_nRefCount_pngwr ? HXR_FAIL : HXR_OK);
>}
CanUnload should be implemented using CHXBaseCountingObject. CPNGFileWriter
should derive from CHXBaseCountingObject and then CanUnload
can be implemented using CHXBaseCountingObject::ObjectsActive().
See datatype/aac/fileformat/aacffdll.cpp for an example.
8) pngwrtr.h
>extern INT32 g_nRefCount_pngwr;
This is no longer needed after you change to using CHXBaseCountingObject.
> FILE* fp;
> png_structp png_ptr;
> png_infop info_ptr;
Please give all class member variables a "m_" prefix in their
name so they can be easily identified as member variables.
> INT16 m_uMaximumImageOutputFiles;
The "m_u" prefix would indicate this is an *unsigned* variable, but
you have it as signed. Is there any reason this should not just
be a UINT32 and be called "m_ulMaximumImageOutputFiles"?
9) pngwrtr.cpp
>INT32 g_nRefCount_pngwr = 0;
No longer needed.
>const char* CPNGFileWriter::zm_pDescription = "Helix Portable File Writer Plugin";
The string should be "Helix PNG File Writer Plugin".
> InterlockedIncrement(&g_nRefCount_pngwr);
No longer needed.
> InterlockedDecrement(&g_nRefCount_pngwr);
No longer needed.
> if (IsPNGCompatibleStream(m_pCurrentStreamHeader))
For now, if the "MimeType" of the stream header is NOT
"video/X-HX-RGB", then SetStreamHeader() should return
an error. Later, once this checkin is complete, then you
can add code to color convert from whatever color format
to RGB (and then not return an error in SetStreamHeader).
> ULONG32 ulTemp = 0;
> m_pCurrentStreamHeader->GetPropertyULONG32("", ulTemp);
Not sure why this is here.
- The commented-out code in CPNGFileWriter::OnPacketsReady can be removed.
- It looks like CPNGFileWriter::SuplementStreamHeader is not needed
at all for the PNG file writer.
- In CreatePNGFile:
- Is strnicmp() cross-platform?
- Use the new operator and not malloc()
- I believe that _itoa is Windows-specific, correct? If so,
you need to only use functions that are cross-platform.
- EncryptPNGPacket() doesn't seem to be needed.
- In ClosePNGFile:
if (png_ptr)
{
png_ptr = NULL;
}
if (info_ptr)
{
info_ptr = NULL;
}
Both png_ptr and info_ptr need to be deleted with libpng functions, correct?
10) Umakefil for pngwrtr looks good.
General comments:
- I didn't see any BIF file changes. These should be included with the CR.
- I'm assuming the PNG file writer is going to be checked in
at datatype/image/png/filewriter, correct?
- Since we know we are going to be making changes to the PNG file writer
after this initial checkin, then there's no need to initially branch
the PNG file writer to 310Atlas. We can do that once we have finished
adding everything we want. Adding it to just the HEAD is sufficient for now.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ???(Hayoung Choi) [mailto:hayoung.choi@ap.real.com]
>Sent: Monday, September 08, 2008 5:40 PM
>To: datatype-dev@lists.helixcommunity.org
>Cc: ehyche@real.com; milko@real.com; hyoon@real.com
>Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
>
>Date: September 8, 2008
>
>Project: Thumbnail Generation Improvement (for PNG)
>
>Synopsis:
>
>=============
>
>This CR is for PNG thumbnail generation through the dtdrive.
>
>The option newly added MOF(Maximum image Output Files) describes the number of values how many
>thumbnail images be generated.
>
>If put the option "-W xxx.png", then it automatically converts the color format to RGB24 and generates
>a PNG thubnail.
>
>
>
>Overview:
>
>=============
>
>1) PNG file writer plug-in added
>
>Under datatype/image/png/filewriter, source codes were added for supporting to write PNG file.
>
>
>
>2) Modifying main.cpp and ffdriver.cpp and ffdriver.h
>
>To support the option MOF and color converting automatically, above three files were modified.
>
>
>
>3) Test
>
>D:\source\dtdriver\debug>dtdrive.exe +u +f -DV 1 -PTU 10 -MOF 5 -W videotest.png videotest.rm
>
>
>
>Files Added:
>
>=============
>
>[File 1] - datatype/image/png/filewriter/Umakefil
>
>[File 2] - datatype/image/png/filewriter/dlliids.cpp
>
>[File 3] - datatype/image/png/filewriter/pngwrpln.cpp
>
>[File 4] - datatype/image/png/filewriter/pngwrpln.h
>
>[File 5] - datatype/image/png/filewriter/pngwrtr.cpp
>
>[File 6] - datatype/image/png/filewriter/pngwrtr.h
>
>
>
>Files Modified:
>
>=============
>
>[File 7] - datatype/tools/dtdriver/apps/dtdrive/Umakefil
>
>[File 8] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
>
>[File 9] - datatype/tools/dtdriver/engine/Umakefil
>
>[File10] - datatype/tools/dtdriver/engine/ffdriver.cpp
>
>[File11] - datatype/tools/dtdriver/engine/pub/ffdriver.h
>
>
>
>=============
>
>Image Size and Heap Use impact (Client -Only):
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Affected:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>=============
>
>Distribution Libraries Affected:
>
>pngwrtr.dll
>
>dtdrive.lib
>
>dtdrengine.lib
>
>
>
>=============
>
>Distribution library impact and planned action:
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Build Verified:
>
>System id: win32-i386-vc7
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>Microsoft Compiler 13.10.6030
>
>
>
>=============
>
>Platforms and Profiles Functionality verified:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>Branch: hxclient_restricted, hxclient_3_1_0_atlas
>
>Target: dtdrive
>
>Profile: helix-client-all-defines
>
>
>
>=============
>
>Copyright assignment:
>
>I am a RealNetworks employee or contractor
>
>=============
>
>QA Instructions:
>
>NA
From ext-anuj.dhamija at nokia.com Tue Sep 9 14:06:58 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Tue Sep 9 12:26:46 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in Helix
Message-ID: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Diff.zip
Type: application/x-zip-compressed
Size: 8229 bytes
Desc: Diff.zip
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080909/ad721850/Diff-0001.bin
From hayoung.choi at ap.real.com Tue Sep 9 20:52:13 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Tue Sep 9 19:11:40 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
References:
<004801c91285$787ae4c0$6970ae40$@com>
Message-ID:
Eric,
My comments are below.
Thanks,
Hayoung
________________________________
From: Eric Hyche [mailto:ehyche@real.com]
Sent: 2008-09-09 (?) ?? 11:07
To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
Cc: milko@real.com; hyoon@real.com
Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Hayoung,
Here is my review:
1) dlliids.cpp - looks good.
2) ffdriver.h
+#define MAXNUMIMAGEOUTPUTFILES_OPTION_NAME "MaximumImageOutputFiles"
Option string should "MaximumNumImageOutputFiles".
==> [Hayoung] Okay, I correct this.
+ HXBOOL m_bThumbnail;
+ ULONG32 m_ulMaxOutFiles;
Best I can tell from looking at the ffdriver.cpp changes, there
is no need for these two variables. They do not appear to be
needed in the ffdriver.cpp changes.
==> [Hayoung] Okay, I removed this.
3) ffdriver.cpp
-
+#include "ciddefs.h"
This will become unnecessary with my comment regarding color conversion
below.
==> [Hayoung] I see. I'll remove after initial check-in first.
+ , m_bThumbnail(FALSE)
+ , m_ulMaxOutFiles(0)
Again, these don't appear to be needed.
==> [Hayoung] Okay, I removed this.
+ else if (strcmp(pOptName, MAXNUMIMAGEOUTPUTFILES_OPTION_NAME) == 0)
+ {
+ m_bThumbnail = TRUE;
+ //ULONG32 retVal = m_pOptions-
>GetPropertyULONG32(MAXNUMIMAGEOUTPUTFILES_OPTION_NAME, m_ulMaxOutFiles);
+ }
This doesn't appear to be needed.
==> [Hayoung] Okay, I removed this.
+ const char** ppszMimeTypes = NULL;
+ const char** ppszExtensions = NULL;
+ const char** ppszOpenNames = NULL;
+ m_pFileWriter->GetFileFormatInfo(ppszMimeTypes, ppszExtensions,
ppszOpenNames);
+
+ if (strcmp(*ppszExtensions, "png") == 0)
+ {
+ m_pOptions->SetPropertyULONG32(COLORCONVERT_OPTION_NAME, CID_RGB24);
+ }
+
After further discussions with Milko, we decided the best place
to handle color conversion for the PNG file writer would be
in the PNG file writer itself. That does not mean that
your changes in the video decoder are unnecessary - it
is still a very useful thing to have the ability to color
convert the output.
Therefore, after you get the initial checkin of the PNG file
writer completed, we will want to add the ability to color convert
(if necessary) in the PNG file writer. So if the PNG file writer
detects that it is getting a color format that is not RGB, then
it color converts there (in a similar way to what you added in
vdecoder.cpp) to RGB.
But for now (this checkin), we will just not worry about color
conversion, since the color conversion can be manually set
by the user.
So the above change can be removed.
==> [Hayoung] Okay, I removed above. So for now, to generate the PNG thumbnail it should be processed with *the value of CC option* together.
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulMaxOutFiles = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(MAXNUMIMAGEOUTPUTFILES_OPTION_NAME, ulMaxOutFiles)))
+ {
+ retVal = pNewProps->SetPropertyULONG32("MaximumImageOutputFiles", ulMaxOutFiles);
+ }
+ }
We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
places instead of using the string "MaximumImageOutputFiles"
in the SetPropertyULONG32.
==> [Hayoung] It seems that the other options also have been used the "string" in the SetPropertyULONG32, not XXXX_OPTION_NAME value. So I used the string value to be consistent with them. How do you think?
4) main.cpp
These changes look good. Please also add a usage string for the "MOF" dtdrive.exe
command-line option, similar to the one you added for the "CC" command-line option.
==> [Hayoung] Okay, I added a usage string for the "MOF" option.
5) datatype/tools/dtdriver/engine/Umakefil
You included the whole file - do you have a diff for this file?
==> [Hayoung] I missed the diff file, I'll send it on next.
6) pngwrpln.h
It doesn't look like this file is necessary.
7) pngwrpln.cpp
>STDAPI ENTRYPOINT(RMACreateInstance)
This should be:
STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(HXCreateInstance)
==> [Hayoung] Okay, I correct this.
>STDAPI ENTRYPOINT(CanUnload)(void)
>{
> return (g_nRefCount_pngwr ? HXR_FAIL : HXR_OK);
>}
CanUnload should be implemented using CHXBaseCountingObject. CPNGFileWriter
should derive from CHXBaseCountingObject and then CanUnload
can be implemented using CHXBaseCountingObject::ObjectsActive().
See datatype/aac/fileformat/aacffdll.cpp for an example.
==> [Hayoung] Okay, I changed this to use CHXBaseCountingObject::ObjectActive().
8) pngwrtr.h
>extern INT32 g_nRefCount_pngwr;
This is no longer needed after you change to using CHXBaseCountingObject.
==> [Hayoung] Okay, I removed this.
> FILE* fp;
> png_structp png_ptr;
> png_infop info_ptr;
Please give all class member variables a "m_" prefix in their
name so they can be easily identified as member variables.
==> [Hayoung] Okay, I correct those to identify easily.
> INT16 m_uMaximumImageOutputFiles;
The "m_u" prefix would indicate this is an *unsigned* variable, but
you have it as signed. Is there any reason this should not just
be a UINT32 and be called "m_ulMaximumImageOutputFiles"?
==> [Hayoung] At first time, I used the INT16 type just to test the function, however now I changed the type to UINT32 and name as well.
9) pngwrtr.cpp
>INT32 g_nRefCount_pngwr = 0;
No longer needed.
==> [Hayoung] Okay, I removed this.
>const char* CPNGFileWriter::zm_pDescription = "Helix Portable File Writer Plugin";
The string should be "Helix PNG File Writer Plugin".
==> [Hayoung] Okay, I correct this.
> InterlockedIncrement(&g_nRefCount_pngwr);
No longer needed.
==> [Hayoung] Okay, I removed this.
> InterlockedDecrement(&g_nRefCount_pngwr);
==> [Hayoung] Okay, I removed this.
No longer needed.
> if (IsPNGCompatibleStream(m_pCurrentStreamHeader))
==> [Hayoung] Okay, I removed this.
For now, if the "MimeType" of the stream header is NOT
"video/X-HX-RGB", then SetStreamHeader() should return
an error. Later, once this checkin is complete, then you
can add code to color convert from whatever color format
to RGB (and then not return an error in SetStreamHeader).
==> [Hayoung] Okay, I'll keep this in mind.
> ULONG32 ulTemp = 0;
> m_pCurrentStreamHeader->GetPropertyULONG32("", ulTemp);
Not sure why this is here.
==> [Hayoung] Okay, I removed this.
- The commented-out code in CPNGFileWriter::OnPacketsReady can be removed.
==> [Hayoung] Okay, I removed this.
- It looks like CPNGFileWriter::SuplementStreamHeader is not needed
at all for the PNG file writer.
==> [Hayoung] Okay, I removed this.
- In CreatePNGFile:
- Is strnicmp() cross-platform?
==> [Hayoung] Yes, because it use _strnicmp() function internally. The "strnicmp" function is defined like below in hxstring.h.
#define strnicmp strncasecmp
strncasecmp(const char* str1, const char* str2, int len)
{
return _strnicmp(str1, str2, (size_t) len);
}
- Use the new operator and not malloc()
==> [Hayoung] Okay, I changed it to use new operator.
- I believe that _itoa is Windows-specific, correct? If so,
you need to only use functions that are cross-platform.
==> [Hayoung] Right. _itoa is Windows-specific, so I replaced it as sprintf function.
- EncryptPNGPacket() doesn't seem to be needed.
==> [Hayoung] Okay, I removed this.
- In ClosePNGFile:
if (png_ptr)
{
png_ptr = NULL;
}
if (info_ptr)
{
info_ptr = NULL;
}
Both png_ptr and info_ptr need to be deleted with libpng functions, correct?
==> [Hayoung] Okay, I added the png_destroy_write_struct() which frees allocated memory related png struct.
10) Umakefil for pngwrtr looks good.
General comments:
- I didn't see any BIF file changes. These should be included with the CR.
==> [Hayoung] Okay, I will update BIF file to be changed.
- I'm assuming the PNG file writer is going to be checked in
at datatype/image/png/filewriter, correct?
==> [Hayoung] Correct.
- Since we know we are going to be making changes to the PNG file writer
after this initial checkin, then there's no need to initially branch
the PNG file writer to 310Atlas. We can do that once we have finished
adding everything we want. Adding it to just the HEAD is sufficient for now.
==> [Hayoung] Do you mean that check in only PNG file writer codes first and check in the other updates such as main.cpp.diff and ffdriver.cpp.diff later?
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ???(Hayoung Choi) [mailto:hayoung.choi@ap.real.com]
>Sent: Monday, September 08, 2008 5:40 PM
>To: datatype-dev@lists.helixcommunity.org
>Cc: ehyche@real.com; milko@real.com; hyoon@real.com
>Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
>
>Date: September 8, 2008
>
>Project: Thumbnail Generation Improvement (for PNG)
>
>Synopsis:
>
>=============
>
>This CR is for PNG thumbnail generation through the dtdrive.
>
>The option newly added MOF(Maximum image Output Files) describes the number of values how many
>thumbnail images be generated.
>
>If put the option "-W xxx.png", then it automatically converts the color format to RGB24 and generates
>a PNG thubnail.
>
>
>
>Overview:
>
>=============
>
>1) PNG file writer plug-in added
>
>Under datatype/image/png/filewriter, source codes were added for supporting to write PNG file.
>
>
>
>2) Modifying main.cpp and ffdriver.cpp and ffdriver.h
>
>To support the option MOF and color converting automatically, above three files were modified.
>
>
>
>3) Test
>
>D:\source\dtdriver\debug>dtdrive.exe +u +f -DV 1 -PTU 10 -MOF 5 -W videotest.png videotest.rm
>
>
>
>Files Added:
>
>=============
>
>[File 1] - datatype/image/png/filewriter/Umakefil
>
>[File 2] - datatype/image/png/filewriter/dlliids.cpp
>
>[File 3] - datatype/image/png/filewriter/pngwrpln.cpp
>
>[File 4] - datatype/image/png/filewriter/pngwrpln.h
>
>[File 5] - datatype/image/png/filewriter/pngwrtr.cpp
>
>[File 6] - datatype/image/png/filewriter/pngwrtr.h
>
>
>
>Files Modified:
>
>=============
>
>[File 7] - datatype/tools/dtdriver/apps/dtdrive/Umakefil
>
>[File 8] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
>
>[File 9] - datatype/tools/dtdriver/engine/Umakefil
>
>[File10] - datatype/tools/dtdriver/engine/ffdriver.cpp
>
>[File11] - datatype/tools/dtdriver/engine/pub/ffdriver.h
>
>
>
>=============
>
>Image Size and Heap Use impact (Client -Only):
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Affected:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>=============
>
>Distribution Libraries Affected:
>
>pngwrtr.dll
>
>dtdrive.lib
>
>dtdrengine.lib
>
>
>
>=============
>
>Distribution library impact and planned action:
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Build Verified:
>
>System id: win32-i386-vc7
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>Microsoft Compiler 13.10.6030
>
>
>
>=============
>
>Platforms and Profiles Functionality verified:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>Branch: hxclient_restricted, hxclient_3_1_0_atlas
>
>Target: dtdrive
>
>Profile: helix-client-all-defines
>
>
>
>=============
>
>Copyright assignment:
>
>I am a RealNetworks employee or contractor
>
>=============
>
>QA Instructions:
>
>NA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/5769dcd6/attachment-0001.html
From hayoung.choi at ap.real.com Tue Sep 9 21:09:19 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Tue Sep 9 19:28:45 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Umakefil.diff
Type: application/octet-stream
Size: 669 bytes
Desc: Umakefil.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/Umakefil-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp.diff
Type: application/octet-stream
Size: 3180 bytes
Desc: main.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/main.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Umakefil.diff
Type: application/octet-stream
Size: 710 bytes
Desc: Umakefil.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/Umakefil-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.cpp.diff
Type: application/octet-stream
Size: 1581 bytes
Desc: ffdriver.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/ffdriver.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.h.diff
Type: application/octet-stream
Size: 782 bytes
Desc: ffdriver.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/ffdriver.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix.bif.diff
Type: application/octet-stream
Size: 1784 bytes
Desc: helix.bif.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/45d2520d/helix.bif-0001.obj
-------------- next part --------------
# -*- python -*-
#
# ***** BEGIN LICENSE BLOCK *****
# Source last modified: $Id: Umakefil,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
#
# Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
#
# The contents of this file, and the files included with this file,
# are subject to the current version of the RealNetworks Public
# Source License (the "RPSL") available at
# http://www.helixcommunity.org/content/rpsl unless you have licensed
# the file under the current version of the RealNetworks Community
# Source License (the "RCSL") available at
# http://www.helixcommunity.org/content/rcsl, in which case the RCSL
# will apply. You may also obtain the license terms directly from
# RealNetworks. You may not use this file except in compliance with
# the RPSL or, if you have a valid RCSL with RealNetworks applicable
# to this file, the RCSL. Please see the applicable RPSL or RCSL for
# the rights, obligations and limitations governing use of the
# contents of the file.
#
# Alternatively, the contents of this file may be used under the
# terms of the GNU General Public License Version 2 (the
# "GPL") in which case the provisions of the GPL are applicable
# instead of those above. If you wish to allow use of your version of
# this file only under the terms of the GPL, and not to allow others
# to use your version of this file under the terms of either the RPSL
# or RCSL, indicate your decision by deleting the provisions above
# and replace them with the notice and other provisions required by
# the GPL. If you do not delete the provisions above, a recipient may
# use your version of this file under the terms of any one of the
# RPSL, the RCSL or the GPL.
#
# This file is part of the Helix DNA Technology. RealNetworks is the
# developer of the Original Code and owns the copyrights in the
# portions it created.
#
# This file, and the files included with this file, is distributed
# and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
# KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
# ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
# ENJOYMENT OR NON-INFRINGEMENT.
#
# Technology Compatibility Kit Test Suite(s) Location:
# http://www.helixcommunity.org/content/tck
#
# Contributor(s):
#
# ***** END LICENSE BLOCK *****
#
UmakefileVersion(2,1)
project.AddSources("dlliids.cpp",
"pngwrpln.cpp",
"pngwrtr.cpp"
)
project.AddModuleIncludes( "common/include",
"common/dbgtool/pub",
"common/container/pub",
"common/runtime/pub",
"common/util/pub",
"datatype/image/png/import/libpng",
"common/import/zlib/pub"
)
project.AddModuleLibraries( "common/container[contlib]",
"datatype/common/filewriter[wrtrlib]",
"common/util[utillib]",
"common/runtime[runtlib]",
"common/dbgtool[debuglib]",
"datatype/image/png/import/libpng[libpng]",
"common/import/zlib[zlib]"
)
project.ExportFunction("RMACreateInstance",
"IUnknown** ppObj",
"common/include",
"hxcom.h")
DLLTarget('pngwrtr')
DependTarget()
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: dlliids.cpp,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#define INITGUID 1
#include "hxcom.h"
#include "hxfwrtr.h"
#include "hxiids.h"
#include "hxpiids.h"
#undef INITGUID
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrpln.cpp,v 1.2 2007/07/06 22:02:09 jfinnecy Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#include "pngwrtr.h"
#include "pngwrpln.h"
#include "baseobj.h"
/****************************************************************************
* DLL Interface
*/
/****************************************************************************
* HXCreateInstance()
* Purpose:
* Function implemented by all plugin DLL's to create an instance of
* any of the objects supported by the DLL. This method is similar to
* Window's CoCreateInstance() in its purpose, except that it only
* creates objects from this plugin DLL.
*
* NOTE: Aggregation is never used. Therefore and outer unknown is
* not passed to this function, and you do not need to code for this
* situation.
*/
STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(HXCreateInstance)
(
IUnknown** /*OUT*/ ppIUnknown
)
{
*ppIUnknown = (IUnknown*)(IHXPlugin*) new CPNGFileWriter();
if (*ppIUnknown)
{
(*ppIUnknown)->AddRef();
return HXR_OK;
}
return HXR_OUTOFMEMORY;
}
/****************************************************************************
* CanUnload()
* Purpose:
* Function implemented by all plugin DLL's if it returns HXR_OK
* then the pluginhandler can unload the DLL
*/
STDAPI ENTRYPOINT(CanUnload)(void)
{
return (CHXBaseCountingObject::ObjectsActive() > 0 ? HXR_FAIL : HXR_OK);
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrtr.cpp,v 1.6 2007/09/10 00:03:56 milko Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#define VIDEO_MIME_PREFIX "video"
#define VIDEO_MIME_PREFIX_SIZE (sizeof(VIDEO_MIME_PREFIX) - 1)
#define AUDIO_MIME_PREFIX "audio"
#define AUDIO_MIME_PREFIX_SIZE (sizeof(AUDIO_MIME_PREFIX) - 1)
#define SUPLEMENTED_MIME_POSTFIX "-RN"
#define ENCRYPTED_MIME_EXTENSION "-encrypted"
#define ENCRYPTED_MIME_EXTENSION_SIZE (sizeof(ENCRYPTED_MIME_EXTENSION) - 1)
#define MIN_RESCHED_TIME 2 // in milliseconds
/****************************************************************************
* Includes
*/
#include "pngwrpln.h"
#include "pngwrtr.ver"
#include "hxmime.h"
#include "hxstring.h"
#include "hlxclib/string.h"
#include "hxstrutl.h"
#include "hxbuffer.h"
#include "hxver.h"
#include "chxpckts.h"
#include "pckunpck.h"
#include "rmfftype.h"
#include "netbyte.h"
#include "mimechk.h"
#include "pngwrtr.h"
#include "hlxclib/fcntl.h"
#if defined(_WIN32)
#include
#endif
/****************************************************************************
* CPNGFileWriter class
*/
const char* CPNGFileWriter::zm_pDescription = "Helix PNG File Writer Plugin";
const char* CPNGFileWriter::zm_pCopyright = HXVER_COPYRIGHT;
const char* CPNGFileWriter::zm_pMoreInfoURL = HXVER_MOREINFO;
const char* CPNGFileWriter::zm_pFileMimeTypes[] = {NULL};
const char* CPNGFileWriter::zm_pFileExtensions[] = {"png", NULL};
const char* CPNGFileWriter::zm_pFileOpenNames[] = {"PNG Image Files (*.png)", NULL};
/****************************************************************************
* Constructor/Destructor
*/
CPNGFileWriter::CPNGFileWriter(IUnknown* pUnknown)
: m_pContext(pUnknown)
, m_pRequest(NULL)
, m_pMonitor(NULL)
, m_pAdviser(NULL)
, m_pProperties(NULL)
, m_hOutFile(0)
, m_State(Offline)
, m_bClosing(TRUE)
, m_pCurrentStreamHeader(NULL)
, m_pFileHeader(NULL)
, m_bStreamDone(FALSE)
, m_bSwapEndianess(FALSE)
, m_ulBitsPerSample(0)
, m_ulFileSize(0)
, m_ulDataChunkSizeOffset(0)
, m_ulDataSize(0)
, m_ulChannels(0)
, m_uStreamCount(0)
, m_pScheduler(NULL)
, m_CallbackHandle(0)
, m_ulVolumeTag(0)
, m_lRefCount(0)
, m_pFile(NULL)
, m_ulWidth(0)
, m_ulHeight(0)
, m_ulIndex(0)
, m_uIMaxNumImageOutputFiles(0)
{
if (m_pContext)
{
m_pContext->AddRef();
}
}
CPNGFileWriter::~CPNGFileWriter(void)
{
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pProperties);
HX_RELEASE(m_pContext);
HX_RELEASE(m_pScheduler);
HX_RELEASE(m_pFileHeader);
HX_RELEASE(m_pCurrentStreamHeader);
}
/************************************************************************
* IHXPlugin methods
*/
/************************************************************************
* CPNGFileWriter::InitPlugin
* Purpose:
* Initializes the plugin for use. This interface must always be
* called before any other method is called. This is primarily needed
* so that the plugin can have access to the context for creation of
* IHXBuffers and IMalloc.
*/
STDMETHODIMP CPNGFileWriter::InitPlugin(IUnknown* /*IN*/ pContext)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_pFileHeader == NULL)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = HXR_INVALID_PARAMETER;
if (pContext)
{
HX_RELEASE(m_pContext);
m_pContext = pContext;
m_pContext->AddRef();
retVal = HXR_OK;
}
else if (m_pContext)
{
retVal = HXR_OK;
}
}
return retVal;
}
/************************************************************************
* CPNGFileWriter::GetPluginInfo
* Purpose:
* Returns the basic information about this plugin. Including:
*
* bLoadMultiple whether or not this plugin DLL can be loaded
* multiple times. All File Formats must set
* this value to TRUE.
* pDescription which is used in about UIs (can be NULL)
* pCopyright which is used in about UIs (can be NULL)
* pMoreInfoURL which is used in about UIs (can be NULL)
*/
STDMETHODIMP CPNGFileWriter::GetPluginInfo
(
REF(HXBOOL) bLoadMultiple,
REF(const char*) pDescription,
REF(const char*) pCopyright,
REF(const char*) pMoreInfoURL,
REF(ULONG32) ulVersionNumber
)
{
bLoadMultiple = TRUE; // Must be true for file formats.
pDescription = zm_pDescription;
pCopyright = zm_pCopyright;
pMoreInfoURL = zm_pMoreInfoURL;
ulVersionNumber = TARVER_ULONG32_VERSION;
return HXR_OK;
}
/****************************************************************************
* IHXFileWriter methods
*/
/************************************************************************
* GetFileFormatInfo
* Purpose:
* If this object is a file format object this method returns
* information vital to the instantiation of file format plugins.
* If this object is not a file format object, it should return
* HXR_UNEXPECTED.
*/
STDMETHODIMP CPNGFileWriter::GetFileFormatInfo
(
REF(const char**) /*OUT*/ pFileMimeTypes,
REF(const char**) /*OUT*/ pFileExtensions,
REF(const char**) /*OUT*/ pFileOpenNames
)
{
pFileMimeTypes = zm_pFileMimeTypes;
pFileExtensions = zm_pFileExtensions;
pFileOpenNames = zm_pFileOpenNames;
return HXR_OK;
}
/****************************************************************************
* InitFileWriter
*/
STDMETHODIMP CPNGFileWriter::InitFileWriter
(
IHXRequest* pRequest,
IHXFileWriterMonitor* pMonitor,
IHXPropertyAdviser* pAdviser
)
{
HX_RESULT retVal = HXR_UNEXPECTED;
IHXValues* pProperties = NULL;
if (m_pFileHeader == NULL)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = HXR_FAIL;
if (m_pContext)
{
HX_RELEASE(m_pScheduler);
// we may not need a scheduler
retVal = m_pContext->QueryInterface(IID_IHXScheduler,
(void**) &m_pScheduler);
}
}
if (SUCCEEDED(retVal))
{
if (pRequest)
{
pRequest->AddRef();
pRequest->GetRequestHeaders(pProperties);
}
if (pMonitor)
{
pMonitor->AddRef();
}
if (pAdviser)
{
pAdviser->AddRef();
}
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
HX_RELEASE(m_pProperties);
m_pRequest = pRequest;
m_pMonitor = pMonitor;
m_pAdviser = pAdviser;
m_pProperties = pProperties;
m_ulVolumeTag = 0;
m_bClosing = FALSE;
}
return retVal;
}
/****************************************************************************
* Close
*/
STDMETHODIMP CPNGFileWriter::Close(void)
{
UINT16 uIdx;
HX_RESULT retVal = HXR_OK;
if (!m_bClosing)
{
m_bClosing = TRUE;
// No more information will be sent
HX_RELEASE(m_pMonitor);
HX_RELEASE(m_pAdviser);
for (uIdx = 0; uIdx < m_uStreamCount; uIdx++)
{
StreamDone(uIdx);
}
m_State = Offline;
m_uStreamCount = 0;
HX_RELEASE(m_pRequest);
HX_RELEASE(m_pProperties);
HX_RELEASE(m_pContext);
HX_RELEASE(m_pFileHeader);
HX_RELEASE(m_pCurrentStreamHeader);
m_bClosing = FALSE;
}
return retVal;
}
/****************************************************************************
* Abort
*/
STDMETHODIMP CPNGFileWriter::Abort(void)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_CallbackHandle && m_pScheduler)
{
m_pScheduler->Remove(m_CallbackHandle);
m_CallbackHandle = 0;
}
return retVal;
}
/****************************************************************************
* SetProperties
*/
STDMETHODIMP CPNGFileWriter::SetProperties(IHXValues* pProperties)
{
IHXValues* pNewPorperties = NULL;
HX_RESULT retVal = HXR_OK;
pNewPorperties = CloneHeader(pProperties, m_pContext);
HX_RELEASE(m_pProperties);
m_pProperties = pNewPorperties;
return retVal;
}
/****************************************************************************
* SetFileHeader
*/
STDMETHODIMP CPNGFileWriter::SetFileHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_INVALID_PARAMETER;
HX_ASSERT(pHeader);
if (pHeader)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
HX_RELEASE(m_pFileHeader);
m_pFileHeader = pHeader;
m_pFileHeader->AddRef();
UINT32 count = 0;
m_pFileHeader->GetPropertyULONG32("StreamCount", count);
m_uStreamCount = (UINT16) count;
// only suport a single stream
if (m_uStreamCount != 1)
{
retVal = HXR_UNEXPECTED;
}
}
ULONG32 maxImageOutputFiles = 0;
retVal = m_pProperties->GetPropertyULONG32("MaximumNumImageOutputFiles", maxImageOutputFiles);
if (SUCCEEDED(retVal))
{
m_uIMaxNumImageOutputFiles = maxImageOutputFiles;
}
return retVal;
}
/****************************************************************************
* SetStreamHeader
*/
STDMETHODIMP CPNGFileWriter::SetStreamHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_UNEXPECTED;
// Check input parameters
if (m_pFileHeader != NULL && m_uStreamCount == 1)
{
retVal = HXR_OK;
}
// Perform addtion or modification
if (SUCCEEDED(retVal))
{
m_pCurrentStreamHeader = pHeader;
m_pCurrentStreamHeader->AddRef();
if (IsPNGCompatibleStream(m_pCurrentStreamHeader))
{
/* if (SUCCEEDED(retVal))
{*/
/*retVal = CreatePNGFile();
if (retVal == HXR_OK)
{*/
//retVal = WritePNGFileHeader();
//}
//}
}
//inform core that we are ready for SetPackets
m_pMonitor->OnPacketsReady(retVal);
m_State = PacketsReady;
retVal = m_pCurrentStreamHeader->GetPropertyULONG32("Width", m_ulWidth);
if (SUCCEEDED(retVal))
{
retVal = m_pCurrentStreamHeader->GetPropertyULONG32("Height", m_ulHeight);
}
}
return retVal;
}
/****************************************************************************
* SetPacket
*/
STDMETHODIMP CPNGFileWriter::SetPacket(IHXPacket* pPacket)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_State == PacketsReady && pPacket->GetStreamNumber() == 0)
{
retVal = HXR_OK;
// send the packet to deinterleaver, if it is our stream
if (pPacket)
{
retVal = HXR_FAIL;
if (!m_bStreamDone)
{
IHXBuffer* pBuffer = pPacket->GetBuffer();
if (pBuffer)
{
if (m_uIMaxNumImageOutputFiles > 0)
{
retVal = CreatePNGFile();
if (SUCCEEDED(retVal))
{
retVal = WritePNGFileHeader();
}
if (SUCCEEDED(retVal))
{
retVal = WritePNGPacket(pBuffer);
}
if (SUCCEEDED(retVal))
{
retVal = ClosePNGFile();
}
m_uIMaxNumImageOutputFiles--;
}
else
{
// no more thumbnail needed
retVal = HXR_OK;
}
pBuffer->Release();
}
}
}
}
return retVal;
}
/****************************************************************************
* StreamDone
*/
STDMETHODIMP CPNGFileWriter::StreamDone(UINT16 unStreamNumber)
{
HX_RESULT retVal = HXR_UNEXPECTED;
if (m_State != Offline && !m_bStreamDone)
{
m_bStreamDone = TRUE;
//close PNG file, no matter error or not
ClosePNGFile();
// all streams are done, set complete
m_pMonitor->OnVolumeCompletion(HXR_OK, m_ulVolumeTag);
m_pMonitor->OnCompletion(HXR_OK);
}
return retVal;
}
/****************************************************************************
* IHXFileWriterMonitor
*/
/****************************************************************************
* OnStatus
*/
STDMETHODIMP CPNGFileWriter::OnStatus(HX_RESULT status, IHXValues* pInfoList)
{
HX_RESULT retVal = HXR_OK;
if (m_pMonitor)
{
retVal = m_pMonitor->OnStatus(status, pInfoList);
}
return retVal;
}
/****************************************************************************
* OnVolumeInitiation
*/
STDMETHODIMP CPNGFileWriter::OnVolumeInitiation(HX_RESULT status,
const char* pName,
REF(ULONG32) ulTag)
{
HX_RESULT retVal = HXR_OK;
m_ulVolumeTag++;
if (m_pMonitor)
{
ulTag = m_ulVolumeTag;
AddRef();
retVal = m_pMonitor->OnVolumeInitiation(status, pName, ulTag);
if (retVal == HXR_OK)
{
m_ulVolumeTag = ulTag;
}
Release();
}
else
{
ulTag = m_ulVolumeTag;
}
return retVal;
}
/****************************************************************************
* OnPacketsReady
*/
STDMETHODIMP CPNGFileWriter::OnPacketsReady(HX_RESULT status)
{
HX_RESULT retVal = HXR_OK;
if (SUCCEEDED(status) && (m_State != PacketsReady))
{
/*
ULONG32 ulMaxDepth = DLFT_MERGESORTER_DEPTH;
ULONG32 ulMaxTimespan = DFLT_MERGESORTER_TIMESPAN;
m_ulMergeSorterMaxDepletionRate = DFLT_MERGESORTER_DEPLETIONRATE;
GetPropertyULONG32("MergeSorterMaxDepth", ulMaxDepth);
GetPropertyULONG32("MergeSorterMaxTimespan", ulMaxTimespan);
GetPropertyULONG32("MergeSorterMaxDepletionRate",
m_ulMergeSorterMaxDepletionRate);
ulMaxTimespan &= 0x7FFFFFFF;
if (m_ulMergeSorterMaxDepletionRate == 0)
{
m_ulMergeSorterMaxDepletionRate = 1;
}
status = m_MergeSorter.Init(m_uStreamCount,
ulMaxDepth,
(LONG32) ulMaxTimespan);
*/
}
if (SUCCEEDED(status))
{
m_State = PacketsReady;
}
if (m_pMonitor)
{
retVal = m_pMonitor->OnPacketsReady(status);
}
return retVal;
}
/****************************************************************************
* OnVolumeCompletion
*/
STDMETHODIMP CPNGFileWriter::OnVolumeCompletion(HX_RESULT status,
ULONG32 ulTag)
{
HX_RESULT retVal = HXR_OK;
if (m_pMonitor)
{
retVal = m_pMonitor->OnVolumeCompletion(status, ulTag);
}
return retVal;
}
/****************************************************************************
* OnCompletion
*/
STDMETHODIMP CPNGFileWriter::OnCompletion(HX_RESULT status)
{
HX_RESULT retVal = HXR_OK;
m_State = Offline;
if (m_pMonitor)
{
retVal = m_pMonitor->OnCompletion(status);
}
return retVal;
}
/****************************************************************************
* IHXPropertyAdviser Merhods
*/
/****************************************************************************
* GetPropertyULONG32
*/
STDMETHODIMP CPNGFileWriter::GetPropertyULONG32(const char* pPropertyName,
REF(ULONG32) ulPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (strcmp(pPropertyName, "IsFullyNative") == 0)
{
ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
ulPropertyValue = 0;
retVal = HXR_OK;
}
else if (strcmp(pPropertyName, "IsNativeStream") == 0)
{
UINT16 uStreamNum = (UINT16) ulPropertyValue;
if ((uStreamNum < m_uStreamCount) && m_pCurrentStreamHeader)
{
//ulPropertyValue = m_pStreamHeaderInfo[uStreamNum].m_bIsNativeStream ? 1 : 0;
ulPropertyValue = 0;
retVal = HXR_OK;
}
}
else
{
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyULONG32(pPropertyName,
ulPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyULONG32(pPropertyName,
ulPropertyValue);
}
}
}
return retVal;
}
/****************************************************************************
* GetPropertyBuffer
*/
STDMETHODIMP CPNGFileWriter::GetPropertyBuffer(const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyBuffer(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyBuffer(pPropertyName,
pPropertyValue);
}
}
return retVal;
}
/****************************************************************************
* GetPropertyCString
*/
STDMETHODIMP CPNGFileWriter::GetPropertyCString(const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue)
{
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertyCString(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (m_pProperties)
{
retVal = m_pProperties->GetPropertyCString(pPropertyName,
pPropertyValue);
}
if (FAILED(retVal))
{
if (strcmp(pPropertyName, "FileExtension") == 0)
{
IHXBuffer* pExtensionBuffer = NULL;
const char* pzExtension = ".png";
ULONG32 ulContainerFormatEnabled = TRUE;
GetPropertyULONG32( "EnableContainerFormat",
ulContainerFormatEnabled);
// Report the extension
retVal = CreateAndSetBufferCCF(pExtensionBuffer, (UINT8*) pzExtension,
strlen(pzExtension)+1, m_pContext);
if (SUCCEEDED(retVal))
{
pExtensionBuffer->AddRef();
pPropertyValue = pExtensionBuffer;
}
HX_RELEASE(pExtensionBuffer);
}
}
}
return retVal;
}
/****************************************************************************
* GetPropertySet
*/
STDMETHODIMP CPNGFileWriter::GetPropertySet(const char* pPropertySetName,
REF(IHXValues*) pPropertySet)
{
IHXValues* pSet = NULL;
HX_RESULT retVal = HXR_FAIL;
if (m_pAdviser)
{
retVal = m_pAdviser->GetPropertySet(pPropertySetName,
pPropertySet);
}
/*if (FAILED(retVal))
{
if (strcmp(pPropertySetName, SUPLEMENTED_STRM_HEADER_SET) == 0)
{
pSet = pPropertySet;
retVal = SuplementStreamHeader(pSet);
}
else if (strcmp(pPropertySetName, STRM_HEADER_SET) == 0)
{
ULONG32 ulStreamNumber;
retVal = HXR_INVALID_PARAMETER;
if (pPropertySet)
{
retVal = pPropertySet->GetPropertyULONG32("StreamNumber",
ulStreamNumber);
}
if (SUCCEEDED(retVal))
{
retVal = HXR_INVALID_PARAMETER;
if ((ulStreamNumber < m_uStreamCount) &&
(m_pCurrentStreamHeader != NULL))
{
retVal = HXR_OK;
pSet = m_pCurrentStreamHeader;
}
}
}
else if (strcmp(pPropertySetName, FILE_HEADER_SET) == 0)
{
retVal = HXR_OK;
pSet = m_pFileHeader;
}
else if (strcmp(pPropertySetName, FWRT_PROPERTY_SET) == 0)
{
retVal = HXR_OK;
pSet = m_pProperties;
}
if (SUCCEEDED(retVal))
{
if (pSet)
{
pSet->AddRef();
if (pPropertySet)
{
pPropertySet->Release();
}
pPropertySet = pSet;
}
}
}*/
return retVal;
}
/****************************************************************************
* SuplementStreamHeader
*/
//HX_RESULT CPNGFileWriter::SuplementStreamHeader(IHXValues* pHeader)
//{
// const char* pMimeTypeChars;
// IHXBuffer* pMimeType = NULL;
// HX_RESULT retVal = HXR_INVALID_PARAMETER;
// UINT8* pSuplement = NULL;
// ULONG32 ulSuplementSize = 0;
// const char* pMimeTypeExtension = NULL;
//
// if (pHeader)
// {
// retVal = HXR_OK;
// }
//
// if (SUCCEEDED(retVal))
// {
// retVal = pHeader->GetPropertyCString("MimeType", pMimeType);
// }
//
// if (SUCCEEDED(retVal))
// {
// retVal = HXR_FAIL;
//
// pMimeTypeChars = (const char*) pMimeType->GetBuffer();
//
// if (strncmp(pMimeTypeChars,
// AUDIO_MIME_PREFIX,
// AUDIO_MIME_PREFIX_SIZE) == 0)
// {
// ULONG32 ulNumChannels = 0;
// ULONG32 ulSampleRate = 0;
//
// pHeader->GetPropertyULONG32("NumChannels", ulNumChannels);
// if (ulNumChannels == 0)
// {
// pHeader->GetPropertyULONG32("Channels", ulNumChannels);
// }
// pHeader->GetPropertyULONG32("SampleRate", ulSampleRate);
// if (ulSampleRate == 0)
// {
// pHeader->GetPropertyULONG32("SamplesPerSecond", ulSampleRate);
// }
//
// if ((ulNumChannels != 0) ||
// (ulSampleRate != 0))
// {
// HXBOOL bMakeSuplement = TRUE;
//
// if (bMakeSuplement)
// {
// AudioTypeSpecificData audioData;
//
// memset(&audioData, 0, sizeof(audioData));
//
// audioData.numChannels = (UINT16) ulNumChannels;
// audioData.sampleRate = (UINT16) ulSampleRate;
//
// pSuplement = new UINT8 [audioData.static_size()];
//
// retVal = HXR_OUTOFMEMORY;
// if (pSuplement)
// {
// audioData.pack(pSuplement, ulSuplementSize);
// pMimeTypeExtension = SUPLEMENTED_MIME_POSTFIX;
// retVal = HXR_OK;
// }
// }
// }
// }
// }
//
// // Add Mime Type Extension
// if (SUCCEEDED(retVal) &&
// pMimeTypeExtension)
// {
// HXBOOL bEncryptedMimeType;
// CHXString strNewMimeType = pMimeTypeChars;
// IHXBuffer* pNewMimeType = NULL;
//
// bEncryptedMimeType = decryptMimeType(strNewMimeType);
//
// strNewMimeType += pMimeTypeExtension;
//
// if (bEncryptedMimeType)
// {
// encryptMimeType(strNewMimeType);
// }
//
// retVal = CreateBufferCCF(pNewMimeType, m_pContext);
// if (SUCCEEDED(retVal))
// {
// retVal = pNewMimeType->SetSize(strNewMimeType.GetLength() + 1);
// }
//
// if (SUCCEEDED(retVal))
// {
// const char* pNewMimeTypeChars = (const char*) strNewMimeType;
//
// strcpy((char*) pNewMimeType->GetBuffer(), pNewMimeTypeChars);
// }
//
// if (SUCCEEDED(retVal))
// {
// pHeader->SetPropertyCString("MimeType", pNewMimeType);
// }
//
// HX_RELEASE(pNewMimeType);
// }
//
// // Add the Suplement (OpaqueData)
// if (SUCCEEDED(retVal) &&
// pSuplement &&
// (ulSuplementSize > 0))
// {
// IHXBuffer* pOpaqueData = NULL;
//
// retVal = CreateAndSetBufferCCF(pOpaqueData, pSuplement, ulSuplementSize, m_pContext);
// if (SUCCEEDED(retVal))
// {
// pHeader->SetPropertyBuffer("OpaqueData", pOpaqueData);
// }
// HX_RELEASE(pOpaqueData);
// }
//
// HX_RELEASE(pMimeType);
// HX_VECTOR_DELETE(pSuplement);
//
// return retVal;
//}
/****************************************************************************
* IsStreamHeaderChangable
*/
HXBOOL CPNGFileWriter::IsStreamHeaderChangable(IHXValues* pNewHeader,
IHXValues* pOldHeader)
{
IHXBuffer* pBufferNew = NULL;
IHXBuffer* pBufferOld = NULL;
HXBOOL bRetVal = FALSE;
HX_ASSERT(pNewHeader);
HX_ASSERT(pOldHeader);
pNewHeader->GetPropertyCString("MimeType", pBufferNew);
pOldHeader->GetPropertyCString("MimeType", pBufferOld);
if (pNewHeader && pOldHeader)
{
if (strcasecmp((char*) pBufferNew->GetBuffer(),
(char*) pBufferOld->GetBuffer()) == 0)
{
bRetVal = TRUE;
}
}
HX_RELEASE(pBufferNew);
HX_RELEASE(pBufferOld);
return bRetVal;
}
/****************************************************************************
* IsSupportedMimeType
*/
HXBOOL CPNGFileWriter::IsSupportedMimeType(IHXBuffer* pMimeType)
{
char* pMimeTypeData;
HXBOOL bRetVal = FALSE;
HX_ASSERT(pMimeType);
pMimeTypeData = (char*)pMimeType->GetBuffer();
//clean up trailing space, may not need this
if (strlen(pMimeTypeData) != 0)
{
char *p = pMimeTypeData + strlen(pMimeTypeData)-1;
while (p>pMimeTypeData && *p == ' ') *(p--)=0;
}
HX_ASSERT(pMimeTypeData);
if (strcasecmp("video/X-HX-RGB", pMimeTypeData) == 0)
{
/*m_ulBitsPerSample = 16;
m_bSwapEndianess = TRUE;*/
bRetVal = TRUE;
}
return bRetVal;
}
/****************************************************************************
* IsPNGCompabitleStream
*/
HXBOOL CPNGFileWriter::IsPNGCompatibleStream(IHXValues* pHeader)
{
IHXBuffer* pBuffer = NULL;
HX_RESULT theErr = HXR_OK;
HXBOOL bCompatible = TRUE;
//do we support this mime type?
theErr = pHeader->GetPropertyCString("MimeType", pBuffer);
if (theErr == HXR_OK)
{
bCompatible = IsSupportedMimeType(pBuffer);
}
else
{
bCompatible = FALSE;
}
HX_RELEASE(pBuffer);
return bCompatible;
}
HX_RESULT CPNGFileWriter::CreatePNGFile(void)
{
HX_RESULT theErr = HXR_OK;
char* pURL;
char *pfilename;
if (m_pRequest->GetURL((const char *&)pURL) != HXR_OK)
{
theErr = HXR_FAIL;
}
if (theErr == HXR_OK)
{
char* temp;
//a very limited URL to filename converter
if( strnicmp(pURL, "file://",strlen("file://"))==0 )
{
pfilename = pURL+strlen("file://");
}
else
{
char str_index[5] = {0, };
temp = new char[strlen(pfilename)+1000];
memset(temp, '\0', strlen(pfilename)+1000);
char* token;
pfilename = pURL;
token = strtok(pfilename, ".");
if (token != NULL)
{
strncat(temp, token, strlen(pfilename)+1000);
sprintf(str_index, "%d", m_ulIndex++);
if (!strcmp(str_index, "0") == 0)
{
strncat(temp, "_", strlen(pfilename)+1000);
strncat(temp, str_index, strlen(pfilename)+1000);
}
strncat(temp, ".png", strlen(pfilename)+1000);
}
}
/*m_hOutFile = open(pfilename, O_CREAT|O_RDWR|O_TRUNC|O_BINARY, S_IREAD|S_IWRITE);
if (m_hOutFile == -1)
{
theErr = HXR_FAIL;
}*/
if (m_pFile == NULL)
{
m_pFile = fopen(temp/*pfilename*/, "wb");
if (temp)
{
delete temp;
}
}
if (!m_pFile)
{
// Couldn't open file for writing
return HXR_FAIL;
}
/* Create and initialize the png_struct with the desired error handler
* functions. If you want to use the default stderr and longjump method,
* you can supply NULL for the last three parameters. We also check that
* the library version is compatible with the one used at compile time,
* in case we are using dynamically linked libraries. REQUIRED.
*/
m_pPngStruct = png_create_write_struct(PNG_LIBPNG_VER_STRING,
NULL, // pointer to user error struct
NULL, // point to user error function
NULL); // point to user warning function
if (m_pPngStruct == NULL)
{
theErr = HXR_FAIL;
}
/* Allocate/initialize the image information data. REQUIRED */
m_pPngInfo = png_create_info_struct(m_pPngStruct);
if (m_pPngInfo == NULL)
{
png_destroy_write_struct(&m_pPngStruct, (png_infopp)NULL);
theErr = HXR_FAIL;
}
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(m_pPngStruct)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&m_pPngStruct, &m_pPngInfo);
theErr = HXR_FAIL;
}
/* set up the output control if you are using standard C streams */
png_init_io(m_pPngStruct, m_pFile);
}
return theErr;
}
HX_RESULT CPNGFileWriter::WritePNGFileHeader(void)
{
HX_RESULT theErr = HXR_OK;
if(!m_pFile || m_pCurrentStreamHeader==NULL )
{
return HXR_FAIL;
}
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(m_pPngStruct)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&m_pPngStruct, &m_pPngInfo);
return HXR_FAIL;
}
/* Set the image information here. Width and height are up to 2^31,
* bit_depth is one of 1, 2, 4, 8, or 16, but valid values also depend on
* the color_type selected. color_type is one of PNG_COLOR_TYPE_GRAY,
* PNG_COLOR_TYPE_GRAY_ALPHA, PNG_COLOR_TYPE_PALETTE, PNG_COLOR_TYPE_RGB,
* or PNG_COLOR_TYPE_RGB_ALPHA. interlace is either PNG_INTERLACE_NONE or
* PNG_INTERLACE_ADAM7, and the compression_type and filter_type MUST
* currently be PNG_COMPRESSION_TYPE_BASE and PNG_FILTER_TYPE_BASE. REQUIRED
*/
png_set_IHDR(m_pPngStruct, m_pPngInfo, m_ulWidth, m_ulHeight, 8 /*bit_depth*/, PNG_COLOR_TYPE_RGB,
PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
/* Write the file header information. REQUIRED */
png_write_info(m_pPngStruct, m_pPngInfo);
return theErr;
}
HX_RESULT CPNGFileWriter::WritePNGPacket(IHXBuffer* pBuffer)
{
HX_RESULT retVal = HXR_FAIL;
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(m_pPngStruct)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&m_pPngStruct, &m_pPngInfo);
return HXR_FAIL;
}
/* flip the RGB pixels to BGR (or RGBA to BGRA) */
if (PNG_COLOR_TYPE_RGB & PNG_COLOR_MASK_COLOR)
{
png_set_bgr(m_pPngStruct);
}
const int bytes_per_pixel = 3;
UCHAR* tmp = pBuffer->GetBuffer();
//png_byte image[height][width*bytes_per_pixel];
//png_byte *image = (png_byte*)malloc(height * width*bytes_per_pixel);
//png_byte* row_pointers[height];
png_byte **row_pointers = new png_byte*[m_ulHeight];
for (int k = 0; k < m_ulHeight; k++) {
//row_pointers[k] = image[k];
row_pointers[k] = (png_byte*)(&(tmp[k*m_ulWidth*bytes_per_pixel]));
}
png_write_image(m_pPngStruct, row_pointers);
/* Set error handling. REQUIRED if you aren't supplying your own
* error handling functions in the png_create_write_struct() call.
*/
if (setjmp(png_jmpbuf(m_pPngStruct)))
{
/* If we get here, we had a problem reading the file */
png_destroy_write_struct(&m_pPngStruct, &m_pPngInfo);
return HXR_FAIL;
}
//png_write_end(m_pPngStruct, NULL); // NULL because we don't need to
png_write_end(m_pPngStruct, m_pPngInfo); // NULL because we don't need to
// write any comments, etc.
if (row_pointers)
{
delete []row_pointers;
/*for (int i=0; i < height; i++)
{
delete row_pointers[i];
}*/
}
return HXR_OK;
}
HX_RESULT CPNGFileWriter::ClosePNGFile(void)
{
if (m_pPngStruct != NULL && m_pPngInfo != NULL)
{
png_destroy_write_struct(&m_pPngStruct, &m_pPngInfo);
m_pPngStruct = NULL;
m_pPngInfo = NULL;
}
if (m_pFile)
{
fclose(m_pFile);
m_pFile = NULL;
}
HX_RELEASE(m_pFileHeader);
return HXR_OK;
}
/************************************************************************
* IHXCallback methods
*/
STDMETHODIMP CPNGFileWriter::Func()
{
HX_RESULT retVal = HXR_OK;
return retVal;
}
/************************************************************************
* IUnknown methods
*/
STDMETHODIMP CPNGFileWriter::QueryInterface(REFIID riid, void** ppvObj)
{
if (IsEqualIID(riid, IID_IUnknown))
{
AddRef();
*ppvObj = (IUnknown*) (IHXPlugin*) this;
return HXR_OK;
}
else if (IsEqualIID(riid, IID_IHXPlugin))
{
AddRef();
*ppvObj = (IHXPlugin*) this;
return HXR_OK;
}
else if (IsEqualIID(riid, IID_IHXFileWriter))
{
AddRef();
*ppvObj = (IHXFileWriter*) this;
return HXR_OK;
}
else if (IsEqualIID(riid, IID_IHXPropertyAdviser))
{
AddRef();
*ppvObj = (IHXPropertyAdviser*) this;
return HXR_OK;
}
*ppvObj = NULL;
return HXR_NOINTERFACE;
}
STDMETHODIMP_(ULONG32) CPNGFileWriter::AddRef()
{
return InterlockedIncrement(&m_lRefCount);
}
STDMETHODIMP_(ULONG32) CPNGFileWriter::Release()
{
if (InterlockedDecrement(&m_lRefCount) > 0)
{
return m_lRefCount;
}
delete this;
return 0;
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Source last modified: $Id: wavwrtr.h,v 1.5 2007/09/10 00:03:56 milko Exp $
*
* Portions Copyright (c) 1995-2004 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file,
* are subject to the current version of the RealNetworks Public
* Source License (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the current version of the RealNetworks Community
* Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. If you wish to allow use of your version of
* this file only under the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting the provisions above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete the provisions above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created.
*
* This file, and the files included with this file, is distributed
* and made available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY
* KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS
* ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET
* ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifndef _PNGWRTR_H_
#define _PNGWRTR_H_
/****************************************************************************
* Defines
*/
#define FILE_HEADER_SET "FileHeader"
#define STRM_HEADER_SET "StreamHeader"
#define FWRT_PROPERTY_SET "Properties"
#define SUPLEMENTED_STRM_HEADER_SET "SuplementedStreamHeader"
/****************************************************************************
* Includes
*/
#include "hxtypes.h"
#include "hxcom.h"
#include "hxfwrtr.h"
#include "hxplugn.h"
#include "hxengin.h"
#include "cstrmsrt.h"
#include "png.h"
class CDeInterleaver;
class CStreamParam;
/****************************************************************************
* Globals
*/
/****************************************************************************
* CPNGFileWriter Class
*/
class CPNGFileWriter : public IHXPlugin,
public IHXFileWriter,
public IHXFileWriterMonitor,
public IHXPropertyAdviser,
public IHXCallback
{
public:
/*
* Constructor/Desctructor
*/
CPNGFileWriter(IUnknown* pContext = NULL);
/*
* IUnknown methods
*/
STDMETHOD(QueryInterface) (THIS_
REFIID riid,
void** ppvObj);
STDMETHOD_(ULONG32,AddRef) (THIS);
STDMETHOD_(ULONG32,Release) (THIS);
/*
* IHXPlugin methods
*/
STDMETHOD(GetPluginInfo) (THIS_
REF(HXBOOL) bLoadMultiple,
REF(const char*) pDescription,
REF(const char*) pCopyright,
REF(const char*) pMoreInfoURL,
REF(ULONG32) ulVersionNumber
);
STDMETHOD(InitPlugin) (THIS_
IUnknown* /*IN*/ pContext);
/*
* IHXFileWriter methods
*/
STDMETHOD(GetFileFormatInfo)(THIS_
REF(const char**) /*OUT*/ pFileMimeTypes,
REF(const char**) /*OUT*/ pFileExtensions,
REF(const char**) /*OUT*/ pFileOpenNames
);
STDMETHOD(InitFileWriter) (THIS_
IHXRequest* pRequest,
IHXFileWriterMonitor* pMonitor,
IHXPropertyAdviser* pAdviser
);
STDMETHOD(Close) (THIS);
STDMETHOD(Abort) (THIS);
STDMETHOD(SetFileHeader) (THIS_
IHXValues* pHeader
);
STDMETHOD(SetStreamHeader) (THIS_
IHXValues* pHeader
);
STDMETHOD(SetProperties) (THIS_
IHXValues* pProperties
);
STDMETHOD(SetPacket) (THIS_
IHXPacket* pPacket
);
STDMETHOD(StreamDone) (THIS_
UINT16 unStreamNumber
);
/*
* IHXFileWriterMonitor methods
*/
STDMETHOD(OnStatus) (THIS_
HX_RESULT status,
IHXValues* pInfoList
);
STDMETHOD(OnVolumeInitiation) (THIS_
HX_RESULT status,
const char* pFileName,
REF(ULONG32) ulTag
);
STDMETHOD(OnPacketsReady) (THIS_
HX_RESULT status
);
STDMETHOD(OnVolumeCompletion) (THIS_
HX_RESULT status,
ULONG32 ulTag
);
STDMETHOD(OnCompletion) (THIS_
HX_RESULT status
);
/*
* IHXPropertyAdviser methods
*/
STDMETHOD(GetPropertyULONG32) (THIS_
const char* pPropertyName,
REF(ULONG32) ulPropertyValue
);
STDMETHOD(GetPropertyBuffer) (THIS_
const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue
);
STDMETHOD(GetPropertyCString) (THIS_
const char* pPropertyName,
REF(IHXBuffer*) pPropertyValue
);
STDMETHOD(GetPropertySet) (THIS_
const char* pPropertySetName,
REF(IHXValues*) pPropertySet
);
/*
* IHXCallback methods
*/
STDMETHOD(Func) (THIS);
private:
typedef enum
{
Offline,
PacketsReady,
Finishing
} WriterState;
static const char* zm_pDescription;
static const char* zm_pCopyright;
static const char* zm_pMoreInfoURL;
static const char* zm_pFileMimeTypes[];
static const char* zm_pFileExtensions[];
static const char* zm_pFileOpenNames[];
//HX_RESULT SuplementStreamHeader(IHXValues* pHeader);
HXBOOL IsStreamHeaderChangable(IHXValues* pNewHeader,
IHXValues* pOldHeader);
HXBOOL IsSupportedMimeType(IHXBuffer* pMimeType);
HXBOOL IsPNGCompatibleStream(IHXValues* pStreamHeader);
HX_RESULT CreatePNGFile(void);
HX_RESULT WritePNGFileHeader(void);
HX_RESULT WritePNGPacket(IHXBuffer* pBuffer);
//void EncryptPNGPacket(UINT8* pBuffer, UINT32 size);
HX_RESULT ClosePNGFile(void);
IUnknown* m_pContext;
IHXRequest* m_pRequest;
IHXFileWriterMonitor* m_pMonitor;
IHXPropertyAdviser* m_pAdviser;
IHXValues* m_pProperties;
int m_hOutFile;
WriterState m_State;
HXBOOL m_bClosing;
IHXValues* m_pCurrentStreamHeader;
IHXValues* m_pFileHeader;
HXBOOL m_bStreamDone;
HXBOOL m_bSwapEndianess;
UINT32 m_ulBitsPerSample;
UINT32 m_ulFileSize;
UINT32 m_ulDataChunkSizeOffset;
UINT32 m_ulDataSize;
UINT32 m_ulChannels;
UINT16 m_uStreamCount;
IHXScheduler* m_pScheduler;
CallbackHandle m_CallbackHandle;
ULONG32 m_ulVolumeTag;
LONG32 m_lRefCount;
FILE* m_pFile;
png_structp m_pPngStruct;
png_infop m_pPngInfo;
ULONG32 m_ulWidth;
ULONG32 m_ulHeight;
ULONG32 m_ulIndex;
UINT32 m_uIMaxNumImageOutputFiles;
~CPNGFileWriter();
};
#endif /* _PNGWRTR_H_ */
From halley.zhao at intel.com Tue Sep 9 22:11:13 2008
From: halley.zhao at intel.com (Zhao, Halley)
Date: Tue Sep 9 20:30:44 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
In-Reply-To:
References:
Message-ID: <8FED46E8A9CA574792FC7AACAC38FE7701ACA5CA89@PDSMSX501.ccr.corp.intel.com>
We have some investigation for the performance of thumbnail generation.
And found that save png file is the hot spot; so if we scale down the picture data before save it to a png file will improve the performance.
And in most case, thumbnail doesn?t need a big dimension as original video size .
________________________________
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ???(Hayoung Choi)
Sent: 2008?9?10? 12:09
To: datatype-dev@lists.helixcommunity.org
Cc: hyoon@real.com
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Hi all,
I re-submit the CR (Thumbnail generation improvement for PNG) below, please review it.
---
Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
Date: September 9, 2008
Project: Thumbnail Generation Improvement (for PNG)
Synopsis:
=============
This CR is for PNG thumbnail generation through the dtdrive.
The option newly added MOF(Maximum image Output Files) describes the number of values how many thumbnail images be generated.
To generate a PNG thumbnail, you put the option "-CC RGB24" and "-W xxx.png", then it converts the color format to RGB24 and generates a PNG thubnail.
Overview:
=============
1) PNG file writer plug-in added
Under datatype/image/png/filewriter, source codes were added for supporting to write PNG file.
2) Modifying main.cpp and ffdriver.cpp and ffdriver.h
To support the option MOF and color converting automatically, above three files were modified.
3) Test
D:\source\dtdriver\debug>dtdrive.exe +u +f -DV 1 -CC RGB24 -MOF 5 -W videotest.png videotest.rm
Files Added:
=============
[File 1] - datatype/image/png/filewriter/Umakefil
[File 2] - datatype/image/png/filewriter/dlliids.cpp
[File 3] - datatype/image/png/filewriter/pngwrpln.cpp
[File 4] - datatype/image/png/filewriter/pngwrtr.cpp
[File 5] - datatype/image/png/filewriter/pngwrtr.h
Files Modified:
=============
[File 6] - datatype/tools/dtdriver/apps/dtdrive/Umakefil
[File 7] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
[File 8] - datatype/tools/dtdriver/engine/Umakefil
[File9] - datatype/tools/dtdriver/engine/ffdriver.cpp
[File10] - datatype/tools/dtdriver/engine/pub/ffdriver.h
[File11] - bif-cvs/helix/common/build/BIF/helix.bif
=============
Image Size and Heap Use impact (Client -Only):
NA
=============
Platforms and Profiles Affected:
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
=============
Distribution Libraries Affected:
pngwrtr.dll
dtdrive.lib
dtdrengine.lib
=============
Distribution library impact and planned action:
NA
=============
Platforms and Profiles Build Verified:
System id: win32-i386-vc7
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
Microsoft Compiler 13.10.6030
=============
Platforms and Profiles Functionality verified:
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
Branch: HEAD
Target: dtdrive
Profile: helix-client-all-defines
=============
Copyright assignment:
I am a RealNetworks employee or contractor
=============
QA Instructions:
NA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/8ef09875/attachment-0001.html
From alokj at real.com Wed Sep 10 06:03:16 2008
From: alokj at real.com (Alok Jain)
Date: Wed Sep 10 04:22:36 2008
Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
Message-ID: <00dc01c91345$9933a6a0$7701a8c0@hp>
Skipped content of type multipart/alternative-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
/****************************************************************************
* Defines
*/
// #define _APPEND_BITSTREAM_HEADER
// #define _DONOT_SEGMENT
// #define _ASSERT_ON_LOSS
// #define _DUMP_FIRST_NFRAMES 5
#define _OVERALLOC_CODEC_DATA 3
#define HX_FLV_PAYLOAD_MIME_TYPE "video/x-hx-flv"
#define HX_FLV_CODEC_ID "vp67"
#define FLUSH_ALL_PACKETS 0xFFFFFFFF
#define MAX_FRAME_SEGMENTS 1024
#define NUM_OVERLAP_SEGMENTS 256
#define DLFT_MAX_PACKET_DATA_SIZE 0x7FFFFFFF
#define CHAR_LF 0x0a
#define CHAR_CR 0x0d
#define MAX_INT_TEXT_LENGTH 10
/****************************************************************************
* Includes
*/
#include "hxtypes.h"
#include "hxwintyp.h"
#include "hxcom.h"
#include "hxcomm.h"
#include "hxassert.h"
#include "hxslist.h"
#include "hxstrutl.h"
#include "hxcomm.h"
#include "ihxpckts.h"
#include "hxformt.h"
#include "hxrendr.h"
#include "hxformt.h"
#include "hxengin.h"
#include "sdptools.h"
#include "mp4desc.h"
#include "flvpyld.h"
#include "mp4pyldutil.h"
#include "avcconfig.h"
CHXFLVPayloadFormat::CHXFLVPayloadFormat(CHXBufferMemoryAllocator* pAllocator)
: m_lRefCount (0)
, m_pClassFactory (NULL)
, m_pAllocator (pAllocator)
, m_pStreamHeader (NULL)
, m_pBitstreamHeader (NULL)
, m_ulBitstreamHeaderSize (0)
, m_ulSamplesPerSecond(1000)
, m_ulFrameCount (0)
, m_uSeqNumber (0)
, m_ulMaxPacketDataSize(DLFT_MAX_PACKET_DATA_SIZE)
, m_bFlushed (FALSE)
, m_bFirstPacket (TRUE)
, m_bFirstFrame (TRUE)
, m_bUsesRTPPackets (FALSE)
, m_bRTPPacketTested(FALSE)
, m_bPacketize (FALSE)
, m_PayloadID (PYID_UNKNOWN)
, m_pCodecId (NULL)
{
if (m_pAllocator)
{
m_pAllocator->AddRef();
}
}
CHXFLVPayloadFormat::~CHXFLVPayloadFormat()
{
FlushPackets(FLUSH_ALL_PACKETS);
FlushOutputPackets(FLUSH_ALL_PACKETS);
HX_VECTOR_DELETE(m_pBitstreamHeader);
if (m_pAllocator)
{
m_pAllocator->Release();
m_pAllocator = NULL;
}
HX_RELEASE(m_pClassFactory);
HX_RELEASE(m_pStreamHeader);
}
HX_RESULT CHXFLVPayloadFormat::Build(REF(IMP4VPayloadFormat*) pFmt)
{
pFmt = new CHXFLVPayloadFormat();
HX_RESULT res = HXR_OUTOFMEMORY;
if (pFmt)
{
pFmt->AddRef();
res = HXR_OK;
}
return res;
}
// *** IUnknown methods ***
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::QueryInterface
// Purpose:
// Implement this to export the interfaces supported by your
// object.
//
STDMETHODIMP
CHXFLVPayloadFormat::QueryInterface(REFIID riid, void** ppvObj)
{
QInterfaceList qiList[] =
{
{ GET_IIDHANDLE(IID_IUnknown), this },
{ GET_IIDHANDLE(IID_IHXPayloadFormatObject), (IHXPayloadFormatObject*) this },
};
return ::QIFind(qiList, QILISTSIZE(qiList), riid, ppvObj);
}
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::AddRef
// Purpose:
// Everyone usually implements this the same... feel free to use
// this implementation.
//
STDMETHODIMP_(ULONG32)
CHXFLVPayloadFormat::AddRef()
{
return InterlockedIncrement(&m_lRefCount);
}
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::Release
// Purpose:
// Everyone usually implements this the same... feel free to use
// this implementation.
//
STDMETHODIMP_(ULONG32)
CHXFLVPayloadFormat::Release()
{
if (InterlockedDecrement(&m_lRefCount) > 0)
{
return m_lRefCount;
}
delete this;
return 0;
}
STDMETHODIMP
CHXFLVPayloadFormat::Init(IUnknown* pContext,
HXBOOL bPacketize)
{
HX_RESULT retVal = HXR_OK;
HX_RELEASE(m_pClassFactory);
m_bPacketize = bPacketize;
if (SUCCEEDED(retVal))
{
retVal = pContext->QueryInterface(IID_IHXCommonClassFactory,
(void**) &m_pClassFactory);
}
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::Reset()
{
// Release all input packets we have stored
FlushPackets(FLUSH_ALL_PACKETS);
FlushOutputPackets(FLUSH_ALL_PACKETS);
m_bFlushed = FALSE;
m_bFirstPacket = TRUE;
m_bFirstFrame = TRUE;
m_bUsesRTPPackets = FALSE;
m_bRTPPacketTested = FALSE;
m_ulFrameCount = 0;
m_uSeqNumber = 0;
m_TSConverter.Reset();
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::SetStreamHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_OK;
HX_ASSERT(pHeader);
HX_RELEASE(m_pStreamHeader);
m_pStreamHeader = pHeader;
if (m_pStreamHeader)
{
m_pStreamHeader->AddRef();
}
if (m_bPacketize)
{
retVal = SetPacketizerHeader(pHeader);
}
else
{
retVal = SetAssemblerHeader(pHeader);
}
return retVal;
}
void CHXFLVPayloadFormat::SetAllocator(CHXBufferMemoryAllocator* pAllocator)
{
if (pAllocator)
{
m_pAllocator = pAllocator;
m_pAllocator->AddRef();
}
}
HX_RESULT CHXFLVPayloadFormat::SetPacketizerHeader(IHXValues* pHeader)
{
return HXR_OK;
}
HX_RESULT CHXFLVPayloadFormat::SetAssemblerHeader(IHXValues* pHeader)
{
IHXBuffer* pMimeType = NULL;
const char* pMimeTypeData = NULL;
HX_RESULT retVal = HXR_INVALID_PARAMETER;
if (pHeader)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = pHeader->GetPropertyCString("MimeType", pMimeType);
}
if (SUCCEEDED(retVal))
{
pMimeTypeData = (char*) pMimeType->GetBuffer();
retVal = HXR_FAIL;
if (pMimeTypeData)
{
retVal = HXR_OK;
}
}
// Determine payload type here based on mime type
if (SUCCEEDED(retVal))
{
retVal = HXR_FAIL;
if (strcasecmp(pMimeTypeData, HX_FLV_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_FLV;
m_pCodecId = HX_FLV_CODEC_ID;
retVal = HXR_OK;
}
}
if (SUCCEEDED(retVal))
{
m_pStreamHeader->GetPropertyULONG32("SamplesPerSecond",
m_ulSamplesPerSecond);
}
HX_RELEASE(pMimeType);
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::GetStreamHeader(REF(IHXValues*) pHeader)
{
HX_ASSERT(m_pStreamHeader);
pHeader = m_pStreamHeader;
pHeader->AddRef();
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::SetPacket(IHXPacket* pPacket)
{
HX_RESULT retVal;
HX_ASSERT(pPacket);
if (!m_bRTPPacketTested)
{
IHXRTPPacket* pRTPPacket = NULL;
m_bUsesRTPPackets = (pPacket->QueryInterface(
IID_IHXRTPPacket,
(void**) &pRTPPacket)
== HXR_OK);
m_bRTPPacketTested = TRUE;
HX_RELEASE(pRTPPacket);
if (m_bUsesRTPPackets)
{
HX_ASSERT(m_ulSamplesPerSecond != 0);
m_TSConverter.SetBase(m_ulSamplesPerSecond,
1000);
}
else
{
m_TSConverter.SetBase(1000, 1000);
}
}
// Add this packet to our list of input packets
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
if (m_bPacketize)
{
retVal = SetPacketizerPacket(pPacket);
}
else
{
retVal = SetAssemblerPacket(pPacket);
}
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::SetPacketizerPacket(IHXPacket* pPacket)
{
if (m_bFirstFrame)
{
m_bFirstFrame = FALSE;
}
return HXR_OK;
}
HX_RESULT CHXFLVPayloadFormat::SetAssemblerPacket(IHXPacket* pPacket)
{
if (!pPacket->IsLost())
{
if (m_bFirstPacket)
{
m_bFirstPacket = FALSE;
m_ulFrameTime = GetPacketTime(pPacket);
}
if (GetPacketTime(pPacket) != m_ulFrameTime)
{
m_ulFrameCount++;
m_ulFrameTime = GetPacketTime(pPacket);
}
if (pPacket->GetASMRuleNumber() == 0)
{
m_ulFrameCount++;
m_bFirstPacket = TRUE;
}
}
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::GetPacket(REF(IHXPacket*) pOutPacket)
{
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
{
if (m_bPacketize)
{
retVal = GetPacketizerPacket(pOutPacket);
}
else
{
retVal = GetAssemblerPacket(pOutPacket);
}
}
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::GetPacketizerPacket(IHXPacket* &pOutPacket)
{
HX_RESULT retVal = HXR_NOTIMPL;
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::GetAssemblerPacket(IHXPacket* &pOutPacket)
{
HX_RESULT retVal = HXR_NOTIMPL;
return retVal;
}
void CHXFLVPayloadFormat::FlushPackets(ULONG32 ulCount)
{
IHXPacket* pDeadPacket;
while ((ulCount > 0) && (!m_InputPackets.IsEmpty()))
{
pDeadPacket = (IHXPacket*) m_InputPackets.RemoveHead();
HX_RELEASE(pDeadPacket);
if (ulCount != FLUSH_ALL_PACKETS)
{
ulCount--;
}
}
}
void CHXFLVPayloadFormat::FlushOutputPackets(ULONG32 ulCount)
{
IHXPacket* pDeadPacket;
while ((ulCount > 0) && (!m_OutputPackets.IsEmpty()))
{
pDeadPacket = (IHXPacket*) m_OutputPackets.RemoveHead();
HX_RELEASE(pDeadPacket);
if (ulCount != FLUSH_ALL_PACKETS)
{
ulCount--;
}
}
}
ULONG32 CHXFLVPayloadFormat::CountValidPackets(ULONG32 ulCount)
{
IHXPacket* pPacket;
LISTPOSITION listPos;
ULONG32 ulValidCount = 0;
listPos = m_InputPackets.GetHeadPosition();
while ((ulCount > 0) && (listPos != NULL))
{
pPacket = (IHXPacket*) m_InputPackets.GetNext(listPos);
HX_ASSERT(pPacket);
if (!pPacket->IsLost())
{
ulValidCount++;
}
ulCount--;
}
return ulValidCount;
}
ULONG32 CHXFLVPayloadFormat::SumPacketSizes(ULONG32 ulCount)
{
IHXPacket* pPacket;
IHXBuffer* pBuffer;
LISTPOSITION listPos;
ULONG32 ulSize = 0;
listPos = m_InputPackets.GetHeadPosition();
while ((ulCount > 0) && (listPos != NULL))
{
pPacket = (IHXPacket*) m_InputPackets.GetNext(listPos);
HX_ASSERT(pPacket);
if (!pPacket->IsLost())
{
pBuffer = pPacket->GetBuffer();
if (pBuffer)
{
ulSize += pBuffer->GetSize();
pBuffer->Release();
}
}
ulCount--;
}
return ulSize;
}
HX_RESULT CHXFLVPayloadFormat::CreateHXCodecPacket(UINT32* &pHXCodecDataOut)
{
HX_RESULT retVal = HXR_INCOMPLETE;
if (m_ulFrameCount > 0)
{
m_ulFrameCount--;
IHXPacket* pPacket = NULL;
IHXBuffer* pBuffer = NULL;
UINT32 ulFrameSize = 0;
HXCODEC_DATA* pHXCodecData = NULL;
UINT32 ulFrameTime = 0;
UINT32* pData = NULL;
UINT32 ulSegmentCount = 1;
retVal = HXR_OK;
pPacket = (IHXPacket*) m_InputPackets.RemoveHead();
HX_ASSERT(pPacket);
HXBOOL bIsLost = pPacket->IsLost();
if (!bIsLost)
{
pBuffer = pPacket->GetBuffer();
}
if (pBuffer)
{
ulFrameSize = pBuffer->GetSize();
}
ulFrameTime = GetPacketTime(pPacket);
pData = new UINT32[(sizeof(HXCODEC_DATA) +
sizeof(HXCODEC_SEGMENTINFO) *
(ulSegmentCount - 1)) / 4 + 1];
retVal = HXR_OUTOFMEMORY;
if (pData)
{
retVal = HXR_OK;
}
// Init. codec data header
if (SUCCEEDED(retVal))
{
pHXCodecData = (HXCODEC_DATA*) pData;
pHXCodecData->dataLength = ulFrameSize;
pHXCodecData->timestamp = ulFrameTime;
pHXCodecData->sequenceNum = m_uSeqNumber;
pHXCodecData->flags = 0;
pHXCodecData->lastPacket = FALSE;
pHXCodecData->numSegments = NUM_OVERLAP_SEGMENTS;
pHXCodecData->data = NULL;
}
if (m_pAllocator)
{
IHXUnknown* pIUnkn = NULL;
HX20ALLOCPROPS allocRequest;
HX20ALLOCPROPS allocActual;
allocRequest.uBufferSize = ulFrameSize;
allocRequest.nNumBuffers = 0;
m_pAllocator->SetProperties(&allocRequest, &allocActual);
pHXCodecData->data = m_pAllocator->GetPacketBuffer(&pIUnkn);
}
else
{
pHXCodecData->data = (UINT8*) new UINT32 [ulFrameSize / 4 + 1];
}
if (pHXCodecData->data == NULL)
{
retVal = HXR_OUTOFMEMORY;
}
if (retVal == HXR_OK)
{
pHXCodecDataOut = pData;
}
else
{
if (pHXCodecData && pHXCodecData->data)
{
m_pAllocator->ReleasePacketPtr(pHXCodecData->data);
}
HX_VECTOR_DELETE(pData);
}
}
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::Flush()
{
m_bFlushed = TRUE;
return HXR_OK;
}
ULONG32 CHXFLVPayloadFormat::GetPacketTime(IHXPacket* pPacket)
{
ULONG32 ulTime;
HX_ASSERT(pPacket);
if (m_bUsesRTPPackets && (m_ulSamplesPerSecond != 0))
{
ulTime = ((IHXRTPPacket*) pPacket)->GetRTPTime();
ulTime = m_TSConverter.Convert(ulTime);
}
else
{
ulTime = pPacket->GetTime();
}
return ulTime;
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifndef _FLVVPYLD_H_
#define _FLVVPYLD_H_
/****************************************************************************
* Includes
*/
#include "hxalloc.h"
#include "tsconvrt.h"
#include "mp4vpyif.h"
/****************************************************************************
* CHXFLVPayloadFormat
*/
class CHXFLVPayloadFormat : public IMP4VPayloadFormat
{
public:
CHXFLVPayloadFormat(CHXBufferMemoryAllocator* pAllocator = NULL);
~CHXFLVPayloadFormat();
static HX_RESULT Build(REF(IMP4VPayloadFormat*) pFmt);
// *** IUnknown methods ***
STDMETHOD(QueryInterface) (THIS_
REFIID riid,
void** ppvObj);
STDMETHOD_(ULONG32,AddRef) (THIS);
STDMETHOD_(ULONG32,Release) (THIS);
/*
* IHXPayloadFormatObject methods
*/
STDMETHOD(Init) (THIS_
IUnknown* pContext,
HXBOOL bPacketize);
STDMETHOD(Close) (THIS) { return HXR_NOTIMPL; }
STDMETHOD(Reset) (THIS);
STDMETHOD(SetStreamHeader) (THIS_
IHXValues* pHeader);
STDMETHOD(GetStreamHeader) (THIS_
REF(IHXValues*) pHeader);
STDMETHOD(SetPacket) (THIS_
IHXPacket* pPacket);
STDMETHOD(GetPacket) (THIS_
REF(IHXPacket*) pPacket);
STDMETHOD(Flush) (THIS);
/*
* Custom public interface methods
*/
HX_RESULT CreateHXCodecPacket(ULONG32* &pHXCodecDataOut);
const char* GetCodecId(void) { return m_pCodecId; }
ULONG32 GetBitstreamHeaderSize(void) { return m_ulBitstreamHeaderSize; }
const UINT8* GetBitstreamHeader(void) { return m_pBitstreamHeader; }
void SetAllocator(CHXBufferMemoryAllocator* pAllocator);
HX_RESULT SetTimeAnchor(ULONG32 ulTime)
{
m_TSConverter.SetOffset(ulTime);
return HXR_OK;
}
HX_RESULT SetMaxPacketSize(UINT32 ulMax)
{
m_ulMaxPacketDataSize = ulMax;
return HXR_OK;
}
private:
typedef enum
{
PYID_UNKNOWN,
PYID_X_HX_FLV
} PayloadID;
inline HX_RESULT SetPacketizerHeader(IHXValues* pHeader);
inline HX_RESULT SetAssemblerHeader(IHXValues* pHeader);
inline HX_RESULT GetPacketizerPacket(IHXPacket* &pOutPacket);
inline HX_RESULT GetAssemblerPacket(IHXPacket* &pOutPacket);
inline HX_RESULT SetPacketizerPacket(IHXPacket* pPacket);
inline HX_RESULT SetAssemblerPacket(IHXPacket* pPacket);
inline ULONG32 GetFrameSize(CHXSimpleList* pPacketList);
inline ULONG32 GetPacketTime(IHXPacket* pPacket);
void FlushPackets(ULONG32 ulCount);
void FlushOutputPackets(ULONG32 ulCount);
ULONG32 CountValidPackets(ULONG32 ulCount);
ULONG32 SumPacketSizes(ULONG32 ulCount);
LONG32 m_lRefCount;
IHXCommonClassFactory* m_pClassFactory;
CHXBufferMemoryAllocator* m_pAllocator;
IHXValues* m_pStreamHeader;
UINT8* m_pBitstreamHeader;
ULONG32 m_ulBitstreamHeaderSize;
const char* m_pCodecId;
ULONG32 m_ulSamplesPerSecond;
CHXSimpleList m_InputPackets;
CHXSimpleList m_OutputPackets;
ULONG32 m_ulFrameCount;
ULONG32 m_ulFrameTime;
UINT16 m_uSeqNumber;
HXBOOL m_bPictureStarted;
ULONG32 m_ulMaxPacketDataSize;
HXBOOL m_bFlushed;
HXBOOL m_bFirstPacket;
HXBOOL m_bFirstFrame;
HXBOOL m_bUsesRTPPackets;
HXBOOL m_bRTPPacketTested;
HXBOOL m_bPacketize;
PayloadID m_PayloadID;
CTSConverter m_TSConverter;
};
#endif // _FLVVPYLD_H_
-------------- next part --------------
Index: payload/Umakefil
===================================================================
RCS file: /cvsroot/datatype/mp4/payload/Umakefil,v
retrieving revision 1.19
diff -u -w -r1.19 Umakefil
--- payload/Umakefil 23 Jul 2008 04:33:25 -0000 1.19
+++ payload/Umakefil 10 Sep 2008 10:31:20 -0000
@@ -37,6 +37,8 @@
UmakefileVersion(2,1)
+#project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6")
+
project.AddModuleIncludes("common/include",
"common/system/pub",
"common/dbgtool/pub",
@@ -83,6 +85,9 @@
if project.IsDefined("HELIX_FEATURE_AUDIO_CODEC_MP3"):
project.AddSources("mp3draft.cpp")
+if project.IsDefined("HELIX_FEATURE_VIDEO_CODEC_VP6"):
+ project.AddSources("flvpyld.cpp")
+
if project.IsDefined("HELIX_FEATURE_SERVER") or \
project.IsDefined("HELIX_FEATURE_MP4_FILEFORMAT_ALL"):
project.AddSources("latmpacketizer.cpp",
Index: video/renderer/libumakefil
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/libumakefil,v
retrieving revision 1.4
diff -u -w -r1.4 libumakefil
--- video/renderer/libumakefil 29 Sep 2006 18:04:46 -0000 1.4
+++ video/renderer/libumakefil 10 Sep 2008 10:31:20 -0000
@@ -1,5 +1,6 @@
UmakefileVersion(2,1)
+#project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6")
# _IGNORE_UNSUPPORTED - The purpose is to allow audio or other accompanying
# streams to play when unsupported video stream is
Index: video/renderer/mp4vdfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp,v
retrieving revision 1.19
diff -u -w -r1.19 mp4vdfmt.cpp
--- video/renderer/mp4vdfmt.cpp 4 Jun 2008 13:09:49 -0000 1.19
+++ video/renderer/mp4vdfmt.cpp 10 Sep 2008 10:31:21 -0000
@@ -83,6 +83,9 @@
#ifdef HELIX_FEATURE_VIDEO_CODEC_AVC1
#include "h264pyld.h"
#endif //HELIX_FEATURE_VIDEO_CODEC_AVC1
+#if defined(HELIX_FEATURE_VIDEO_CODEC_VP6)
+#include "flvpyld.h"
+#endif //HELIX_FEATURE_VIDEO_CODEC_VP6
/****************************************************************************
* Locals
@@ -1133,4 +1136,7 @@
// H264 video format
m_fmtFactory.RegisterBuilder(&H264PayloadFormat::Build);
#endif // defined(HELIX_FEATURE_VIDEO_CODEC_AVC1)
+#if defined(HELIX_FEATURE_VIDEO_CODEC_VP6)
+ m_fmtFactory.RegisterBuilder(&CHXFLVPayloadFormat::Build);
+#endif
}
Index: video/renderer/mp4video.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4video.cpp,v
retrieving revision 1.13
diff -u -w -r1.13 mp4video.cpp
--- video/renderer/mp4video.cpp 25 Jul 2006 00:40:50 -0000 1.13
+++ video/renderer/mp4video.cpp 10 Sep 2008 10:31:21 -0000
@@ -70,6 +70,9 @@
"video/X-HX-AVC1",
"video/X-HX-DIVX",
"video/H264",
+#if defined(HELIX_FEATURE_VIDEO_CODEC_VP6)
+ "video/x-hx-flv",
+#endif
NULL
};
From ehyche at real.com Wed Sep 10 06:07:50 2008
From: ehyche at real.com (Eric Hyche)
Date: Wed Sep 10 04:27:15 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
In-Reply-To:
References:
<004801c91285$787ae4c0$6970ae40$@com>
Message-ID: <004d01c91346$3bb117f0$b31347d0$@com>
Hayoung,
My answers to your questions inline below...
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>
>We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
>places instead of using the string "MaximumImageOutputFiles"
>in the SetPropertyULONG32.
>==> [Hayoung] It seems that the other options also have been used the "string" in the
>SetPropertyULONG32, not XXXX_OPTION_NAME value. So I used the string value to be consistent with them.
>How do you think?
>
If it's the same literal string as the define, then
we should use the define everywhere.
>- Since we know we are going to be making changes to the PNG file writer
> after this initial checkin, then there's no need to initially branch
> the PNG file writer to 310Atlas. We can do that once we have finished
> adding everything we want. Adding it to just the HEAD is sufficient for now.
>
>==> [Hayoung] Do you mean that check in only PNG file writer codes first and check in the other
>updates such as main.cpp.diff and ffdriver.cpp.diff later?
>
Sorry - I wasn't clear.
For the new PNG writer: just check into HEAD only for now, because
we know we are still going to be making further changes to it.
Once we are done with all the changes we want to make, then
we can branch it to 310Atlas.
For changes to existing files: check in changes to HEAD and 310Atlas.
Thanks,
Eric
From alokj at real.com Wed Sep 10 06:12:40 2008
From: alokj at real.com (Alok Jain)
Date: Wed Sep 10 04:31:59 2008
Subject: [datatype-dev] CR: NULL Decoder
Message-ID: <011701c91346$e94743d0$7701a8c0@hp>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: codec.zip
Type: application/octet-stream
Size: 11978 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/7bfdfab5/codec.obj
From ehyche at real.com Wed Sep 10 06:39:53 2008
From: ehyche at real.com (Eric Hyche)
Date: Wed Sep 10 04:59:14 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
Message-ID: <005d01c9134a$b587e6e0$2097b4a0$@com>
Anuj,
Here are my comments:
1) parse_audio.cpp
+ case 1:
+ pTSD->m_WaveFormatEx.m_usChannels = HXWM_SPEAKER_FRONT_CENTER;
+ break;
+ case 2:
+ pTSD->m_WaveFormatEx.m_usChannels = HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
+ break;
It looks like we should be setting pTSD->m_ulChannelMask instead
of replacing the value of pTSD->m_WaveFormatEx.m_usChannels. However,
it looks like all the code in parse_audio.cpp has this same
problem. I wondered why this didn't cause a playback problem, but apparently
it doesn't because in CWMAudioDecoder::GetNumChannels() we
first get the number of channels from m_AudioTSD.m_WaveFormatEx.m_usChannels
(which would be wrong) and then we override it with the value
from the IHXAudioDecoder, which would be correct. So this
is masking this obvious bug in parse_audio.cpp.
So I think all of the places in parse_audio.cpp which set
pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
changed to set the channel mask to pTSD->m_ulChannelMask instead.
2) wmadecoder.cpp
- Instead of having to QI for IHXPreferences, you should just use
the alternate version of ReadPrefUINT8 which takes an IUnknown
and does the QI for you.
- Let's call the pref name "MaxSupportedWMAChannels" instead of "MAXSupportWMAChannels"
The rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of ext-anuj.dhamija@nokia.com
>Sent: Tuesday, September 09, 2008 5:07 PM
>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in Helix
>
>"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-anuj.dhamija@nokia.com
>
>Reviewed by:
>
>Req ID: 106-1630
>
>Date: 09/09/2008
>
>Project: Support WMA10 Pro Audio in Helix
>
>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining backward compatible with old
>WMA9 decoder
>
>Overview:
>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM 9t/9E and ARM11 processors. It is
>not backward compatible as extra parameters are required to configure the decoder and different
>payload format is used. Same FourCC code is used to initialize the decoder. So Helix needs to figure
>out the available codec at runtime and support both cases (old codec and new codec) accordingly
>
>
>Fix:
>A) wmasymbianswdecoder.cpp
>i) Method ConfigDecoder introduced to handle configuration of decoder based on codec available (WMA9
>or WMA10) and media type. Update config file with availablity status of WMA10 support for next time.
>
>ii) Method InitWMA9Header and InitWMA10Header take care of prepending header to frame. InitWMA9Header
>prepends same header as used by old decoder. InitWMA10Header prepends header as required by new WMA10
>pro decoder.
>
>B) wmaaudioconfigs.cpp
>i) Introduce new methods to set and get format tag. These are used by ConfigDecoder in
>wmasymbianswdecoder.cpp when configuring decoder.
>
>ii) Add new variables to class HXAudioConfiguratorWMA to support WMA10Pro. Append these variables in
>config array in ConfigureDecoder call.
>
>C) wmadecoder.cpp
>i) Read Max number of supported channels from configuration file and if number of audio channels in
>Audio stream are more than the config parameter then reject audio. [Default is 2]
>
>ii) Reject 24 bit sample clips. [For now only 16-bit clips are supported]
>
>D) parse_audio.cpp
>i) Introduce new parameters for WMA10 to structure HXWMATypeSpecificData
>ii) Unpack new parameters for WMA10 from payload when parsing Audio Data
>
>E) R1_Mobile_4_0_Factory.cfg
>i) New config parameter for max supported channels for a WMA clip. [MAXSupportedWMAChannels]
>
>Files modified & changes:
>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>\datatype\wm\audio\renderer\wmadecoder.cpp
>\datatype\wm\common\pub\parse_audio.h
>\datatype\wm\common\parse_audio.cpp
>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>
>Image Size and Heap Use impact: None
>
>Module Release testing (STIF, Audio) : Passed
>
>Test case(s) Added : None
>
>Memory leak check performed : Passed, No leaks found
>
>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
>Platforms and Profiles Functionality verified: armv5
>
>Branch: Head, 210CayS
>
>===========================
>DIFF enclosed as text files
>===========================
>
>thnx & regds
>AD
><>
>
>
>
From ehyche at real.com Wed Sep 10 07:40:48 2008
From: ehyche at real.com (Eric Hyche)
Date: Wed Sep 10 06:00:01 2008
Subject: [datatype-dev] CR: add logging lib to rm filewriter
Message-ID: <3841.24.158.143.31.1221057648.squirrel@mailone.real.com>
Description
---------------------------------
This adds the logging utility library to the list
of libraries the rm filewriter links against.
Files Modified
---------------------------------
datatype/rm/filewriter/Umakefil
Branches
---------------------------------
HEAD only
Index: Umakefil
===================================================================
RCS file: /cvsroot/datatype/rm/filewriter/Umakefil,v
retrieving revision 1.4
diff -u -w -r1.4 Umakefil
--- Umakefil 6 Jul 2007 22:01:32 -0000 1.4
+++ Umakefil 10 Sep 2008 14:08:54 -0000
@@ -86,6 +86,7 @@
,'common/container[contlib]'
,'common/system[syslib]'
,'common/runtime[runtlib]'
+ ,'common/log/logutil[logutillib]'
,'protocol/sdp[sdplib]'
)
=====================================
Eric Hyche, Technical Lead
RealNetworks, Inc.
ehyche@real.com
From gwright at real.com Wed Sep 10 08:44:56 2008
From: gwright at real.com (Greg Wright)
Date: Wed Sep 10 07:04:18 2008
Subject: [datatype-dev] CR: add logging lib to rm filewriter
In-Reply-To: <3841.24.158.143.31.1221057648.squirrel@mailone.real.com>
References: <3841.24.158.143.31.1221057648.squirrel@mailone.real.com>
Message-ID: <48C7EB78.7030200@real.com>
Looks good.
--greg.
Eric Hyche wrote:
> Description
> ---------------------------------
> This adds the logging utility library to the list
> of libraries the rm filewriter links against.
>
> Files Modified
> ---------------------------------
> datatype/rm/filewriter/Umakefil
>
> Branches
> ---------------------------------
> HEAD only
>
> Index: Umakefil
> ===================================================================
> RCS file: /cvsroot/datatype/rm/filewriter/Umakefil,v
> retrieving revision 1.4
> diff -u -w -r1.4 Umakefil
> --- Umakefil 6 Jul 2007 22:01:32 -0000 1.4
> +++ Umakefil 10 Sep 2008 14:08:54 -0000
> @@ -86,6 +86,7 @@
> ,'common/container[contlib]'
> ,'common/system[syslib]'
> ,'common/runtime[runtlib]'
> + ,'common/log/logutil[logutillib]'
> ,'protocol/sdp[sdplib]'
> )
>
>
> =====================================
> Eric Hyche, Technical Lead
> RealNetworks, Inc.
> ehyche@real.com
>
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From ext-anuj.dhamija at nokia.com Wed Sep 10 08:59:01 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Wed Sep 10 07:18:29 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <005d01c9134a$b587e6e0$2097b4a0$@com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
Message-ID: <2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
Hi Eric,
I erroneously sent the older diff files. Please find the latest diff
files enclosed which take care of your comments.
Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
introduced with WMA10 and is not available in older versions. So I am
not preparing a mask for WMA10 (see enclosed diff files) as it already
has a channel mask present in the stream. Rather I have to avoid calling
CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
There are other changes for updating config file to indicate support for
WMA10 when WMA clip is played the very first time so that multiple
configurations are not required subsequently.
Thnx & regds
AD
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Wednesday, September 10, 2008 8:40 AM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
Cc: nokia-private-dev@helixcommunity.org
Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
in Helix
Anuj,
Here are my comments:
1) parse_audio.cpp
+ case 1:
+ pTSD->m_WaveFormatEx.m_usChannels =
HXWM_SPEAKER_FRONT_CENTER;
+ break;
+ case 2:
+ pTSD->m_WaveFormatEx.m_usChannels =
HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
+ break;
It looks like we should be setting pTSD->m_ulChannelMask instead of
replacing the value of pTSD->m_WaveFormatEx.m_usChannels. However, it
looks like all the code in parse_audio.cpp has this same problem. I
wondered why this didn't cause a playback problem, but apparently it
doesn't because in CWMAudioDecoder::GetNumChannels() we first get the
number of channels from m_AudioTSD.m_WaveFormatEx.m_usChannels
(which would be wrong) and then we override it with the value from the
IHXAudioDecoder, which would be correct. So this is masking this obvious
bug in parse_audio.cpp.
So I think all of the places in parse_audio.cpp which set
pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
changed to set the channel mask to pTSD->m_ulChannelMask instead.
2) wmadecoder.cpp
- Instead of having to QI for IHXPreferences, you should just use
the alternate version of ReadPrefUINT8 which takes an IUnknown
and does the QI for you.
- Let's call the pref name "MaxSupportedWMAChannels" instead of
"MAXSupportWMAChannels"
The rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org
>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>ext-anuj.dhamija@nokia.com
>Sent: Tuesday, September 09, 2008 5:07 PM
>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>Helix
>
>"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-anuj.dhamija@nokia.com
>
>Reviewed by:
>
>Req ID: 106-1630
>
>Date: 09/09/2008
>
>Project: Support WMA10 Pro Audio in Helix
>
>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>backward compatible with old
>WMA9 decoder
>
>Overview:
>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>9t/9E and ARM11 processors. It is not backward compatible as extra
>parameters are required to configure the decoder and different payload
>format is used. Same FourCC code is used to initialize the decoder. So
>Helix needs to figure out the available codec at runtime and support
>both cases (old codec and new codec) accordingly
>
>
>Fix:
>A) wmasymbianswdecoder.cpp
>i) Method ConfigDecoder introduced to handle configuration of decoder
>based on codec available (WMA9 or WMA10) and media type. Update config
file with availablity status of WMA10 support for next time.
>
>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>header to frame. InitWMA9Header prepends same header as used by old
>decoder. InitWMA10Header prepends header as required by new WMA10 pro
decoder.
>
>B) wmaaudioconfigs.cpp
>i) Introduce new methods to set and get format tag. These are used by
>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>
>ii) Add new variables to class HXAudioConfiguratorWMA to support
>WMA10Pro. Append these variables in config array in ConfigureDecoder
call.
>
>C) wmadecoder.cpp
>i) Read Max number of supported channels from configuration file and if
>number of audio channels in Audio stream are more than the config
>parameter then reject audio. [Default is 2]
>
>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>supported]
>
>D) parse_audio.cpp
>i) Introduce new parameters for WMA10 to structure
>HXWMATypeSpecificData
>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>Data
>
>E) R1_Mobile_4_0_Factory.cfg
>i) New config parameter for max supported channels for a WMA clip.
>[MAXSupportedWMAChannels]
>
>Files modified & changes:
>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>\datatype\wm\audio\renderer\wmadecoder.cpp
>\datatype\wm\common\pub\parse_audio.h
>\datatype\wm\common\parse_audio.cpp
>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>
>Image Size and Heap Use impact: None
>
>Module Release testing (STIF, Audio) : Passed
>
>Test case(s) Added : None
>
>Memory leak check performed : Passed, No leaks found
>
>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
>Platforms and Profiles Functionality verified: armv5
>
>Branch: Head, 210CayS
>
>===========================
>DIFF enclosed as text files
>===========================
>
>thnx & regds
>AD
><>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DiffSep10.zip
Type: application/x-zip-compressed
Size: 7398 bytes
Desc: DiffSep10.zip
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080910/c8adbb32/DiffSep10.bin
From hayoung.choi at ap.real.com Wed Sep 10 16:48:15 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Wed Sep 10 15:07:27 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
References:
<004801c91285$787ae4c0$6970ae40$@com>
<004d01c91346$3bb117f0$b31347d0$@com>
Message-ID:
Eric,
I got it. Perhaps, did you check all updates?
If so, I'll check in PNG file writer into HEAD and others into HEAD and 310Atlas.
Thanks,
Hayoung
________________________________
From: Eric Hyche [mailto:ehyche@real.com]
Sent: 2008-09-10 (?) ?? 10:07
To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
Cc: milko@real.com; hyoon@real.com
Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Hayoung,
My answers to your questions inline below...
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>
>We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
>places instead of using the string "MaximumImageOutputFiles"
>in the SetPropertyULONG32.
>==> [Hayoung] It seems that the other options also have been used the "string" in the
>SetPropertyULONG32, not XXXX_OPTION_NAME value. So I used the string value to be consistent with them.
>How do you think?
>
If it's the same literal string as the define, then
we should use the define everywhere.
>- Since we know we are going to be making changes to the PNG file writer
> after this initial checkin, then there's no need to initially branch
> the PNG file writer to 310Atlas. We can do that once we have finished
> adding everything we want. Adding it to just the HEAD is sufficient for now.
>
>==> [Hayoung] Do you mean that check in only PNG file writer codes first and check in the other
>updates such as main.cpp.diff and ffdriver.cpp.diff later?
>
Sorry - I wasn't clear.
For the new PNG writer: just check into HEAD only for now, because
we know we are still going to be making further changes to it.
Once we are done with all the changes we want to make, then
we can branch it to 310Atlas.
For changes to existing files: check in changes to HEAD and 310Atlas.
Thanks,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080911/cf46ed7c/attachment-0001.html
From ehyche at real.com Thu Sep 11 07:20:48 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 05:39:54 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
In-Reply-To:
References:
<004801c91285$787ae4c0$6970ae40$@com>
<004d01c91346$3bb117f0$b31347d0$@com>
Message-ID: <009801c91419$97996440$c6cc2cc0$@com>
Hayoung,
>I got it. Perhaps, did you check all updates?
>
I'm not sure what you mean. I looked at your
updated diff, and it looked fine. Is that what you mean?
>If so, I'll check in PNG file writer into HEAD and others into HEAD and 310Atlas.
>
Yes, please do.
Thanks,
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ???(Hayoung Choi) [mailto:hayoung.choi@ap.real.com]
>Sent: Wednesday, September 10, 2008 7:48 PM
>To: ehyche@real.com; datatype-dev@lists.helixcommunity.org
>Cc: milko@real.com; hyoon@real.com
>Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>Eric,
>
>I got it. Perhaps, did you check all updates?
>
>If so, I'll check in PNG file writer into HEAD and others into HEAD and 310Atlas.
>
>Thanks,
>Hayoung
>
>________________________________
>
>From: Eric Hyche [mailto:ehyche@real.com]
>Sent: 2008-09-10 (?) ?? 10:07
>To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
>Cc: milko@real.com; hyoon@real.com
>Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>
>
>Hayoung,
>
>My answers to your questions inline below...
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>
>>We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
>>places instead of using the string "MaximumImageOutputFiles"
>>in the SetPropertyULONG32.
>>==> [Hayoung] It seems that the other options also have been used the "string" in the
>>SetPropertyULONG32, not XXXX_OPTION_NAME value. So I used the string value to be consistent with
>them.
>>How do you think?
>>
>
>If it's the same literal string as the define, then
>we should use the define everywhere.
>
>>- Since we know we are going to be making changes to the PNG file writer
>> after this initial checkin, then there's no need to initially branch
>> the PNG file writer to 310Atlas. We can do that once we have finished
>> adding everything we want. Adding it to just the HEAD is sufficient for now.
>>
>>==> [Hayoung] Do you mean that check in only PNG file writer codes first and check in the other
>>updates such as main.cpp.diff and ffdriver.cpp.diff later?
>>
>
>Sorry - I wasn't clear.
>
>For the new PNG writer: just check into HEAD only for now, because
>we know we are still going to be making further changes to it.
>Once we are done with all the changes we want to make, then
>we can branch it to 310Atlas.
>
>For changes to existing files: check in changes to HEAD and 310Atlas.
>
>Thanks,
>
>Eric
>
>
>
>
>
From dyek at real.com Thu Sep 11 07:22:45 2008
From: dyek at real.com (Daniel Yek)
Date: Thu Sep 11 05:41:45 2008
Subject: [datatype-dev] CR: NULL Decoder
In-Reply-To: <011701c91346$e94743d0$7701a8c0@hp>
References: <011701c91346$e94743d0$7701a8c0@hp>
Message-ID: <48C929B5.5000208@real.com>
Null decoder sounds useful.
I think it would be even more useful if the null decoder is extended to
output a repeated sequence of moving patterns, starting from a
recognizable key frame and looping the rest of the moving non-key frames
and then back to the key frame and repeat.
The sequence can be a smaller rectangular area extended to the larger
(black or with border lines) output dimensions.
Maybe this feature should be a variant of the null decoder instead.
Thanks.
--
Daniel Yek.
Alok Jain wrote:
>
> Synopsis:
>
> Null decoder implementaion.
>
>
>
> Overview:
> Null decoder implements the Helix video decoder API. The null decoder
> produces one black frame for every input encoded frame it receives.
>
>
> Files Modified:
> None
>
>
> Files Added:
> /cvsroot/datatype/null/codec/nullcodec.cpp
>
> /cvsroot/datatype/null/codec/nullcodec.h
>
> /cvsroot/datatype/null/codec/nullcodecapi.cpp
>
> /cvsroot/datatype/null/codec/ Umakefil
> /cvsroot/datatype/null/codec/ win32.pcf
>
>
>
> Image Size and Heap Use impact (Client -Only):
> None.
>
> Platforms and Profiles Affected:
> None
>
> Distribution Libraries Affected:
> None.
>
> Distribution library impact and planned action:
> None.
>
>
> Platforms and Profiles Build Verified:
> Profile: helix-client-all-defines
>
> BIF branch: helix.bif
> Target: splay
>
> Branch: HEAD
>
>
> Thanks & Regards
>
> Alok Jain
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From ehyche at real.com Thu Sep 11 07:36:23 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 05:55:30 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
<2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
Message-ID: <009901c9141b$c48d0ae0$4da720a0$@com>
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field introduced with WMA10 and is not
>available in older versions. So I am not preparing a mask for WMA10 (see enclosed diff files) as it
>already has a channel mask present in the stream. Rather I have to avoid calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See changes in method
>HXAudioConfiguratorWMA::ValidateDecoderConfig].
HXWMATypeSpecificData::m_ulChannelMask has always been there. The issue
was that I had intended to set m_ulChannelMask for TSD's that
didn't have it, but had a typo and actually wound up overwriting m_usChannels.
I'll fix that bug in parse_audio.cpp myself, after you check in your
changes.
By the way, how does the new m_nBitPerSample differ from the existing m_usBitsPerSample?
And how does the new m_nBlockAlign differ from the existing m_usBlockAlign?
One further comment using your new diffs:
+ UINT8 numWMAChannels = 0;
Any reason why this is a UINT8 instead of a UINT16? Since we are going
to compare it against a UINT16, we might as well make it a UINT16, so
we can avoid the compiler warnings on Win32 and Linux. Also, we should
use the naming convention and call this "usWMAChannels". And I guess
if we use a UINT16, then we'll need to use ReadPrefUINT16.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>Sent: Wednesday, September 10, 2008 11:59 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in Helix
>
>Hi Eric,
>
>I erroneously sent the older diff files. Please find the latest diff files enclosed which take care of
>your comments.
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field introduced with WMA10 and is not
>available in older versions. So I am not preparing a mask for WMA10 (see enclosed diff files) as it
>already has a channel mask present in the stream. Rather I have to avoid calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See changes in method
>HXAudioConfiguratorWMA::ValidateDecoderConfig].
>There are other changes for updating config file to indicate support for WMA10 when WMA clip is played
>the very first time so that multiple configurations are not required subsequently.
>
>Thnx & regds
>AD
>
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Wednesday, September 10, 2008 8:40 AM
>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in Helix
>
>Anuj,
>
>Here are my comments:
>
>1) parse_audio.cpp
>
>+ case 1:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_CENTER;
>+ break;
>+ case 2:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
>+ break;
>
>It looks like we should be setting pTSD->m_ulChannelMask instead of replacing the value of pTSD-
>>m_WaveFormatEx.m_usChannels. However, it looks like all the code in parse_audio.cpp has this same
>problem. I wondered why this didn't cause a playback problem, but apparently it doesn't because in
>CWMAudioDecoder::GetNumChannels() we first get the number of channels from
>m_AudioTSD.m_WaveFormatEx.m_usChannels
>(which would be wrong) and then we override it with the value from the IHXAudioDecoder, which would be
>correct. So this is masking this obvious bug in parse_audio.cpp.
>
>So I think all of the places in parse_audio.cpp which set
>pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
>changed to set the channel mask to pTSD->m_ulChannelMask instead.
>
>2) wmadecoder.cpp
>
>- Instead of having to QI for IHXPreferences, you should just use
> the alternate version of ReadPrefUINT8 which takes an IUnknown
> and does the QI for you.
>
>- Let's call the pref name "MaxSupportedWMAChannels" instead of "MAXSupportWMAChannels"
>
>
>The rest looks good.
>
>Eric
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>ext-anuj.dhamija@nokia.com
>>Sent: Tuesday, September 09, 2008 5:07 PM
>>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>>Helix
>>
>>"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-anuj.dhamija@nokia.com
>>
>>Reviewed by:
>>
>>Req ID: 106-1630
>>
>>Date: 09/09/2008
>>
>>Project: Support WMA10 Pro Audio in Helix
>>
>>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>>backward compatible with old
>>WMA9 decoder
>>
>>Overview:
>>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>>9t/9E and ARM11 processors. It is not backward compatible as extra
>>parameters are required to configure the decoder and different payload
>>format is used. Same FourCC code is used to initialize the decoder. So
>>Helix needs to figure out the available codec at runtime and support
>>both cases (old codec and new codec) accordingly
>>
>>
>>Fix:
>>A) wmasymbianswdecoder.cpp
>>i) Method ConfigDecoder introduced to handle configuration of decoder
>>based on codec available (WMA9 or WMA10) and media type. Update config
>file with availablity status of WMA10 support for next time.
>>
>>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>>header to frame. InitWMA9Header prepends same header as used by old
>>decoder. InitWMA10Header prepends header as required by new WMA10 pro
>decoder.
>>
>>B) wmaaudioconfigs.cpp
>>i) Introduce new methods to set and get format tag. These are used by
>>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>>
>>ii) Add new variables to class HXAudioConfiguratorWMA to support
>>WMA10Pro. Append these variables in config array in ConfigureDecoder
>call.
>>
>>C) wmadecoder.cpp
>>i) Read Max number of supported channels from configuration file and if
>
>>number of audio channels in Audio stream are more than the config
>>parameter then reject audio. [Default is 2]
>>
>>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>>supported]
>>
>>D) parse_audio.cpp
>>i) Introduce new parameters for WMA10 to structure
>>HXWMATypeSpecificData
>>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>>Data
>>
>>E) R1_Mobile_4_0_Factory.cfg
>>i) New config parameter for max supported channels for a WMA clip.
>>[MAXSupportedWMAChannels]
>>
>>Files modified & changes:
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>>\datatype\wm\audio\renderer\wmadecoder.cpp
>>\datatype\wm\common\pub\parse_audio.h
>>\datatype\wm\common\parse_audio.cpp
>>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>>
>>Image Size and Heap Use impact: None
>>
>>Module Release testing (STIF, Audio) : Passed
>>
>>Test case(s) Added : None
>>
>>Memory leak check performed : Passed, No leaks found
>>
>>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>>
>>Platforms and Profiles Functionality verified: armv5
>>
>>Branch: Head, 210CayS
>>
>>===========================
>>DIFF enclosed as text files
>>===========================
>>
>>thnx & regds
>>AD
>><>
>>
>>
>>
>
From ehyche at real.com Thu Sep 11 08:06:54 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 06:25:59 2008
Subject: [datatype-dev] CR: NULL Decoder
In-Reply-To: <48C929B5.5000208@real.com>
References: <011701c91346$e94743d0$7701a8c0@hp> <48C929B5.5000208@real.com>
Message-ID: <009d01c91420$08039010$180ab030$@com>
Daniel/Alok:
I was thinking exactly along the same lines. It would be useful to have
it actually write the frame number into the frame, or perhaps the
millisecond timestamp of the frame. I remember debugging an issue
a couple of years ago where the the RV renderer was not issuing
the proper commands to the RV decoder to tell it that it had received
its last frame, and that it should flush all of its frames. In order
to verify we had fixed this, we had to construct a special clip that wrote frame
numbers in bottom right. Before the bug was fixed, you never saw the final
frame of the sequence. After the bug was fixed, you could see that the
last frame in the clip was bltted.
Having a null decoder would have really helped with diagnosing that problem.
Also, I see the null decoder as useful when analyzing CPU usage. We already
have a null renderer, but now with a null decoder, we can measure performance
of various video renderers where they are performing everything but decoding.
Alok: can you investigate to see how much dev time it would be to
write some of the parameters of the input HXCODEC_DATA into the output
frame. I describe below what I have in mind. If your investigation
tells you that you could do this in 2 days of work or less, then please
go ahead and do it. If it's more than 2 days, then please just document
the results of your investigation, and send them to me. In that case,
we'll just put that on the to-do list.
The input frame the null decoder receives is in a HXCODEC_DATA struct.
Two of the parameters of that struct are a ULONG32 timestamp and
a UINT16 sequenceNum. Both of those would be really useful to see
visually on the screen. The null decoder produces an an I420 frame
on output and I420 frames are laid out in memory like this:
--------------------------------
| |
| |
| |
| Y |
| |
| |
| |
| |
--------------------------------
| |
| U |
| |
| |
----------------
| |
| V |
| |
| |
----------------
The width and height of the Y are the same as the width
and height of the frame. However, the U and V planes are
subsampled and are half the width and half the height of
the Y plane.
The Y plane is the luminance plane. So you can essentially
think of it as a grayscale version of the video frame.
So what I was thinking is that after you generate the dummy
output video frame, you would construct a string that
contains both the value of sequenceNum and timestamp,
using a fixed number of characters for both. So perhaps
your sprintf() command might look something like:
sprintf(szBuffer, "%5u %10lu", sequenceNum, timestamp);
Then you could take that string and draw it into
the luminance plane buffer. After you drew it, it might
look something like this:
--------------------------------
| |
| |
| |
| Y |
| |
| |
| 274 10450 |
| |
--------------------------------
| |
| U |
| |
| |
----------------
| |
| V |
| |
| |
----------------
if the sequence number was 274 and the timestamp
on the frame was 10450.
Exactly how to do that drawing is the part that
needs investigation. On Windows, I think it's pretty
clear how to do it. You make a DIB out of the Y buffer
and then use that DIB as the offscreen buffer for
your GDI drawing commands like DrawText().
I'm less familiar with how to do it on Linux.
Daniel: do you have any suggestions off the top
of your head on the easiest way to do it for Linux?
Another approach would simply be to come up with simple
bitmaps for the characters 0-9 and then copy those
characters into the buffer. This would have the advantage
of being cross-platform, but it probably wouldn't look
as nice as using the platform-specific drawing APIs.
Anyway, that's my idea. Let me know what you find out.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Daniel Yek
>Sent: Thursday, September 11, 2008 10:23 AM
>To: datatype-dev@helixcommunity.org
>Cc: Alok Jain
>Subject: Re: [datatype-dev] CR: NULL Decoder
>
>Null decoder sounds useful.
>
>I think it would be even more useful if the null decoder is extended to
>output a repeated sequence of moving patterns, starting from a
>recognizable key frame and looping the rest of the moving non-key frames
>and then back to the key frame and repeat.
>
>The sequence can be a smaller rectangular area extended to the larger
>(black or with border lines) output dimensions.
>
>Maybe this feature should be a variant of the null decoder instead.
>
>Thanks.
>
>--
>Daniel Yek.
>
>
>
>Alok Jain wrote:
>>
>> Synopsis:
>>
>> Null decoder implementaion.
>>
>>
>>
>> Overview:
>> Null decoder implements the Helix video decoder API. The null decoder
>> produces one black frame for every input encoded frame it receives.
>>
>>
>> Files Modified:
>> None
>>
>>
>> Files Added:
>> /cvsroot/datatype/null/codec/nullcodec.cpp
>>
>> /cvsroot/datatype/null/codec/nullcodec.h
>>
>> /cvsroot/datatype/null/codec/nullcodecapi.cpp
>>
>> /cvsroot/datatype/null/codec/ Umakefil
>> /cvsroot/datatype/null/codec/ win32.pcf
>>
>>
>>
>> Image Size and Heap Use impact (Client -Only):
>> None.
>>
>> Platforms and Profiles Affected:
>> None
>>
>> Distribution Libraries Affected:
>> None.
>>
>> Distribution library impact and planned action:
>> None.
>>
>>
>> Platforms and Profiles Build Verified:
>> Profile: helix-client-all-defines
>>
>> BIF branch: helix.bif
>> Target: splay
>>
>> Branch: HEAD
>>
>>
>> Thanks & Regards
>>
>> Alok Jain
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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 ehyche at real.com Thu Sep 11 08:29:25 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 06:48:26 2008
Subject: [datatype-dev] CR: NULL Decoder
In-Reply-To: <011701c91346$e94743d0$7701a8c0@hp>
References: <011701c91346$e94743d0$7701a8c0@hp>
Message-ID: <00a101c91423$2d4bc100$87e34300$@com>
Alok,
Here are my comments:
1) This should go in datatype/null/video/decoder. This location
makes is consistent with the location of other decoders,
and distinguishes it from any future audio null decoder.
2) I didn't see any BIF file changes. Please add a null decoder
target to helix.bif and provide the resulting diffs for helix.bif.
3) Umakefil
a) Visual Studio is detecting inconsistent line endings in this file.
Please correct this.
b) The file needs to end in a blank line or the python scripts that
check into CVS will complain.
4) win32.pcf
a) need a blank line on the end
5) nullcodecapi.cpp
a) In each of the entrypoints, we should make sure that codecRef
is non-NULL.
6) nullcodec.h
a) Visual Studio says inconsistent line endings on this file as well.
7) nullcodec.cpp
a) We need to check m_pFormatVideo for non-NULL before using it;
b) Need to check m_pInputAllocator and m_pContext for non-NULL before AddRef()'ing them
c) Need to check m_pOutputAllocator for non-NULL before using it
d) Need to check puSize for non-NULL
e) Need to check pHeader for non-NULL before using
f) Need to check pcdOutData->data before memcpy'ing into it
g) Need to check m_fpData_Callback for non-NULL before calling it
h) Use HX_VECTOR_DELETE(pcdOutData) instead of "delete [] pcdOutData".
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Alok Jain
>Sent: Wednesday, September 10, 2008 9:13 AM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR: NULL Decoder
>
>Synopsis:
>
>Null decoder implementaion.
>
>
>
>Overview:
>Null decoder implements the Helix video decoder API. The null decoder produces one black frame for
>every input encoded frame it receives.
>
>
>Files Modified:
>None
>
>
>Files Added:
>/cvsroot/datatype/null/codec/nullcodec.cpp
>
>/cvsroot/datatype/null/codec/nullcodec.h
>
>/cvsroot/datatype/null/codec/nullcodecapi.cpp
>
>/cvsroot/datatype/null/codec/ Umakefil
>/cvsroot/datatype/null/codec/ win32.pcf
>
>
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>None
>
>Distribution Libraries Affected:
>None.
>
>Distribution library impact and planned action:
>None.
>
>
>Platforms and Profiles Build Verified:
> Profile: helix-client-all-defines
>
> BIF branch: helix.bif
> Target: splay
>
>Branch: HEAD
>
>
>Thanks & Regards
>
>Alok Jain
From ehyche at real.com Thu Sep 11 08:31:20 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 06:50:35 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
In-Reply-To: <8FED46E8A9CA574792FC7AACAC38FE7701ACA5CA89@PDSMSX501.ccr.corp.intel.com>
References:
<8FED46E8A9CA574792FC7AACAC38FE7701ACA5CA89@PDSMSX501.ccr.corp.intel.com>
Message-ID: <00a201c91423$71bdba00$55392e00$@com>
Good point, Halley. We may need to add that ability to resize the
decoded frame in the very near future. I can see your point that
when you have a 720p video frame, for instance, you don't really need
a 1280x720 PNG image to serve as the thumbnail. It can be much smaller.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Zhao, Halley
>Sent: Wednesday, September 10, 2008 1:11 AM
>To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
>Cc: hyoon@real.com
>Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>We have some investigation for the performance of thumbnail generation.
>
>And found that save png file is the hot spot; so if we scale down the picture data before save it to a
>png file will improve the performance.
>
>And in most case, thumbnail doesn?t need a big dimension as original video size .
>
>
>
>
>
>
>
>________________________________
>
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of ???(Hayoung Choi)
>Sent: 2008?9?10? 12:09
>To: datatype-dev@lists.helixcommunity.org
>Cc: hyoon@real.com
>Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>
>
>Hi all,
>
>I re-submit the CR (Thumbnail generation improvement for PNG) below, please review it.
>
>
>
>---
>
>Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
>
>Date: September 9, 2008
>
>Project: Thumbnail Generation Improvement (for PNG)
>
>Synopsis:
>
>=============
>
>This CR is for PNG thumbnail generation through the dtdrive.
>
>The option newly added MOF(Maximum image Output Files) describes the number of values how many
>thumbnail images be generated.
>
>To generate a PNG thumbnail, you put the option "-CC RGB24" and "-W xxx.png", then it converts the
>color format to RGB24 and generates a PNG thubnail.
>
>
>
>Overview:
>
>=============
>
>1) PNG file writer plug-in added
>
>Under datatype/image/png/filewriter, source codes were added for supporting to write PNG file.
>
>
>
>2) Modifying main.cpp and ffdriver.cpp and ffdriver.h
>
>To support the option MOF and color converting automatically, above three files were modified.
>
>
>
>3) Test
>
>D:\source\dtdriver\debug>dtdrive.exe +u +f -DV 1 -CC RGB24 -MOF 5 -W videotest.png videotest.rm
>
>
>
>Files Added:
>
>=============
>
>[File 1] - datatype/image/png/filewriter/Umakefil
>
>[File 2] - datatype/image/png/filewriter/dlliids.cpp
>
>[File 3] - datatype/image/png/filewriter/pngwrpln.cpp
>
>[File 4] - datatype/image/png/filewriter/pngwrtr.cpp
>
>[File 5] - datatype/image/png/filewriter/pngwrtr.h
>
>
>
>Files Modified:
>
>=============
>
>[File 6] - datatype/tools/dtdriver/apps/dtdrive/Umakefil
>
>[File 7] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
>
>[File 8] - datatype/tools/dtdriver/engine/Umakefil
>
>[File9] - datatype/tools/dtdriver/engine/ffdriver.cpp
>
>[File10] - datatype/tools/dtdriver/engine/pub/ffdriver.h
>
>[File11] - bif-cvs/helix/common/build/BIF/helix.bif
>
>
>
>=============
>
>Image Size and Heap Use impact (Client -Only):
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Affected:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>=============
>
>Distribution Libraries Affected:
>
>pngwrtr.dll
>
>dtdrive.lib
>
>dtdrengine.lib
>
>
>
>=============
>
>Distribution library impact and planned action:
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Build Verified:
>
>System id: win32-i386-vc7
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>Microsoft Compiler 13.10.6030
>
>
>
>=============
>
>Platforms and Profiles Functionality verified:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>Branch: HEAD
>
>Target: dtdrive
>
>Profile: helix-client-all-defines
>
>
>
>=============
>
>Copyright assignment:
>
>I am a RealNetworks employee or contractor
>
>=============
>
>QA Instructions:
>
>NA
>
>
From ehyche at real.com Thu Sep 11 08:56:21 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 07:15:22 2008
Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
In-Reply-To: <00dc01c91345$9933a6a0$7701a8c0@hp>
References: <00dc01c91345$9933a6a0$7701a8c0@hp>
Message-ID: <00b201c91426$f0575da0$d10618e0$@com>
Alok,
Here are my comments:
1) License headers are incorrect on the two new files. The
correct license header can be found here:
http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders#head-793d4290d3c24c0fa63825229350b0e861b6b0fe
and for future reference, the page I use to find the
license headers is here:
http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders
2) flvpyld.h - looks good
3) flvpyld.cpp
a) In destructor, use HX_RELEASE(m_pAllocator), since it does the same
as the code that's currently there.
b) In SetAllocator(), we should do a HX_RELEASE(m_pAllocator) before
we assign a new value to m_pAllocator.
c) In GetPacketTime, we should check for non-NULL pPacket
d) In CreateHXCodecPacket, I don't actually see anywhere where
the actual data in the pBuffer (the IHXPacket's IHXBuffer) ever gets copied
into pHXCodecData->data. The memory is allocated, but nothing
ever gets copied into it.
4) In datatype/mp4/payload/Umakefil,
a) We should not manually set project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6").
This should be set in the profile. So you may need to include
a diff for adding this to the appropriate .pfi file in
ribosome/build/umakepf.
5) datatype/mp4/video/renderer/libumakefil
a) same comment as 4(a) above
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Alok Jain
>Sent: Wednesday, September 10, 2008 9:03 AM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
>
>
>Synopsis:
>
>MP4 video renderer modifications to support flv format.
>
>Overview:
>Changes done to support flv format. mp4 video renderer will look at the CodecID = HX_FLV_CODEC_ID in
>the stream header and attempt to load the vp67 codec.
>
>
>Files Modified:
>/cvsroot/datatype/mp4/payload/Umakefil
>
>/cvsroot/datatype/mp4/video/renderer/libumakefil
>
>/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>
>/cvsroot/datatype/mp4/video/renderer/mp4video.cpp
>
>Files Added:
>/cvsroot/datatype/mp4/payload/flvpyld.cpp
>
>/cvsroot/datatype/mp4/payload/pub/ flvpyld.h
>
>
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>None
>
>Distribution Libraries Affected:
>None.
>
>Distribution library impact and planned action:
>None.
>
>Platforms and Profiles Build Verified:
> Profile: helix-client-all-defines
>
> BIF branch: helix.bif
> Target: splay
>
>Branch: HEAD
>
>
>Thanks & Regards
>
>Alok Jain
From hayoung.choi at ap.real.com Thu Sep 11 09:08:05 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Thu Sep 11 07:28:16 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
References:
<004801c91285$787ae4c0$6970ae40$@com>
<004d01c91346$3bb117f0$b31347d0$@com>
<009801c91419$97996440$c6cc2cc0$@com>
Message-ID:
Eric,
I am sorry it was not clear.
What I meant is that did you review my thumbnail CR re-submitted a day before yesterday.
But, it seemed there was no issues, so I'll check in PNG file writer and several updates.
Thanks,
Hayoung
________________________________
From: Eric Hyche [mailto:ehyche@real.com]
Sent: 2008-09-11 (?) ?? 11:20
To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
Cc: milko@real.com; hyoon@real.com
Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Hayoung,
>I got it. Perhaps, did you check all updates?
>
I'm not sure what you mean. I looked at your
updated diff, and it looked fine. Is that what you mean?
>If so, I'll check in PNG file writer into HEAD and others into HEAD and 310Atlas.
>
Yes, please do.
Thanks,
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ???(Hayoung Choi) [mailto:hayoung.choi@ap.real.com]
>Sent: Wednesday, September 10, 2008 7:48 PM
>To: ehyche@real.com; datatype-dev@lists.helixcommunity.org
>Cc: milko@real.com; hyoon@real.com
>Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>Eric,
>
>I got it. Perhaps, did you check all updates?
>
>If so, I'll check in PNG file writer into HEAD and others into HEAD and 310Atlas.
>
>Thanks,
>Hayoung
>
>________________________________
>
>From: Eric Hyche [mailto:ehyche@real.com]
>Sent: 2008-09-10 (?) ?? 10:07
>To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
>Cc: milko@real.com; hyoon@real.com
>Subject: RE: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
>
>
>
>Hayoung,
>
>My answers to your questions inline below...
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>
>>We should use MAXNUMIMAGEOUTPUTFILES_OPTION_NAME in both
>>places instead of using the string "MaximumImageOutputFiles"
>>in the SetPropertyULONG32.
>>==> [Hayoung] It seems that the other options also have been used the "string" in the
>>SetPropertyULONG32, not XXXX_OPTION_NAME value. So I used the string value to be consistent with
>them.
>>How do you think?
>>
>
>If it's the same literal string as the define, then
>we should use the define everywhere.
>
>>- Since we know we are going to be making changes to the PNG file writer
>> after this initial checkin, then there's no need to initially branch
>> the PNG file writer to 310Atlas. We can do that once we have finished
>> adding everything we want. Adding it to just the HEAD is sufficient for now.
>>
>>==> [Hayoung] Do you mean that check in only PNG file writer codes first and check in the other
>>updates such as main.cpp.diff and ffdriver.cpp.diff later?
>>
>
>Sorry - I wasn't clear.
>
>For the new PNG writer: just check into HEAD only for now, because
>we know we are still going to be making further changes to it.
>Once we are done with all the changes we want to make, then
>we can branch it to 310Atlas.
>
>For changes to existing files: check in changes to HEAD and 310Atlas.
>
>Thanks,
>
>Eric
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080912/e66ce1b0/attachment.html
From hayoung.choi at ap.real.com Thu Sep 11 11:54:54 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Thu Sep 11 10:13:52 2008
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
References:
Message-ID:
Hi all,
I have checked in the source codes below into HEAD and 310Atlas as follows.
BIF: helix_restricted
Target: dtdrive
Profile: helix-client-all-defnes
* CVS add list
- datatype/image/png/filewriter/Umakefil
- datatype/image/png/filewriter/dllids.h
- datatype/image/png/filewriter/pngwrpln.cpp
- datatype/image/png/filewriter/pngwrtr.cpp
- datatype/image/png/filewriter/pngwrtr.h
- datatype/image/png/filewriter/pngwrtr.ver
- datatype/image/png/filewriter/win.pcf
- datatype/image/png/filewriter/pltform/win/pngwrtr.rc
* CVS update list
- build/bif-cvs/helix/common/build/BIF/helix.bif
- datatype/tools/dtdriver/apps/dtdrive/Umakefil
- datatype/tools/dtdriver/apps/dtdrive/main.cpp
- datatype/tools/dtdriver/engine/Umakefil
- datatype/tools/dtdriver/engine/ffdriver.cpp
- datatype/tools/dtdriver/engine/pub/ffdriver.h
BIF: hxclient_3_1_0_atlas
Target: dtdrive
Profile: helix-client-all-defnes
* CVS update list
- build/bif-cvs/helix/common/build/BIF/helix.bif
- datatype/tools/dtdriver/apps/dtdrive/Umakefil
- datatype/tools/dtdriver/apps/dtdrive/main.cpp
- datatype/tools/dtdriver/engine/Umakefil
- datatype/tools/dtdriver/engine/ffdriver.cpp
- datatype/tools/dtdriver/engine/pub/ffdriver.h
Thanks,
Hayoung
________________________________
From: ???(Hayoung Choi)
Sent: 2008-09-10 (?) ?? 1:09
To: datatype-dev@lists.helixcommunity.org
Cc: ehyche@real.com; milko@real.com; hyoon@real.com
Subject: [datatype-dev] CR: Thumbnail Generation Improvement (for PNG)
Hi all,
I re-submit the CR (Thumbnail generation improvement for PNG) below, please review it.
---
Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
Date: September 9, 2008
Project: Thumbnail Generation Improvement (for PNG)
Synopsis:
=============
This CR is for PNG thumbnail generation through the dtdrive.
The option newly added MOF(Maximum image Output Files) describes the number of values how many thumbnail images be generated.
To generate a PNG thumbnail, you put the option "-CC RGB24" and "-W xxx.png", then it converts the color format to RGB24 and generates a PNG thubnail.
Overview:
=============
1) PNG file writer plug-in added
Under datatype/image/png/filewriter, source codes were added for supporting to write PNG file.
2) Modifying main.cpp and ffdriver.cpp and ffdriver.h
To support the option MOF and color converting automatically, above three files were modified.
3) Test
D:\source\dtdriver\debug>dtdrive.exe +u +f -DV 1 -CC RGB24 -MOF 5 -W videotest.png videotest.rm
Files Added:
=============
[File 1] - datatype/image/png/filewriter/Umakefil
[File 2] - datatype/image/png/filewriter/dlliids.cpp
[File 3] - datatype/image/png/filewriter/pngwrpln.cpp
[File 4] - datatype/image/png/filewriter/pngwrtr.cpp
[File 5] - datatype/image/png/filewriter/pngwrtr.h
Files Modified:
=============
[File 6] - datatype/tools/dtdriver/apps/dtdrive/Umakefil
[File 7] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
[File 8] - datatype/tools/dtdriver/engine/Umakefil
[File9] - datatype/tools/dtdriver/engine/ffdriver.cpp
[File10] - datatype/tools/dtdriver/engine/pub/ffdriver.h
[File11] - bif-cvs/helix/common/build/BIF/helix.bif
=============
Image Size and Heap Use impact (Client -Only):
NA
=============
Platforms and Profiles Affected:
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
=============
Distribution Libraries Affected:
pngwrtr.dll
dtdrive.lib
dtdrengine.lib
=============
Distribution library impact and planned action:
NA
=============
Platforms and Profiles Build Verified:
System id: win32-i386-vc7
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
Microsoft Compiler 13.10.6030
=============
Platforms and Profiles Functionality verified:
x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
Branch: HEAD
Target: dtdrive
Profile: helix-client-all-defines
=============
Copyright assignment:
I am a RealNetworks employee or contractor
=============
QA Instructions:
NA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080912/1606be7e/attachment-0001.html
From ext-anuj.dhamija at nokia.com Thu Sep 11 12:31:04 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Thu Sep 11 10:50:13 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <009901c9141b$c48d0ae0$4da720a0$@com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
<2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
<009901c9141b$c48d0ae0$4da720a0$@com>
Message-ID: <2198383E1141814486F0B881B3260CF502B711E7@daebe103.NOE.Nokia.com>
Hi Eric,
I meant channel mask is a new field in HXAudioConfiguratorWMA.
I fixed the parse_audio.cpp channel mask bug as I am not getting correct
number of channels when filtering clips with more than 2 channels.
Also I figured out that CWMAudioDecoder won't be the right place to put
check for number of channels. So I moved this logic to
HXAudioConfiguratorWMA::ValidateDecoderInfo as it is more decoder
specific class. Since there is no context available in
HXAudioConfiguratorWMA I read in the max number of supported channels in
HXSymbianWMASwAudioDecoder::Open() call and pass in to
HXAudioConfiguratorWMA using new API for setting max supported shannels.
This check is now removed from CWMAudioDecoder::Init(). No changes are
now made to WMADecoder.cpp
I have removed m_nBitPerSample and m_nBlockAlign from
HXWMATypeSpecificData as they are not required. Also corrected the
naming convention for numWMAChannels [now in wmasymbianswdecoder.cpp].
Let me know your comments about these new changes.
thnx & regds
AD
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Thursday, September 11, 2008 9:36 AM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
Cc: nokia-private-dev@helixcommunity.org
Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
in Helix
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>introduced with WMA10 and is not available in older versions. So I am
>not preparing a mask for WMA10 (see enclosed diff files) as it already
>has a channel mask present in the stream. Rather I have to avoid
>calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
HXWMATypeSpecificData::m_ulChannelMask has always been there. The issue
was that I had intended to set m_ulChannelMask for TSD's that didn't
have it, but had a typo and actually wound up overwriting m_usChannels.
I'll fix that bug in parse_audio.cpp myself, after you check in your
changes.
By the way, how does the new m_nBitPerSample differ from the existing
m_usBitsPerSample?
And how does the new m_nBlockAlign differ from the existing
m_usBlockAlign?
One further comment using your new diffs:
+ UINT8 numWMAChannels = 0;
Any reason why this is a UINT8 instead of a UINT16? Since we are going
to compare it against a UINT16, we might as well make it a UINT16, so we
can avoid the compiler warnings on Win32 and Linux. Also, we should use
the naming convention and call this "usWMAChannels". And I guess if we
use a UINT16, then we'll need to use ReadPrefUINT16.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>Sent: Wednesday, September 10, 2008 11:59 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Hi Eric,
>
>I erroneously sent the older diff files. Please find the latest diff
>files enclosed which take care of your comments.
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>introduced with WMA10 and is not available in older versions. So I am
>not preparing a mask for WMA10 (see enclosed diff files) as it already
>has a channel mask present in the stream. Rather I have to avoid
>calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>There are other changes for updating config file to indicate support
>for WMA10 when WMA clip is played the very first time so that multiple
configurations are not required subsequently.
>
>Thnx & regds
>AD
>
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Wednesday, September 10, 2008 8:40 AM
>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Anuj,
>
>Here are my comments:
>
>1) parse_audio.cpp
>
>+ case 1:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_CENTER;
>+ break;
>+ case 2:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
>+ break;
>
>It looks like we should be setting pTSD->m_ulChannelMask instead of
>replacing the value of pTSD-
>>m_WaveFormatEx.m_usChannels. However, it looks like all the code in
>>parse_audio.cpp has this same
>problem. I wondered why this didn't cause a playback problem, but
>apparently it doesn't because in
>CWMAudioDecoder::GetNumChannels() we first get the number of channels
>from m_AudioTSD.m_WaveFormatEx.m_usChannels
>(which would be wrong) and then we override it with the value from the
>IHXAudioDecoder, which would be correct. So this is masking this
obvious bug in parse_audio.cpp.
>
>So I think all of the places in parse_audio.cpp which set
>pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
>changed to set the channel mask to pTSD->m_ulChannelMask instead.
>
>2) wmadecoder.cpp
>
>- Instead of having to QI for IHXPreferences, you should just use
> the alternate version of ReadPrefUINT8 which takes an IUnknown
> and does the QI for you.
>
>- Let's call the pref name "MaxSupportedWMAChannels" instead of
"MAXSupportWMAChannels"
>
>
>The rest looks good.
>
>Eric
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>ext-anuj.dhamija@nokia.com
>>Sent: Tuesday, September 09, 2008 5:07 PM
>>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>>Helix
>>
>>"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-anuj.dhamija@nokia.com
>>
>>Reviewed by:
>>
>>Req ID: 106-1630
>>
>>Date: 09/09/2008
>>
>>Project: Support WMA10 Pro Audio in Helix
>>
>>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>>backward compatible with old
>>WMA9 decoder
>>
>>Overview:
>>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>>9t/9E and ARM11 processors. It is not backward compatible as extra
>>parameters are required to configure the decoder and different payload
>>format is used. Same FourCC code is used to initialize the decoder. So
>>Helix needs to figure out the available codec at runtime and support
>>both cases (old codec and new codec) accordingly
>>
>>
>>Fix:
>>A) wmasymbianswdecoder.cpp
>>i) Method ConfigDecoder introduced to handle configuration of decoder
>>based on codec available (WMA9 or WMA10) and media type. Update config
>file with availablity status of WMA10 support for next time.
>>
>>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>>header to frame. InitWMA9Header prepends same header as used by old
>>decoder. InitWMA10Header prepends header as required by new WMA10 pro
>decoder.
>>
>>B) wmaaudioconfigs.cpp
>>i) Introduce new methods to set and get format tag. These are used by
>>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>>
>>ii) Add new variables to class HXAudioConfiguratorWMA to support
>>WMA10Pro. Append these variables in config array in ConfigureDecoder
>call.
>>
>>C) wmadecoder.cpp
>>i) Read Max number of supported channels from configuration file and
>>if
>
>>number of audio channels in Audio stream are more than the config
>>parameter then reject audio. [Default is 2]
>>
>>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>>supported]
>>
>>D) parse_audio.cpp
>>i) Introduce new parameters for WMA10 to structure
>>HXWMATypeSpecificData
>>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>>Data
>>
>>E) R1_Mobile_4_0_Factory.cfg
>>i) New config parameter for max supported channels for a WMA clip.
>>[MAXSupportedWMAChannels]
>>
>>Files modified & changes:
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>>\datatype\wm\audio\renderer\wmadecoder.cpp
>>\datatype\wm\common\pub\parse_audio.h
>>\datatype\wm\common\parse_audio.cpp
>>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>>
>>Image Size and Heap Use impact: None
>>
>>Module Release testing (STIF, Audio) : Passed
>>
>>Test case(s) Added : None
>>
>>Memory leak check performed : Passed, No leaks found
>>
>>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>>
>>Platforms and Profiles Functionality verified: armv5
>>
>>Branch: Head, 210CayS
>>
>>===========================
>>DIFF enclosed as text files
>>===========================
>>
>>thnx & regds
>>AD
>><>
>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DiffSep11.zip
Type: application/x-zip-compressed
Size: 6675 bytes
Desc: DiffSep11.zip
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080911/8e73dbd7/DiffSep11.bin
From ehyche at real.com Thu Sep 11 13:42:48 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 11 12:01:47 2008
Subject: [datatype-dev] CR: fix some VC8 build busters
Message-ID: <013f01c9144e$f4c1dc80$de459580$@com>
Description
--------------------------------------
This change fixes 3 VC8 build busters.
Files Modified
--------------------------------------
datatype/aac/fileformat/aacffdll.cpp
datatype/group/audio/audplin.cpp
datatype/rm/video/codec/rvg2dec/drv2_win.pcf
Branches
--------------------------------------
HEAD and 310Atlas
Index: aac/fileformat/aacffdll.cpp
===================================================================
RCS file: /cvsroot/datatype/aac/fileformat/aacffdll.cpp,v
retrieving revision 1.8
diff -u -w -u -w -r1.8 aacffdll.cpp
--- aac/fileformat/aacffdll.cpp 8 Apr 2008 14:53:31 -0000 1.8
+++ aac/fileformat/aacffdll.cpp 11 Sep 2008 20:35:51 -0000
@@ -60,12 +60,12 @@
static const char HX_THIS_FILE[] = __FILE__;
#endif
-STDAPI HXEXPORT ENTRYPOINT(HXCREATEINSTANCE)(IUnknown** ppIUnknown)
+STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(HXCREATEINSTANCE)(IUnknown** ppIUnknown)
{
return CAACFileFormat::HXCreateInstance(ppIUnknown);
}
-STDAPI HXEXPORT ENTRYPOINT(CanUnload)(void)
+STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(CanUnload)(void)
{
return (CHXBaseCountingObject::ObjectsActive() > 0 ? HXR_FAIL : HXR_OK);
}
Index: group/audio/audplin.cpp
===================================================================
RCS file: /cvsroot/datatype/group/audio/audplin.cpp,v
retrieving revision 1.10
diff -u -w -u -w -r1.10 audplin.cpp
--- group/audio/audplin.cpp 30 Nov 2007 02:03:18 -0000 1.10
+++ group/audio/audplin.cpp 11 Sep 2008 20:35:51 -0000
@@ -157,7 +157,7 @@
NULL
};
-STDAPI HXEXPORT ENTRYPOINT(HXCREATEINSTANCE)(IUnknown** ppIUnknown)
+STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(HXCREATEINSTANCE)(IUnknown** ppIUnknown)
{
*ppIUnknown = (IUnknown*)(IHXPlugin*)new AudioPluginFactory();
if (*ppIUnknown)
@@ -168,7 +168,7 @@
return HXR_OUTOFMEMORY;
}
-STDAPI HXEXPORT ENTRYPOINT(CanUnload2)(void)
+STDAPI ENTRYPOINTCALLTYPE ENTRYPOINT(CanUnload2)(void)
{
for( int i=0; AudioPluginFactory::m_fpUnloadArray[i]; i++ )
{
Index: rm/video/codec/rvg2dec/drv2_win.pcf
===================================================================
RCS file: /cvsroot/datatype/rm/video/codec/rvg2dec/drv2_win.pcf,v
retrieving revision 1.2
diff -u -w -u -w -r1.2 drv2_win.pcf
--- rm/video/codec/rvg2dec/drv2_win.pcf 29 Apr 2003 05:05:41 -0000 1.2
+++ rm/video/codec/rvg2dec/drv2_win.pcf 11 Sep 2008 20:35:51 -0000
@@ -38,7 +38,7 @@
project.AddSources('platform/win/rarv2032.rc')
#add APK core lib:
-if 'wince' not in sysinfo.family_list:
+if 'wince' not in sysinfo.family_list and sysinfo.id != 'win32-i386-vc8':
project.AddLibraries(GetSDKPath("rvg2dec_libs")+'[adecg2]')
else:
project.AddLibraries(GetSDKPath("rvg2dec_libs")+'[cdecg2]')
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
From alokj at real.com Fri Sep 12 03:36:09 2008
From: alokj at real.com (Alok Jain)
Date: Fri Sep 12 01:55:11 2008
Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
References: <00dc01c91345$9933a6a0$7701a8c0@hp>
<00b201c91426$f0575da0$d10618e0$@com>
Message-ID: <005b01c914c3$62488d70$7701a8c0@hp>
Thanks Eric,
I modified the all file as you were mentioned.
Thanks
Alok
----- Original Message -----
From: "Eric Hyche"
To: "'Alok Jain'" ;
Sent: Thursday, September 11, 2008 9:26 PM
Subject: RE: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
format
> Alok,
>
> Here are my comments:
>
> 1) License headers are incorrect on the two new files. The
> correct license header can be found here:
>
> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders#head-793d4290d3c24c0fa63825229350b0e861b6b0fe
>
> and for future reference, the page I use to find the
> license headers is here:
>
> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders
>
> 2) flvpyld.h - looks good
>
> 3) flvpyld.cpp
> a) In destructor, use HX_RELEASE(m_pAllocator), since it does the same
> as the code that's currently there.
> b) In SetAllocator(), we should do a HX_RELEASE(m_pAllocator) before
> we assign a new value to m_pAllocator.
> c) In GetPacketTime, we should check for non-NULL pPacket
> d) In CreateHXCodecPacket, I don't actually see anywhere where
> the actual data in the pBuffer (the IHXPacket's IHXBuffer) ever gets
> copied
> into pHXCodecData->data. The memory is allocated, but nothing
> ever gets copied into it.
>
> 4) In datatype/mp4/payload/Umakefil,
> a) We should not manually set
> project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6").
> This should be set in the profile. So you may need to include
> a diff for adding this to the appropriate .pfi file in
> ribosome/build/umakepf.
>
> 5) datatype/mp4/video/renderer/libumakefil
> a) same comment as 4(a) above
>
> Rest looks good.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>Behalf Of Alok Jain
>>Sent: Wednesday, September 10, 2008 9:03 AM
>>To: datatype-dev@helixcommunity.org
>>Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
>>
>>
>>Synopsis:
>>
>>MP4 video renderer modifications to support flv format.
>>
>>Overview:
>>Changes done to support flv format. mp4 video renderer will look at the
>>CodecID = HX_FLV_CODEC_ID in
>>the stream header and attempt to load the vp67 codec.
>>
>>
>>Files Modified:
>>/cvsroot/datatype/mp4/payload/Umakefil
>>
>>/cvsroot/datatype/mp4/video/renderer/libumakefil
>>
>>/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>
>>/cvsroot/datatype/mp4/video/renderer/mp4video.cpp
>>
>>Files Added:
>>/cvsroot/datatype/mp4/payload/flvpyld.cpp
>>
>>/cvsroot/datatype/mp4/payload/pub/ flvpyld.h
>>
>>
>>
>>Image Size and Heap Use impact (Client -Only):
>>None.
>>
>>Platforms and Profiles Affected:
>>None
>>
>>Distribution Libraries Affected:
>>None.
>>
>>Distribution library impact and planned action:
>>None.
>>
>>Platforms and Profiles Build Verified:
>> Profile: helix-client-all-defines
>>
>> BIF branch: helix.bif
>> Target: splay
>>
>>Branch: HEAD
>>
>>
>>Thanks & Regards
>>
>>Alok Jain
>
-------------- next part --------------
===================================================================
RCS file: /cvsroot/ribosome/build/umakepf/helix-client-mp4.pfi,v
retrieving revision 1.6
diff -u -r1.6 helix-client-mp4.pfi
--- helix-client-mp4.pfi 24 Apr 2006 23:34:19 -0000 1.6
+++ helix-client-mp4.pfi 12 Sep 2008 06:11:30 -0000
@@ -70,3 +70,4 @@
project.AddDefines('HELIX_FEATURE_ISMA')
project.AddDefines('HELIX_FEATURE_AUDIO_RALF')
project.AddDefines('HELIX_FEATURE_VIDEO_CODEC_AVC1')
+project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6")
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
*
* Source last modified: $Id:
*
* Copyright Notices:
*
* Portions Copyright (c) 1995-2006 RealNetworks, Inc. All Rights Reserved.
*
* Patent Notices: This file may contain technology protected by one or
* more of the patents listed at www.helixcommunity.org
*
* 1. The contents of this file, and the files included with this file,
* are protected by copyright controlled by RealNetworks and its
* licensors, and made available by RealNetworks subject to the current
* version of the RealNetworks Public Source License (the "RPSL")
* available at * http://www.helixcommunity.org/content/rpsl unless
* you have licensed the file under the current version of the
* RealNetworks Community Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* 2. Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. Please note that RealNetworks and its
* licensors disclaim any implied patent license under the GPL.
* If you wish to allow use of your version of this file only under
* the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting Paragraph 1 above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete Paragraph 1 above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created. Copying, including reproducing, storing,
* adapting or translating, any or all of this material other than
* pursuant to the license terms referred to above requires the prior
* written consent of RealNetworks and its licensors
*
* This file, and the files included with this file, is distributed
* and made available by RealNetworks on an 'AS IS' basis, WITHOUT
* WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS
* AND ITS LICENSORS HEREBY DISCLAIM ALL SUCH WARRANTIES, INCLUDING
* WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
/****************************************************************************
* Defines
*/
// #define _APPEND_BITSTREAM_HEADER
// #define _DONOT_SEGMENT
// #define _ASSERT_ON_LOSS
// #define _DUMP_FIRST_NFRAMES 5
#define _OVERALLOC_CODEC_DATA 3
#define HX_FLV_PAYLOAD_MIME_TYPE "video/x-hx-flv"
#define HX_FLV_CODEC_ID "vp67"
#define FLUSH_ALL_PACKETS 0xFFFFFFFF
#define MAX_FRAME_SEGMENTS 1024
#define NUM_OVERLAP_SEGMENTS 256
#define DLFT_MAX_PACKET_DATA_SIZE 0x7FFFFFFF
#define CHAR_LF 0x0a
#define CHAR_CR 0x0d
#define MAX_INT_TEXT_LENGTH 10
/****************************************************************************
* Includes
*/
#include "hxtypes.h"
#include "hxwintyp.h"
#include "hxcom.h"
#include "hxcomm.h"
#include "hxassert.h"
#include "hxslist.h"
#include "hxstrutl.h"
#include "hxcomm.h"
#include "ihxpckts.h"
#include "hxformt.h"
#include "hxrendr.h"
#include "hxformt.h"
#include "hxengin.h"
#include "sdptools.h"
#include "mp4desc.h"
#include "flvpyld.h"
#include "mp4pyldutil.h"
#include "avcconfig.h"
CHXFLVPayloadFormat::CHXFLVPayloadFormat(CHXBufferMemoryAllocator* pAllocator)
: m_lRefCount (0)
, m_pClassFactory (NULL)
, m_pAllocator (pAllocator)
, m_pStreamHeader (NULL)
, m_pBitstreamHeader (NULL)
, m_ulBitstreamHeaderSize (0)
, m_ulSamplesPerSecond(1000)
, m_ulFrameCount (0)
, m_uSeqNumber (0)
, m_ulMaxPacketDataSize(DLFT_MAX_PACKET_DATA_SIZE)
, m_bFlushed (FALSE)
, m_bFirstPacket (TRUE)
, m_bFirstFrame (TRUE)
, m_bUsesRTPPackets (FALSE)
, m_bRTPPacketTested(FALSE)
, m_bPacketize (FALSE)
, m_PayloadID (PYID_UNKNOWN)
, m_pCodecId (NULL)
{
if (m_pAllocator)
{
m_pAllocator->AddRef();
}
}
CHXFLVPayloadFormat::~CHXFLVPayloadFormat()
{
FlushPackets(FLUSH_ALL_PACKETS);
FlushOutputPackets(FLUSH_ALL_PACKETS);
HX_VECTOR_DELETE(m_pBitstreamHeader);
HX_RELEASE(m_pAllocator);
HX_RELEASE(m_pClassFactory);
HX_RELEASE(m_pStreamHeader);
}
HX_RESULT CHXFLVPayloadFormat::Build(REF(IMP4VPayloadFormat*) pFmt)
{
pFmt = new CHXFLVPayloadFormat();
HX_RESULT res = HXR_OUTOFMEMORY;
if (pFmt)
{
pFmt->AddRef();
res = HXR_OK;
}
return res;
}
// *** IUnknown methods ***
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::QueryInterface
// Purpose:
// Implement this to export the interfaces supported by your
// object.
//
STDMETHODIMP
CHXFLVPayloadFormat::QueryInterface(REFIID riid, void** ppvObj)
{
QInterfaceList qiList[] =
{
{ GET_IIDHANDLE(IID_IUnknown), this },
{ GET_IIDHANDLE(IID_IHXPayloadFormatObject), (IHXPayloadFormatObject*) this },
};
return ::QIFind(qiList, QILISTSIZE(qiList), riid, ppvObj);
}
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::AddRef
// Purpose:
// Everyone usually implements this the same... feel free to use
// this implementation.
//
STDMETHODIMP_(ULONG32)
CHXFLVPayloadFormat::AddRef()
{
return InterlockedIncrement(&m_lRefCount);
}
/////////////////////////////////////////////////////////////////////////
// Method:
// IUnknown::Release
// Purpose:
// Everyone usually implements this the same... feel free to use
// this implementation.
//
STDMETHODIMP_(ULONG32)
CHXFLVPayloadFormat::Release()
{
if (InterlockedDecrement(&m_lRefCount) > 0)
{
return m_lRefCount;
}
delete this;
return 0;
}
STDMETHODIMP
CHXFLVPayloadFormat::Init(IUnknown* pContext,
HXBOOL bPacketize)
{
HX_RESULT retVal = HXR_OK;
HX_RELEASE(m_pClassFactory);
m_bPacketize = bPacketize;
if (SUCCEEDED(retVal))
{
retVal = pContext->QueryInterface(IID_IHXCommonClassFactory,
(void**) &m_pClassFactory);
}
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::Reset()
{
// Release all input packets we have stored
FlushPackets(FLUSH_ALL_PACKETS);
FlushOutputPackets(FLUSH_ALL_PACKETS);
m_bFlushed = FALSE;
m_bFirstPacket = TRUE;
m_bFirstFrame = TRUE;
m_bUsesRTPPackets = FALSE;
m_bRTPPacketTested = FALSE;
m_ulFrameCount = 0;
m_uSeqNumber = 0;
m_TSConverter.Reset();
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::SetStreamHeader(IHXValues* pHeader)
{
HX_RESULT retVal = HXR_OK;
HX_ASSERT(pHeader);
HX_RELEASE(m_pStreamHeader);
m_pStreamHeader = pHeader;
if (m_pStreamHeader)
{
m_pStreamHeader->AddRef();
}
if (m_bPacketize)
{
retVal = SetPacketizerHeader(pHeader);
}
else
{
retVal = SetAssemblerHeader(pHeader);
}
return retVal;
}
void CHXFLVPayloadFormat::SetAllocator(CHXBufferMemoryAllocator* pAllocator)
{
HX_RELEASE(m_pAllocator);
if (pAllocator)
{
m_pAllocator = pAllocator;
m_pAllocator->AddRef();
}
}
HX_RESULT CHXFLVPayloadFormat::SetPacketizerHeader(IHXValues* pHeader)
{
return HXR_OK;
}
HX_RESULT CHXFLVPayloadFormat::SetAssemblerHeader(IHXValues* pHeader)
{
IHXBuffer* pMimeType = NULL;
const char* pMimeTypeData = NULL;
HX_RESULT retVal = HXR_INVALID_PARAMETER;
if (pHeader)
{
retVal = HXR_OK;
}
if (SUCCEEDED(retVal))
{
retVal = pHeader->GetPropertyCString("MimeType", pMimeType);
}
if (SUCCEEDED(retVal))
{
pMimeTypeData = (char*) pMimeType->GetBuffer();
retVal = HXR_FAIL;
if (pMimeTypeData)
{
retVal = HXR_OK;
}
}
// Determine payload type here based on mime type
if (SUCCEEDED(retVal))
{
retVal = HXR_FAIL;
if (strcasecmp(pMimeTypeData, HX_FLV_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_FLV;
m_pCodecId = HX_FLV_CODEC_ID;
retVal = HXR_OK;
}
}
if (SUCCEEDED(retVal))
{
m_pStreamHeader->GetPropertyULONG32("SamplesPerSecond",
m_ulSamplesPerSecond);
}
HX_RELEASE(pMimeType);
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::GetStreamHeader(REF(IHXValues*) pHeader)
{
HX_ASSERT(m_pStreamHeader);
pHeader = m_pStreamHeader;
pHeader->AddRef();
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::SetPacket(IHXPacket* pPacket)
{
HX_RESULT retVal;
HX_ASSERT(pPacket);
if (!m_bRTPPacketTested)
{
IHXRTPPacket* pRTPPacket = NULL;
m_bUsesRTPPackets = (pPacket->QueryInterface(
IID_IHXRTPPacket,
(void**) &pRTPPacket)
== HXR_OK);
m_bRTPPacketTested = TRUE;
HX_RELEASE(pRTPPacket);
if (m_bUsesRTPPackets)
{
HX_ASSERT(m_ulSamplesPerSecond != 0);
m_TSConverter.SetBase(m_ulSamplesPerSecond,
1000);
}
else
{
m_TSConverter.SetBase(1000, 1000);
}
}
// Add this packet to our list of input packets
pPacket->AddRef();
m_InputPackets.AddTail(pPacket);
if (m_bPacketize)
{
retVal = SetPacketizerPacket(pPacket);
}
else
{
retVal = SetAssemblerPacket(pPacket);
}
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::SetPacketizerPacket(IHXPacket* pPacket)
{
if (m_bFirstFrame)
{
m_bFirstFrame = FALSE;
}
return HXR_OK;
}
HX_RESULT CHXFLVPayloadFormat::SetAssemblerPacket(IHXPacket* pPacket)
{
if (pPacket && !pPacket->IsLost())
{
if (m_bFirstPacket)
{
m_bFirstPacket = FALSE;
m_ulFrameTime = GetPacketTime(pPacket);
}
if (GetPacketTime(pPacket) != m_ulFrameTime)
{
m_ulFrameCount++;
m_ulFrameTime = GetPacketTime(pPacket);
}
if (pPacket->GetASMRuleNumber() == 0)
{
m_ulFrameCount++;
m_bFirstPacket = TRUE;
}
}
return HXR_OK;
}
STDMETHODIMP
CHXFLVPayloadFormat::GetPacket(REF(IHXPacket*) pOutPacket)
{
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
{
if (m_bPacketize)
{
retVal = GetPacketizerPacket(pOutPacket);
}
else
{
retVal = GetAssemblerPacket(pOutPacket);
}
}
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::GetPacketizerPacket(IHXPacket* &pOutPacket)
{
HX_RESULT retVal = HXR_NOTIMPL;
return retVal;
}
HX_RESULT CHXFLVPayloadFormat::GetAssemblerPacket(IHXPacket* &pOutPacket)
{
HX_RESULT retVal = HXR_NOTIMPL;
return retVal;
}
void CHXFLVPayloadFormat::FlushPackets(ULONG32 ulCount)
{
IHXPacket* pDeadPacket;
while ((ulCount > 0) && (!m_InputPackets.IsEmpty()))
{
pDeadPacket = (IHXPacket*) m_InputPackets.RemoveHead();
HX_RELEASE(pDeadPacket);
if (ulCount != FLUSH_ALL_PACKETS)
{
ulCount--;
}
}
}
void CHXFLVPayloadFormat::FlushOutputPackets(ULONG32 ulCount)
{
IHXPacket* pDeadPacket;
while ((ulCount > 0) && (!m_OutputPackets.IsEmpty()))
{
pDeadPacket = (IHXPacket*) m_OutputPackets.RemoveHead();
HX_RELEASE(pDeadPacket);
if (ulCount != FLUSH_ALL_PACKETS)
{
ulCount--;
}
}
}
ULONG32 CHXFLVPayloadFormat::CountValidPackets(ULONG32 ulCount)
{
IHXPacket* pPacket;
LISTPOSITION listPos;
ULONG32 ulValidCount = 0;
listPos = m_InputPackets.GetHeadPosition();
while ((ulCount > 0) && (listPos != NULL))
{
pPacket = (IHXPacket*) m_InputPackets.GetNext(listPos);
HX_ASSERT(pPacket);
if (!pPacket->IsLost())
{
ulValidCount++;
}
ulCount--;
}
return ulValidCount;
}
ULONG32 CHXFLVPayloadFormat::SumPacketSizes(ULONG32 ulCount)
{
IHXPacket* pPacket;
IHXBuffer* pBuffer;
LISTPOSITION listPos;
ULONG32 ulSize = 0;
listPos = m_InputPackets.GetHeadPosition();
while ((ulCount > 0) && (listPos != NULL))
{
pPacket = (IHXPacket*) m_InputPackets.GetNext(listPos);
HX_ASSERT(pPacket);
if (!pPacket->IsLost())
{
pBuffer = pPacket->GetBuffer();
if (pBuffer)
{
ulSize += pBuffer->GetSize();
pBuffer->Release();
}
}
ulCount--;
}
return ulSize;
}
HX_RESULT CHXFLVPayloadFormat::CreateHXCodecPacket(UINT32* &pHXCodecDataOut)
{
HX_RESULT retVal = HXR_INCOMPLETE;
if (m_ulFrameCount > 0)
{
m_ulFrameCount--;
IHXPacket* pPacket = NULL;
IHXBuffer* pBuffer = NULL;
UINT32 ulFrameSize = 0;
HXCODEC_DATA* pHXCodecData = NULL;
UINT32 ulFrameTime = 0;
UINT32* pData = NULL;
UINT32 ulSegmentCount = 1;
retVal = HXR_OK;
pPacket = (IHXPacket*) m_InputPackets.RemoveHead();
HX_ASSERT(pPacket);
HXBOOL bIsLost = pPacket->IsLost();
if (!bIsLost)
{
pBuffer = pPacket->GetBuffer();
}
if (pBuffer)
{
ulFrameSize = pBuffer->GetSize();
}
ulFrameTime = GetPacketTime(pPacket);
pData = new UINT32[(sizeof(HXCODEC_DATA) +
sizeof(HXCODEC_SEGMENTINFO) *
(ulSegmentCount - 1)) / 4 + 1];
retVal = HXR_OUTOFMEMORY;
if (pData)
{
retVal = HXR_OK;
}
// Init. codec data header
if (SUCCEEDED(retVal))
{
pHXCodecData = (HXCODEC_DATA*) pData;
pHXCodecData->dataLength = ulFrameSize;
pHXCodecData->timestamp = ulFrameTime;
pHXCodecData->sequenceNum = m_uSeqNumber;
pHXCodecData->flags = 0;
pHXCodecData->lastPacket = FALSE;
pHXCodecData->numSegments = NUM_OVERLAP_SEGMENTS;
pHXCodecData->data = NULL;
}
if (m_pAllocator)
{
IHXUnknown* pIUnkn = NULL;
HX20ALLOCPROPS allocRequest;
HX20ALLOCPROPS allocActual;
allocRequest.uBufferSize = ulFrameSize;
allocRequest.nNumBuffers = 0;
m_pAllocator->SetProperties(&allocRequest, &allocActual);
pHXCodecData->data = m_pAllocator->GetPacketBuffer(&pIUnkn);
}
else
{
pHXCodecData->data = (UINT8*) new UINT32 [ulFrameSize / 4 + 1];
}
if (pHXCodecData->data == NULL)
{
retVal = HXR_OUTOFMEMORY;
}
if (retVal == HXR_OK)
{
if (pBuffer)
{
memcpy(pHXCodecData->data, pBuffer->GetBuffer(), pBuffer->GetSize());
}
}
else
{
if (pHXCodecData && pHXCodecData->data)
{
m_pAllocator->ReleasePacketPtr(pHXCodecData->data);
}
HX_VECTOR_DELETE(pData);
}
}
return retVal;
}
STDMETHODIMP
CHXFLVPayloadFormat::Flush()
{
m_bFlushed = TRUE;
return HXR_OK;
}
ULONG32 CHXFLVPayloadFormat::GetPacketTime(IHXPacket* pPacket)
{
ULONG32 ulTime=0;
HX_ASSERT(pPacket);
if (pPacket)
{
if (m_bUsesRTPPackets && (m_ulSamplesPerSecond != 0))
{
ulTime = ((IHXRTPPacket*) pPacket)->GetRTPTime();
ulTime = m_TSConverter.Convert(ulTime);
}
else
{
ulTime = pPacket->GetTime();
}
}
return ulTime;
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
*
* Source last modified: $Id:
*
* Copyright Notices:
*
* Portions Copyright (c) 1995-2006 RealNetworks, Inc. All Rights Reserved.
*
* Patent Notices: This file may contain technology protected by one or
* more of the patents listed at www.helixcommunity.org
*
* 1. The contents of this file, and the files included with this file,
* are protected by copyright controlled by RealNetworks and its
* licensors, and made available by RealNetworks subject to the current
* version of the RealNetworks Public Source License (the "RPSL")
* available at * http://www.helixcommunity.org/content/rpsl unless
* you have licensed the file under the current version of the
* RealNetworks Community Source License (the "RCSL") available at
* http://www.helixcommunity.org/content/rcsl, in which case the RCSL
* will apply. You may also obtain the license terms directly from
* RealNetworks. You may not use this file except in compliance with
* the RPSL or, if you have a valid RCSL with RealNetworks applicable
* to this file, the RCSL. Please see the applicable RPSL or RCSL for
* the rights, obligations and limitations governing use of the
* contents of the file.
*
* 2. Alternatively, the contents of this file may be used under the
* terms of the GNU General Public License Version 2 (the
* "GPL") in which case the provisions of the GPL are applicable
* instead of those above. Please note that RealNetworks and its
* licensors disclaim any implied patent license under the GPL.
* If you wish to allow use of your version of this file only under
* the terms of the GPL, and not to allow others
* to use your version of this file under the terms of either the RPSL
* or RCSL, indicate your decision by deleting Paragraph 1 above
* and replace them with the notice and other provisions required by
* the GPL. If you do not delete Paragraph 1 above, a recipient may
* use your version of this file under the terms of any one of the
* RPSL, the RCSL or the GPL.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the
* portions it created. Copying, including reproducing, storing,
* adapting or translating, any or all of this material other than
* pursuant to the license terms referred to above requires the prior
* written consent of RealNetworks and its licensors
*
* This file, and the files included with this file, is distributed
* and made available by RealNetworks on an 'AS IS' basis, WITHOUT
* WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, AND REALNETWORKS
* AND ITS LICENSORS HEREBY DISCLAIM ALL SUCH WARRANTIES, INCLUDING
* WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
#ifndef _FLVVPYLD_H_
#define _FLVVPYLD_H_
/****************************************************************************
* Includes
*/
#include "hxalloc.h"
#include "tsconvrt.h"
#include "mp4vpyif.h"
/****************************************************************************
* CHXFLVPayloadFormat
*/
class CHXFLVPayloadFormat : public IMP4VPayloadFormat
{
public:
CHXFLVPayloadFormat(CHXBufferMemoryAllocator* pAllocator = NULL);
~CHXFLVPayloadFormat();
static HX_RESULT Build(REF(IMP4VPayloadFormat*) pFmt);
// *** IUnknown methods ***
STDMETHOD(QueryInterface) (THIS_
REFIID riid,
void** ppvObj);
STDMETHOD_(ULONG32,AddRef) (THIS);
STDMETHOD_(ULONG32,Release) (THIS);
/*
* IHXPayloadFormatObject methods
*/
STDMETHOD(Init) (THIS_
IUnknown* pContext,
HXBOOL bPacketize);
STDMETHOD(Close) (THIS) { return HXR_NOTIMPL; }
STDMETHOD(Reset) (THIS);
STDMETHOD(SetStreamHeader) (THIS_
IHXValues* pHeader);
STDMETHOD(GetStreamHeader) (THIS_
REF(IHXValues*) pHeader);
STDMETHOD(SetPacket) (THIS_
IHXPacket* pPacket);
STDMETHOD(GetPacket) (THIS_
REF(IHXPacket*) pPacket);
STDMETHOD(Flush) (THIS);
/*
* Custom public interface methods
*/
HX_RESULT CreateHXCodecPacket(ULONG32* &pHXCodecDataOut);
const char* GetCodecId(void) { return m_pCodecId; }
ULONG32 GetBitstreamHeaderSize(void) { return m_ulBitstreamHeaderSize; }
const UINT8* GetBitstreamHeader(void) { return m_pBitstreamHeader; }
void SetAllocator(CHXBufferMemoryAllocator* pAllocator);
HX_RESULT SetTimeAnchor(ULONG32 ulTime)
{
m_TSConverter.SetOffset(ulTime);
return HXR_OK;
}
HX_RESULT SetMaxPacketSize(UINT32 ulMax)
{
m_ulMaxPacketDataSize = ulMax;
return HXR_OK;
}
private:
typedef enum
{
PYID_UNKNOWN,
PYID_X_HX_FLV
} PayloadID;
inline HX_RESULT SetPacketizerHeader(IHXValues* pHeader);
inline HX_RESULT SetAssemblerHeader(IHXValues* pHeader);
inline HX_RESULT GetPacketizerPacket(IHXPacket* &pOutPacket);
inline HX_RESULT GetAssemblerPacket(IHXPacket* &pOutPacket);
inline HX_RESULT SetPacketizerPacket(IHXPacket* pPacket);
inline HX_RESULT SetAssemblerPacket(IHXPacket* pPacket);
inline ULONG32 GetFrameSize(CHXSimpleList* pPacketList);
inline ULONG32 GetPacketTime(IHXPacket* pPacket);
void FlushPackets(ULONG32 ulCount);
void FlushOutputPackets(ULONG32 ulCount);
ULONG32 CountValidPackets(ULONG32 ulCount);
ULONG32 SumPacketSizes(ULONG32 ulCount);
LONG32 m_lRefCount;
IHXCommonClassFactory* m_pClassFactory;
CHXBufferMemoryAllocator* m_pAllocator;
IHXValues* m_pStreamHeader;
UINT8* m_pBitstreamHeader;
ULONG32 m_ulBitstreamHeaderSize;
const char* m_pCodecId;
ULONG32 m_ulSamplesPerSecond;
CHXSimpleList m_InputPackets;
CHXSimpleList m_OutputPackets;
ULONG32 m_ulFrameCount;
ULONG32 m_ulFrameTime;
UINT16 m_uSeqNumber;
HXBOOL m_bPictureStarted;
ULONG32 m_ulMaxPacketDataSize;
HXBOOL m_bFlushed;
HXBOOL m_bFirstPacket;
HXBOOL m_bFirstFrame;
HXBOOL m_bUsesRTPPackets;
HXBOOL m_bRTPPacketTested;
HXBOOL m_bPacketize;
PayloadID m_PayloadID;
CTSConverter m_TSConverter;
};
#endif // _FLVVPYLD_H_
From alokj at real.com Fri Sep 12 04:38:41 2008
From: alokj at real.com (Alok Jain)
Date: Fri Sep 12 02:57:34 2008
Subject: Resending: [datatype-dev] CR: NULL Decoder
References: <011701c91346$e94743d0$7701a8c0@hp>
<00a101c91423$2d4bc100$87e34300$@com>
Message-ID: <011401c914cc$1dae5ce0$7701a8c0@hp>
Thanks Eric
Att. is the modified code as per your comments.
Please verify the suggested changes so that I can send the final CR
Thanks & Regards
Alok Jain
----- Original Message -----
From: "Eric Hyche"
To: "'Alok Jain'" ;
Sent: Thursday, September 11, 2008 8:59 PM
Subject: RE: [datatype-dev] CR: NULL Decoder
> Alok,
>
> Here are my comments:
>
> 1) This should go in datatype/null/video/decoder. This location
> makes is consistent with the location of other decoders,
> and distinguishes it from any future audio null decoder.
>
> 2) I didn't see any BIF file changes. Please add a null decoder
> target to helix.bif and provide the resulting diffs for helix.bif.
>
> 3) Umakefil
> a) Visual Studio is detecting inconsistent line endings in this file.
> Please correct this.
> b) The file needs to end in a blank line or the python scripts that
> check into CVS will complain.
>
> 4) win32.pcf
> a) need a blank line on the end
>
> 5) nullcodecapi.cpp
> a) In each of the entrypoints, we should make sure that codecRef
> is non-NULL.
>
> 6) nullcodec.h
> a) Visual Studio says inconsistent line endings on this file as well.
>
> 7) nullcodec.cpp
>
> a) We need to check m_pFormatVideo for non-NULL before using it;
> b) Need to check m_pInputAllocator and m_pContext for non-NULL before
> AddRef()'ing them
> c) Need to check m_pOutputAllocator for non-NULL before using it
> d) Need to check puSize for non-NULL
> e) Need to check pHeader for non-NULL before using
> f) Need to check pcdOutData->data before memcpy'ing into it
> g) Need to check m_fpData_Callback for non-NULL before calling it
> h) Use HX_VECTOR_DELETE(pcdOutData) instead of "delete [] pcdOutData".
>
> Rest looks good.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>Behalf Of Alok Jain
>>Sent: Wednesday, September 10, 2008 9:13 AM
>>To: datatype-dev@helixcommunity.org
>>Subject: [datatype-dev] CR: NULL Decoder
>>
>>Synopsis:
>>
>>Null decoder implementaion.
>>
>>
>>
>>Overview:
>>Null decoder implements the Helix video decoder API. The null decoder
>>produces one black frame for
>>every input encoded frame it receives.
>>
>>
>>Files Modified:
>>None
>>
>>
>>Files Added:
>>/cvsroot/datatype/null/codec/nullcodec.cpp
>>
>>/cvsroot/datatype/null/codec/nullcodec.h
>>
>>/cvsroot/datatype/null/codec/nullcodecapi.cpp
>>
>>/cvsroot/datatype/null/codec/ Umakefil
>>/cvsroot/datatype/null/codec/ win32.pcf
>>
>>
>>
>>Image Size and Heap Use impact (Client -Only):
>>None.
>>
>>Platforms and Profiles Affected:
>>None
>>
>>Distribution Libraries Affected:
>>None.
>>
>>Distribution library impact and planned action:
>>None.
>>
>>
>>Platforms and Profiles Build Verified:
>> Profile: helix-client-all-defines
>>
>> BIF branch: helix.bif
>> Target: splay
>>
>>Branch: HEAD
>>
>>
>>Thanks & Regards
>>
>>Alok Jain
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Decoder.zip
Type: application/octet-stream
Size: 12091 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080912/5764df5a/Decoder.obj
-------------- next part --------------
Index: helix.bif
===================================================================
RCS file: /cvsroot/common/build/BIF/helix.bif,v
retrieving revision 1.698
diff -u -r1.698 helix.bif
--- helix.bif 12 Sep 2008 01:06:01 -0000 1.698
+++ helix.bif 12 Sep 2008 11:15:55 -0000
@@ -14563,6 +14563,20 @@
+
+
+
+ common_include
+ common_runtime
+ common_container
+ common_util
+ common_system
+ common_dbgtool
+ common_runtime
+ datatype_common_util
+ common_log_logutil
+
+
From ext-anuj.dhamija at nokia.com Fri Sep 12 08:59:31 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Fri Sep 12 07:18:32 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <64CE512FAA5FAE4B88AEE94299D17522021141060C@daebe103.NOE.Nokia.com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
<2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
<009901c9141b$c48d0ae0$4da720a0$@com>
<64CE512FAA5FAE4B88AEE94299D17522021141060C@daebe103.NOE.Nokia.com>
Message-ID: <2198383E1141814486F0B881B3260CF502B7139C@daebe103.NOE.Nokia.com>
Hi Eric,
Can you please provide your comments on the latest changes so that I can
check in by today.
thnx & regds
AD
-----Original Message-----
From: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
Sent: Thursday, September 11, 2008 2:31 PM
To: ehyche@real.com; datatype-dev@helixcommunity.org;
audio-dev@helixcommunity.org
Cc: nokia-private-dev@helixcommunity.org
Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
in Helix
Hi Eric,
I meant channel mask is a new field in HXAudioConfiguratorWMA.
I fixed the parse_audio.cpp channel mask bug as I am not getting correct
number of channels when filtering clips with more than 2 channels.
Also I figured out that CWMAudioDecoder won't be the right place to put
check for number of channels. So I moved this logic to
HXAudioConfiguratorWMA::ValidateDecoderInfo as it is more decoder
specific class. Since there is no context available in
HXAudioConfiguratorWMA I read in the max number of supported channels in
HXSymbianWMASwAudioDecoder::Open() call and pass in to
HXAudioConfiguratorWMA using new API for setting max supported shannels.
This check is now removed from CWMAudioDecoder::Init(). No changes are
now made to WMADecoder.cpp
I have removed m_nBitPerSample and m_nBlockAlign from
HXWMATypeSpecificData as they are not required. Also corrected the
naming convention for numWMAChannels [now in wmasymbianswdecoder.cpp].
Let me know your comments about these new changes.
thnx & regds
AD
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Thursday, September 11, 2008 9:36 AM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
Cc: nokia-private-dev@helixcommunity.org
Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
in Helix
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>introduced with WMA10 and is not available in older versions. So I am
>not preparing a mask for WMA10 (see enclosed diff files) as it already
>has a channel mask present in the stream. Rather I have to avoid
>calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
HXWMATypeSpecificData::m_ulChannelMask has always been there. The issue
was that I had intended to set m_ulChannelMask for TSD's that didn't
have it, but had a typo and actually wound up overwriting m_usChannels.
I'll fix that bug in parse_audio.cpp myself, after you check in your
changes.
By the way, how does the new m_nBitPerSample differ from the existing
m_usBitsPerSample?
And how does the new m_nBlockAlign differ from the existing
m_usBlockAlign?
One further comment using your new diffs:
+ UINT8 numWMAChannels = 0;
Any reason why this is a UINT8 instead of a UINT16? Since we are going
to compare it against a UINT16, we might as well make it a UINT16, so we
can avoid the compiler warnings on Win32 and Linux. Also, we should use
the naming convention and call this "usWMAChannels". And I guess if we
use a UINT16, then we'll need to use ReadPrefUINT16.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>Sent: Wednesday, September 10, 2008 11:59 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Hi Eric,
>
>I erroneously sent the older diff files. Please find the latest diff
>files enclosed which take care of your comments.
>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>introduced with WMA10 and is not available in older versions. So I am
>not preparing a mask for WMA10 (see enclosed diff files) as it already
>has a channel mask present in the stream. Rather I have to avoid
>calling
>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>There are other changes for updating config file to indicate support
>for WMA10 when WMA clip is played the very first time so that multiple
configurations are not required subsequently.
>
>Thnx & regds
>AD
>
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Wednesday, September 10, 2008 8:40 AM
>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Anuj,
>
>Here are my comments:
>
>1) parse_audio.cpp
>
>+ case 1:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_CENTER;
>+ break;
>+ case 2:
>+ pTSD->m_WaveFormatEx.m_usChannels =
>HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
>+ break;
>
>It looks like we should be setting pTSD->m_ulChannelMask instead of
>replacing the value of pTSD-
>>m_WaveFormatEx.m_usChannels. However, it looks like all the code in
>>parse_audio.cpp has this same
>problem. I wondered why this didn't cause a playback problem, but
>apparently it doesn't because in
>CWMAudioDecoder::GetNumChannels() we first get the number of channels
>from m_AudioTSD.m_WaveFormatEx.m_usChannels
>(which would be wrong) and then we override it with the value from the
>IHXAudioDecoder, which would be correct. So this is masking this
obvious bug in parse_audio.cpp.
>
>So I think all of the places in parse_audio.cpp which set
>pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
>changed to set the channel mask to pTSD->m_ulChannelMask instead.
>
>2) wmadecoder.cpp
>
>- Instead of having to QI for IHXPreferences, you should just use
> the alternate version of ReadPrefUINT8 which takes an IUnknown
> and does the QI for you.
>
>- Let's call the pref name "MaxSupportedWMAChannels" instead of
"MAXSupportWMAChannels"
>
>
>The rest looks good.
>
>Eric
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>ext-anuj.dhamija@nokia.com
>>Sent: Tuesday, September 09, 2008 5:07 PM
>>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>>Helix
>>
>>"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-anuj.dhamija@nokia.com
>>
>>Reviewed by:
>>
>>Req ID: 106-1630
>>
>>Date: 09/09/2008
>>
>>Project: Support WMA10 Pro Audio in Helix
>>
>>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>>backward compatible with old
>>WMA9 decoder
>>
>>Overview:
>>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>>9t/9E and ARM11 processors. It is not backward compatible as extra
>>parameters are required to configure the decoder and different payload
>>format is used. Same FourCC code is used to initialize the decoder. So
>>Helix needs to figure out the available codec at runtime and support
>>both cases (old codec and new codec) accordingly
>>
>>
>>Fix:
>>A) wmasymbianswdecoder.cpp
>>i) Method ConfigDecoder introduced to handle configuration of decoder
>>based on codec available (WMA9 or WMA10) and media type. Update config
>file with availablity status of WMA10 support for next time.
>>
>>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>>header to frame. InitWMA9Header prepends same header as used by old
>>decoder. InitWMA10Header prepends header as required by new WMA10 pro
>decoder.
>>
>>B) wmaaudioconfigs.cpp
>>i) Introduce new methods to set and get format tag. These are used by
>>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>>
>>ii) Add new variables to class HXAudioConfiguratorWMA to support
>>WMA10Pro. Append these variables in config array in ConfigureDecoder
>call.
>>
>>C) wmadecoder.cpp
>>i) Read Max number of supported channels from configuration file and
>>if
>
>>number of audio channels in Audio stream are more than the config
>>parameter then reject audio. [Default is 2]
>>
>>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>>supported]
>>
>>D) parse_audio.cpp
>>i) Introduce new parameters for WMA10 to structure
>>HXWMATypeSpecificData
>>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>>Data
>>
>>E) R1_Mobile_4_0_Factory.cfg
>>i) New config parameter for max supported channels for a WMA clip.
>>[MAXSupportedWMAChannels]
>>
>>Files modified & changes:
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>>\datatype\wm\audio\renderer\wmadecoder.cpp
>>\datatype\wm\common\pub\parse_audio.h
>>\datatype\wm\common\parse_audio.cpp
>>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>>
>>Image Size and Heap Use impact: None
>>
>>Module Release testing (STIF, Audio) : Passed
>>
>>Test case(s) Added : None
>>
>>Memory leak check performed : Passed, No leaks found
>>
>>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>>
>>Platforms and Profiles Functionality verified: armv5
>>
>>Branch: Head, 210CayS
>>
>>===========================
>>DIFF enclosed as text files
>>===========================
>>
>>thnx & regds
>>AD
>><>
>>
>>
>>
>
From ehyche at real.com Fri Sep 12 09:04:13 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 12 07:23:04 2008
Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <2198383E1141814486F0B881B3260CF502B7139C@daebe103.NOE.Nokia.com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
<2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
<009901c9141b$c48d0ae0$4da720a0$@com>
<64CE512FAA5FAE4B88AEE94299D17522021141060C@daebe103.NOE.Nokia.com>
<2198383E1141814486F0B881B3260CF502B7139C@daebe103.NOE.Nokia.com>
Message-ID: <00a501c914f1$341c17e0$9c5447a0$@com>
My only comment:
+ UINT32 m_nAdvancedEncodeOpt2;
Let's follow coding guidelines and call this "m_ulAdvancedEncodeOpt2".
Rest looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>Sent: Friday, September 12, 2008 12:00 PM
>To: ehyche@real.com; datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in Helix
>
>Hi Eric,
>
>Can you please provide your comments on the latest changes so that I can
>check in by today.
>
>thnx & regds
>AD
>
>-----Original Message-----
>From: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
>Sent: Thursday, September 11, 2008 2:31 PM
>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Hi Eric,
>
>I meant channel mask is a new field in HXAudioConfiguratorWMA.
>
>I fixed the parse_audio.cpp channel mask bug as I am not getting correct
>number of channels when filtering clips with more than 2 channels.
>
>Also I figured out that CWMAudioDecoder won't be the right place to put
>check for number of channels. So I moved this logic to
>HXAudioConfiguratorWMA::ValidateDecoderInfo as it is more decoder
>specific class. Since there is no context available in
>HXAudioConfiguratorWMA I read in the max number of supported channels in
>HXSymbianWMASwAudioDecoder::Open() call and pass in to
>HXAudioConfiguratorWMA using new API for setting max supported shannels.
>This check is now removed from CWMAudioDecoder::Init(). No changes are
>now made to WMADecoder.cpp
>
>I have removed m_nBitPerSample and m_nBlockAlign from
>HXWMATypeSpecificData as they are not required. Also corrected the
>naming convention for numWMAChannels [now in wmasymbianswdecoder.cpp].
>
>Let me know your comments about these new changes.
>
>thnx & regds
>AD
>
>
>
>
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Thursday, September 11, 2008 9:36 AM
>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>>introduced with WMA10 and is not available in older versions. So I am
>>not preparing a mask for WMA10 (see enclosed diff files) as it already
>>has a channel mask present in the stream. Rather I have to avoid
>>calling
>>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>
>>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>
>HXWMATypeSpecificData::m_ulChannelMask has always been there. The issue
>was that I had intended to set m_ulChannelMask for TSD's that didn't
>have it, but had a typo and actually wound up overwriting m_usChannels.
>I'll fix that bug in parse_audio.cpp myself, after you check in your
>changes.
>
>By the way, how does the new m_nBitPerSample differ from the existing
>m_usBitsPerSample?
>And how does the new m_nBlockAlign differ from the existing
>m_usBlockAlign?
>
>One further comment using your new diffs:
>
> + UINT8 numWMAChannels = 0;
>
>Any reason why this is a UINT8 instead of a UINT16? Since we are going
>to compare it against a UINT16, we might as well make it a UINT16, so we
>can avoid the compiler warnings on Win32 and Linux. Also, we should use
>the naming convention and call this "usWMAChannels". And I guess if we
>use a UINT16, then we'll need to use ReadPrefUINT16.
>
>Rest looks good.
>
>Eric
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>>Sent: Wednesday, September 10, 2008 11:59 AM
>>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>>audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>>in Helix
>>
>>Hi Eric,
>>
>>I erroneously sent the older diff files. Please find the latest diff
>>files enclosed which take care of your comments.
>>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>>introduced with WMA10 and is not available in older versions. So I am
>>not preparing a mask for WMA10 (see enclosed diff files) as it already
>>has a channel mask present in the stream. Rather I have to avoid
>>calling
>>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10 [See
>
>>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>>There are other changes for updating config file to indicate support
>>for WMA10 when WMA clip is played the very first time so that multiple
>configurations are not required subsequently.
>>
>>Thnx & regds
>>AD
>>
>>-----Original Message-----
>>From: ext Eric Hyche [mailto:ehyche@real.com]
>>Sent: Wednesday, September 10, 2008 8:40 AM
>>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>>in Helix
>>
>>Anuj,
>>
>>Here are my comments:
>>
>>1) parse_audio.cpp
>>
>>+ case 1:
>>+ pTSD->m_WaveFormatEx.m_usChannels =
>>HXWM_SPEAKER_FRONT_CENTER;
>>+ break;
>>+ case 2:
>>+ pTSD->m_WaveFormatEx.m_usChannels =
>>HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
>>+ break;
>>
>>It looks like we should be setting pTSD->m_ulChannelMask instead of
>>replacing the value of pTSD-
>>>m_WaveFormatEx.m_usChannels. However, it looks like all the code in
>>>parse_audio.cpp has this same
>>problem. I wondered why this didn't cause a playback problem, but
>>apparently it doesn't because in
>>CWMAudioDecoder::GetNumChannels() we first get the number of channels
>>from m_AudioTSD.m_WaveFormatEx.m_usChannels
>>(which would be wrong) and then we override it with the value from the
>>IHXAudioDecoder, which would be correct. So this is masking this
>obvious bug in parse_audio.cpp.
>>
>>So I think all of the places in parse_audio.cpp which set
>>pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
>>changed to set the channel mask to pTSD->m_ulChannelMask instead.
>>
>>2) wmadecoder.cpp
>>
>>- Instead of having to QI for IHXPreferences, you should just use
>> the alternate version of ReadPrefUINT8 which takes an IUnknown
>> and does the QI for you.
>>
>>- Let's call the pref name "MaxSupportedWMAChannels" instead of
>"MAXSupportWMAChannels"
>>
>>
>>The rest looks good.
>>
>>Eric
>>
>>=======================================
>>Eric Hyche (ehyche@real.com)
>>Principal Engineer
>>RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: datatype-dev-bounces@helixcommunity.org
>>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>>ext-anuj.dhamija@nokia.com
>>>Sent: Tuesday, September 09, 2008 5:07 PM
>>>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>>Cc: nokia-private-dev@helixcommunity.org
>>>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>>>Helix
>>>
>>>"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-anuj.dhamija@nokia.com
>>>
>>>Reviewed by:
>>>
>>>Req ID: 106-1630
>>>
>>>Date: 09/09/2008
>>>
>>>Project: Support WMA10 Pro Audio in Helix
>>>
>>>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>>>backward compatible with old
>>>WMA9 decoder
>>>
>>>Overview:
>>>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>>>9t/9E and ARM11 processors. It is not backward compatible as extra
>>>parameters are required to configure the decoder and different payload
>
>>>format is used. Same FourCC code is used to initialize the decoder. So
>
>>>Helix needs to figure out the available codec at runtime and support
>>>both cases (old codec and new codec) accordingly
>>>
>>>
>>>Fix:
>>>A) wmasymbianswdecoder.cpp
>>>i) Method ConfigDecoder introduced to handle configuration of decoder
>>>based on codec available (WMA9 or WMA10) and media type. Update config
>>file with availablity status of WMA10 support for next time.
>>>
>>>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>>>header to frame. InitWMA9Header prepends same header as used by old
>>>decoder. InitWMA10Header prepends header as required by new WMA10 pro
>>decoder.
>>>
>>>B) wmaaudioconfigs.cpp
>>>i) Introduce new methods to set and get format tag. These are used by
>>>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>>>
>>>ii) Add new variables to class HXAudioConfiguratorWMA to support
>>>WMA10Pro. Append these variables in config array in ConfigureDecoder
>>call.
>>>
>>>C) wmadecoder.cpp
>>>i) Read Max number of supported channels from configuration file and
>>>if
>>
>>>number of audio channels in Audio stream are more than the config
>>>parameter then reject audio. [Default is 2]
>>>
>>>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>>>supported]
>>>
>>>D) parse_audio.cpp
>>>i) Introduce new parameters for WMA10 to structure
>>>HXWMATypeSpecificData
>>>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>>>Data
>>>
>>>E) R1_Mobile_4_0_Factory.cfg
>>>i) New config parameter for max supported channels for a WMA clip.
>>>[MAXSupportedWMAChannels]
>>>
>>>Files modified & changes:
>>>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>>>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
>>>\datatype\wm\audio\renderer\wmadecoder.cpp
>>>\datatype\wm\common\pub\parse_audio.h
>>>\datatype\wm\common\parse_audio.cpp
>>>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>>>
>>>Image Size and Heap Use impact: None
>>>
>>>Module Release testing (STIF, Audio) : Passed
>>>
>>>Test case(s) Added : None
>>>
>>>Memory leak check performed : Passed, No leaks found
>>>
>>>Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>>>
>>>Platforms and Profiles Functionality verified: armv5
>>>
>>>Branch: Head, 210CayS
>>>
>>>===========================
>>>DIFF enclosed as text files
>>>===========================
>>>
>>>thnx & regds
>>>AD
>>><>
>>>
>>>
>>>
>>
From ehyche at real.com Fri Sep 12 09:05:56 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 12 07:24:44 2008
Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
In-Reply-To: <005b01c914c3$62488d70$7701a8c0@hp>
References: <00dc01c91345$9933a6a0$7701a8c0@hp>
<00b201c91426$f0575da0$d10618e0$@com>
<005b01c914c3$62488d70$7701a8c0@hp>
Message-ID: <00a601c914f1$71548c50$53fda4f0$@com>
This looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: Alok Jain [mailto:alokj@real.com]
>Sent: Friday, September 12, 2008 6:36 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org
>Subject: Re: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
>
>Thanks Eric,
> I modified the all file as you were mentioned.
>
>Thanks
>Alok
>
>
>----- Original Message -----
>From: "Eric Hyche"
>To: "'Alok Jain'" ;
>Sent: Thursday, September 11, 2008 9:26 PM
>Subject: RE: [datatype-dev] CR: Changes in MP4 Renderer to support FLV format
>
>
>> Alok,
>>
>> Here are my comments:
>>
>> 1) License headers are incorrect on the two new files. The
>> correct license header can be found here:
>>
>> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders#head
>> -793d4290d3c24c0fa63825229350b0e861b6b0fe
>>
>> and for future reference, the page I use to find the
>> license headers is here:
>>
>> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders
>>
>> 2) flvpyld.h - looks good
>>
>> 3) flvpyld.cpp
>> a) In destructor, use HX_RELEASE(m_pAllocator), since it does the same
>> as the code that's currently there.
>> b) In SetAllocator(), we should do a HX_RELEASE(m_pAllocator) before
>> we assign a new value to m_pAllocator.
>> c) In GetPacketTime, we should check for non-NULL pPacket
>> d) In CreateHXCodecPacket, I don't actually see anywhere where
>> the actual data in the pBuffer (the IHXPacket's IHXBuffer) ever
>> gets copied
>> into pHXCodecData->data. The memory is allocated, but nothing
>> ever gets copied into it.
>>
>> 4) In datatype/mp4/payload/Umakefil,
>> a) We should not manually set
>> project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6").
>> This should be set in the profile. So you may need to include
>> a diff for adding this to the appropriate .pfi file in
>> ribosome/build/umakepf.
>>
>> 5) datatype/mp4/video/renderer/libumakefil
>> a) same comment as 4(a) above
>>
>> Rest looks good.
>>
>> Eric
>>
>> =======================================
>> Eric Hyche (ehyche@real.com)
>> Principal Engineer
>> RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: datatype-dev-bounces@helixcommunity.org
>>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Alok
>>>Jain
>>>Sent: Wednesday, September 10, 2008 9:03 AM
>>>To: datatype-dev@helixcommunity.org
>>>Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
>>>format
>>>
>>>
>>>Synopsis:
>>>
>>>MP4 video renderer modifications to support flv format.
>>>
>>>Overview:
>>>Changes done to support flv format. mp4 video renderer will look at
>>>the CodecID = HX_FLV_CODEC_ID in the stream header and attempt to
>>>load the vp67 codec.
>>>
>>>
>>>Files Modified:
>>>/cvsroot/datatype/mp4/payload/Umakefil
>>>
>>>/cvsroot/datatype/mp4/video/renderer/libumakefil
>>>
>>>/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>
>>>/cvsroot/datatype/mp4/video/renderer/mp4video.cpp
>>>
>>>Files Added:
>>>/cvsroot/datatype/mp4/payload/flvpyld.cpp
>>>
>>>/cvsroot/datatype/mp4/payload/pub/ flvpyld.h
>>>
>>>
>>>
>>>Image Size and Heap Use impact (Client -Only):
>>>None.
>>>
>>>Platforms and Profiles Affected:
>>>None
>>>
>>>Distribution Libraries Affected:
>>>None.
>>>
>>>Distribution library impact and planned action:
>>>None.
>>>
>>>Platforms and Profiles Build Verified:
>>> Profile: helix-client-all-defines
>>>
>>> BIF branch: helix.bif
>>> Target: splay
>>>
>>>Branch: HEAD
>>>
>>>
>>>Thanks & Regards
>>>
>>>Alok Jain
>>
From ehyche at real.com Fri Sep 12 09:12:31 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 12 07:31:20 2008
Subject: Resending: [datatype-dev] CR: NULL Decoder
In-Reply-To: <011401c914cc$1dae5ce0$7701a8c0@hp>
References: <011701c91346$e94743d0$7701a8c0@hp>
<00a101c91423$2d4bc100$87e34300$@com>
<011401c914cc$1dae5ce0$7701a8c0@hp>
Message-ID: <00aa01c914f2$5d682fc0$18388f40$@com>
Further comments on this new diff:
a) There are still several places in nullcodecapi.cpp
where we use a pointer passed in as an API argument
without first checking it for NULL.
b) BOOL m_bFirstPNStreamInput;
BOOL is deprecated on HEAD and later branches.
Use HXBOOL instead.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: Alok Jain [mailto:alokj@real.com]
>Sent: Friday, September 12, 2008 7:39 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org
>Cc: dyek@real.com
>Subject: Resending: [datatype-dev] CR: NULL Decoder
>
>Thanks Eric
> Att. is the modified code as per your comments.
> Please verify the suggested changes so that I can send the final CR
>
> Thanks & Regards
>
> Alok Jain
>
>
>----- Original Message -----
>From: "Eric Hyche"
>To: "'Alok Jain'" ;
>Sent: Thursday, September 11, 2008 8:59 PM
>Subject: RE: [datatype-dev] CR: NULL Decoder
>
>
>> Alok,
>>
>> Here are my comments:
>>
>> 1) This should go in datatype/null/video/decoder. This location
>> makes is consistent with the location of other decoders,
>> and distinguishes it from any future audio null decoder.
>>
>> 2) I didn't see any BIF file changes. Please add a null decoder
>> target to helix.bif and provide the resulting diffs for helix.bif.
>>
>> 3) Umakefil
>> a) Visual Studio is detecting inconsistent line endings in this file.
>> Please correct this.
>> b) The file needs to end in a blank line or the python scripts that
>> check into CVS will complain.
>>
>> 4) win32.pcf
>> a) need a blank line on the end
>>
>> 5) nullcodecapi.cpp
>> a) In each of the entrypoints, we should make sure that codecRef
>> is non-NULL.
>>
>> 6) nullcodec.h
>> a) Visual Studio says inconsistent line endings on this file as well.
>>
>> 7) nullcodec.cpp
>>
>> a) We need to check m_pFormatVideo for non-NULL before using it;
>> b) Need to check m_pInputAllocator and m_pContext for non-NULL before
>> AddRef()'ing them
>> c) Need to check m_pOutputAllocator for non-NULL before using it
>> d) Need to check puSize for non-NULL
>> e) Need to check pHeader for non-NULL before using
>> f) Need to check pcdOutData->data before memcpy'ing into it
>> g) Need to check m_fpData_Callback for non-NULL before calling it
>> h) Use HX_VECTOR_DELETE(pcdOutData) instead of "delete [] pcdOutData".
>>
>> Rest looks good.
>>
>> Eric
>>
>> =======================================
>> Eric Hyche (ehyche@real.com)
>> Principal Engineer
>> RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: datatype-dev-bounces@helixcommunity.org
>>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>>Behalf Of Alok Jain
>>>Sent: Wednesday, September 10, 2008 9:13 AM
>>>To: datatype-dev@helixcommunity.org
>>>Subject: [datatype-dev] CR: NULL Decoder
>>>
>>>Synopsis:
>>>
>>>Null decoder implementaion.
>>>
>>>
>>>
>>>Overview:
>>>Null decoder implements the Helix video decoder API. The null decoder
>>>produces one black frame for
>>>every input encoded frame it receives.
>>>
>>>
>>>Files Modified:
>>>None
>>>
>>>
>>>Files Added:
>>>/cvsroot/datatype/null/codec/nullcodec.cpp
>>>
>>>/cvsroot/datatype/null/codec/nullcodec.h
>>>
>>>/cvsroot/datatype/null/codec/nullcodecapi.cpp
>>>
>>>/cvsroot/datatype/null/codec/ Umakefil
>>>/cvsroot/datatype/null/codec/ win32.pcf
>>>
>>>
>>>
>>>Image Size and Heap Use impact (Client -Only):
>>>None.
>>>
>>>Platforms and Profiles Affected:
>>>None
>>>
>>>Distribution Libraries Affected:
>>>None.
>>>
>>>Distribution library impact and planned action:
>>>None.
>>>
>>>
>>>Platforms and Profiles Build Verified:
>>> Profile: helix-client-all-defines
>>>
>>> BIF branch: helix.bif
>>> Target: splay
>>>
>>>Branch: HEAD
>>>
>>>
>>>Thanks & Regards
>>>
>>>Alok Jain
>>
>>
From alokj at real.com Mon Sep 15 02:08:13 2008
From: alokj at real.com (Alok Jain)
Date: Mon Sep 15 00:26:25 2008
Subject: Resending: [datatype-dev] CR: NULL Decoder
References: <011701c91346$e94743d0$7701a8c0@hp>
<00a101c91423$2d4bc100$87e34300$@com>
<011401c914cc$1dae5ce0$7701a8c0@hp>
<00aa01c914f2$5d682fc0$18388f40$@com>
Message-ID: <003a01c91712$984022c0$7701a8c0@hp>
Thanks Eric, Please find the Modified code after including changes.
Thanks
Alok
----- Original Message -----
From: "Eric Hyche"
To: "'Alok Jain'" ;
Cc:
Sent: Friday, September 12, 2008 9:42 PM
Subject: RE: Resending: [datatype-dev] CR: NULL Decoder
> Further comments on this new diff:
>
> a) There are still several places in nullcodecapi.cpp
> where we use a pointer passed in as an API argument
> without first checking it for NULL.
>
> b) BOOL m_bFirstPNStreamInput;
>
> BOOL is deprecated on HEAD and later branches.
> Use HXBOOL instead.
>
> Rest looks good.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: Alok Jain [mailto:alokj@real.com]
>>Sent: Friday, September 12, 2008 7:39 AM
>>To: ehyche@real.com; datatype-dev@helixcommunity.org
>>Cc: dyek@real.com
>>Subject: Resending: [datatype-dev] CR: NULL Decoder
>>
>>Thanks Eric
>> Att. is the modified code as per your comments.
>> Please verify the suggested changes so that I can send the final CR
>>
>> Thanks & Regards
>>
>> Alok Jain
>>
>>
>>----- Original Message -----
>>From: "Eric Hyche"
>>To: "'Alok Jain'" ;
>>Sent: Thursday, September 11, 2008 8:59 PM
>>Subject: RE: [datatype-dev] CR: NULL Decoder
>>
>>
>>> Alok,
>>>
>>> Here are my comments:
>>>
>>> 1) This should go in datatype/null/video/decoder. This location
>>> makes is consistent with the location of other decoders,
>>> and distinguishes it from any future audio null decoder.
>>>
>>> 2) I didn't see any BIF file changes. Please add a null decoder
>>> target to helix.bif and provide the resulting diffs for helix.bif.
>>>
>>> 3) Umakefil
>>> a) Visual Studio is detecting inconsistent line endings in this file.
>>> Please correct this.
>>> b) The file needs to end in a blank line or the python scripts that
>>> check into CVS will complain.
>>>
>>> 4) win32.pcf
>>> a) need a blank line on the end
>>>
>>> 5) nullcodecapi.cpp
>>> a) In each of the entrypoints, we should make sure that codecRef
>>> is non-NULL.
>>>
>>> 6) nullcodec.h
>>> a) Visual Studio says inconsistent line endings on this file as well.
>>>
>>> 7) nullcodec.cpp
>>>
>>> a) We need to check m_pFormatVideo for non-NULL before using it;
>>> b) Need to check m_pInputAllocator and m_pContext for non-NULL before
>>> AddRef()'ing them
>>> c) Need to check m_pOutputAllocator for non-NULL before using it
>>> d) Need to check puSize for non-NULL
>>> e) Need to check pHeader for non-NULL before using
>>> f) Need to check pcdOutData->data before memcpy'ing into it
>>> g) Need to check m_fpData_Callback for non-NULL before calling it
>>> h) Use HX_VECTOR_DELETE(pcdOutData) instead of "delete [] pcdOutData".
>>>
>>> Rest looks good.
>>>
>>> Eric
>>>
>>> =======================================
>>> Eric Hyche (ehyche@real.com)
>>> Principal Engineer
>>> RealNetworks, Inc.
>>>
>>>
>>>>-----Original Message-----
>>>>From: datatype-dev-bounces@helixcommunity.org
>>>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>>>Behalf Of Alok Jain
>>>>Sent: Wednesday, September 10, 2008 9:13 AM
>>>>To: datatype-dev@helixcommunity.org
>>>>Subject: [datatype-dev] CR: NULL Decoder
>>>>
>>>>Synopsis:
>>>>
>>>>Null decoder implementaion.
>>>>
>>>>
>>>>
>>>>Overview:
>>>>Null decoder implements the Helix video decoder API. The null decoder
>>>>produces one black frame for
>>>>every input encoded frame it receives.
>>>>
>>>>
>>>>Files Modified:
>>>>None
>>>>
>>>>
>>>>Files Added:
>>>>/cvsroot/datatype/null/codec/nullcodec.cpp
>>>>
>>>>/cvsroot/datatype/null/codec/nullcodec.h
>>>>
>>>>/cvsroot/datatype/null/codec/nullcodecapi.cpp
>>>>
>>>>/cvsroot/datatype/null/codec/ Umakefil
>>>>/cvsroot/datatype/null/codec/ win32.pcf
>>>>
>>>>
>>>>
>>>>Image Size and Heap Use impact (Client -Only):
>>>>None.
>>>>
>>>>Platforms and Profiles Affected:
>>>>None
>>>>
>>>>Distribution Libraries Affected:
>>>>None.
>>>>
>>>>Distribution library impact and planned action:
>>>>None.
>>>>
>>>>
>>>>Platforms and Profiles Build Verified:
>>>> Profile: helix-client-all-defines
>>>>
>>>> BIF branch: helix.bif
>>>> Target: splay
>>>>
>>>>Branch: HEAD
>>>>
>>>>
>>>>Thanks & Regards
>>>>
>>>>Alok Jain
>>>
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: updated_null_decoder.zip
Type: application/octet-stream
Size: 12468 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080915/c11e5eb0/updated_null_decoder-0001.obj
-------------- next part --------------
Index: helix.bif
===================================================================
RCS file: /cvsroot/common/build/BIF/helix.bif,v
retrieving revision 1.698
diff -u -r1.698 helix.bif
--- helix.bif 12 Sep 2008 01:06:01 -0000 1.698
+++ helix.bif 12 Sep 2008 11:15:55 -0000
@@ -14563,6 +14563,20 @@
+
+
+
+ common_include
+ common_runtime
+ common_container
+ common_util
+ common_system
+ common_dbgtool
+ common_runtime
+ datatype_common_util
+ common_log_logutil
+
+
From alokj at real.com Tue Sep 16 05:37:21 2008
From: alokj at real.com (Alok Jain)
Date: Tue Sep 16 03:55:19 2008
Subject: Final CR: [datatype-dev] CR: NULL Decoder
References: <011701c91346$e94743d0$7701a8c0@hp> <48C929B5.5000208@real.com>
<009d01c91420$08039010$180ab030$@com>
Message-ID: <004b01c917f8$fa1d9220$7701a8c0@hp>
Synopsis:
Final CR for the null decoder with added implementation for Sequence number
and time stamp in the frame (white frame) on windows
platform.
Overview:
Null decoder implements the Helix video decoder API. The null decoder
produces one frame showing sequence no. and timestamp for every input
encoded frame it receives.
Files Modified:
None
Files Added:
/cvsroot/datatype/null/video/decoder/nullcodec.cpp
/cvsroot/datatype/null/video/decoder/nullcodec.h
/cvsroot/datatype/null/video/decoder/nullcodecapi.cpp
/cvsroot/datatype/null/video/decoder/ Umakefil
/cvsroot/datatype/null/video/decoder/ win32.pcf
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
None
Distribution Libraries Affected:
None.
Distribution library impact and planned action:
None.
Platforms and Profiles Build Verified:
Profile: helix-client-all-defines
BIF branch: helix.bif
Target: splay
Branch: HEAD
Thanks
Alok Jain
----- Original Message -----
From: "Eric Hyche"
To: "'Daniel Yek'" ;
Cc: "'Alok Jain'"
Sent: Thursday, September 11, 2008 8:36 PM
Subject: RE: [datatype-dev] CR: NULL Decoder
> Daniel/Alok:
>
> I was thinking exactly along the same lines. It would be useful to have
> it actually write the frame number into the frame, or perhaps the
> millisecond timestamp of the frame. I remember debugging an issue
> a couple of years ago where the the RV renderer was not issuing
> the proper commands to the RV decoder to tell it that it had received
> its last frame, and that it should flush all of its frames. In order
> to verify we had fixed this, we had to construct a special clip that wrote
> frame
> numbers in bottom right. Before the bug was fixed, you never saw the final
> frame of the sequence. After the bug was fixed, you could see that the
> last frame in the clip was bltted.
>
> Having a null decoder would have really helped with diagnosing that
> problem.
>
> Also, I see the null decoder as useful when analyzing CPU usage. We
> already
> have a null renderer, but now with a null decoder, we can measure
> performance
> of various video renderers where they are performing everything but
> decoding.
>
> Alok: can you investigate to see how much dev time it would be to
> write some of the parameters of the input HXCODEC_DATA into the output
> frame. I describe below what I have in mind. If your investigation
> tells you that you could do this in 2 days of work or less, then please
> go ahead and do it. If it's more than 2 days, then please just document
> the results of your investigation, and send them to me. In that case,
> we'll just put that on the to-do list.
>
> The input frame the null decoder receives is in a HXCODEC_DATA struct.
> Two of the parameters of that struct are a ULONG32 timestamp and
> a UINT16 sequenceNum. Both of those would be really useful to see
> visually on the screen. The null decoder produces an an I420 frame
> on output and I420 frames are laid out in memory like this:
>
> --------------------------------
> | |
> | |
> | |
> | Y |
> | |
> | |
> | |
> | |
> --------------------------------
> | |
> | U |
> | |
> | |
> ----------------
> | |
> | V |
> | |
> | |
> ----------------
>
> The width and height of the Y are the same as the width
> and height of the frame. However, the U and V planes are
> subsampled and are half the width and half the height of
> the Y plane.
>
> The Y plane is the luminance plane. So you can essentially
> think of it as a grayscale version of the video frame.
>
> So what I was thinking is that after you generate the dummy
> output video frame, you would construct a string that
> contains both the value of sequenceNum and timestamp,
> using a fixed number of characters for both. So perhaps
> your sprintf() command might look something like:
>
> sprintf(szBuffer, "%5u %10lu", sequenceNum, timestamp);
>
> Then you could take that string and draw it into
> the luminance plane buffer. After you drew it, it might
> look something like this:
>
> --------------------------------
> | |
> | |
> | |
> | Y |
> | |
> | |
> | 274 10450 |
> | |
> --------------------------------
> | |
> | U |
> | |
> | |
> ----------------
> | |
> | V |
> | |
> | |
> ----------------
>
> if the sequence number was 274 and the timestamp
> on the frame was 10450.
>
> Exactly how to do that drawing is the part that
> needs investigation. On Windows, I think it's pretty
> clear how to do it. You make a DIB out of the Y buffer
> and then use that DIB as the offscreen buffer for
> your GDI drawing commands like DrawText().
>
> I'm less familiar with how to do it on Linux.
> Daniel: do you have any suggestions off the top
> of your head on the easiest way to do it for Linux?
>
> Another approach would simply be to come up with simple
> bitmaps for the characters 0-9 and then copy those
> characters into the buffer. This would have the advantage
> of being cross-platform, but it probably wouldn't look
> as nice as using the platform-specific drawing APIs.
>
> Anyway, that's my idea. Let me know what you find out.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>Behalf Of Daniel Yek
>>Sent: Thursday, September 11, 2008 10:23 AM
>>To: datatype-dev@helixcommunity.org
>>Cc: Alok Jain
>>Subject: Re: [datatype-dev] CR: NULL Decoder
>>
>>Null decoder sounds useful.
>>
>>I think it would be even more useful if the null decoder is extended to
>>output a repeated sequence of moving patterns, starting from a
>>recognizable key frame and looping the rest of the moving non-key frames
>>and then back to the key frame and repeat.
>>
>>The sequence can be a smaller rectangular area extended to the larger
>>(black or with border lines) output dimensions.
>>
>>Maybe this feature should be a variant of the null decoder instead.
>>
>>Thanks.
>>
>>--
>>Daniel Yek.
>>
>>
>>
>>Alok Jain wrote:
>>>
>>> Synopsis:
>>>
>>> Null decoder implementaion.
>>>
>>>
>>>
>>> Overview:
>>> Null decoder implements the Helix video decoder API. The null decoder
>>> produces one black frame for every input encoded frame it receives.
>>>
>>>
>>> Files Modified:
>>> None
>>>
>>>
>>> Files Added:
>>> /cvsroot/datatype/null/codec/nullcodec.cpp
>>>
>>> /cvsroot/datatype/null/codec/nullcodec.h
>>>
>>> /cvsroot/datatype/null/codec/nullcodecapi.cpp
>>>
>>> /cvsroot/datatype/null/codec/ Umakefil
>>> /cvsroot/datatype/null/codec/ win32.pcf
>>>
>>>
>>>
>>> Image Size and Heap Use impact (Client -Only):
>>> None.
>>>
>>> Platforms and Profiles Affected:
>>> None
>>>
>>> Distribution Libraries Affected:
>>> None.
>>>
>>> Distribution library impact and planned action:
>>> None.
>>>
>>>
>>> Platforms and Profiles Build Verified:
>>> Profile: helix-client-all-defines
>>>
>>> BIF branch: helix.bif
>>> Target: splay
>>>
>>> Branch: HEAD
>>>
>>>
>>> Thanks & Regards
>>>
>>> Alok Jain
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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 --------------
A non-text attachment was scrubbed...
Name: NullDecoder.zip
Type: application/octet-stream
Size: 13820 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080916/7eda6dc6/NullDecoder.obj
From alokj at real.com Thu Sep 18 03:09:35 2008
From: alokj at real.com (Alok Jain)
Date: Thu Sep 18 01:27:02 2008
Subject: [datatype-dev] Resending- Final CR: NULL Decoder
Message-ID: <003301c91976$a9921bd0$7701a8c0@hp>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: NullDecoder.zip
Type: application/octet-stream
Size: 13820 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080918/8ee11640/NullDecoder-0001.obj
From ehyche at real.com Thu Sep 18 09:13:54 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 18 07:31:10 2008
Subject: [datatype-dev] RE: Resending- Final CR: NULL Decoder
In-Reply-To: <003301c91976$a9921bd0$7701a8c0@hp>
References: <003301c91976$a9921bd0$7701a8c0@hp>
Message-ID: <008001c919a9$8c52e4e0$a4f8aea0$@com>
Alok,
Here are my comments:
1) helix.bif
a)let's follow the pattern of the other
targets and give this new target an id attribute
of "datatype_null_video_codec" and a name attribute
of "datatype/null/video/codec". Therefore, we'll
check it into datatype/null/video/codec. This follows
the same pattern as:
datatype/rm/video/codec
and
datatype/wm/video/codec
b) common_include should be included in the
rather than the
c) video/include is added to the include path in win32.pcf, but
is not listed in the for the BIF target.
d) video_vidutil is added to the libraries in win32.pcf but is
not listed in the in the BIF target.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: Alok Jain [mailto:alokj@real.com]
>Sent: Thursday, September 18, 2008 6:10 AM
>To: ehyche@real.com; datatype-dev@helixcommunity.org
>Subject: Resending- Final CR: NULL Decoder
>
>
>Synopsis:
>
>Final CR for the null decoder with added implementation for Sequence number and time stamp in the
>frame (white frame) on windows platform.
>
>Overview:
>Null decoder implements the Helix video decoder API. The null decoder produces one frame showing
>sequence no. and timestamp for every input encoded frame it receives.
>
> Files Modified:
> None
>
> Files Added:
> /cvsroot/datatype/null/video/decoder/nullcodec.cpp
> /cvsroot/datatype/null/video/decoder/nullcodec.h
> /cvsroot/datatype/null/video/decoder/nullcodecapi.cpp
>
> /cvsroot/datatype/null/video/decoder/ Umakefil /cvsroot/datatype/null/video/decoder/ win32.pcf
>
> Image Size and Heap Use impact (Client -Only):
> None.
>
> Platforms and Profiles Affected:
> None
>
> Distribution Libraries Affected:
> None.
>
> Distribution library impact and planned action:
> None.
>
>
> Platforms and Profiles Build Verified:
> Profile: helix-client-all-defines
>
> BIF branch: helix.bif
> Target: splay
>
> Branch: HEAD
>
>Thanks
>Alok Jain
>
>----- Original Message -----
>From: "Eric Hyche"
>To: "'Daniel Yek'" ;
>Cc: "'Alok Jain'"
>Sent: Thursday, September 11, 2008 8:36 PM
>Subject: RE: [datatype-dev] CR: NULL Decoder
>
>
>> Daniel/Alok:
>>
>> I was thinking exactly along the same lines. It would be useful to have
>> it actually write the frame number into the frame, or perhaps the
>> millisecond timestamp of the frame. I remember debugging an issue
>> a couple of years ago where the the RV renderer was not issuing
>> the proper commands to the RV decoder to tell it that it had received
>> its last frame, and that it should flush all of its frames. In order
>> to verify we had fixed this, we had to construct a special clip that wrote
>> frame
>> numbers in bottom right. Before the bug was fixed, you never saw the final
>> frame of the sequence. After the bug was fixed, you could see that the
>> last frame in the clip was bltted.
>>
>> Having a null decoder would have really helped with diagnosing that
>> problem.
>>
>> Also, I see the null decoder as useful when analyzing CPU usage. We
>> already
>> have a null renderer, but now with a null decoder, we can measure
>> performance
>> of various video renderers where they are performing everything but
>> decoding.
>>
>> Alok: can you investigate to see how much dev time it would be to
>> write some of the parameters of the input HXCODEC_DATA into the output
>> frame. I describe below what I have in mind. If your investigation
>> tells you that you could do this in 2 days of work or less, then please
>> go ahead and do it. If it's more than 2 days, then please just document
>> the results of your investigation, and send them to me. In that case,
>> we'll just put that on the to-do list.
>>
>> The input frame the null decoder receives is in a HXCODEC_DATA struct.
>> Two of the parameters of that struct are a ULONG32 timestamp and
>> a UINT16 sequenceNum. Both of those would be really useful to see
>> visually on the screen. The null decoder produces an an I420 frame
>> on output and I420 frames are laid out in memory like this:
>>
>> --------------------------------
>> | |
>> | |
>> | |
>> | Y |
>> | |
>> | |
>> | |
>> | |
>> --------------------------------
>> | |
>> | U |
>> | |
>> | |
>> ----------------
>> | |
>> | V |
>> | |
>> | |
>> ----------------
>>
>> The width and height of the Y are the same as the width
>> and height of the frame. However, the U and V planes are
>> subsampled and are half the width and half the height of
>> the Y plane.
>>
>> The Y plane is the luminance plane. So you can essentially
>> think of it as a grayscale version of the video frame.
>>
>> So what I was thinking is that after you generate the dummy
>> output video frame, you would construct a string that
>> contains both the value of sequenceNum and timestamp,
>> using a fixed number of characters for both. So perhaps
>> your sprintf() command might look something like:
>>
>> sprintf(szBuffer, "%5u %10lu", sequenceNum, timestamp);
>>
>> Then you could take that string and draw it into
>> the luminance plane buffer. After you drew it, it might
>> look something like this:
>>
>> --------------------------------
>> | |
>> | |
>> | |
>> | Y |
>> | |
>> | |
>> | 274 10450 |
>> | |
>> --------------------------------
>> | |
>> | U |
>> | |
>> | |
>> ----------------
>> | |
>> | V |
>> | |
>> | |
>> ----------------
>>
>> if the sequence number was 274 and the timestamp
>> on the frame was 10450.
>>
>> Exactly how to do that drawing is the part that
>> needs investigation. On Windows, I think it's pretty
>> clear how to do it. You make a DIB out of the Y buffer
>> and then use that DIB as the offscreen buffer for
>> your GDI drawing commands like DrawText().
>>
>> I'm less familiar with how to do it on Linux.
>> Daniel: do you have any suggestions off the top
>> of your head on the easiest way to do it for Linux?
>>
>> Another approach would simply be to come up with simple
>> bitmaps for the characters 0-9 and then copy those
>> characters into the buffer. This would have the advantage
>> of being cross-platform, but it probably wouldn't look
>> as nice as using the platform-specific drawing APIs.
>>
>> Anyway, that's my idea. Let me know what you find out.
>>
>> Eric
>>
>> =======================================
>> Eric Hyche (ehyche@real.com)
>> Principal Engineer
>> RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: datatype-dev-bounces@helixcommunity.org
>>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>>Behalf Of Daniel Yek
>>>Sent: Thursday, September 11, 2008 10:23 AM
>>>To: datatype-dev@helixcommunity.org
>>>Cc: Alok Jain
>>>Subject: Re: [datatype-dev] CR: NULL Decoder
>>>
>>>Null decoder sounds useful.
>>>
>>>I think it would be even more useful if the null decoder is extended to
>>>output a repeated sequence of moving patterns, starting from a
>>>recognizable key frame and looping the rest of the moving non-key frames
>>>and then back to the key frame and repeat.
>>>
>>>The sequence can be a smaller rectangular area extended to the larger
>>>(black or with border lines) output dimensions.
>>>
>>>Maybe this feature should be a variant of the null decoder instead.
>>>
>>>Thanks.
>>>
>>>--
>>>Daniel Yek.
>>>
>>>
>>>
>>>Alok Jain wrote:
>>>>
>>>> Synopsis:
>>>>
>>>> Null decoder implementaion.
>>>>
>>>>
>>>>
>>>> Overview:
>>>> Null decoder implements the Helix video decoder API. The null decoder
>>>> produces one black frame for every input encoded frame it receives.
>>>>
>>>>
>>>> Files Modified:
>>>> None
>>>>
>>>>
>>>> Files Added:
>>>> /cvsroot/datatype/null/codec/nullcodec.cpp
>>>>
>>>> /cvsroot/datatype/null/codec/nullcodec.h
>>>>
>>>> /cvsroot/datatype/null/codec/nullcodecapi.cpp
>>>>
>>>> /cvsroot/datatype/null/codec/ Umakefil
>>>> /cvsroot/datatype/null/codec/ win32.pcf
>>>>
>>>>
>>>>
>>>> Image Size and Heap Use impact (Client -Only):
>>>> None.
>>>>
>>>> Platforms and Profiles Affected:
>>>> None
>>>>
>>>> Distribution Libraries Affected:
>>>> None.
>>>>
>>>> Distribution library impact and planned action:
>>>> None.
>>>>
>>>>
>>>> Platforms and Profiles Build Verified:
>>>> Profile: helix-client-all-defines
>>>>
>>>> BIF branch: helix.bif
>>>> Target: splay
>>>>
>>>> Branch: HEAD
>>>>
>>>>
>>>> Thanks & Regards
>>>>
>>>> Alok Jain
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> 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-anuj.dhamija at nokia.com Thu Sep 18 17:03:54 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Thu Sep 18 15:21:11 2008
Subject: CN: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
Helix
In-Reply-To: <00a501c914f1$341c17e0$9c5447a0$@com>
References: <2198383E1141814486F0B881B3260CF502B2C5F3@daebe103.NOE.Nokia.com>
<005d01c9134a$b587e6e0$2097b4a0$@com>
<2198383E1141814486F0B881B3260CF502B2C76A@daebe103.NOE.Nokia.com>
<009901c9141b$c48d0ae0$4da720a0$@com>
<64CE512FAA5FAE4B88AEE94299D17522021141060C@daebe103.NOE.Nokia.com>
<2198383E1141814486F0B881B3260CF502B7139C@daebe103.NOE.Nokia.com>
<00a501c914f1$341c17e0$9c5447a0$@com>
Message-ID: <2198383E1141814486F0B881B3260CF502BBE0E6@daebe103.NOE.Nokia.com>
Checkins made to Head and 210Cays.
Final checkin comments as following:
========================================
"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-anuj.dhamija@nokia.com
Reviewed by:
Req ID: 106-1630
Date: 09/09/2008
Project: Support WMA10 Pro Audio in Helix
Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
backward compatible with old WMA9 decoder
Overview:
WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
9t/9E and ARM11 processors. It is not backward compatible as extra
parameters are required to configure the decoder and different payload
format is used. Same FourCC code is used to initialize the decoder. So
Helix needs to figure out the available codec at runtime and support
both cases (old codec and new codec) accordingly
Fix:
A) wmasymbianswdecoder.cpp
i) Method ConfigDecoder introduced to handle configuration of decoder
based on codec available (WMA9 or WMA10) and media type. Update config
file with availablity status of WMA10 support for next time.
ii) In OpenDecoder() read in max number of WMA10 channels supported and
pass this value to HXAudioConfiguratorWMA (wmaaudioconfigs.cpp).
ii) Method InitWMA9Header and InitWMA10Header take care of prepending
header to frame. InitWMA9Header prepends same header as used by old
decoder. InitWMA10Header prepends header as required by new WMA10 pro
decoder.
iii) Level 2 logs in Decode() method converted to Level 4.
B) wmaaudioconfigs.cpp
i) Introduce new methods to set and get format tag. These are used by
ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
ii) Introduce new method to set maximum wma10 channels supported
(Default 2).
ii) Add new variables to class HXAudioConfiguratorWMA to support
WMA10Pro. Append these variables in config array in ConfigureDecoder
call.
iii) Modify ValidateDecoderInfo method to reject clips with more than
maximum supported channels. Also reject 24 bit WMA clips as it is not
yet supported. Call this method from ValidateDecoderConfig() method.
iv) In method HXAudioConfiguratorWMA::ValidateDecoderConfig() do not
call CalculateNumberOfChannels to calculate number of channels from
value returned by ParseAudioTypeSpecificData() as number of channels is
no more masked (it is fixed in parse_audio.cpp as below).
C) parse_audio.cpp
i) Introduce new parameters for WMA10 to structure HXWMATypeSpecificData
ii) Unpack new parameters for WMA10 from payload when parsing Audio Data
iii) Fix bug where field number of channels is modified instead of
channel mask field for WMA9 and older.
D) R1_Mobile_4_0_Factory.cfg
i) New config parameter for max supported channels for a WMA clip.
[MAXSupportedWMAChannels]
Files modified & changes:
\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.h
\datatype\wm\common\pub\parse_audio.h
\datatype\wm\common\parse_audio.cpp
\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
Image Size and Heap Use impact: None
Module Release testing (STIF, Audio) : Passed
Test case(s) Added : None
Memory leak check performed : Passed, No leaks found
Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
Platforms and Profiles Functionality verified: armv5
Branch: Head, 210CayS
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Friday, September 12, 2008 11:04 AM
To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
Cc: nokia-private-dev@helixcommunity.org
Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
in Helix
My only comment:
+ UINT32 m_nAdvancedEncodeOpt2;
Let's follow coding guidelines and call this "m_ulAdvancedEncodeOpt2".
Rest looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>Sent: Friday, September 12, 2008 12:00 PM
>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Hi Eric,
>
>Can you please provide your comments on the latest changes so that I
>can check in by today.
>
>thnx & regds
>AD
>
>-----Original Message-----
>From: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas)
>Sent: Thursday, September 11, 2008 2:31 PM
>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>Hi Eric,
>
>I meant channel mask is a new field in HXAudioConfiguratorWMA.
>
>I fixed the parse_audio.cpp channel mask bug as I am not getting
>correct number of channels when filtering clips with more than 2
channels.
>
>Also I figured out that CWMAudioDecoder won't be the right place to put
>check for number of channels. So I moved this logic to
>HXAudioConfiguratorWMA::ValidateDecoderInfo as it is more decoder
>specific class. Since there is no context available in
>HXAudioConfiguratorWMA I read in the max number of supported channels
>in
>HXSymbianWMASwAudioDecoder::Open() call and pass in to
>HXAudioConfiguratorWMA using new API for setting max supported
shannels.
>This check is now removed from CWMAudioDecoder::Init(). No changes are
>now made to WMADecoder.cpp
>
>I have removed m_nBitPerSample and m_nBlockAlign from
>HXWMATypeSpecificData as they are not required. Also corrected the
>naming convention for numWMAChannels [now in wmasymbianswdecoder.cpp].
>
>Let me know your comments about these new changes.
>
>thnx & regds
>AD
>
>
>
>
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Thursday, September 11, 2008 9:36 AM
>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>Cc: nokia-private-dev@helixcommunity.org
>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>in Helix
>
>>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>>introduced with WMA10 and is not available in older versions. So I am
>>not preparing a mask for WMA10 (see enclosed diff files) as it already
>>has a channel mask present in the stream. Rather I have to avoid
>>calling
>>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10
>>[See
>
>>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>
>HXWMATypeSpecificData::m_ulChannelMask has always been there. The issue
>was that I had intended to set m_ulChannelMask for TSD's that didn't
>have it, but had a typo and actually wound up overwriting m_usChannels.
>I'll fix that bug in parse_audio.cpp myself, after you check in your
>changes.
>
>By the way, how does the new m_nBitPerSample differ from the existing
>m_usBitsPerSample?
>And how does the new m_nBlockAlign differ from the existing
>m_usBlockAlign?
>
>One further comment using your new diffs:
>
> + UINT8 numWMAChannels = 0;
>
>Any reason why this is a UINT8 instead of a UINT16? Since we are going
>to compare it against a UINT16, we might as well make it a UINT16, so
>we can avoid the compiler warnings on Win32 and Linux. Also, we should
>use the naming convention and call this "usWMAChannels". And I guess if
>we use a UINT16, then we'll need to use ReadPrefUINT16.
>
>Rest looks good.
>
>Eric
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: ext-anuj.dhamija@nokia.com [mailto:ext-anuj.dhamija@nokia.com]
>>Sent: Wednesday, September 10, 2008 11:59 AM
>>To: ehyche@real.com; datatype-dev@helixcommunity.org;
>>audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>>in Helix
>>
>>Hi Eric,
>>
>>I erroneously sent the older diff files. Please find the latest diff
>>files enclosed which take care of your comments.
>>Regarding m_usChannelMask in parse_audio.cpp, this mask is new field
>>introduced with WMA10 and is not available in older versions. So I am
>>not preparing a mask for WMA10 (see enclosed diff files) as it already
>>has a channel mask present in the stream. Rather I have to avoid
>>calling
>>CWMAudioDecoder::GetNumChannels() for m_usChannels field for WMA10
>>[See
>
>>changes in method HXAudioConfiguratorWMA::ValidateDecoderConfig].
>>There are other changes for updating config file to indicate support
>>for WMA10 when WMA clip is played the very first time so that multiple
>configurations are not required subsequently.
>>
>>Thnx & regds
>>AD
>>
>>-----Original Message-----
>>From: ext Eric Hyche [mailto:ehyche@real.com]
>>Sent: Wednesday, September 10, 2008 8:40 AM
>>To: Dhamija Anuj (EXT-InfoVisionConsultants-MSW/Dallas);
>>datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>Cc: nokia-private-dev@helixcommunity.org
>>Subject: RE: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio
>>in Helix
>>
>>Anuj,
>>
>>Here are my comments:
>>
>>1) parse_audio.cpp
>>
>>+ case 1:
>>+ pTSD->m_WaveFormatEx.m_usChannels =
>>HXWM_SPEAKER_FRONT_CENTER;
>>+ break;
>>+ case 2:
>>+ pTSD->m_WaveFormatEx.m_usChannels =
>>HXWM_SPEAKER_FRONT_LEFT | HXWM_SPEAKER_FRONT_RIGHT;
>>+ break;
>>
>>It looks like we should be setting pTSD->m_ulChannelMask instead of
>>replacing the value of pTSD-
>>>m_WaveFormatEx.m_usChannels. However, it looks like all the code in
>>>parse_audio.cpp has this same
>>problem. I wondered why this didn't cause a playback problem, but
>>apparently it doesn't because in
>>CWMAudioDecoder::GetNumChannels() we first get the number of channels
>>from m_AudioTSD.m_WaveFormatEx.m_usChannels
>>(which would be wrong) and then we override it with the value from the
>>IHXAudioDecoder, which would be correct. So this is masking this
>obvious bug in parse_audio.cpp.
>>
>>So I think all of the places in parse_audio.cpp which set
>>pTSD->m_WaveFormatEx.m_usChannels to a channel mask should be
>>changed to set the channel mask to pTSD->m_ulChannelMask instead.
>>
>>2) wmadecoder.cpp
>>
>>- Instead of having to QI for IHXPreferences, you should just use
>> the alternate version of ReadPrefUINT8 which takes an IUnknown
>> and does the QI for you.
>>
>>- Let's call the pref name "MaxSupportedWMAChannels" instead of
>"MAXSupportWMAChannels"
>>
>>
>>The rest looks good.
>>
>>Eric
>>
>>=======================================
>>Eric Hyche (ehyche@real.com)
>>Principal Engineer
>>RealNetworks, Inc.
>>
>>
>>>-----Original Message-----
>>>From: datatype-dev-bounces@helixcommunity.org
>>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>>ext-anuj.dhamija@nokia.com
>>>Sent: Tuesday, September 09, 2008 5:07 PM
>>>To: datatype-dev@helixcommunity.org; audio-dev@helixcommunity.org
>>>Cc: nokia-private-dev@helixcommunity.org
>>>Subject: [datatype-dev] Req ID: 106-1630 - Support WMA10 Pro Audio in
>>>Helix
>>>
>>>"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-anuj.dhamija@nokia.com
>>>
>>>Reviewed by:
>>>
>>>Req ID: 106-1630
>>>
>>>Date: 09/09/2008
>>>
>>>Project: Support WMA10 Pro Audio in Helix
>>>
>>>Synopsis: Integrate WMA10 pro decoder inside Helix while maintaining
>>>backward compatible with old
>>>WMA9 decoder
>>>
>>>Overview:
>>>WMA10 pro is a super set of WMA9 decoder which is optimized for ARM
>>>9t/9E and ARM11 processors. It is not backward compatible as extra
>>>parameters are required to configure the decoder and different
>>>payload
>
>>>format is used. Same FourCC code is used to initialize the decoder.
>>>So
>
>>>Helix needs to figure out the available codec at runtime and support
>>>both cases (old codec and new codec) accordingly
>>>
>>>
>>>Fix:
>>>A) wmasymbianswdecoder.cpp
>>>i) Method ConfigDecoder introduced to handle configuration of decoder
>>>based on codec available (WMA9 or WMA10) and media type. Update
>>>config
>>file with availablity status of WMA10 support for next time.
>>>
>>>ii) Method InitWMA9Header and InitWMA10Header take care of prepending
>>>header to frame. InitWMA9Header prepends same header as used by old
>>>decoder. InitWMA10Header prepends header as required by new WMA10 pro
>>decoder.
>>>
>>>B) wmaaudioconfigs.cpp
>>>i) Introduce new methods to set and get format tag. These are used by
>>>ConfigDecoder in wmasymbianswdecoder.cpp when configuring decoder.
>>>
>>>ii) Add new variables to class HXAudioConfiguratorWMA to support
>>>WMA10Pro. Append these variables in config array in ConfigureDecoder
>>call.
>>>
>>>C) wmadecoder.cpp
>>>i) Read Max number of supported channels from configuration file and
>>>if
>>
>>>number of audio channels in Audio stream are more than the config
>>>parameter then reject audio. [Default is 2]
>>>
>>>ii) Reject 24 bit sample clips. [For now only 16-bit clips are
>>>supported]
>>>
>>>D) parse_audio.cpp
>>>i) Introduce new parameters for WMA10 to structure
>>>HXWMATypeSpecificData
>>>ii) Unpack new parameters for WMA10 from payload when parsing Audio
>>>Data
>>>
>>>E) R1_Mobile_4_0_Factory.cfg
>>>i) New config parameter for max supported channels for a WMA clip.
>>>[MAXSupportedWMAChannels]
>>>
>>>Files modified & changes:
>>>\datatype\mdf\audio\arm\wma\platform\symbian\wmaaudioconfigs.cpp
>>>\datatype\mdf\audio\arm\wma\platform\symbian\wmasymbianswdecoder.cpp
>>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmaaudioconfigs.h
>>>\datatype\mdf\audio\arm\wma\pub\platform\symbian\wmasymbianswdecoder.
>>>h \datatype\wm\audio\renderer\wmadecoder.cpp
>>>\datatype\wm\common\pub\parse_audio.h
>>>\datatype\wm\common\parse_audio.cpp
>>>\clientapps\symbiancommon\config\R1_Mobile_4_0_Factory.cfg
>>>
>>>Image Size and Heap Use impact: None
>>>
>>>Module Release testing (STIF, Audio) : Passed
>>>
>>>Test case(s) Added : None
>>>
>>>Memory leak check performed : Passed, No leaks found
>>>
>>>Platforms and Profiles Build Verified:
>>>helix-client-s60-32-mmf-mdf-arm
>>>
>>>Platforms and Profiles Functionality verified: armv5
>>>
>>>Branch: Head, 210CayS
>>>
>>>===========================
>>>DIFF enclosed as text files
>>>===========================
>>>
>>>thnx & regds
>>>AD
>>><>
>>>
>>>
>>>
>>
From alokj at real.com Tue Sep 23 05:48:54 2008
From: alokj at real.com (Alok Jain)
Date: Tue Sep 23 04:04:57 2008
Subject: [datatype-dev] CN: NULL Decoder
References: <003301c91976$a9921bd0$7701a8c0@hp>
<008001c919a9$8c52e4e0$a4f8aea0$@com>
Message-ID: <002601c91d7a$bf207200$7701a8c0@hp>
Thanks Eric
Suggested changes incorporated & checked into the HEAD.
Thanks
Alok Jain
----- Original Message -----
From: "Eric Hyche"
To: "'Alok Jain'" ;
Sent: Thursday, September 18, 2008 9:43 PM
Subject: RE: Resending- Final CR: NULL Decoder
>
> Alok,
>
> Here are my comments:
>
> 1) helix.bif
> a)let's follow the pattern of the other
> targets and give this new target an id attribute
> of "datatype_null_video_codec" and a name attribute
> of "datatype/null/video/codec". Therefore, we'll
> check it into datatype/null/video/codec. This follows
> the same pattern as:
> datatype/rm/video/codec
> and
> datatype/wm/video/codec
>
> b) common_include should be included in the
> rather than the
>
> c) video/include is added to the include path in win32.pcf, but
> is not listed in the for the BIF target.
>
> d) video_vidutil is added to the libraries in win32.pcf but is
> not listed in the in the BIF target.
>
> Rest looks good.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: Alok Jain [mailto:alokj@real.com]
>>Sent: Thursday, September 18, 2008 6:10 AM
>>To: ehyche@real.com; datatype-dev@helixcommunity.org
>>Subject: Resending- Final CR: NULL Decoder
>>
>>
>>Synopsis:
>>
>>Final CR for the null decoder with added implementation for Sequence
>>number and time stamp in the
>>frame (white frame) on windows platform.
>>
>>Overview:
>>Null decoder implements the Helix video decoder API. The null decoder
>>produces one frame showing
>>sequence no. and timestamp for every input encoded frame it receives.
>>
>> Files Modified:
>> None
>>
>> Files Added:
>> /cvsroot/datatype/null/video/decoder/nullcodec.cpp
>> /cvsroot/datatype/null/video/decoder/nullcodec.h
>> /cvsroot/datatype/null/video/decoder/nullcodecapi.cpp
>>
>> /cvsroot/datatype/null/video/decoder/ Umakefil
>> /cvsroot/datatype/null/video/decoder/ win32.pcf
>>
>> Image Size and Heap Use impact (Client -Only):
>> None.
>>
>> Platforms and Profiles Affected:
>> None
>>
>> Distribution Libraries Affected:
>> None.
>>
>> Distribution library impact and planned action:
>> None.
>>
>>
>> Platforms and Profiles Build Verified:
>> Profile: helix-client-all-defines
>>
>> BIF branch: helix.bif
>> Target: splay
>>
>> Branch: HEAD
>>
>>Thanks
>>Alok Jain
>>
>>----- Original Message -----
>>From: "Eric Hyche"
>>To: "'Daniel Yek'" ;
>>Cc: "'Alok Jain'"
>>Sent: Thursday, September 11, 2008 8:36 PM
>>Subject: RE: [datatype-dev] CR: NULL Decoder
>>
>>
>>> Daniel/Alok:
>>>
>>> I was thinking exactly along the same lines. It would be useful to have
>>> it actually write the frame number into the frame, or perhaps the
>>> millisecond timestamp of the frame. I remember debugging an issue
>>> a couple of years ago where the the RV renderer was not issuing
>>> the proper commands to the RV decoder to tell it that it had received
>>> its last frame, and that it should flush all of its frames. In order
>>> to verify we had fixed this, we had to construct a special clip that
>>> wrote
>>> frame
>>> numbers in bottom right. Before the bug was fixed, you never saw the
>>> final
>>> frame of the sequence. After the bug was fixed, you could see that the
>>> last frame in the clip was bltted.
>>>
>>> Having a null decoder would have really helped with diagnosing that
>>> problem.
>>>
>>> Also, I see the null decoder as useful when analyzing CPU usage. We
>>> already
>>> have a null renderer, but now with a null decoder, we can measure
>>> performance
>>> of various video renderers where they are performing everything but
>>> decoding.
>>>
>>> Alok: can you investigate to see how much dev time it would be to
>>> write some of the parameters of the input HXCODEC_DATA into the output
>>> frame. I describe below what I have in mind. If your investigation
>>> tells you that you could do this in 2 days of work or less, then please
>>> go ahead and do it. If it's more than 2 days, then please just document
>>> the results of your investigation, and send them to me. In that case,
>>> we'll just put that on the to-do list.
>>>
>>> The input frame the null decoder receives is in a HXCODEC_DATA struct.
>>> Two of the parameters of that struct are a ULONG32 timestamp and
>>> a UINT16 sequenceNum. Both of those would be really useful to see
>>> visually on the screen. The null decoder produces an an I420 frame
>>> on output and I420 frames are laid out in memory like this:
>>>
>>> --------------------------------
>>> | |
>>> | |
>>> | |
>>> | Y |
>>> | |
>>> | |
>>> | |
>>> | |
>>> --------------------------------
>>> | |
>>> | U |
>>> | |
>>> | |
>>> ----------------
>>> | |
>>> | V |
>>> | |
>>> | |
>>> ----------------
>>>
>>> The width and height of the Y are the same as the width
>>> and height of the frame. However, the U and V planes are
>>> subsampled and are half the width and half the height of
>>> the Y plane.
>>>
>>> The Y plane is the luminance plane. So you can essentially
>>> think of it as a grayscale version of the video frame.
>>>
>>> So what I was thinking is that after you generate the dummy
>>> output video frame, you would construct a string that
>>> contains both the value of sequenceNum and timestamp,
>>> using a fixed number of characters for both. So perhaps
>>> your sprintf() command might look something like:
>>>
>>> sprintf(szBuffer, "%5u %10lu", sequenceNum, timestamp);
>>>
>>> Then you could take that string and draw it into
>>> the luminance plane buffer. After you drew it, it might
>>> look something like this:
>>>
>>> --------------------------------
>>> | |
>>> | |
>>> | |
>>> | Y |
>>> | |
>>> | |
>>> | 274 10450 |
>>> | |
>>> --------------------------------
>>> | |
>>> | U |
>>> | |
>>> | |
>>> ----------------
>>> | |
>>> | V |
>>> | |
>>> | |
>>> ----------------
>>>
>>> if the sequence number was 274 and the timestamp
>>> on the frame was 10450.
>>>
>>> Exactly how to do that drawing is the part that
>>> needs investigation. On Windows, I think it's pretty
>>> clear how to do it. You make a DIB out of the Y buffer
>>> and then use that DIB as the offscreen buffer for
>>> your GDI drawing commands like DrawText().
>>>
>>> I'm less familiar with how to do it on Linux.
>>> Daniel: do you have any suggestions off the top
>>> of your head on the easiest way to do it for Linux?
>>>
>>> Another approach would simply be to come up with simple
>>> bitmaps for the characters 0-9 and then copy those
>>> characters into the buffer. This would have the advantage
>>> of being cross-platform, but it probably wouldn't look
>>> as nice as using the platform-specific drawing APIs.
>>>
>>> Anyway, that's my idea. Let me know what you find out.
>>>
>>> Eric
>>>
>>> =======================================
>>> Eric Hyche (ehyche@real.com)
>>> Principal Engineer
>>> RealNetworks, Inc.
>>>
>>>
>>>>-----Original Message-----
>>>>From: datatype-dev-bounces@helixcommunity.org
>>>>[mailto:datatype-dev-bounces@helixcommunity.org] On
>>>>Behalf Of Daniel Yek
>>>>Sent: Thursday, September 11, 2008 10:23 AM
>>>>To: datatype-dev@helixcommunity.org
>>>>Cc: Alok Jain
>>>>Subject: Re: [datatype-dev] CR: NULL Decoder
>>>>
>>>>Null decoder sounds useful.
>>>>
>>>>I think it would be even more useful if the null decoder is extended to
>>>>output a repeated sequence of moving patterns, starting from a
>>>>recognizable key frame and looping the rest of the moving non-key frames
>>>>and then back to the key frame and repeat.
>>>>
>>>>The sequence can be a smaller rectangular area extended to the larger
>>>>(black or with border lines) output dimensions.
>>>>
>>>>Maybe this feature should be a variant of the null decoder instead.
>>>>
>>>>Thanks.
>>>>
>>>>--
>>>>Daniel Yek.
>>>>
>>>>
>>>>
>>>>Alok Jain wrote:
>>>>>
>>>>> Synopsis:
>>>>>
>>>>> Null decoder implementaion.
>>>>>
>>>>>
>>>>>
>>>>> Overview:
>>>>> Null decoder implements the Helix video decoder API. The null decoder
>>>>> produces one black frame for every input encoded frame it receives.
>>>>>
>>>>>
>>>>> Files Modified:
>>>>> None
>>>>>
>>>>>
>>>>> Files Added:
>>>>> /cvsroot/datatype/null/codec/nullcodec.cpp
>>>>>
>>>>> /cvsroot/datatype/null/codec/nullcodec.h
>>>>>
>>>>> /cvsroot/datatype/null/codec/nullcodecapi.cpp
>>>>>
>>>>> /cvsroot/datatype/null/codec/ Umakefil
>>>>> /cvsroot/datatype/null/codec/ win32.pcf
>>>>>
>>>>>
>>>>>
>>>>> Image Size and Heap Use impact (Client -Only):
>>>>> None.
>>>>>
>>>>> Platforms and Profiles Affected:
>>>>> None
>>>>>
>>>>> Distribution Libraries Affected:
>>>>> None.
>>>>>
>>>>> Distribution library impact and planned action:
>>>>> None.
>>>>>
>>>>>
>>>>> Platforms and Profiles Build Verified:
>>>>> Profile: helix-client-all-defines
>>>>>
>>>>> BIF branch: helix.bif
>>>>> Target: splay
>>>>>
>>>>> Branch: HEAD
>>>>>
>>>>>
>>>>> Thanks & Regards
>>>>>
>>>>> Alok Jain
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> 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 alokj at real.com Tue Sep 23 06:37:18 2008
From: alokj at real.com (Alok Jain)
Date: Tue Sep 23 04:53:25 2008
Subject: [datatype-dev] CN: Changes in MP4 Renderer to support FLV format
References: <00dc01c91345$9933a6a0$7701a8c0@hp>
<00b201c91426$f0575da0$d10618e0$@com>
<005b01c914c3$62488d70$7701a8c0@hp>
<00a601c914f1$71548c50$53fda4f0$@com>
Message-ID: <00cf01c91d81$81ea4350$7701a8c0@hp>
Thanks Eric,
This has been checked into HEAD.
Thanks
Alok Jain
----- Original Message -----
From: "Eric Hyche"
To: "'Alok Jain'" ;
Sent: Friday, September 12, 2008 9:35 PM
Subject: RE: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
format
> This looks good.
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: Alok Jain [mailto:alokj@real.com]
>>Sent: Friday, September 12, 2008 6:36 AM
>>To: ehyche@real.com; datatype-dev@helixcommunity.org
>>Subject: Re: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
>>format
>>
>>Thanks Eric,
>> I modified the all file as you were mentioned.
>>
>>Thanks
>>Alok
>>
>>
>>----- Original Message -----
>>From: "Eric Hyche"
>>To: "'Alok Jain'" ;
>>Sent: Thursday, September 11, 2008 9:26 PM
>>Subject: RE: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
>>format
>>
>>
>>> Alok,
>>>
>>> Here are my comments:
>>>
>>> 1) License headers are incorrect on the two new files. The
>>> correct license header can be found here:
>>>
>>> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders#head
>>> -793d4290d3c24c0fa63825229350b0e861b6b0fe
>>>
>>> and for future reference, the page I use to find the
>>> license headers is here:
>>>
>>> http://asg-plone.dev.prognet.com/helix/moin.cgi/SourceFileHeaders
>>>
>>> 2) flvpyld.h - looks good
>>>
>>> 3) flvpyld.cpp
>>> a) In destructor, use HX_RELEASE(m_pAllocator), since it does the same
>>> as the code that's currently there.
>>> b) In SetAllocator(), we should do a HX_RELEASE(m_pAllocator) before
>>> we assign a new value to m_pAllocator.
>>> c) In GetPacketTime, we should check for non-NULL pPacket
>>> d) In CreateHXCodecPacket, I don't actually see anywhere where
>>> the actual data in the pBuffer (the IHXPacket's IHXBuffer) ever
>>> gets copied
>>> into pHXCodecData->data. The memory is allocated, but nothing
>>> ever gets copied into it.
>>>
>>> 4) In datatype/mp4/payload/Umakefil,
>>> a) We should not manually set
>>> project.AddDefines("HELIX_FEATURE_VIDEO_CODEC_VP6").
>>> This should be set in the profile. So you may need to include
>>> a diff for adding this to the appropriate .pfi file in
>>> ribosome/build/umakepf.
>>>
>>> 5) datatype/mp4/video/renderer/libumakefil
>>> a) same comment as 4(a) above
>>>
>>> Rest looks good.
>>>
>>> Eric
>>>
>>> =======================================
>>> Eric Hyche (ehyche@real.com)
>>> Principal Engineer
>>> RealNetworks, Inc.
>>>
>>>
>>>>-----Original Message-----
>>>>From: datatype-dev-bounces@helixcommunity.org
>>>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Alok
>>>>Jain
>>>>Sent: Wednesday, September 10, 2008 9:03 AM
>>>>To: datatype-dev@helixcommunity.org
>>>>Subject: [datatype-dev] CR: Changes in MP4 Renderer to support FLV
>>>>format
>>>>
>>>>
>>>>Synopsis:
>>>>
>>>>MP4 video renderer modifications to support flv format.
>>>>
>>>>Overview:
>>>>Changes done to support flv format. mp4 video renderer will look at
>>>>the CodecID = HX_FLV_CODEC_ID in the stream header and attempt to
>>>>load the vp67 codec.
>>>>
>>>>
>>>>Files Modified:
>>>>/cvsroot/datatype/mp4/payload/Umakefil
>>>>
>>>>/cvsroot/datatype/mp4/video/renderer/libumakefil
>>>>
>>>>/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>
>>>>/cvsroot/datatype/mp4/video/renderer/mp4video.cpp
>>>>
>>>>Files Added:
>>>>/cvsroot/datatype/mp4/payload/flvpyld.cpp
>>>>
>>>>/cvsroot/datatype/mp4/payload/pub/ flvpyld.h
>>>>
>>>>
>>>>
>>>>Image Size and Heap Use impact (Client -Only):
>>>>None.
>>>>
>>>>Platforms and Profiles Affected:
>>>>None
>>>>
>>>>Distribution Libraries Affected:
>>>>None.
>>>>
>>>>Distribution library impact and planned action:
>>>>None.
>>>>
>>>>Platforms and Profiles Build Verified:
>>>> Profile: helix-client-all-defines
>>>>
>>>> BIF branch: helix.bif
>>>> Target: splay
>>>>
>>>>Branch: HEAD
>>>>
>>>>
>>>>Thanks & Regards
>>>>
>>>>Alok Jain
>>>
>
From ext-ashwinkumar.1.nadagoudar at nokia.com Tue Sep 23 13:03:27 2008
From: ext-ashwinkumar.1.nadagoudar at nokia.com (ext-ashwinkumar.1.nadagoudar@nokia.com)
Date: Tue Sep 23 11:19:41 2008
Subject: [datatype-dev] CR:403-961 Configurability in Helix of the
deblocking and deringing filter
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Diff.zip
Type: application/x-zip-compressed
Size: 3951 bytes
Desc: Diff.zip
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080923/8487af2f/Diff-0001.bin
From stanb at real.com Wed Sep 24 10:54:35 2008
From: stanb at real.com (Stanislav Bobrovskiy)
Date: Wed Sep 24 09:10:22 2008
Subject: [datatype-dev] CR: Fix of inserting opaque data in mp4/m4v
files
Message-ID: <6.2.1.2.2.20080924104044.0405a008@mailone.real.com>
Modified by: stanb@real.com
Date: 09:24:08
Project: Helix DNA Client
Synopsis: This fixes a bug of loosing data that follows avcC block when
stripping Producer created MULTI stream header out of passed opaque data.
Overview: H264 encoder has to insert avcC block into mp4 file header. It is
currently done by passing OpaqueData to video stream header.
In some cases video encoder might want to insert additional data to mp4
file header - in my instance uuid block that makes iTunes transfer
resulting files to iPod withjout conversion. This fix makes sure data
following avcC block is not stripped out.
Files Added: none
Files Modified:
/datatype/mp4/filewriter/avcsh.cpp)
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
Platforms and Profiles Build Verified:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
target(s): playinst
Platforms and Profiles Functionality verified:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
target(s): playinst
Branch: hxclient_3_1_0_atlas, HEAD
Copyright assignment: I am a RealNetworks employee.
Files Attached: avcsh.diff
-------------- next part --------------
Index: datatype/mp4/filewriter/avcsh.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/avcsh.cpp,v
retrieving revision 1.2
diff -u -1 -0 -r1.2 avcsh.cpp
--- datatype/mp4/filewriter/avcsh.cpp 20 Jun 2007 13:42:10 -0000 1.2
+++ datatype/mp4/filewriter/avcsh.cpp 24 Sep 2008 17:32:07 -0000
@@ -169,26 +169,26 @@
{
// MP4 file format put MP4 stsd avcC box in OpaqueData.
// producer though always attaches a MultiStreamHeader to the front of avcC box
// created by h264enc filter plugin. need to strip the MLTI header
UINT32 ulID = DwToHost(*(UINT32*)(pBuffer));
if( RM_MULTIHEADER_OBJECT == ulID )
{
MultiStreamHeader multiStreamHeader;
+ UCHAR* pOpaqueData = pBuffer;
pBuffer = multiStreamHeader.unpack( pBuffer, ulLen );
//bypass the size of header field, we should be at the avcC box now
pBuffer += sizeof(UINT32);
-
- ulLen = DwToHost(*(UINT32*)(pBuffer));
+ ulLen -= (pBuffer - pOpaqueData);
}
}
IHXBuffer* pDecoderInfoBuffer = NULL;
if (SUCCEEDED(retVal))
{
retVal = m_pCommonClassFactory->CreateInstance( IID_IHXBuffer, (void**) &pDecoderInfoBuffer );
}
if (SUCCEEDED(retVal))
From ext-ashwinkumar.1.nadagoudar at nokia.com Wed Sep 24 13:56:03 2008
From: ext-ashwinkumar.1.nadagoudar at nokia.com (ext-ashwinkumar.1.nadagoudar@nokia.com)
Date: Wed Sep 24 12:11:54 2008
Subject: FW: [datatype-dev] CR:403-961 Configurability in Helix of
thedeblocking and deringing filter
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Diff.zip
Type: application/x-zip-compressed
Size: 3951 bytes
Desc: Diff.zip
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080924/a576a595/Diff.bin
-------------- next part --------------
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From sarah200612 at gmail.com Wed Sep 24 22:23:59 2008
From: sarah200612 at gmail.com (Sarah Wei)
Date: Wed Sep 24 20:39:36 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
Message-ID: <1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
Hi, Real and Community,
Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I found
that its depactizer seems to provide some support. For an example, following
lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
=======================
else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_DIVX;
retVal = SetAssemblerHXAVIHeader(pHeader);
}
=======================
I am especially interested in local playback. As to the streaming, does
Helix server support Divx?
If Divx is not supported, is it in the plan? What is the time frame?
I plan to add Divx support into Helix codes. Should I write a new fileformat
and depactizer? Or is it easy to modify the MP4 fileformat and its
depactizer?
Thanks for your time.
--slwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/fc8c50fd/attachment-0001.html
From hayoung.choi at ap.real.com Thu Sep 25 12:12:46 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Thu Sep 25 10:28:51 2008
Subject: [datatype-dev] CR: Thumbnail generation improvement updates
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: pngwrtr.cpp.diff
Type: application/octet-stream
Size: 19129 bytes
Desc: pngwrtr.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/pngwrtr.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pngwrtr.h.diff
Type: application/octet-stream
Size: 942 bytes
Desc: pngwrtr.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/pngwrtr.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Umakefil.diff
Type: application/octet-stream
Size: 1359 bytes
Desc: Umakefil.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/Umakefil-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp.diff
Type: application/octet-stream
Size: 3810 bytes
Desc: main.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/main.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdecoder.cpp.diff
Type: application/octet-stream
Size: 4630 bytes
Desc: vdecoder.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/vdecoder.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdecoder.h.diff
Type: application/octet-stream
Size: 848 bytes
Desc: vdecoder.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/vdecoder.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.cpp.diff
Type: application/octet-stream
Size: 2037 bytes
Desc: ffdriver.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/ffdriver.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.h.diff
Type: application/octet-stream
Size: 1452 bytes
Desc: ffdriver.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/ad526eed/ffdriver.h-0001.obj
From jrathore at real.com Thu Sep 25 14:28:44 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Thu Sep 25 12:44:16 2008
Subject: [datatype-dev] Adding divx extension in AVI file format
Message-ID: <006201c91f55$b17f4900$f58016ac@corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: aviffpln.diff
Type: application/octet-stream
Size: 884 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/2d8d2e4f/aviffpln.obj
From jrathore at real.com Thu Sep 25 15:17:54 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Thu Sep 25 13:33:20 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
Message-ID: <006e01c91f5c$8f665370$f58016ac@corp.real.com>
Hi Sarah,
Helix supports DivX in avi fileformat.
Thanks,
Jyotsana
_____
From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Sarah Wei
Sent: Wednesday, September 24, 2008 10:24 PM
To: datatype-dev@helixcommunity.org; sarah2006@gmail.com
Subject: [datatype-dev] Re: Divx support in Helix
Hi, Real and Community,
Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I found
that its depactizer seems to provide some support. For an example, following
lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
=======================
else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_DIVX;
retVal = SetAssemblerHXAVIHeader(pHeader);
}
=======================
I am especially interested in local playback. As to the streaming, does
Helix server support Divx?
If Divx is not supported, is it in the plan? What is the time frame?
I plan to add Divx support into Helix codes. Should I write a new fileformat
and depactizer? Or is it easy to modify the MP4 fileformat and its
depactizer?
Thanks for your time.
--slwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/991f0211/attachment.html
From sarah200612 at gmail.com Thu Sep 25 16:21:16 2008
From: sarah200612 at gmail.com (Sarah Wei)
Date: Thu Sep 25 14:36:46 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <006e01c91f5c$8f665370$f58016ac@corp.real.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
Message-ID: <1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
Hi, Jyotsana,
Thank you very much. I will check the version out for a look. How about DRM?
Does DRM encrypted content supported by Helix? i.e. Is Divx DRM decrypter
part of Helix?
br,
--slwei
On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore wrote:
> Hi Sarah,
>
>
>
> Helix supports DivX in avi fileformat.
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* datatype-dev-bounces@helixcommunity.org [mailto:
> datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Sarah Wei
> *Sent:* Wednesday, September 24, 2008 10:24 PM
> *To:* datatype-dev@helixcommunity.org; sarah2006@gmail.com
> *Subject:* [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Real and Community,
>
> Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I
> found that its depactizer seems to provide some support. For an example,
> following lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
> =======================
> else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
> {
> m_PayloadID = PYID_X_HX_DIVX;
> retVal = SetAssemblerHXAVIHeader(pHeader);
> }
> =======================
>
> I am especially interested in local playback. As to the streaming, does
> Helix server support Divx?
> If Divx is not supported, is it in the plan? What is the time frame?
>
> I plan to add Divx support into Helix codes. Should I write a new
> fileformat and depactizer? Or is it easy to modify the MP4 fileformat and
> its depactizer?
>
> Thanks for your time.
>
> --slwei
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/04430bac/attachment-0001.html
From jrathore at real.com Thu Sep 25 16:31:28 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Thu Sep 25 14:46:53 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
<1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
Message-ID: <008e01c91f66$d5c23690$f58016ac@corp.real.com>
Hi Sarah,
No, Divx DRM decrypter is not a part of helix. We haven't seen a market need
for DivX DRM :-)
Thanks,
Jyotsana
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 4:21 PM
To: Jyotsana Rathore
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
Thank you very much. I will check the version out for a look. How about DRM?
Does DRM encrypted content supported by Helix? i.e. Is Divx DRM decrypter
part of Helix?
br,
--slwei
On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore wrote:
Hi Sarah,
Helix supports DivX in avi fileformat.
Thanks,
Jyotsana
_____
From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Sarah Wei
Sent: Wednesday, September 24, 2008 10:24 PM
To: datatype-dev@helixcommunity.org; sarah2006@gmail.com
Subject: [datatype-dev] Re: Divx support in Helix
Hi, Real and Community,
Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I found
that its depactizer seems to provide some support. For an example, following
lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
=======================
else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_DIVX;
retVal = SetAssemblerHXAVIHeader(pHeader);
}
=======================
I am especially interested in local playback. As to the streaming, does
Helix server support Divx?
If Divx is not supported, is it in the plan? What is the time frame?
I plan to add Divx support into Helix codes. Should I write a new fileformat
and depactizer? Or is it easy to modify the MP4 fileformat and its
depactizer?
Thanks for your time.
--slwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/5c1987d6/attachment.html
From sarah200612 at gmail.com Thu Sep 25 16:43:20 2008
From: sarah200612 at gmail.com (Sarah Wei)
Date: Thu Sep 25 14:58:46 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <008e01c91f66$d5c23690$f58016ac@corp.real.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
<1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
<008e01c91f66$d5c23690$f58016ac@corp.real.com>
Message-ID: <1aed96a10809251643x2dfc2733rde2471b88f8a7e14@mail.gmail.com>
Hi, Jyotsana,
Thank you very much for your quick answer. One last question, I try to
develop code on Symbian mobile platform. I believe DivX filefomat is
currently in window platform as stated in your CR (win32-i386-vc7). Does it
also in Symbian (branch Cayes 210, 221)? In another words, should I do any
symbian specific code changes to get DivX support?
br,
--slwei
On Fri, Sep 26, 2008 at 8:31 AM, Jyotsana Rathore wrote:
> Hi Sarah,
>
>
>
> No, Divx DRM decrypter is not a part of helix. We haven't seen a market
> need for DivX DRM J
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* Sarah Wei [mailto:sarah200612@gmail.com]
> *Sent:* Thursday, September 25, 2008 4:21 PM
> *To:* Jyotsana Rathore
> *Cc:* datatype-dev@helixcommunity.org
> *Subject:* Re: [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Jyotsana,
>
>
>
> Thank you very much. I will check the version out for a look. How about
> DRM? Does DRM encrypted content supported by Helix? i.e. Is Divx DRM
> decrypter part of Helix?
>
>
>
> br,
>
>
>
> --slwei
>
>
> On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore
> wrote:
>
> Hi Sarah,
>
>
>
> Helix supports DivX in avi fileformat.
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* datatype-dev-bounces@helixcommunity.org [mailto:
> datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Sarah Wei
> *Sent:* Wednesday, September 24, 2008 10:24 PM
> *To:* datatype-dev@helixcommunity.org; sarah2006@gmail.com
> *Subject:* [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Real and Community,
>
> Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I
> found that its depactizer seems to provide some support. For an example,
> following lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
> =======================
> else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
> {
> m_PayloadID = PYID_X_HX_DIVX;
> retVal = SetAssemblerHXAVIHeader(pHeader);
> }
> =======================
>
> I am especially interested in local playback. As to the streaming, does
> Helix server support Divx?
> If Divx is not supported, is it in the plan? What is the time frame?
>
> I plan to add Divx support into Helix codes. Should I write a new
> fileformat and depactizer? Or is it easy to modify the MP4 fileformat and
> its depactizer?
>
> Thanks for your time.
>
> --slwei
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/29230c00/attachment-0001.html
From jrathore at real.com Thu Sep 25 17:04:43 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Thu Sep 25 15:20:08 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <1aed96a10809251643x2dfc2733rde2471b88f8a7e14@mail.gmail.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
<1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
<008e01c91f66$d5c23690$f58016ac@corp.real.com>
<1aed96a10809251643x2dfc2733rde2471b88f8a7e14@mail.gmail.com>
Message-ID: <009c01c91f6b$7ae8d210$f58016ac@corp.real.com>
Hi,
My CR is just to add the extension. The support for DixX was added earlier
and should also exist for Symbian in Cays 210 and HEAD. If approved, I will
check in my changes to Cays 210 also.
After a quick look at viewcvs, I noticed datatype/avi does not exist in Cays
221. So, these files are not used in 221.
Thanks,
Jyotsana
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 4:43 PM
To: Jyotsana Rathore; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
Thank you very much for your quick answer. One last question, I try to
develop code on Symbian mobile platform. I believe DivX filefomat is
currently in window platform as stated in your CR (win32-i386-vc7). Does it
also in Symbian (branch Cayes 210, 221)? In another words, should I do any
symbian specific code changes to get DivX support?
br,
--slwei
On Fri, Sep 26, 2008 at 8:31 AM, Jyotsana Rathore wrote:
Hi Sarah,
No, Divx DRM decrypter is not a part of helix. We haven't seen a market need
for DivX DRM :-)
Thanks,
Jyotsana
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 4:21 PM
To: Jyotsana Rathore
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
Thank you very much. I will check the version out for a look. How about DRM?
Does DRM encrypted content supported by Helix? i.e. Is Divx DRM decrypter
part of Helix?
br,
--slwei
On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore wrote:
Hi Sarah,
Helix supports DivX in avi fileformat.
Thanks,
Jyotsana
_____
From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Sarah Wei
Sent: Wednesday, September 24, 2008 10:24 PM
To: datatype-dev@helixcommunity.org; sarah2006@gmail.com
Subject: [datatype-dev] Re: Divx support in Helix
Hi, Real and Community,
Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I found
that its depactizer seems to provide some support. For an example, following
lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
=======================
else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_DIVX;
retVal = SetAssemblerHXAVIHeader(pHeader);
}
=======================
I am especially interested in local playback. As to the streaming, does
Helix server support Divx?
If Divx is not supported, is it in the plan? What is the time frame?
I plan to add Divx support into Helix codes. Should I write a new fileformat
and depactizer? Or is it easy to modify the MP4 fileformat and its
depactizer?
Thanks for your time.
--slwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/215491e0/attachment.html
From sarah200612 at gmail.com Thu Sep 25 17:24:36 2008
From: sarah200612 at gmail.com (Sarah Wei)
Date: Thu Sep 25 15:40:12 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <009c01c91f6b$7ae8d210$f58016ac@corp.real.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
<1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
<008e01c91f66$d5c23690$f58016ac@corp.real.com>
<1aed96a10809251643x2dfc2733rde2471b88f8a7e14@mail.gmail.com>
<009c01c91f6b$7ae8d210$f58016ac@corp.real.com>
Message-ID: <1aed96a10809251724p1823e5b8g4c026bce79929a4b@mail.gmail.com>
Hi, Jyotsana,
I saw avi in Cays210. That is good enough. Compared to MP4, I do not see
"payload" in avi folder. So who is doing AVI's depactizing? Mp4?
Thanks.
--slwei
On 9/26/08, Jyotsana Rathore wrote:
>
> Hi,
>
>
>
> My CR is just to add the extension. The support for DixX was added earlier
> and should also exist for Symbian in Cays 210 and HEAD. If approved, I will
> check in my changes to Cays 210 also.
>
> After a quick look at viewcvs, I noticed datatype/avi does not exist in
> Cays 221. So, these files are not used in 221.
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* Sarah Wei [mailto:sarah200612@gmail.com]
> *Sent:* Thursday, September 25, 2008 4:43 PM
> *To:* Jyotsana Rathore; datatype-dev@helixcommunity.org
> *Subject:* Re: [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Jyotsana,
>
>
>
> Thank you very much for your quick answer. One last question, I try to
> develop code on Symbian mobile platform. I believe DivX filefomat is
> currently in window platform as stated in your CR (win32-i386-vc7). Does it
> also in Symbian (branch Cayes 210, 221)? In another words, should I do any
> symbian specific code changes to get DivX support?
>
>
>
> br,
>
>
>
> --slwei
>
> On Fri, Sep 26, 2008 at 8:31 AM, Jyotsana Rathore
> wrote:
>
> Hi Sarah,
>
>
>
> No, Divx DRM decrypter is not a part of helix. We haven't seen a market
> need for DivX DRM J
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* Sarah Wei [mailto:sarah200612@gmail.com]
> *Sent:* Thursday, September 25, 2008 4:21 PM
> *To:* Jyotsana Rathore
> *Cc:* datatype-dev@helixcommunity.org
> *Subject:* Re: [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Jyotsana,
>
>
>
> Thank you very much. I will check the version out for a look. How about
> DRM? Does DRM encrypted content supported by Helix? i.e. Is Divx DRM
> decrypter part of Helix?
>
>
>
> br,
>
>
>
> --slwei
>
> On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore
> wrote:
>
> Hi Sarah,
>
>
>
> Helix supports DivX in avi fileformat.
>
>
>
> Thanks,
>
> Jyotsana
>
>
> ------------------------------
>
> *From:* datatype-dev-bounces@helixcommunity.org [mailto:
> datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Sarah Wei
> *Sent:* Wednesday, September 24, 2008 10:24 PM
> *To:* datatype-dev@helixcommunity.org; sarah2006@gmail.com
> *Subject:* [datatype-dev] Re: Divx support in Helix
>
>
>
> Hi, Real and Community,
>
> Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I
> found that its depactizer seems to provide some support. For an example,
> following lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
> =======================
> else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
> {
> m_PayloadID = PYID_X_HX_DIVX;
> retVal = SetAssemblerHXAVIHeader(pHeader);
> }
> =======================
>
> I am especially interested in local playback. As to the streaming, does
> Helix server support Divx?
> If Divx is not supported, is it in the plan? What is the time frame?
>
> I plan to add Divx support into Helix codes. Should I write a new
> fileformat and depactizer? Or is it easy to modify the MP4 fileformat and
> its depactizer?
>
> Thanks for your time.
>
> --slwei
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/757c04c1/attachment-0001.html
From jrathore at real.com Thu Sep 25 17:38:03 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Thu Sep 25 15:53:30 2008
Subject: [datatype-dev] Re: Divx support in Helix
In-Reply-To: <1aed96a10809251724p1823e5b8g4c026bce79929a4b@mail.gmail.com>
References: <1aed96a10809242215m649438b4g96ae58b496387fd9@mail.gmail.com>
<1aed96a10809242223o128549e1l4fc683119385ec6b@mail.gmail.com>
<006e01c91f5c$8f665370$f58016ac@corp.real.com>
<1aed96a10809251621wa16a711tbcaf289d9d42ffad@mail.gmail.com>
<008e01c91f66$d5c23690$f58016ac@corp.real.com>
<1aed96a10809251643x2dfc2733rde2471b88f8a7e14@mail.gmail.com>
<009c01c91f6b$7ae8d210$f58016ac@corp.real.com>
<1aed96a10809251724p1823e5b8g4c026bce79929a4b@mail.gmail.com>
Message-ID: <00b001c91f70$22f54f70$f58016ac@corp.real.com>
Comments inline.
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 5:25 PM
To: Jyotsana Rathore
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
I saw avi in Cays210. That is good enough. Compared to MP4, I do not see
"payload" in avi folder. So who is doing AVI's depactizing? Mp4? Yes. Avi
is just the container.
Thanks.
--slwei
On 9/26/08, Jyotsana Rathore wrote:
Hi,
My CR is just to add the extension. The support for DixX was added earlier
and should also exist for Symbian in Cays 210 and HEAD. If approved, I will
check in my changes to Cays 210 also.
After a quick look at viewcvs, I noticed datatype/avi does not exist in Cays
221. So, these files are not used in 221.
Thanks,
Jyotsana
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 4:43 PM
To: Jyotsana Rathore; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
Thank you very much for your quick answer. One last question, I try to
develop code on Symbian mobile platform. I believe DivX filefomat is
currently in window platform as stated in your CR (win32-i386-vc7). Does it
also in Symbian (branch Cayes 210, 221)? In another words, should I do any
symbian specific code changes to get DivX support?
br,
--slwei
On Fri, Sep 26, 2008 at 8:31 AM, Jyotsana Rathore wrote:
Hi Sarah,
No, Divx DRM decrypter is not a part of helix. We haven't seen a market need
for DivX DRM :-)
Thanks,
Jyotsana
_____
From: Sarah Wei [mailto:sarah200612@gmail.com]
Sent: Thursday, September 25, 2008 4:21 PM
To: Jyotsana Rathore
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] Re: Divx support in Helix
Hi, Jyotsana,
Thank you very much. I will check the version out for a look. How about DRM?
Does DRM encrypted content supported by Helix? i.e. Is Divx DRM decrypter
part of Helix?
br,
--slwei
On Fri, Sep 26, 2008 at 7:17 AM, Jyotsana Rathore wrote:
Hi Sarah,
Helix supports DivX in avi fileformat.
Thanks,
Jyotsana
_____
From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Sarah Wei
Sent: Wednesday, September 24, 2008 10:24 PM
To: datatype-dev@helixcommunity.org; sarah2006@gmail.com
Subject: [datatype-dev] Re: Divx support in Helix
Hi, Real and Community,
Does Helix support Divx format, i.e. fileformat, depactizer and DRM? I found
that its depactizer seems to provide some support. For an example, following
lines are in the file datatype/mp4/payload/mp4vpyld.cpp:
=======================
else if (strcasecmp(pMimeTypeData, MP4V_HX_DIVX_PAYLOAD_MIME_TYPE) == 0)
{
m_PayloadID = PYID_X_HX_DIVX;
retVal = SetAssemblerHXAVIHeader(pHeader);
}
=======================
I am especially interested in local playback. As to the streaming, does
Helix server support Divx?
If Divx is not supported, is it in the plan? What is the time frame?
I plan to add Divx support into Helix codes. Should I write a new fileformat
and depactizer? Or is it easy to modify the MP4 fileformat and its
depactizer?
Thanks for your time.
--slwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080925/59da2357/attachment.html
From stanb at real.com Thu Sep 25 18:01:01 2008
From: stanb at real.com (Stanislav Bobrovskiy)
Date: Thu Sep 25 16:16:38 2008
Subject: [datatype-dev] CR: Adding h.263 support to MP4 file writer
Message-ID: <6.2.1.2.2.20080925173449.043a3008@mailone.real.com>
Modified by: stanb@real.com
Date: 09:25:08
Project: Helix DNA Client
Synopsis: These changes allow to write h263 video data to 3gp files.
Overview:
- Added CH263StreamHandler class (h263sh.cpp, h263sh.h) analogous to one
that handles h264 video (avcsh.cpp, avcsh.h).
- Added 2 needed MP4 atom calsses to mp4atoms.h: CMP4Atom_d263 and
CMP4Atom_s263.
- Added method for building h263 stsd entry to mp4sm.cpp:
CMP4StreamMixer::BuildH263StsdEntry().
Files Added: /datatype/mp4/filewriter/h263sh.cpp,
/datatype/mp4/filewriter/h263sh.h
Files Modified:
/datatype/mp4/filewriter/Umakefil
/datatype/mp4/filewriter/mp4atoms.h
/datatype/mp4/filewriter/mp4sm.cpp
/datatype/mp4/filewriter/mp4sm.h
/datatype/mp4/filewriter/mp4wrtr.cpp
/datatype_rn/mp4/filewriter/Umakefil
Image Size and Heap Use impact (Client-Only): negligible
Platforms and Profiles Affected:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
Platforms and Profiles Build Verified:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
target(s): playinst
Platforms and Profiles Functionality verified:
Platform: win32-i386-vc7
Profile: helix-client-all-defines
target(s): playinst
Branch: hxclient_3_1_0_atlas, HEAD
Copyright assignment: I am a RealNetworks employee.
Files Attached: h263sh.cpp, h263sh.h, datatype_mp4_filewriter.diff,
datatype_rn_mp4_filewriter.diff
-------------- next part --------------
Index: datatype/mp4/filewriter/Umakefil
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/Umakefil,v
retrieving revision 1.5.2.1
diff -u -1 -0 -r1.5.2.1 Umakefil
--- datatype/mp4/filewriter/Umakefil 21 Mar 2008 11:26:53 -0000 1.5.2.1
+++ datatype/mp4/filewriter/Umakefil 26 Sep 2008 00:28:10 -0000
@@ -41,21 +41,22 @@
GetSDKPath("rmacom_lib")
)
project.AddSources(
'mp4arch.cpp',
'dlliids.cpp',
'mp4wrplin.cpp',
'mp4wrtr.cpp',
'ra10sh.cpp',
'm4avsh.cpp',
- 'avcsh.cpp',
+ 'avcsh.cpp',
+ 'h263sh.cpp',
'blist.cpp',
'mp4sm.cpp',
'mp4atomgateway.cpp'
)
project.AddSources('3gpmeta.cpp')
project.AddExportedFunctions('RMACreateInstance')
DLLTarget('mp4wrtr')
Index: datatype/mp4/filewriter/mp4atoms.h
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/mp4atoms.h,v
retrieving revision 1.5.2.1
diff -u -1 -0 -r1.5.2.1 mp4atoms.h
--- datatype/mp4/filewriter/mp4atoms.h 28 Apr 2008 02:07:31 -0000 1.5.2.1
+++ datatype/mp4/filewriter/mp4atoms.h 26 Sep 2008 00:28:10 -0000
@@ -1649,20 +1649,89 @@
// container: stsd
// purpose: mp4v video sample description entry
class CMP4Atom_mp4v : public CMP4Atom_VisualSampleEntry
{
public:
CMP4Atom_mp4v() : CMP4Atom_VisualSampleEntry(MP4_BUILD_ATOMID('m','p','4','v'))
{
}
};
+// atom: d263
+// container: s263
+// purpose: h263 decoder info
+class CMP4Atom_d263 : public CMP4Atom
+{
+public:
+ CMP4Atom_d263() : CMP4Atom(MP4_BUILD_ATOMID('d','2','6','3'))
+ {
+ m_ulDecoderInfoSize = 0;
+ m_pDecoderInfo = NULL;
+ }
+
+ ~CMP4Atom_d263()
+ {
+ HX_VECTOR_DELETE(m_pDecoderInfo);
+ }
+
+ STDMETHOD_(UINT32, GetCurrentSize ) (THIS_ BOOL bIncludeChildren = FALSE)
+ {
+ return 8 + m_ulDecoderInfoSize;
+ }
+
+ STDMETHOD( WriteToBuffer ) (THIS_ UCHAR*& pBuffer,
+ BOOL bIncludeChildren=FALSE)
+ {
+ HX_RESULT retVal = HXR_OK;
+
+ if( pBuffer )
+ {
+ CMP4Atom::WriteToBufferAndInc( pBuffer, GetCurrentSize() );
+ CMP4Atom::WriteToBufferAndInc( pBuffer, m_ulAtomID );
+
+ CMP4Atom::WriteToBufferAndInc( pBuffer, m_pDecoderInfo, m_ulDecoderInfoSize);
+
+ if( bIncludeChildren )
+ {
+ ChildrenWriteToBuffer( pBuffer );
+ }
+ }
+ return retVal;
+ }
+
+ void SetDecoderInfo(UINT8* pData, int size)
+ {
+ HX_VECTOR_DELETE(m_pDecoderInfo);
+ m_pDecoderInfo = new UINT8[size];
+ memcpy(m_pDecoderInfo, pData, size);
+ m_ulDecoderInfoSize = size;
+ }
+
+private:
+
+ UINT32 m_ulDecoderInfoSize;
+ UINT8* m_pDecoderInfo;
+};
+
+
+// atom: s263
+// container: stsd
+// purpose: h263 video sample description entry
+class CMP4Atom_s263 : public CMP4Atom_VisualSampleEntry
+{
+public:
+ CMP4Atom_s263() : CMP4Atom_VisualSampleEntry(MP4_BUILD_ATOMID('s','2','6','3'))
+ {
+ }
+};
+
+
// atom: AudioSampleEntry base box
// container: stsd
// purpose: base box for AudioSampleEntry
class CMP4Atom_AudioSampleEntry : public CMP4Atom_SampleEntry
{
public:
CMP4Atom_AudioSampleEntry( UINT32 ulAtomID ) : CMP4Atom_SampleEntry( ulAtomID )
{
memset( m_reserved2, 0, sizeof(m_reserved2) );
m_reserved3 = 2;
Index: datatype/mp4/filewriter/mp4sm.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/mp4sm.cpp,v
retrieving revision 1.3.2.3
diff -u -1 -0 -r1.3.2.3 mp4sm.cpp
--- datatype/mp4/filewriter/mp4sm.cpp 6 May 2008 10:08:13 -0000 1.3.2.3
+++ datatype/mp4/filewriter/mp4sm.cpp 26 Sep 2008 00:28:10 -0000
@@ -2208,20 +2208,23 @@
{
case MP4_BUILD_ATOMID('m', 'p', '4', 'a'):
return BuildMP4AStsdEntry(pStsd, usStreamNum);
break;
case MP4_BUILD_ATOMID('m', 'p', '4', 'v'):
return BuildMP4VStsdEntry(pStsd, usStreamNum);
break;
case MP4_BUILD_ATOMID('a', 'v', 'c', '1'):
return BuildAVC1StsdEntry(pStsd, usStreamNum);
break;
+ case MP4_BUILD_ATOMID('h', '2', '6', '3'):
+ return BuildH263StsdEntry(pStsd, usStreamNum);
+ break;
default:
return HXR_INVALID_PARAMETER;
break;
}
}
HX_RESULT CMP4StreamMixer::BuildMP4AStsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum )
{
IHXValues* pStreamHeader = m_pStreamInfo[usStreamNum].m_pStreamHeader;
HX_RESULT retVal = HXR_OUTOFMEMORY;
@@ -2385,20 +2388,61 @@
pAVC1->SetAVCCAtom(pBuf, len);
pStsd->AddChild( pAVC1 );
}
HX_RELEASE( pDecoderInfo );
}
return retVal;
}
+HX_RESULT CMP4StreamMixer::BuildH263StsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum )
+{
+ IHXValues* pStreamHeader = m_pStreamInfo[usStreamNum].m_pStreamHeader;
+ HX_RESULT retVal = HXR_OUTOFMEMORY;
+
+ IHXBuffer* pDecoderInfo = NULL;
+ retVal = pStreamHeader->GetPropertyBuffer("DecoderInfo", pDecoderInfo);
+
+ if( SUCCEEDED( retVal ) )
+ {
+ UCHAR* pBuf = pDecoderInfo->GetBuffer();
+ UINT32 len = pDecoderInfo->GetSize();
+
+ CMP4Atom_s263* pS263 = new CMP4Atom_s263();
+ if( pS263 )
+ {
+ retVal = HXR_OK;
+
+ UINT32 ulWidth = 0, ulHeight = 0;
+ m_pStreamInfo[usStreamNum].m_pStreamHeader->GetPropertyULONG32("Width", ulWidth);
+ m_pStreamInfo[usStreamNum].m_pStreamHeader->GetPropertyULONG32("Height", ulHeight);
+
+ pS263->SetWidth((UINT16) ulWidth);
+ pS263->SetHeight((UINT16) ulHeight);
+
+ CMP4Atom_d263* pD263 = new CMP4Atom_d263();
+ if( pD263 )
+ {
+ pD263->SetDecoderInfo( pBuf, len );
+ pS263->AddChild( pD263 );
+ }
+
+ pStsd->AddChild( pS263 );
+ }
+
+ HX_RELEASE( pDecoderInfo );
+ }
+
+ return retVal;
+}
+
HX_RESULT CMP4StreamMixer::UpdateTrackDuration( UINT16 usStreamNo, UINT32 ulDuration )
{
if (m_pStreamInfo[usStreamNo].m_pTkhd)
{
m_pStreamInfo[usStreamNo].m_pTkhd->SetDuration(ulDuration);
}
if (m_pStreamInfo[usStreamNo].m_pMdhd)
{
Index: datatype/mp4/filewriter/mp4sm.h
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/mp4sm.h,v
retrieving revision 1.2.2.3
diff -u -1 -0 -r1.2.2.3 mp4sm.h
--- datatype/mp4/filewriter/mp4sm.h 6 May 2008 10:08:13 -0000 1.2.2.3
+++ datatype/mp4/filewriter/mp4sm.h 26 Sep 2008 00:28:10 -0000
@@ -95,20 +95,21 @@
// Build the trak subtree
HX_RESULT BuildTrack( UINT16 usStreamNum, CMP4Atom* pTrak );
// Build out an stsd entry for a specific stream
HX_RESULT BuildStsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum );
HX_RESULT BuildMP4AStsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum );
HX_RESULT BuildMP4VStsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum );
HX_RESULT BuildAVC1StsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum );
+ HX_RESULT BuildH263StsdEntry( CMP4Atom_stsd* pStsd, UINT16 usStreamNum );
// 3GP Utilities
void Meta3GP_SetLanguageEncoding(C3GPAtom_LangBase* pAtom, const char* propertySpec = 0);
BOOL Meta3GP_NewAtomGuard(HX_RESULT& retVal, CMP4VersionedAtom* pAtom);
void Meta3GP_AddAtom_StringBase(HX_RESULT& retVal, CMP4Atom* pUdta, C3GPAtom_StringBase* pAtom, const char* pPropName);
void Meta3GP_ExtractUINT32(const EncodedString& s, UINT32& out);
void Meta3GP_ExtractUINT16(const EncodedString& s, UINT16& out);
BOOL Meta3GP_ExtractFixedPoint(const EncodedString& s, INT32& outWhole, UINT32& outFrac, UINT32& outFixed);
// Fix up the duration if it differs from the reported one
Index: datatype/mp4/filewriter/mp4wrtr.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/filewriter/mp4wrtr.cpp,v
retrieving revision 1.7.2.1
diff -u -1 -0 -r1.7.2.1 mp4wrtr.cpp
--- datatype/mp4/filewriter/mp4wrtr.cpp 21 Mar 2008 11:26:53 -0000 1.7.2.1
+++ datatype/mp4/filewriter/mp4wrtr.cpp 26 Sep 2008 00:28:10 -0000
@@ -66,20 +66,21 @@
#include "hxiids.h"
#include "mp4arch.h"
// XXX For now, include the headers for our plugins
//handlers
#include "ra10sh.h"
#include "m4avsh.h"
#include "avcsh.h"
+#include "h263sh.h"
//stream mixer
#include "mp4sm.h"
#include "mp4atoms.h"
/****************************************************************************
* Globals
*/
INT32 g_nRefCount_mp4wr = 0;
@@ -691,20 +692,34 @@
retVal = HXR_OUTOFMEMORY;
pTempHandler = new CAVCStreamHandler( m_pContext, m_pStreamMixer );
if( pTempHandler )
{
pTempHandler->AddRef();
retVal = TestForMimeSupport( pTempHandler, pStreamMimeType );
}
}
+ //h.263 stream handler
+ if( FAILED( retVal ) )
+ {
+ HX_RELEASE( pTempHandler );
+ retVal = HXR_OUTOFMEMORY;
+ pTempHandler = new CH263StreamHandler( m_pContext, m_pStreamMixer );
+
+ if( pTempHandler )
+ {
+ pTempHandler->AddRef();
+ retVal = TestForMimeSupport( pTempHandler, pStreamMimeType );
+ }
+ }
+
//default NULL stream handler, always true
if ( FAILED( retVal ) )
{
HX_RELEASE( pTempHandler );
retVal = HXR_OUTOFMEMORY;
pTempHandler = new CNULStreamHandler( m_pContext, m_pStreamMixer );
if( pTempHandler )
{
pTempHandler->AddRef();
-------------- next part --------------
Index: datatype_rn/mp4/filewriter/Umakefil
===================================================================
RCS file: /home/helixprvt/datatype_rn/mp4/filewriter/Umakefil,v
retrieving revision 1.4.2.1
diff -u -1 -0 -r1.4.2.1 Umakefil
--- datatype_rn/mp4/filewriter/Umakefil 21 Mar 2008 11:28:07 -0000 1.4.2.1
+++ datatype_rn/mp4/filewriter/Umakefil 25 Sep 2008 22:36:37 -0000
@@ -83,20 +83,21 @@
)
project.AddSources(
'../../../datatype/mp4/filewriter/mp4arch.cpp',
'../../../datatype/mp4/filewriter/dlliids.cpp',
'../../../datatype/mp4/filewriter/mp4wrplin.cpp',
'../../../datatype/mp4/filewriter/mp4wrtr.cpp',
'../../../datatype/mp4/filewriter/ra10sh.cpp',
'../../../datatype/mp4/filewriter/m4avsh.cpp',
'../../../datatype/mp4/filewriter/avcsh.cpp',
+ '../../../datatype/mp4/filewriter/h263sh.cpp',
'../../../datatype/mp4/filewriter/blist.cpp',
'../../../datatype/mp4/filewriter/mp4sm.cpp',
'mp4_sinf.cpp'
)
project.AddSources('../../../datatype/mp4/filewriter/3gpmeta.cpp')
project.AddExportedFunctions('RMACreateInstance')
DLLTarget('mp4wrtr')
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
// AVCsh.cpp: AVC stream handler
#include "hxcom.h"
#include "hxcomm.h"
#include "chxpckts.h"
#include "hxassert.h"
#include "mp4atoms.h"
#include "mp4sm.h"
#include "h263sh.h"
#include "rmfftype.h"
#include "netbyte.h" /* common/util/pub/netbyte.h, dwtohost */
// These are the mime types we support
const char* CH263StreamHandler::m_pszFileMimeTypes[] =
{
"video/X-HX-H263",
NULL
};
const char* CH263StreamHandler::m_pszFileExtensions[] =
{
NULL
};
const char* CH263StreamHandler::m_pszFileOpenNames[] =
{
NULL
};
// CH263StreamHandler code
CH263StreamHandler::CH263StreamHandler( IUnknown* pContext, IMP4StreamMixer* pMixer )
{
m_lRefCount = 0;
m_unStreamNumber = 0;
HX_ASSERT(pMixer);
pMixer->AddRef();
m_pStreamMixer = pMixer;
HX_ASSERT(pContext);
pContext->AddRef();
m_pContext = pContext;
m_pCommonClassFactory = NULL;
}
CH263StreamHandler::~CH263StreamHandler()
{
HX_RELEASE( m_pStreamMixer );
HX_RELEASE( m_pContext );
HX_RELEASE( m_pCommonClassFactory );
}
STDMETHODIMP CH263StreamHandler::QueryInterface( REFIID riid, void** ppvObj )
{
// dont support, for now
return HXR_NOINTERFACE;
}
STDMETHODIMP_(ULONG32) CH263StreamHandler::AddRef()
{
return InterlockedIncrement( &m_lRefCount );
}
STDMETHODIMP_(ULONG32) CH263StreamHandler::Release()
{
if( InterlockedDecrement( &m_lRefCount ) > 0 )
{
return m_lRefCount;
}
delete this;
return 0;
}
STDMETHODIMP CH263StreamHandler::GetFormatInfo( const char*** pppFileMimeTypes, const char*** pppFileExtensions, const char*** pppFileOpenNames )
{
if( pppFileMimeTypes )
{
*pppFileMimeTypes = m_pszFileMimeTypes;
}
if( pppFileExtensions )
{
*pppFileExtensions = m_pszFileExtensions;
}
if( pppFileOpenNames )
{
*pppFileOpenNames = m_pszFileOpenNames;
}
return HXR_OK;
}
// InitStreamHandler; this is called after the mp4 filewriter
// has determined it has a stream that actually matches our supported
// mime types, and allows us to do any initialization that would be
// inappropriate in the constructor (such as memory allocation)
STDMETHODIMP CH263StreamHandler::InitStreamHandler()
{
HX_RESULT retVal;
retVal = m_pContext->QueryInterface( IID_IHXCommonClassFactory, (void**) &m_pCommonClassFactory );
return retVal;
}
STDMETHODIMP CH263StreamHandler::SetFileHeader( IHXValues* pHeader )
{
// We dont need the fileheader at all
return HXR_OK;
}
// SetStreamHeader; called when the stream header for this stream is available
STDMETHODIMP CH263StreamHandler::SetStreamHeader( IHXValues* pHeader )
{
HX_RESULT retVal = HXR_OK;
UINT32 ulStreamNumber;
pHeader->GetPropertyULONG32("StreamNumber", ulStreamNumber);
m_unStreamNumber = (UINT16) ulStreamNumber;
IHXBuffer* pOpaqueData = NULL;
retVal = pHeader->GetPropertyBuffer("OpaqueData", pOpaqueData);
if(pOpaqueData)
{
UCHAR* pBuffer = pOpaqueData->GetBuffer();
UINT32 ulLen = pOpaqueData->GetSize();
if ( SUCCEEDED(retVal) )
{
// h263 encoder plugin puts decoder info in OpaqueData.
// Producer though always attaches a MultiStreamHeader to the front.
// Need to strip the MLTI header
UINT32 ulID = DwToHost(*(UINT32*)(pBuffer));
if( RM_MULTIHEADER_OBJECT == ulID )
{
MultiStreamHeader multiStreamHeader;
UCHAR* pOpaqueData = pBuffer;
pBuffer = multiStreamHeader.unpack( pBuffer, ulLen );
//bypass the size of header field, we should be at the avcC box now
pBuffer += sizeof(UINT32);
ulLen -= (pBuffer - pOpaqueData);
}
}
IHXBuffer* pDecoderInfoBuffer = NULL;
if (SUCCEEDED(retVal))
{
retVal = m_pCommonClassFactory->CreateInstance( IID_IHXBuffer, (void**) &pDecoderInfoBuffer );
}
if (SUCCEEDED(retVal))
{
pDecoderInfoBuffer->Set(pBuffer, ulLen);
pHeader->SetPropertyBuffer("DecoderInfo", pDecoderInfoBuffer );
}
HX_RELEASE(pDecoderInfoBuffer);
HX_RELEASE(pOpaqueData);
}
if (SUCCEEDED(retVal))
{
// Indicate this is a video track with h263 sample format
pHeader->SetPropertyULONG32( "TrackType", MP4_BUILD_ATOMID('v','i','d','e') );
pHeader->SetPropertyULONG32( "SampleFormat", MP4_BUILD_ATOMID('h','2','6','3') );
m_pStreamMixer->SetStreamHeader( pHeader );
}
return retVal;
}
// SetPacket; called every time a packet comes in
STDMETHODIMP CH263StreamHandler::SetPacket( IHXPacket* pPacket )
{
HX_RESULT retVal = HXR_FAIL;
if( pPacket )
{
// pass through
retVal = m_pStreamMixer->SetPacket( pPacket );
}
return HXR_OK;
}
// StreamDone; called after the final SetPacket() call for this stream
STDMETHODIMP CH263StreamHandler::StreamDone()
{
m_pStreamMixer->StreamDone( m_unStreamNumber );
return HXR_OK;
}
-------------- next part --------------
/* ***** BEGIN LICENSE BLOCK *****
* Version: RCSL 1.0/RPSL 1.0
*
* Portions Copyright (c) 1995-2002 RealNetworks, Inc. All Rights Reserved.
*
* The contents of this file, and the files included with this file, are
* subject to the current version of the RealNetworks Public Source License
* Version 1.0 (the "RPSL") available at
* http://www.helixcommunity.org/content/rpsl unless you have licensed
* the file under the RealNetworks Community Source License Version 1.0
* (the "RCSL") available at http://www.helixcommunity.org/content/rcsl,
* in which case the RCSL will apply. You may also obtain the license terms
* directly from RealNetworks. You may not use this file except in
* compliance with the RPSL or, if you have a valid RCSL with RealNetworks
* applicable to this file, the RCSL. Please see the applicable RPSL or
* RCSL for the rights, obligations and limitations governing use of the
* contents of the file.
*
* This file is part of the Helix DNA Technology. RealNetworks is the
* developer of the Original Code and owns the copyrights in the portions
* it created.
*
* This file, and the files included with this file, is distributed and made
* available on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER
* EXPRESS OR IMPLIED, AND REALNETWORKS HEREBY DISCLAIMS ALL SUCH WARRANTIES,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS
* FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.
*
* Technology Compatibility Kit Test Suite(s) Location:
* http://www.helixcommunity.org/content/tck
*
* Contributor(s):
*
* ***** END LICENSE BLOCK ***** */
// AVCsh.h: AVC streamhandler
// the initial version of this will plug directly into a streamhandler and output a AVC; later versions
// would require a second component to be built up which would handle layout, and instead of calling archiver
// routines to write a file, this component would feed packets to the layout object.
#ifndef _H263SH_H_
#define _H263SH_H_
#include "mp4fwplg.h"
typedef _INTERFACE IHXCommonClassFactory IHXCommonClassFactory;
class CH263StreamHandler : public IMP4StreamHandler
{
public:
CH263StreamHandler( IUnknown* pContext, IMP4StreamMixer* pMixer );
~CH263StreamHandler();
/*
* IUnknown
*/
STDMETHOD(QueryInterface) ( THIS_ REFIID riid, void** ppvObj );
STDMETHOD_(ULONG32,AddRef) ( THIS );
STDMETHOD_(ULONG32,Release) ( THIS );
/*
* IMP4StreamHandler
*/
STDMETHOD(GetFormatInfo) ( THIS_
const char*** /*OUT*/ pFileMimeTypes,
const char*** /*OUT*/ pFileExtensions,
const char*** /*OUT*/ pFileOpenNames
);
STDMETHOD(InitStreamHandler) ( THIS );
STDMETHOD(SetFileHeader) ( THIS_ IHXValues* pHeader );
STDMETHOD(SetStreamHeader) ( THIS_ IHXValues* pHeader );
STDMETHOD(SetPacket) ( THIS_ IHXPacket* pPacket );
STDMETHOD(StreamDone) ( THIS );
private:
static const char* m_pszFileMimeTypes[];
static const char* m_pszFileExtensions[];
static const char* m_pszFileOpenNames[];
LONG32 m_lRefCount;
UINT16 m_unStreamNumber;
IMP4StreamMixer* m_pStreamMixer;
IUnknown* m_pContext;
IHXCommonClassFactory* m_pCommonClassFactory;
};
#endif /* _H263SH_H_ */
From ehyche at real.com Fri Sep 26 06:35:49 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 26 04:51:07 2008
Subject: [datatype-dev] CR:403-961 Configurability in Helix of
the deblocking and deringing filter
In-Reply-To:
References:
Message-ID: <00b601c91fdc$ca99e800$5fcdb800$@com>
These changes look good to me.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of ext-ashwinkumar.1.nadagoudar@nokia.com
>Sent: Tuesday, September 23, 2008 4:03 PM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR:403-961 Configurability in Helix of the deblocking and deringing filter
>
> "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-ashwinkumar.1.nadagoudar@nokia.com
>
> Reviewed by:
>
> Req ID: 403-961
>
> Date: 09/18/2008
>
> Project: SymbianMmf_rel
>
> Synopsis: Configurability in Helix of the deblocking and deringing filter
>
> Overview:
> Helix already contain a configuration file/system that can be used to select whether SW or
>HW video decoders should be used for certain resolutions in a specific HW platform. This system has to
>be extended to allow also control of when the deblocking filter and the deringing filter are turned
>on/off in the MDF post-processor.
>
>
> Fix:
> Current codec rule looks like this,
> MDFCodecRule1={ H263 Baseline 176x144 0x10206674 0x10273417 0x10204BFA 0x10273417 }
> Now codec rule has been modified to
> MDFCodecRule1={ H263 Baseline 176x144 0x10206674 0x10273417 0x10204BFA 0x10273417
>Resolution filtervalue1 filtervalue2}
> For ex:
> MDFCodecRule1={ H263 Baseline 176x144 0x10206674 0x10273417 0x10204BFA 0x10273417 176x144
>0x3 0x0}
>
> Filtervalue1 is selected depending on the video resolution . In this example if the video
>resolution is <= 176x144(8th field)
>
> then filtervalu1 i.e 0x3 is selected. Filtervalue2 i.e 0x0 is selected otherwise.
>
> Filtervalue 0x1 signifies Deblocking has to be enabled, 0x2 signifies Deringing has to be
>enabled
> 0x3 signifies both have to be enabled. 0x0 signifies both have to be disabled.
>
> If there are no fileds(8th, 9th and 10th) in the codec rule then both filters are not
>enabled.
>
>
> Files modified & changes:
>
> \datatype\mdf\video\renderer\mdfvideoadapter.h
> \datatype\mdf\video\renderer\mdfvideoadapter.cpp
> \datatype\mdf\video\renderer\mdfdevice\server\CMDFDevVideoServerCmds.h
> \datatype\mdf\video\renderer\mdfdevice\server\CMDFDevVideoServerSession.cpp
>
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF) : Passed
>
> Test case(s) Added : None
>
> Memory leak check performed : Passed, No leaks found
>
> Platforms and Profiles Build Verified: helix-client-s60-50-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: Head, 210CayS
>
> ===========================
> DIFF enclosed as text files
> ===========================
> <>
>
> Thanks
> Ashwin
From ehyche at real.com Fri Sep 26 06:46:53 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 26 05:02:16 2008
Subject: [datatype-dev] Adding divx extension in AVI file format
In-Reply-To: <006201c91f55$b17f4900$f58016ac@corp.real.com>
References: <006201c91f55$b17f4900$f58016ac@corp.real.com>
Message-ID: <00b701c91fde$56dbb590$049320b0$@com>
Jyotsana,
My understanding is that the .divx format is also a RIFF
format similar to .avi but that the set of .divx chunk types
is a superset of the .avi chunk types. Have we verified
that the .avi file format plugin skips over any .divx chunks
it does not understand (as opposed to erroring out when
it encounters an unknown chunk type)?
If so, then this change looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Jyotsana Rathore
>Sent: Thursday, September 25, 2008 5:29 PM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] Adding divx extension in AVI file format
>
>Modified by: jrathore@real.com
>
>Date: 09/25/08
>
>Project: Helix DNA Client
>
>
>
>Synopsis: Adding divx extension in AVI file format
>
>
>
>Overview: Adding the divx extension in avi file format without which HXR_NO_RENDERER error is
>returned.
>
>
>
>Files Added: None
>
>
>
>Files Modified:
>
>aacff.cpp (/datatype/avi/fileformat/aviffpln.cpp)
>
>
>
>Image Size and Heap Use impact (Client -Only): None
>
>
>
>Platforms and Profiles Affected:
>
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>
>
>Platforms and Profiles Build and Functionality Verified:
>
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>target(s): splay
>
>
>
>Branch: hxclient_3_1_0_atlas, HEAD
>
>
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>Files Attached: aviffpln.diff
>
>
>
>-Jyotsana
From ehyche at real.com Fri Sep 26 07:46:08 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 26 06:01:28 2008
Subject: [datatype-dev] CR: Adding h.263 support to MP4 file writer
In-Reply-To: <6.2.1.2.2.20080925173449.043a3008@mailone.real.com>
References: <6.2.1.2.2.20080925173449.043a3008@mailone.real.com>
Message-ID: <00be01c91fe6$9d9756d0$d8c60470$@com>
Stan,
Here are my comments:
- h263sh.h still has a comment at the top referring to AVC. This
comment should be removed.
Rest looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Stanislav Bobrovskiy
>Sent: Thursday, September 25, 2008 9:01 PM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] CR: Adding h.263 support to MP4 file writer
>
>Modified by: stanb@real.com
>Date: 09:25:08
>Project: Helix DNA Client
>
>Synopsis: These changes allow to write h263 video data to 3gp files.
>
>Overview:
>- Added CH263StreamHandler class (h263sh.cpp, h263sh.h) analogous to one that handles h264 video
>(avcsh.cpp, avcsh.h).
>- Added 2 needed MP4 atom calsses to mp4atoms.h: CMP4Atom_d263 and CMP4Atom_s263.
>- Added method for building h263 stsd entry to mp4sm.cpp:
>CMP4StreamMixer::BuildH263StsdEntry().
>
>Files Added: /datatype/mp4/filewriter/h263sh.cpp,
>/datatype/mp4/filewriter/h263sh.h
>
>Files Modified:
>/datatype/mp4/filewriter/Umakefil
>/datatype/mp4/filewriter/mp4atoms.h
>/datatype/mp4/filewriter/mp4sm.cpp
>/datatype/mp4/filewriter/mp4sm.h
>/datatype/mp4/filewriter/mp4wrtr.cpp
>
>/datatype_rn/mp4/filewriter/Umakefil
>
>
>Image Size and Heap Use impact (Client-Only): negligible
>
>Platforms and Profiles Affected:
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>Platforms and Profiles Build Verified:
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>target(s): playinst
>
>Platforms and Profiles Functionality verified:
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>target(s): playinst
>
>Branch: hxclient_3_1_0_atlas, HEAD
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>Files Attached: h263sh.cpp, h263sh.h, datatype_mp4_filewriter.diff, datatype_rn_mp4_filewriter.diff
>
>
>
>
>
From ext-ashwinkumar.1.nadagoudar at nokia.com Fri Sep 26 08:46:18 2008
From: ext-ashwinkumar.1.nadagoudar at nokia.com (ext-ashwinkumar.1.nadagoudar@nokia.com)
Date: Fri Sep 26 07:01:35 2008
Subject: [datatype-dev] CN :403-961 Configurability in Helix of
the deblocking and deringing filter
In-Reply-To: <00b601c91fdc$ca99e800$5fcdb800$@com>
References:
<00b601c91fdc$ca99e800$5fcdb800$@com>
Message-ID:
Committed changes in Head and 210CayS
Thanks,
Ashwin
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Friday, September 26, 2008 8:36 AM
>To: Nadagoudar Ashwinkumar.1 (EXT-InfoVision-MSW/Dallas);
>datatype-dev@helixcommunity.org
>Subject: RE: [datatype-dev] CR:403-961 Configurability in
>Helix of the deblocking and deringing filter
>
>These changes look good to me.
>
>=======================================
>Eric Hyche (ehyche@real.com)
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: datatype-dev-bounces@helixcommunity.org
>>[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of
>>ext-ashwinkumar.1.nadagoudar@nokia.com
>>Sent: Tuesday, September 23, 2008 4:03 PM
>>To: datatype-dev@helixcommunity.org
>>Subject: [datatype-dev] CR:403-961 Configurability in Helix of the
>>deblocking and deringing filter
>>
>> "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-ashwinkumar.1.nadagoudar@nokia.com
>>
>> Reviewed by:
>>
>> Req ID: 403-961
>>
>> Date: 09/18/2008
>>
>> Project: SymbianMmf_rel
>>
>> Synopsis: Configurability in Helix of the
>deblocking and deringing
>>filter
>>
>> Overview:
>> Helix already contain a configuration
>file/system that can be used to
>>select whether SW or HW video decoders should be used for certain
>>resolutions in a specific HW platform. This system has to be extended
>>to allow also control of when the deblocking filter and the
>deringing filter are turned on/off in the MDF post-processor.
>>
>>
>> Fix:
>> Current codec rule looks like this,
>> MDFCodecRule1={ H263 Baseline 176x144
>0x10206674 0x10273417 0x10204BFA 0x10273417 }
>> Now codec rule has been modified to
>> MDFCodecRule1={ H263 Baseline 176x144
>0x10206674 0x10273417
>>0x10204BFA 0x10273417 Resolution filtervalue1 filtervalue2}
>> For ex:
>> MDFCodecRule1={ H263 Baseline 176x144
>0x10206674 0x10273417
>>0x10204BFA 0x10273417 176x144
>>0x3 0x0}
>>
>> Filtervalue1 is selected depending on the video
>resolution . In this
>>example if the video resolution is <= 176x144(8th field)
>>
>> then filtervalu1 i.e 0x3 is selected.
>Filtervalue2 i.e 0x0 is selected otherwise.
>>
>> Filtervalue 0x1 signifies Deblocking has to be
>enabled, 0x2 signifies
>>Deringing has to be enabled
>> 0x3 signifies both have to be enabled. 0x0
>signifies both have to be disabled.
>>
>> If there are no fileds(8th, 9th and 10th) in
>the codec rule then both
>>filters are not enabled.
>>
>>
>> Files modified & changes:
>>
>> \datatype\mdf\video\renderer\mdfvideoadapter.h
>> \datatype\mdf\video\renderer\mdfvideoadapter.cpp
>>
>\datatype\mdf\video\renderer\mdfdevice\server\CMDFDevVideoServerCmds.h
>>
>>\datatype\mdf\video\renderer\mdfdevice\server\CMDFDevVideoServ
>erSession
>>.cpp
>>
>> Image Size and Heap Use impact: None
>>
>> Module Release testing (STIF) : Passed
>>
>> Test case(s) Added : None
>>
>> Memory leak check performed : Passed, No leaks found
>>
>> Platforms and Profiles Build Verified:
>>helix-client-s60-50-mmf-mdf-arm
>>
>> Platforms and Profiles Functionality verified: armv5
>>
>> Branch: Head, 210CayS
>>
>> ===========================
>> DIFF enclosed as text files
>> ===========================
>> <>
>>
>> Thanks
>> Ashwin
>
>
>
From ehyche at real.com Fri Sep 26 08:46:22 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 26 07:01:42 2008
Subject: [datatype-dev] CR: Thumbnail generation improvement updates
In-Reply-To:
References:
Message-ID: <00dd01c91fef$07638fe0$162aafa0$@com>
Hayoung,
Here are my comments:
1) You need to set your tab settings in Visual Studio
as shown in the attached image VS7TabSettings.png.
2) datatype/image/png/filewriter/Umakefil
-
-project.ExportFunction("RMACreateInstance",
- "IUnknown** ppObj",
- "common/include",
- "hxcom.h")
RMACreateInstance entrypoint should not be removed. It
is necessary for the PNG file writer to be loaded as
a Helix plugin.
3) ffdriver.h
+#define RESIZINGTHUMBNAILWIDTH_OPTION_NAME "ResizingThumbnailWidth"
+#define RESIZINGTHUMBNAILHEIGHT_OPTION_NAME "ResizingThumbnailHeight"
We should not call these anything to do with "thumbnail" since
this decoding might be used with general video transcoding.
So let's call these options as follows:
+#define DECODED_VIDEO_RESIZE_WIDTH_OPTION_NAME "DecodedVideoResizeWidth"
+#define DECODED_VIDEO_RESIZE_HEIGHT_OPTION_NAME "DecodedVideoResizeHeight"
3) ffdriver.cpp
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulResizingThumbnailWidth = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(RESIZINGTHUMBNAILWIDTH_OPTION_NAME, ulResizingThumbnailWidth)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(RESIZINGTHUMBNAILWIDTH_OPTION_NAME, ulResizingThumbnailWidth);
+ }
+ }
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulResizingThumbnailHeight = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(RESIZINGTHUMBNAILHEIGHT_OPTION_NAME, ulResizingThumbnailHeight)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(RESIZINGTHUMBNAILHEIGHT_OPTION_NAME, ulResizingThumbnailHeight);
+ }
+ }
There is no need for these options to be passed on to the file writer, since the
resizing is done at the video decoder level.
4) main.cpp
+#define RESIZINGTHUMBNAILWIDTH_OPTION_STRING "RTW"
+#define RESIZINGTHUMBNAILHEIGHT_OPTION_STRING "RTH"
In order to match the new option name, then let's call
these command-line option strings as follows:
+#define DECODED_VIDEO_RESIZE_WIDTH_OPTION_STRING "DVRW"
+#define DECODED_VIDEO_RESIZE_HEIGHT_OPTION_STRING "DVRH"
5) pngwrtr.cpp
+ , m_uIBitsPerPixel(0)
+ , m_uIResizingThumbnailWidth(0)
+ , m_uIResizingThumbnailHeight(0)
Please use the prefix "m_ul" instead of "m_uI" on these variables.
+ HX_RELEASE(m_pColorFuncAccessor);
I'm not sure how this even compiles, since the ColorFuncAccess class does not
have a Release() method. This should be HX_DELETE() instead.
+
+ ULONG32 resizingThumbnailWidth = 0;
+ retVal = m_pProperties->GetPropertyULONG32("ResizingThumbnailWidth", resizingThumbnailWidth);
+ if (SUCCEEDED(retVal))
+ {
+ m_uIResizingThumbnailWidth = resizingThumbnailWidth;
+ }
+
+ ULONG32 resizingThumbnailHeight = 0;
+ retVal = m_pProperties->GetPropertyULONG32("ResizingThumbnailHeight", resizingThumbnailHeight);
+ if (SUCCEEDED(retVal))
+ {
+ m_uIResizingThumbnailHeight = resizingThumbnailHeight;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulColorFormatOut = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(COLORCONVERT_OPTION_NAME, ulColorFormatOut)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(COLORCONVERT_OPTION_NAME, ulColorFormatOut);
+ }
+ }
The PNG file writer does not need to resize the video. Resizing will
be done at the video decoder. Also, the PNG file writer always knows
to color convert the video to RGB. It does not need the "ColorConvert"
option. In fact, the "ColorConvert" option should be independent of
the PNG file writer - it is intended for the color conversion that
happens immediately after the video decode.
- ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
+ //ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
If this code is not needed (and you know it will never be needed
in the future), then remove it.
+ else if (strcasecmp("video/X-HX-I420", pMimeTypeData) == 0)
+ {
+ m_bDoConversion = TRUE;
+ m_ulColorFormatIn = CID_I420;
+
+ bRetVal = SUCCEEDED(m_pProperties->GetPropertyULONG32("ColorConvert", m_ulColorFormatOut));
+ if (bRetVal == FALSE)
+ {
+ // Default setting as RGB24
+ m_ulColorFormatOut = CID_RGB24;
Color conversion in the PNG file writer does not depend
on the presence of the "ColorConvert" option. PNG *always*
needs RGB. Therefore, if the input color format is not
either RGB24 or RGB32, then PNG always knows to color
convert to an RGB format. The "ColorConvert" option tells
the system whether or not to color convert immediately
after the video decode.
6) pngwrtr.h - some changes will be required here in order
to make the changes I've suggested above in pngwrtr.cpp.
7) vdecoder.cpp - You have removed the color conversion here.
That is not what we want. We want to leave the color conversion
capability in vdecoder.cpp, which is still controlled by the
"ColorConvert" option. We want to *add* color conversion
capability in the PNG file writer which is NOT controlled
by the "ColorConvert" option. Since the PNG file writer knows
that it needs RGB, then it knows that it will need to
color convert from whatever input color format to RGB.
+ // check to see if ProcessDecodedTimeUnits reach the value,
+ // if so, call OnStreamDone function to stop getting any more packets.
+ if (m_bProcessDecodedTimeUnits)
+ {
+ if (m_ulProcessDecodedTimeUnits == 0)
+ {
+ OnStreamDone(HXR_OK, pPacket->GetStreamNumber());
+ m_bProcessDecodedTimeUnits = FALSE;
+ }
+ else
+ {
+ m_ulProcessDecodedTimeUnits--;
+ }
+ }
+
- I see that the code above calls StreamDone() when you have
passed on m_ulProcessDecodedTimeUnits packets. However, I don't
see any code that prevents us from decoding any packets
we get *after* we have called StreamDone(). We definitely
need that.
- We also need to add the ability here to resize based
upon the "DecodedVideoResizeWidth" and "DecodedVideoResizeHeight"
options. We may also want to add a "DecodedVideoResizePreserveAspect"
option (which defaults to 1) which will allow the user to preserve
the aspect ratio when resizing is done.
If no color conversion is being done, then we can use
the resizing functions in datatype/common/util/pub/resize.h to
resize the video frame. If color conversion is being done, then
it's possible that we might be able to do the resizing and
the color conversion in one step, since some color converters
support that. However, some color converters only support a limited
resizing (like resizing to width/2 and height/2). So the logic
can work something like this (in pseudocode):
if (doing color conversion)
{
if (doing resizing)
{
// Try resizing and color conversion at the same time
retVal = ColorConvert()
if (FAILED(retVal))
{
// Resize Y plane using resize.h functions
// Resize U plane using resize.h functions
// Resize V plane using resize.h functions
// Now do color conversion with no resizing
retVal = ColorConvert()
}
}
else
{
// Color convert as usual
}
}
else if (doing resizing)
{
// Resize Y plane using resize.h functions
// Resize U plane using resize.h functions
// Resize V plane using resize.h functions
}
8) vdecoder.h
As I said above in the comments for vdecoder.cpp, we do NOT
want to remove the color conversion capability from
vdecoder.cpp.
Please rework these changes and re-submit the CR.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of ???(Hayoung Choi)
>Sent: Thursday, September 25, 2008 3:13 PM
>To: datatype-dev@lists.helixcommunity.org
>Subject: [datatype-dev] CR: Thumbnail generation improvement updates
>
>Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
>
>Date: September 25, 2008
>
>Project: Thumbnail generation improvement updates
>
>
>
>Synopsis:
>
>=============
>
>PNG file writer supports both RGB24/RGB32 thumbnail generations, resizing of thumbnail image.
>
>The color conversion code is moved into the PNG file writer from video decoder.
>
>The option ?ProcessDecodedTimeUnits? is added into dtdrive application.
>
>
>
>Overview:
>
>=============
>
>1) RGB24/RGB32 thumbnails support and moving color conversion into PNG file writer
>
>The color conversion codes are moved into PNG file writer from video decoder.
>
>So, if the mime type of video source is RGB, color conversion will not be happened, but in case of
>I420 conversion will be happened PNG file writer inside.
>
>The default value of ?bits per pixel? for RGB is 24, or you can choose RGB24/RGB32 with the
>application option (-CC).
>
>
>
>dtdrive.exe +u +f -DV 1 -CC RGB32 -MOF 5 -W videotest.png videotest.rm
>
>
>
>2) Adding ?ProcessDecodedTimeUnits?
>
>If the count of decoded frames reach the value of ?ProcessDecodedTimeUnits? which was set by the
>application option (-PDTU), the video decoder calls OnStreamDone().
>
>Then decoding will not occurred any more.
>
>
>
> dtdrive.exe +u +f -DV 1 -PDTU 5 -CC RGB32 -MOF 5 -W videotest.png videotest.rm
>
>
>
>3) Resizing the thumbnail image for PNG
>
>Resizing thumbnail image frame option is added. You can resize thumbnail with the option
>ResizingThumbnailWidth (-RTW) / ResizingThumbnailHeight (-RTH).
>
>
>
>dtdrive.exe +u +f -DV 1 -MOF 5 -RTW 160 -RTH 90 -W videotest.png videotest.rm
>
>
>
>Files Modified:
>
>=============
>
>[File 1] - datatype/image/png/filewriter/Umakefil
>
>[File 2] - datatype/image/png/filewriter/pngwrtr.cpp
>
>[File 3] - datatype/image/png/filewriter/pngwrtr.h
>
>[File 4] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
>
>[File 5] - datatype/tools/dtdriver/engine/ffdriver.cpp
>
>[File 6] - datatype/tools/dtdriver/engine/pub/ffdriver.h
>
>[File 7] - datatype/tools/dtdriver/decoder/video/vdecoder.cpp
>
>[File 8] - datatype/tools/dtdriver/decoder/video/vdecoder.h
>
>
>
>=============
>
>Image Size and Heap Use impact (Client -Only):
>
>NA
>
>
>
>
>
>=============
>
>Platforms and Profiles Affected:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>
>
>=============
>
>Distribution Libraries Affected:
>
>pngwrtr.dll
>
>dtdrive.lib
>
>dtdrengine.lib
>
>dtdrviddec.lib
>
>
>
>=============
>
>Distribution library impact and planned action:
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Build Verified:
>
>System id: win32-i386-vc7
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>Microsoft Compiler 13.10.6030
>
>
>
>
>
>=============
>
>Platforms and Profiles Functionality verified:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>Branch: HEAD and Atlas310
>
>Target: dtdrive
>
>Profile: helix-client-all-defines
>
>
>
>
>
>=============
>
>Copyright assignment:
>
>I am a RealNetworks employee or contractor
>
>
>
>=============
>
>QA Instructions:
>
>NA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VS7TabSettings.png
Type: image/png
Size: 36819 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080926/c9643019/VS7TabSettings-0001.png
From hayoung.choi at ap.real.com Mon Sep 29 00:19:38 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Sun Sep 28 22:34:51 2008
Subject: [datatype-dev] CR: Thumbnail generation improvement updates
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: pngwrtr.h.diff
Type: application/octet-stream
Size: 1463 bytes
Desc: pngwrtr.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/pngwrtr.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Umakefil.diff
Type: application/octet-stream
Size: 1359 bytes
Desc: Umakefil.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/Umakefil-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pngwrtr.cpp.diff
Type: application/octet-stream
Size: 20359 bytes
Desc: pngwrtr.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/pngwrtr.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp.diff
Type: application/octet-stream
Size: 4465 bytes
Desc: main.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/main.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.cpp.diff
Type: application/octet-stream
Size: 1463 bytes
Desc: ffdriver.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/ffdriver.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffdriver.h.diff
Type: application/octet-stream
Size: 1237 bytes
Desc: ffdriver.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/ffdriver.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdecoder.cpp.diff
Type: application/octet-stream
Size: 10437 bytes
Desc: vdecoder.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/vdecoder.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Umakefil.diff
Type: application/octet-stream
Size: 691 bytes
Desc: Umakefil.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/Umakefil-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdecoder.h.diff
Type: application/octet-stream
Size: 2287 bytes
Desc: vdecoder.h.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/eed7324e/vdecoder.h-0001.obj
From hayoung.choi at ap.real.com Mon Sep 29 00:27:09 2008
From: hayoung.choi at ap.real.com (=?ks_c_5601-1987?B?w9bHz7+1KEhheW91bmcgQ2hvaSk=?=)
Date: Sun Sep 28 22:42:14 2008
Subject: [datatype-dev] CR: Thumbnail generation improvement updates
References:
<00dd01c91fef$07638fe0$162aafa0$@com>
Message-ID:
Eric,
I've reflected your comments into the new CR and re-submitted it.
Please, review the CR updated.
Among the your comments,
I didn't get the meaning of "DecodedVideoResizePreserveAspect".
Once, I've put the option for it in the video decoder.
Could you explain this more detail? Where does this value be used?
Thanks,
Hayoung
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Saturday, September 27, 2008 12:46 AM
To: ???(Hayoung Choi); datatype-dev@lists.helixcommunity.org
Subject: RE: [datatype-dev] CR: Thumbnail generation improvement updates
Hayoung,
Here are my comments:
1) You need to set your tab settings in Visual Studio
as shown in the attached image VS7TabSettings.png.
2) datatype/image/png/filewriter/Umakefil
-
-project.ExportFunction("RMACreateInstance",
- "IUnknown** ppObj",
- "common/include",
- "hxcom.h")
RMACreateInstance entrypoint should not be removed. It
is necessary for the PNG file writer to be loaded as
a Helix plugin.
3) ffdriver.h
+#define RESIZINGTHUMBNAILWIDTH_OPTION_NAME "ResizingThumbnailWidth"
+#define RESIZINGTHUMBNAILHEIGHT_OPTION_NAME "ResizingThumbnailHeight"
We should not call these anything to do with "thumbnail" since
this decoding might be used with general video transcoding.
So let's call these options as follows:
+#define DECODED_VIDEO_RESIZE_WIDTH_OPTION_NAME "DecodedVideoResizeWidth"
+#define DECODED_VIDEO_RESIZE_HEIGHT_OPTION_NAME "DecodedVideoResizeHeight"
3) ffdriver.cpp
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulResizingThumbnailWidth = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(RESIZINGTHUMBNAILWIDTH_OPTION_NAME, ulResizingThumbnailWidth)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(RESIZINGTHUMBNAILWIDTH_OPTION_NAME, ulResizingThumbnailWidth);
+ }
+ }
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulResizingThumbnailHeight = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(RESIZINGTHUMBNAILHEIGHT_OPTION_NAME, ulResizingThumbnailHeight)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(RESIZINGTHUMBNAILHEIGHT_OPTION_NAME, ulResizingThumbnailHeight);
+ }
+ }
There is no need for these options to be passed on to the file writer, since the
resizing is done at the video decoder level.
4) main.cpp
+#define RESIZINGTHUMBNAILWIDTH_OPTION_STRING "RTW"
+#define RESIZINGTHUMBNAILHEIGHT_OPTION_STRING "RTH"
In order to match the new option name, then let's call
these command-line option strings as follows:
+#define DECODED_VIDEO_RESIZE_WIDTH_OPTION_STRING "DVRW"
+#define DECODED_VIDEO_RESIZE_HEIGHT_OPTION_STRING "DVRH"
5) pngwrtr.cpp
+ , m_uIBitsPerPixel(0)
+ , m_uIResizingThumbnailWidth(0)
+ , m_uIResizingThumbnailHeight(0)
Please use the prefix "m_ul" instead of "m_uI" on these variables.
+ HX_RELEASE(m_pColorFuncAccessor);
I'm not sure how this even compiles, since the ColorFuncAccess class does not
have a Release() method. This should be HX_DELETE() instead.
+
+ ULONG32 resizingThumbnailWidth = 0;
+ retVal = m_pProperties->GetPropertyULONG32("ResizingThumbnailWidth", resizingThumbnailWidth);
+ if (SUCCEEDED(retVal))
+ {
+ m_uIResizingThumbnailWidth = resizingThumbnailWidth;
+ }
+
+ ULONG32 resizingThumbnailHeight = 0;
+ retVal = m_pProperties->GetPropertyULONG32("ResizingThumbnailHeight", resizingThumbnailHeight);
+ if (SUCCEEDED(retVal))
+ {
+ m_uIResizingThumbnailHeight = resizingThumbnailHeight;
+ }
+
+ if (SUCCEEDED(retVal))
+ {
+ ULONG32 ulColorFormatOut = 0;
+ if (SUCCEEDED(m_pOptions->GetPropertyULONG32(COLORCONVERT_OPTION_NAME, ulColorFormatOut)))
+ {
+ retVal = pNewProps->SetPropertyULONG32(COLORCONVERT_OPTION_NAME, ulColorFormatOut);
+ }
+ }
The PNG file writer does not need to resize the video. Resizing will
be done at the video decoder. Also, the PNG file writer always knows
to color convert the video to RGB. It does not need the "ColorConvert"
option. In fact, the "ColorConvert" option should be independent of
the PNG file writer - it is intended for the color conversion that
happens immediately after the video decode.
- ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
+ //ulPropertyValue = // m_FileHeaderInfo.m_bFullyNative ? 1 : 0;
If this code is not needed (and you know it will never be needed
in the future), then remove it.
+ else if (strcasecmp("video/X-HX-I420", pMimeTypeData) == 0)
+ {
+ m_bDoConversion = TRUE;
+ m_ulColorFormatIn = CID_I420;
+
+ bRetVal = SUCCEEDED(m_pProperties->GetPropertyULONG32("ColorConvert", m_ulColorFormatOut));
+ if (bRetVal == FALSE)
+ {
+ // Default setting as RGB24
+ m_ulColorFormatOut = CID_RGB24;
Color conversion in the PNG file writer does not depend
on the presence of the "ColorConvert" option. PNG *always*
needs RGB. Therefore, if the input color format is not
either RGB24 or RGB32, then PNG always knows to color
convert to an RGB format. The "ColorConvert" option tells
the system whether or not to color convert immediately
after the video decode.
6) pngwrtr.h - some changes will be required here in order
to make the changes I've suggested above in pngwrtr.cpp.
7) vdecoder.cpp - You have removed the color conversion here.
That is not what we want. We want to leave the color conversion
capability in vdecoder.cpp, which is still controlled by the
"ColorConvert" option. We want to *add* color conversion
capability in the PNG file writer which is NOT controlled
by the "ColorConvert" option. Since the PNG file writer knows
that it needs RGB, then it knows that it will need to
color convert from whatever input color format to RGB.
+ // check to see if ProcessDecodedTimeUnits reach the value,
+ // if so, call OnStreamDone function to stop getting any more packets.
+ if (m_bProcessDecodedTimeUnits)
+ {
+ if (m_ulProcessDecodedTimeUnits == 0)
+ {
+ OnStreamDone(HXR_OK, pPacket->GetStreamNumber());
+ m_bProcessDecodedTimeUnits = FALSE;
+ }
+ else
+ {
+ m_ulProcessDecodedTimeUnits--;
+ }
+ }
+
- I see that the code above calls StreamDone() when you have
passed on m_ulProcessDecodedTimeUnits packets. However, I don't
see any code that prevents us from decoding any packets
we get *after* we have called StreamDone(). We definitely
need that.
- We also need to add the ability here to resize based
upon the "DecodedVideoResizeWidth" and "DecodedVideoResizeHeight"
options. We may also want to add a "DecodedVideoResizePreserveAspect"
option (which defaults to 1) which will allow the user to preserve
the aspect ratio when resizing is done.
If no color conversion is being done, then we can use
the resizing functions in datatype/common/util/pub/resize.h to
resize the video frame. If color conversion is being done, then
it's possible that we might be able to do the resizing and
the color conversion in one step, since some color converters
support that. However, some color converters only support a limited
resizing (like resizing to width/2 and height/2). So the logic
can work something like this (in pseudocode):
if (doing color conversion)
{
if (doing resizing)
{
// Try resizing and color conversion at the same time
retVal = ColorConvert()
if (FAILED(retVal))
{
// Resize Y plane using resize.h functions
// Resize U plane using resize.h functions
// Resize V plane using resize.h functions
// Now do color conversion with no resizing
retVal = ColorConvert()
}
}
else
{
// Color convert as usual
}
}
else if (doing resizing)
{
// Resize Y plane using resize.h functions
// Resize U plane using resize.h functions
// Resize V plane using resize.h functions
}
8) vdecoder.h
As I said above in the comments for vdecoder.cpp, we do NOT
want to remove the color conversion capability from
vdecoder.cpp.
Please rework these changes and re-submit the CR.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of ???(Hayoung Choi)
>Sent: Thursday, September 25, 2008 3:13 PM
>To: datatype-dev@lists.helixcommunity.org
>Subject: [datatype-dev] CR: Thumbnail generation improvement updates
>
>Modified by: Hayoung Choi (hayoung.choi@ap.real.com)
>
>Date: September 25, 2008
>
>Project: Thumbnail generation improvement updates
>
>
>
>Synopsis:
>
>=============
>
>PNG file writer supports both RGB24/RGB32 thumbnail generations, resizing of thumbnail image.
>
>The color conversion code is moved into the PNG file writer from video decoder.
>
>The option ?ProcessDecodedTimeUnits? is added into dtdrive application.
>
>
>
>Overview:
>
>=============
>
>1) RGB24/RGB32 thumbnails support and moving color conversion into PNG file writer
>
>The color conversion codes are moved into PNG file writer from video decoder.
>
>So, if the mime type of video source is RGB, color conversion will not be happened, but in case of
>I420 conversion will be happened PNG file writer inside.
>
>The default value of ?bits per pixel? for RGB is 24, or you can choose RGB24/RGB32 with the
>application option (-CC).
>
>
>
>dtdrive.exe +u +f -DV 1 -CC RGB32 -MOF 5 -W videotest.png videotest.rm
>
>
>
>2) Adding ?ProcessDecodedTimeUnits?
>
>If the count of decoded frames reach the value of ?ProcessDecodedTimeUnits? which was set by the
>application option (-PDTU), the video decoder calls OnStreamDone().
>
>Then decoding will not occurred any more.
>
>
>
> dtdrive.exe +u +f -DV 1 -PDTU 5 -CC RGB32 -MOF 5 -W videotest.png videotest.rm
>
>
>
>3) Resizing the thumbnail image for PNG
>
>Resizing thumbnail image frame option is added. You can resize thumbnail with the option
>ResizingThumbnailWidth (-RTW) / ResizingThumbnailHeight (-RTH).
>
>
>
>dtdrive.exe +u +f -DV 1 -MOF 5 -RTW 160 -RTH 90 -W videotest.png videotest.rm
>
>
>
>Files Modified:
>
>=============
>
>[File 1] - datatype/image/png/filewriter/Umakefil
>
>[File 2] - datatype/image/png/filewriter/pngwrtr.cpp
>
>[File 3] - datatype/image/png/filewriter/pngwrtr.h
>
>[File 4] - datatype/tools/dtdriver/apps/dtdrive/main.cpp
>
>[File 5] - datatype/tools/dtdriver/engine/ffdriver.cpp
>
>[File 6] - datatype/tools/dtdriver/engine/pub/ffdriver.h
>
>[File 7] - datatype/tools/dtdriver/decoder/video/vdecoder.cpp
>
>[File 8] - datatype/tools/dtdriver/decoder/video/vdecoder.h
>
>
>
>=============
>
>Image Size and Heap Use impact (Client -Only):
>
>NA
>
>
>
>
>
>=============
>
>Platforms and Profiles Affected:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>
>
>=============
>
>Distribution Libraries Affected:
>
>pngwrtr.dll
>
>dtdrive.lib
>
>dtdrengine.lib
>
>dtdrviddec.lib
>
>
>
>=============
>
>Distribution library impact and planned action:
>
>NA
>
>
>
>=============
>
>Platforms and Profiles Build Verified:
>
>System id: win32-i386-vc7
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>Microsoft Compiler 13.10.6030
>
>
>
>
>
>=============
>
>Platforms and Profiles Functionality verified:
>
>x86 Windows XP professional SP3 (Intel Core(TM)2 T5600 CPU 1.83GHz)
>
>
>
>Branch: HEAD and Atlas310
>
>Target: dtdrive
>
>Profile: helix-client-all-defines
>
>
>
>
>
>=============
>
>Copyright assignment:
>
>I am a RealNetworks employee or contractor
>
>
>
>=============
>
>QA Instructions:
>
>NA
From xiaolin.lliu at nokia.com Mon Sep 29 07:32:21 2008
From: xiaolin.lliu at nokia.com (xiaolin.lliu@nokia.com)
Date: Mon Sep 29 05:47:13 2008
Subject: [datatype-dev] CR:[common][datatype]: armv5 abiv2 build error
Message-ID:
> Modified by: xiaolin.lliu@nokia.com
>
> Reviewed by:
>
> Date: 09/26/2008
>
> Project: SymbianMmf_rel
>
> ErrorId: Case ID:
>
> Synopsis: Iniatialized writable data causes armv5 abvi2 build error.
>
>
> Files modified:
> datatype/null/renderer/nullrend.cpp
> common/include/hxtypes.h,
> common/log/logobserverfile/hxtlogobserver.cpp
> common/log/logsystem/hxtdeliverymanager.cpp
> common/log/logsystem/hxtlogfaenumerator.cpp
> common/log/logsystem/hxtlogfilter.cpp
> common/log/logsystem/hxtlogqueue.cpp
> common/log/logsystem/hxtlogsystem.cpp,
> common/log/logsystem/hxtthreadtracker.cpp
> common/log/logsystem/hxttranslationcentre.cpp
> common/log/logsystem/hxtwritermanager.cpp
> common/container/hxsbuffer.cpp
> common/log/logcommon/hxtdirconv.cpp
> common/log/logcommon/hlxxmlparser.cpp
> datatype/group/audio/audplin.cpp
>
> Files added:
> None.
>
> Cvs diff:
>
> Index: nullrend.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/null/renderer/nullrend.cpp,v
> retrieving revision 1.10.2.1
> diff -u -r1.10.2.1 nullrend.cpp
> --- nullrend.cpp 27 Feb 2006 15:52:33 -0000 1.10.2.1
> +++ nullrend.cpp 26 Sep 2008 19:25:21 -0000
> @@ -78,7 +78,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
> Index: hxtypes.h
> ===================================================================
> RCS file: /cvsroot/common/include/hxtypes.h,v
> retrieving revision 1.31.2.1
> diff -u -r1.31.2.1 hxtypes.h
> --- hxtypes.h 19 Jul 2006 13:34:01 -0000 1.31.2.1
> +++ hxtypes.h 26 Sep 2008 18:36:58 -0000
> @@ -766,7 +766,7 @@
> */
> #if defined (INITGUID)
> #define DEFINE_CONSTANT_STRING(name, string) \
> - const char *name = string;
> + const char * const name = string;
> #else
> #define DEFINE_CONSTANT_STRING(name, string) \
> extern const char* name;
>
>
>
> Index: hxtlogobserver.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logobserverfile/hxtlogobserver.cpp,v
> retrieving revision 1.13.2.2
> diff -u -r1.13.2.2 hxtlogobserver.cpp
> --- hxtlogobserver.cpp 27 Sep 2007 19:20:07 -0000 1.13.2.2
> +++ hxtlogobserver.cpp 26 Sep 2008 19:21:43 -0000
> @@ -68,7 +68,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #if defined(HELIX_FEATURE_CLIENT)
>
>
> Index: hxtdeliverymanager.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtdeliverymanager.cpp,v
> retrieving revision 1.5
> diff -u -r1.5 hxtdeliverymanager.cpp
> --- hxtdeliverymanager.cpp 26 Apr 2005 23:02:37 -0000 1.5
> +++ hxtdeliverymanager.cpp 26 Sep 2008 19:12:33 -0000
> @@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
> Index: hxtlogfaenumerator.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogfaenumerator.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtlogfaenumerator.cpp
> --- hxtlogfaenumerator.cpp 16 Mar 2005 02:22:45 -0000 1.2
> +++ hxtlogfaenumerator.cpp 26 Sep 2008 19:12:42 -0000
> @@ -45,7 +45,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> BEGIN_INTERFACE_LIST_NOCREATE( CHXTFuncAreaEnumerator )
>
>
> Index: hxtlogfilter.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogfilter.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtlogfilter.cpp
> --- hxtlogfilter.cpp 16 Mar 2005 02:22:45 -0000 1.2
> +++ hxtlogfilter.cpp 26 Sep 2008 19:12:53 -0000
> @@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _WIN32
>
>
> Index: hxtlogqueue.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogqueue.cpp,v
> retrieving revision 1.4
> diff -u -r1.4 hxtlogqueue.cpp
> --- hxtlogqueue.cpp 15 Jun 2005 16:30:31 -0000 1.4
> +++ hxtlogqueue.cpp 26 Sep 2008 19:13:08 -0000
> @@ -60,7 +60,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CLogMsgBase::CLogMsgBase()
>
>
> Index: hxtlogsystem.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogsystem.cpp,v
> retrieving revision 1.7.2.1
> diff -u -r1.7.2.1 hxtlogsystem.cpp
> --- hxtlogsystem.cpp 19 Jul 2006 13:34:37 -0000 1.7.2.1
> +++ hxtlogsystem.cpp 26 Sep 2008 19:13:34 -0000
> @@ -57,7 +57,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
> Index: hxtthreadtracker.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtthreadtracker.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hxtthreadtracker.cpp
> --- hxtthreadtracker.cpp 5 Sep 2005 12:51:12 -0000 1.3
> +++ hxtthreadtracker.cpp 26 Sep 2008 19:13:57 -0000
> @@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXTThreadTracker::CHXTThreadTracker()
>
> Index: hxttranslationcentre.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxttranslationcentre.cpp,v
> retrieving revision 1.4
> diff -u -r1.4 hxttranslationcentre.cpp
> --- hxttranslationcentre.cpp 5 Sep 2005 12:51:12 -0000 1.4
> +++ hxttranslationcentre.cpp 26 Sep 2008 19:14:36 -0000
> @@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CTranslationInfo::~CTranslationInfo()
>
>
> Index: hxtwritermanager.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtwritermanager.cpp,v
> retrieving revision 1.5.2.1
> diff -u -r1.5.2.1 hxtwritermanager.cpp
> --- hxtwritermanager.cpp 17 Jan 2007 19:57:45 -0000 1.5.2.1
> +++ hxtwritermanager.cpp 26 Sep 2008 19:15:00 -0000
> @@ -59,7 +59,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _RVCT_
>
>
> Index: hxsbuffer.cpp
> ===================================================================
> RCS file: /cvsroot/common/container/hxsbuffer.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hxsbuffer.cpp
> --- hxsbuffer.cpp 9 Jul 2004 18:21:35 -0000 1.3
> +++ hxsbuffer.cpp 26 Sep 2008 19:09:45 -0000
> @@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXStaticBuffer::CHXStaticBuffer(void) :
>
>
> Index: hxtdirconv.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logcommon/hxtdirconv.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtdirconv.cpp
> --- hxtdirconv.cpp 16 Mar 2005 02:04:07 -0000 1.2
> +++ hxtdirconv.cpp 26 Sep 2008 19:06:40 -0000
> @@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
> ndex: hlxxmlparser.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logcommon/hlxxmlparser.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hlxxmlparser.cpp
> --- hlxxmlparser.cpp 26 Apr 2005 22:47:35 -0000 1.3
> +++ hlxxmlparser.cpp 26 Sep 2008 19:04:55 -0000
> @@ -51,7 +51,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> Index: audplin.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/group/audio/audplin.cpp,v
> retrieving revision 1.7.38.1
> diff -u -r1.7.38.1 audplin.cpp
> --- audplin.cpp 19 Jul 2006 13:37:46 -0000 1.7.38.1
> +++ audplin.cpp 26 Sep 2008 18:33:35 -0000
> @@ -102,7 +102,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> HX_RESULT (STDAPICALLTYPE * const
> AudioPluginFactory::m_fpEntryArray[])(IUnknown**)=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/a4a63e1a/attachment-0001.html
From ehyche at real.com Mon Sep 29 08:37:00 2008
From: ehyche at real.com (Eric Hyche)
Date: Mon Sep 29 06:51:40 2008
Subject: [datatype-dev] RE: [Common-dev] CR:[common][datatype]: armv5 abiv2
build error
In-Reply-To:
References:
Message-ID: <008b01c92249$37d82940$a7887bc0$@com>
Looks good.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: common-dev-bounces@helixcommunity.org [mailto:common-dev-bounces@helixcommunity.org] On Behalf
>Of xiaolin.lliu@nokia.com
>Sent: Monday, September 29, 2008 10:32 AM
>To: datatype-dev@lists.helixcommunity.org; common-dev@helixcommunity.org
>Subject: [Common-dev] CR:[common][datatype]: armv5 abiv2 build error
>
>
>
>
>
>Modified by: xiaolin.lliu@nokia.com
>
>Reviewed by:
>
>Date: 09/26/2008
>
>Project: SymbianMmf_rel
>
>ErrorId: Case ID:
>
>Synopsis: Iniatialized writable data causes armv5 abvi2 build error.
>
>
>Files modified:
>datatype/null/renderer/nullrend.cpp
>common/include/hxtypes.h,
>common/log/logobserverfile/hxtlogobserver.cpp
>common/log/logsystem/hxtdeliverymanager.cpp
>common/log/logsystem/hxtlogfaenumerator.cpp
>common/log/logsystem/hxtlogfilter.cpp
>common/log/logsystem/hxtlogqueue.cpp
>common/log/logsystem/hxtlogsystem.cpp,
>common/log/logsystem/hxtthreadtracker.cpp
>common/log/logsystem/hxttranslationcentre.cpp
>common/log/logsystem/hxtwritermanager.cpp
>common/container/hxsbuffer.cpp
>common/log/logcommon/hxtdirconv.cpp
>common/log/logcommon/hlxxmlparser.cpp
>datatype/group/audio/audplin.cpp
>
>Files added:
>None.
>
>Cvs diff:
>
>Index: nullrend.cpp
>===================================================================
>RCS file: /cvsroot/datatype/null/renderer/nullrend.cpp,v
>retrieving revision 1.10.2.1
>diff -u -r1.10.2.1 nullrend.cpp
>--- nullrend.cpp 27 Feb 2006 15:52:33 -0000 1.10.2.1
>+++ nullrend.cpp 26 Sep 2008 19:25:21 -0000
>@@ -78,7 +78,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>Index: hxtypes.h
>===================================================================
>RCS file: /cvsroot/common/include/hxtypes.h,v
>retrieving revision 1.31.2.1
>diff -u -r1.31.2.1 hxtypes.h
>--- hxtypes.h 19 Jul 2006 13:34:01 -0000 1.31.2.1
>+++ hxtypes.h 26 Sep 2008 18:36:58 -0000
>@@ -766,7 +766,7 @@
> */
> #if defined (INITGUID)
> #define DEFINE_CONSTANT_STRING(name, string) \
>- const char *name = string;
>+ const char * const name = string;
> #else
> #define DEFINE_CONSTANT_STRING(name, string) \
> extern const char* name;
>
>
>
>Index: hxtlogobserver.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logobserverfile/hxtlogobserver.cpp,v
>retrieving revision 1.13.2.2
>diff -u -r1.13.2.2 hxtlogobserver.cpp
>--- hxtlogobserver.cpp 27 Sep 2007 19:20:07 -0000 1.13.2.2
>+++ hxtlogobserver.cpp 26 Sep 2008 19:21:43 -0000
>@@ -68,7 +68,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #if defined(HELIX_FEATURE_CLIENT)
>
>
>Index: hxtdeliverymanager.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtdeliverymanager.cpp,v
>retrieving revision 1.5
>diff -u -r1.5 hxtdeliverymanager.cpp
>--- hxtdeliverymanager.cpp 26 Apr 2005 23:02:37 -0000 1.5
>+++ hxtdeliverymanager.cpp 26 Sep 2008 19:12:33 -0000
>@@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
>Index: hxtlogfaenumerator.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtlogfaenumerator.cpp,v
>retrieving revision 1.2
>diff -u -r1.2 hxtlogfaenumerator.cpp
>--- hxtlogfaenumerator.cpp 16 Mar 2005 02:22:45 -0000 1.2
>+++ hxtlogfaenumerator.cpp 26 Sep 2008 19:12:42 -0000
>@@ -45,7 +45,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> BEGIN_INTERFACE_LIST_NOCREATE( CHXTFuncAreaEnumerator )
>
>
>Index: hxtlogfilter.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtlogfilter.cpp,v
>retrieving revision 1.2
>diff -u -r1.2 hxtlogfilter.cpp
>--- hxtlogfilter.cpp 16 Mar 2005 02:22:45 -0000 1.2
>+++ hxtlogfilter.cpp 26 Sep 2008 19:12:53 -0000
>@@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _WIN32
>
>
>Index: hxtlogqueue.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtlogqueue.cpp,v
>retrieving revision 1.4
>diff -u -r1.4 hxtlogqueue.cpp
>--- hxtlogqueue.cpp 15 Jun 2005 16:30:31 -0000 1.4
>+++ hxtlogqueue.cpp 26 Sep 2008 19:13:08 -0000
>@@ -60,7 +60,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CLogMsgBase::CLogMsgBase()
>
>
>Index: hxtlogsystem.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtlogsystem.cpp,v
>retrieving revision 1.7.2.1
>diff -u -r1.7.2.1 hxtlogsystem.cpp
>--- hxtlogsystem.cpp 19 Jul 2006 13:34:37 -0000 1.7.2.1
>+++ hxtlogsystem.cpp 26 Sep 2008 19:13:34 -0000
>@@ -57,7 +57,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
>Index: hxtthreadtracker.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtthreadtracker.cpp,v
>retrieving revision 1.3
>diff -u -r1.3 hxtthreadtracker.cpp
>--- hxtthreadtracker.cpp 5 Sep 2005 12:51:12 -0000 1.3
>+++ hxtthreadtracker.cpp 26 Sep 2008 19:13:57 -0000
>@@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXTThreadTracker::CHXTThreadTracker()
>
>Index: hxttranslationcentre.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxttranslationcentre.cpp,v
>retrieving revision 1.4
>diff -u -r1.4 hxttranslationcentre.cpp
>--- hxttranslationcentre.cpp 5 Sep 2005 12:51:12 -0000 1.4
>+++ hxttranslationcentre.cpp 26 Sep 2008 19:14:36 -0000
>@@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CTranslationInfo::~CTranslationInfo()
>
>
>Index: hxtwritermanager.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logsystem/hxtwritermanager.cpp,v
>retrieving revision 1.5.2.1
>diff -u -r1.5.2.1 hxtwritermanager.cpp
>--- hxtwritermanager.cpp 17 Jan 2007 19:57:45 -0000 1.5.2.1
>+++ hxtwritermanager.cpp 26 Sep 2008 19:15:00 -0000
>@@ -59,7 +59,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _RVCT_
>
>
>Index: hxsbuffer.cpp
>===================================================================
>RCS file: /cvsroot/common/container/hxsbuffer.cpp,v
>retrieving revision 1.3
>diff -u -r1.3 hxsbuffer.cpp
>--- hxsbuffer.cpp 9 Jul 2004 18:21:35 -0000 1.3
>+++ hxsbuffer.cpp 26 Sep 2008 19:09:45 -0000
>@@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXStaticBuffer::CHXStaticBuffer(void) :
>
>
>Index: hxtdirconv.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logcommon/hxtdirconv.cpp,v
>retrieving revision 1.2
>diff -u -r1.2 hxtdirconv.cpp
>--- hxtdirconv.cpp 16 Mar 2005 02:04:07 -0000 1.2
>+++ hxtdirconv.cpp 26 Sep 2008 19:06:40 -0000
>@@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>ndex: hlxxmlparser.cpp
>===================================================================
>RCS file: /cvsroot/common/log/logcommon/hlxxmlparser.cpp,v
>retrieving revision 1.3
>diff -u -r1.3 hlxxmlparser.cpp
>--- hlxxmlparser.cpp 26 Apr 2005 22:47:35 -0000 1.3
>+++ hlxxmlparser.cpp 26 Sep 2008 19:04:55 -0000
>@@ -51,7 +51,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>Index: audplin.cpp
>===================================================================
>RCS file: /cvsroot/datatype/group/audio/audplin.cpp,v
>retrieving revision 1.7.38.1
>diff -u -r1.7.38.1 audplin.cpp
>--- audplin.cpp 19 Jul 2006 13:37:46 -0000 1.7.38.1
>+++ audplin.cpp 26 Sep 2008 18:33:35 -0000
>@@ -102,7 +102,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
>-static char HX_THIS_FILE[] = __FILE__;
>+static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> HX_RESULT (STDAPICALLTYPE * const AudioPluginFactory::m_fpEntryArray[])(IUnknown**)=
From xiaolin.lliu at nokia.com Mon Sep 29 13:22:48 2008
From: xiaolin.lliu at nokia.com (xiaolin.lliu@nokia.com)
Date: Mon Sep 29 11:37:30 2008
Subject: [datatype-dev] CN: [common][datatype]: armv5 abiv2 build error
Message-ID:
Checked in to cays210
> _____________________________________________
>
>
>
>
> Modified by: xiaolin.lliu@nokia.com
>
> Reviewed by:
>
> Date: 09/26/2008
>
> Project: SymbianMmf_rel
>
> ErrorId: Case ID:
>
> Synopsis: Iniatialized writable data causes armv5 abvi2 build error.
>
>
> Files modified:
> datatype/null/renderer/nullrend.cpp
> common/include/hxtypes.h,
> common/log/logobserverfile/hxtlogobserver.cpp
> common/log/logsystem/hxtdeliverymanager.cpp
> common/log/logsystem/hxtlogfaenumerator.cpp
> common/log/logsystem/hxtlogfilter.cpp
> common/log/logsystem/hxtlogqueue.cpp
> common/log/logsystem/hxtlogsystem.cpp,
> common/log/logsystem/hxtthreadtracker.cpp
> common/log/logsystem/hxttranslationcentre.cpp
> common/log/logsystem/hxtwritermanager.cpp
> common/container/hxsbuffer.cpp
> common/log/logcommon/hxtdirconv.cpp
> common/log/logcommon/hlxxmlparser.cpp
> datatype/group/audio/audplin.cpp
>
> Files added:
> None.
>
> Cvs diff:
>
> Index: nullrend.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/null/renderer/nullrend.cpp,v
> retrieving revision 1.10.2.1
> diff -u -r1.10.2.1 nullrend.cpp
> --- nullrend.cpp 27 Feb 2006 15:52:33 -0000 1.10.2.1
> +++ nullrend.cpp 26 Sep 2008 19:25:21 -0000
> @@ -78,7 +78,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
> Index: hxtypes.h
> ===================================================================
> RCS file: /cvsroot/common/include/hxtypes.h,v
> retrieving revision 1.31.2.1
> diff -u -r1.31.2.1 hxtypes.h
> --- hxtypes.h 19 Jul 2006 13:34:01 -0000 1.31.2.1
> +++ hxtypes.h 26 Sep 2008 18:36:58 -0000
> @@ -766,7 +766,7 @@
> */
> #if defined (INITGUID)
> #define DEFINE_CONSTANT_STRING(name, string) \
> - const char *name = string;
> + const char * const name = string;
> #else
> #define DEFINE_CONSTANT_STRING(name, string) \
> extern const char* name;
>
>
>
> Index: hxtlogobserver.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logobserverfile/hxtlogobserver.cpp,v
> retrieving revision 1.13.2.2
> diff -u -r1.13.2.2 hxtlogobserver.cpp
> --- hxtlogobserver.cpp 27 Sep 2007 19:20:07 -0000 1.13.2.2
> +++ hxtlogobserver.cpp 26 Sep 2008 19:21:43 -0000
> @@ -68,7 +68,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #if defined(HELIX_FEATURE_CLIENT)
>
>
> Index: hxtdeliverymanager.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtdeliverymanager.cpp,v
> retrieving revision 1.5
> diff -u -r1.5 hxtdeliverymanager.cpp
> --- hxtdeliverymanager.cpp 26 Apr 2005 23:02:37 -0000 1.5
> +++ hxtdeliverymanager.cpp 26 Sep 2008 19:12:33 -0000
> @@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
> Index: hxtlogfaenumerator.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogfaenumerator.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtlogfaenumerator.cpp
> --- hxtlogfaenumerator.cpp 16 Mar 2005 02:22:45 -0000 1.2
> +++ hxtlogfaenumerator.cpp 26 Sep 2008 19:12:42 -0000
> @@ -45,7 +45,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> BEGIN_INTERFACE_LIST_NOCREATE( CHXTFuncAreaEnumerator )
>
>
> Index: hxtlogfilter.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogfilter.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtlogfilter.cpp
> --- hxtlogfilter.cpp 16 Mar 2005 02:22:45 -0000 1.2
> +++ hxtlogfilter.cpp 26 Sep 2008 19:12:53 -0000
> @@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _WIN32
>
>
> Index: hxtlogqueue.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogqueue.cpp,v
> retrieving revision 1.4
> diff -u -r1.4 hxtlogqueue.cpp
> --- hxtlogqueue.cpp 15 Jun 2005 16:30:31 -0000 1.4
> +++ hxtlogqueue.cpp 26 Sep 2008 19:13:08 -0000
> @@ -60,7 +60,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CLogMsgBase::CLogMsgBase()
>
>
> Index: hxtlogsystem.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtlogsystem.cpp,v
> retrieving revision 1.7.2.1
> diff -u -r1.7.2.1 hxtlogsystem.cpp
> --- hxtlogsystem.cpp 19 Jul 2006 13:34:37 -0000 1.7.2.1
> +++ hxtlogsystem.cpp 26 Sep 2008 19:13:34 -0000
> @@ -57,7 +57,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
>
> Index: hxtthreadtracker.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtthreadtracker.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hxtthreadtracker.cpp
> --- hxtthreadtracker.cpp 5 Sep 2005 12:51:12 -0000 1.3
> +++ hxtthreadtracker.cpp 26 Sep 2008 19:13:57 -0000
> @@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXTThreadTracker::CHXTThreadTracker()
>
> Index: hxttranslationcentre.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxttranslationcentre.cpp,v
> retrieving revision 1.4
> diff -u -r1.4 hxttranslationcentre.cpp
> --- hxttranslationcentre.cpp 5 Sep 2005 12:51:12 -0000 1.4
> +++ hxttranslationcentre.cpp 26 Sep 2008 19:14:36 -0000
> @@ -53,7 +53,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CTranslationInfo::~CTranslationInfo()
>
>
> Index: hxtwritermanager.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logsystem/hxtwritermanager.cpp,v
> retrieving revision 1.5.2.1
> diff -u -r1.5.2.1 hxtwritermanager.cpp
> --- hxtwritermanager.cpp 17 Jan 2007 19:57:45 -0000 1.5.2.1
> +++ hxtwritermanager.cpp 26 Sep 2008 19:15:00 -0000
> @@ -59,7 +59,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> #ifdef _RVCT_
>
>
> Index: hxsbuffer.cpp
> ===================================================================
> RCS file: /cvsroot/common/container/hxsbuffer.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hxsbuffer.cpp
> --- hxsbuffer.cpp 9 Jul 2004 18:21:35 -0000 1.3
> +++ hxsbuffer.cpp 26 Sep 2008 19:09:45 -0000
> @@ -63,7 +63,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> CHXStaticBuffer::CHXStaticBuffer(void) :
>
>
> Index: hxtdirconv.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logcommon/hxtdirconv.cpp,v
> retrieving revision 1.2
> diff -u -r1.2 hxtdirconv.cpp
> --- hxtdirconv.cpp 16 Mar 2005 02:04:07 -0000 1.2
> +++ hxtdirconv.cpp 26 Sep 2008 19:06:40 -0000
> @@ -42,7 +42,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
>
> ndex: hlxxmlparser.cpp
> ===================================================================
> RCS file: /cvsroot/common/log/logcommon/hlxxmlparser.cpp,v
> retrieving revision 1.3
> diff -u -r1.3 hlxxmlparser.cpp
> --- hlxxmlparser.cpp 26 Apr 2005 22:47:35 -0000 1.3
> +++ hlxxmlparser.cpp 26 Sep 2008 19:04:55 -0000
> @@ -51,7 +51,7 @@
> #include "hxheap.h"
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> Index: audplin.cpp
> ===================================================================
> RCS file: /cvsroot/datatype/group/audio/audplin.cpp,v
> retrieving revision 1.7.38.1
> diff -u -r1.7.38.1 audplin.cpp
> --- audplin.cpp 19 Jul 2006 13:37:46 -0000 1.7.38.1
> +++ audplin.cpp 26 Sep 2008 18:33:35 -0000
> @@ -102,7 +102,7 @@
>
> #ifdef _DEBUG
> #undef HX_THIS_FILE
> -static char HX_THIS_FILE[] = __FILE__;
> +static const char HX_THIS_FILE[] = __FILE__;
> #endif
>
> HX_RESULT (STDAPICALLTYPE * const
> AudioPluginFactory::m_fpEntryArray[])(IUnknown**)=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20080929/99948e27/attachment-0001.html
From jrathore at real.com Mon Sep 29 15:31:05 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Mon Sep 29 13:45:32 2008
Subject: [datatype-dev] Adding divx extension in AVI file format
In-Reply-To: <00b701c91fde$56dbb590$049320b0$@com>
References: <006201c91f55$b17f4900$f58016ac@corp.real.com>
<00b701c91fde$56dbb590$049320b0$@com>
Message-ID: <00ce01c92283$10538920$f58016ac@corp.real.com>
Hi Eric,
Thanks for the review.
In order to verify that .avi file format plugin skips over any .divx chunks
that it does not understand, I looked at all those places where
GetChunkType() was being used. It is either used in a 'if' conditional
statement or a 'switch' statement. In both cases if the condition is not
true or if there is no case match respectively then no unknown chunk type
error is reported. For example in a switch statement in
CAVIFileFormat::RIFFReadDone() there is no default case, reporting an
unknown type chunk.
switch (m_pGeneralReader->GetChunkType())
{
case AVI_STRH_CHUNK:
{
..
}
break;
case AVI_STRF_CHUNK:
{
...
}
break;
case AVI_STRD_CHUNK:
{
...
}
break;
}
Hope this is sufficient.
Thanks,
Jyotsana
-----Original Message-----
From: Eric Hyche [mailto:ehyche@real.com]
Sent: Friday, September 26, 2008 6:47 AM
To: 'Jyotsana Rathore'; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] Adding divx extension in AVI file format
Jyotsana,
My understanding is that the .divx format is also a RIFF
format similar to .avi but that the set of .divx chunk types
is a superset of the .avi chunk types. Have we verified
that the .avi file format plugin skips over any .divx chunks
it does not understand (as opposed to erroring out when
it encounters an unknown chunk type)?
If so, then this change looks good.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On
>Behalf Of Jyotsana Rathore
>Sent: Thursday, September 25, 2008 5:29 PM
>To: datatype-dev@helixcommunity.org
>Subject: [datatype-dev] Adding divx extension in AVI file format
>
>Modified by: jrathore@real.com
>
>Date: 09/25/08
>
>Project: Helix DNA Client
>
>
>
>Synopsis: Adding divx extension in AVI file format
>
>
>
>Overview: Adding the divx extension in avi file format without which
HXR_NO_RENDERER error is
>returned.
>
>
>
>Files Added: None
>
>
>
>Files Modified:
>
>aacff.cpp (/datatype/avi/fileformat/aviffpln.cpp)
>
>
>
>Image Size and Heap Use impact (Client -Only): None
>
>
>
>Platforms and Profiles Affected:
>
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>
>
>Platforms and Profiles Build and Functionality Verified:
>
>Platform: win32-i386-vc7
>
>Profile: helix-client-all-defines
>
>target(s): splay
>
>
>
>Branch: hxclient_3_1_0_atlas, HEAD
>
>
>
>Copyright assignment: I am a RealNetworks employee.
>
>
>
>Files Attached: aviffpln.diff
>
>
>
>-Jyotsana
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.