From Arnel.Periquet at nokia.com  Fri Jun  1 08:49:47 2007
From: Arnel.Periquet at nokia.com (Arnel.Periquet@nokia.com)
Date: Fri Jun  1 09:07:16 2007
Subject: [Helix-client-dev] GoingToUnderflow() question
Message-ID: 

Anybody,

I have a question about the use of "m_ulMinBlocksTobeQueuedAtStart"
versus m_ulMinBlocksTobeQueued" in the method
CHXAudioSession::GoingToUnderflow() (client\audiosvc\hxaudses.cpp).
Should the latter be used instead of the former? 

I'm working on an error where rebuffering is not triggered because
GoingToUnderflow() doesn't detect audio ran out of data to play. (See
scenario description below). 

The function basically does "return (nBlocksRemaining <
m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, always
returns FALSE because "nBlocksRemaining == 2" and
"m_ulMinBlocksTobeQueuedAtStart==2". This is caused by
"nBlocksRemaining" being derived from "currentTime" in the audio device
and the device implementation in our case has a little bit (95-140ms) of
data left in it when it stops playing. That little bit is just enough to
cause the GoingToUnderflow() test to fail. As an alternative, I tried
increasing m_ulMinimumStartupPushdown to 150ms and the problem goes
away.

Thanks for your help,
Arnel



S60 Progressive Download

1. Play an audio-only clip using the S60 Browser to trigger Helix in
progressive download mode.
Result
(a) S60 download manager starts a download of the file.
(b) Helix TLC (i.e., S60 MMF plugin) is launched.
(c) Helix loads the S60 Progressive Download filesystem.
(d) Helix starts playing the clip.

2. Pause the download on the S60 download manager.
Result
(a) download of the file is paused.
(b) Helix continues to play out what is in the file
(c) Helix runs out of file data and the filesystem continues to
RetryRead().
(d) Helix runs out of audio buffer to play.
(e) GoingToUnderflow() is continually called to check if we need to
rebuffer, but it always returns FALSE.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070601/e1af3cf9/attachment.html
From gwright at real.com  Fri Jun  1 09:53:42 2007
From: gwright at real.com (Greg Wright)
Date: Fri Jun  1 10:09:09 2007
Subject: [Helix-client-dev] GoingToUnderflow() question
In-Reply-To: 
References: 
Message-ID: <46604F16.8030806@real.com>

Arnel.Periquet@nokia.com wrote:
> Anybody,
> 
> I have a question about the use of "m_ulMinBlocksTobeQueuedAtStart"
> versus m_ulMinBlocksTobeQueued" in the method
> CHXAudioSession::GoingToUnderflow() (client\audiosvc\hxaudses.cpp).
> Should the latter be used instead of the former? 
> 
> I'm working on an error where rebuffering is not triggered because
> GoingToUnderflow() doesn't detect audio ran out of data to play. (See
> scenario description below). 
> 
> The function basically does "return (nBlocksRemaining <
> m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, always
> returns FALSE because "nBlocksRemaining == 2" and
> "m_ulMinBlocksTobeQueuedAtStart==2". This is caused by
> "nBlocksRemaining" being derived from "currentTime" in the audio device
> and the device implementation in our case has a little bit (95-140ms) of
> data left in it when it stops playing. That little bit is just enough to
> cause the GoingToUnderflow() test to fail. As an alternative, I tried
> increasing m_ulMinimumStartupPushdown to 150ms and the problem goes
> away.

Well, that would certainly be the problem. It is very important that the
audio device report a very accurate time. If your audio device is indeed
off by 1 or 2 block-sizes (in milliseconds) then you are right, it will
never try to rebuffer. The fix you are doing is the correct one in your
case, just increase the number of blocks required at start. Or, you could
increase the block size. The real fix is to not have any 'extra' data in
your device, but I know how hard some of those devices can be to work
with.

I would also guess that your extra data in the device might lead to
some A/V sync issues. However, 100ms is hard for a lot of people to
see. That is, if you are playing video content and not just audio.

--greg.


> 
> Thanks for your help,
> Arnel
> 
> 
> 
> S60 Progressive Download
> 
> 1. Play an audio-only clip using the S60 Browser to trigger Helix in
> progressive download mode.
> Result
> (a) S60 download manager starts a download of the file.
> (b) Helix TLC (i.e., S60 MMF plugin) is launched.
> (c) Helix loads the S60 Progressive Download filesystem.
> (d) Helix starts playing the clip.
> 
> 2. Pause the download on the S60 download manager.
> Result
> (a) download of the file is paused.
> (b) Helix continues to play out what is in the file
> (c) Helix runs out of file data and the filesystem continues to
> RetryRead().
> (d) Helix runs out of audio buffer to play.
> (e) GoingToUnderflow() is continually called to check if we need to
> rebuffer, but it always returns FALSE.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev


From milko at real.com  Fri Jun  1 10:19:50 2007
From: milko at real.com (Milko Boic)
Date: Fri Jun  1 10:35:21 2007
Subject: [Helix-client-dev] GoingToUnderflow() question
In-Reply-To: 
References: 
Message-ID: <6.2.1.2.2.20070601095125.06827b90@mailone.real.com>


At 08:49 AM 6/1/2007, Arnel.Periquet@nokia.com wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C7A464.A93A95D3"
>
>Anybody,
>
>I have a question about the use of "m_ulMinBlocksTobeQueuedAtStart" versus 
>m_ulMinBlocksTobeQueued" in the method CHXAudioSession::GoingToUnderflow() 
>(client\audiosvc\hxaudses.cpp). Should the latter be used instead of the 
>former?

No. In cayenne, naming of the variables is confusing.  The code however is 
correct.

Here is the explanation of the pushdown parameters in Atlas and how it 
relates to cayenne:

Here is the explanation for treatment of audio service buffer parameters on 
Atlas platform:

Here is the information on audio pushdown control variables and preferences:
m_ulMinBlocksToBeQueued         (new in meaning but not in name)
m_ulMinBlocksToBeQueuedAtStart  (used to be same as m_ulMinBlocksToBeQueued)
m_ulTargetBlocksToBeQueued      (used to be confusingly named 
m_ulMinBlocksToBeQueued)

The new meaning of theses variables is as follows:
m_ulMinBlocksToBeQueued - the minimum number of audio blocks that must be 
present in audio device at any given time or time-line will halt (rebuffer)
m_ulMinBlocksToBeQueuedAtStart - the minimum number of audio blocks that 
must be present in audio device for playback to start
m_ulTargetBlocksToBeQueued - number of audio blocks in audio device that is 
desirable to build up

*** Note on Cayenne ****
In cayenne, the meaning does not quite follow the variable naming:
m_ulMinBlocksToBeQueued   - number of audio blocks in audio device that is 
desirable to build up
m_ulMinBlocksToBeQueuedAtStart  - the minimum number of audio blocks that 
must be present in audio device at any given time or time-line will halt 
(rebuffer)
*** End Note on Cayenne ***

These values are computed based on the following pushdown setting in 
milliseconds:
MinimumPushdown                 - normally set to 100ms
MimimumStartupPushdown          - normally set to 150ms
TargetPushdown                  - normally set to >=200ms (1000ms on non 
MIN_HEAP builds)

The following preferences can override the pushdown values:
"MinimumAudioPushdown"
"MinimumAudioStartupPushdown"
"TargetAudioPushdown"

HXBOOL CHXAudioSession::GoingToUnderflow()
{
     HXBOOL bRetVal          = FALSE;
     UINT32 nBlocksRemaining = 0;
     if( !m_bFakeAudioTimeline && m_pAudioDev && !m_bPaused && 
!m_bStoppedDuringPause)
     {
         nBlocksRemaining = GetBlocksRemainingToPlay();

         HXLOGL4(HXLOG_ADEV, "CHXAudioSession[%p]::GoingToUnderflow() 
HaveBlocks=%lu MiNeeded=%lu", this, nBlocksRemaining, m_ulMinBlocksTobeQueued);

         bRetVal = (nBlocksRemaining < m_ulMinBlocksTobeQueued) ? TRUE : FALSE;
         if( bRetVal )
         {
             HXLOGL2( "IsRebufferRequired: BlockRemaining: 
%d  BlockToStart: %lu",
                      nBlocksRemaining,
                      m_ulMinBlocksTobeQueued
                      );
         }
     }
     return bRetVal;
}


>I'm working on an error where rebuffering is not triggered because 
>GoingToUnderflow() doesn't detect audio ran out of data to play. (See 
>scenario description below).
>
>The function basically does "return (nBlocksRemaining < 
>m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, always returns 
>FALSE because "nBlocksRemaining == 2" and 
>"m_ulMinBlocksTobeQueuedAtStart==2". This is caused by "nBlocksRemaining" 
>being derived from "currentTime" in the audio device and the device 
>implementation in our case has a little bit (95-140ms) of data left in it 
>when it stops playing. That little bit is just enough to cause the 
>GoingToUnderflow() test to fail. As an alternative, I tried increasing 
>m_ulMinimumStartupPushdown to 150ms and the problem goes away.

OK - I would call that an audio device problem.
To fix properly (compensate), audio device would need to be implement 
IHXAudioPushdown2 interface and the be queried for by audio session for the 
interface and if supported obtain audio devices min. audio pushdown 
required by the audio device (GetAudioPushdown).  Audio session would then 
configure session level audio pushdown making sure it is above the queried 
value.

Changing a #define for symbian is just as effective - and much quicker to do.

Milko


>Thanks for your help,
>Arnel
>
>
>S60 Progressive Download
>
>1. Play an audio-only clip using the S60 Browser to trigger Helix in 
>progressive download mode.
>Result
>(a) S60 download manager starts a download of the file.
>(b) Helix TLC (i.e., S60 MMF plugin) is launched.
>(c) Helix loads the S60 Progressive Download filesystem.
>(d) Helix starts playing the clip.
>
>2. Pause the download on the S60 download manager.
>Result
>(a) download of the file is paused.
>(b) Helix continues to play out what is in the file
>(c) Helix runs out of file data and the filesystem continues to RetryRead().
>(d) Helix runs out of audio buffer to play.
>(e) GoingToUnderflow() is continually called to check if we need to 
>rebuffer, but it always returns FALSE.
>_______________________________________________
>Helix-client-dev mailing list
>Helix-client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070601/b0a0758b/attachment-0001.html
From milko at real.com  Mon Jun  4 12:49:39 2007
From: milko at real.com (Milko Boic)
Date: Mon Jun  4 13:04:26 2007
Subject: [Helix-client-dev] CR-Client: Fullscreen repaint on mac
Message-ID: <6.2.1.2.2.20070604124812.07462f68@mailone.real.com>

Modified by: milko@real.com
Date: 06:04:07
Project: Atlas port to Mac

Synopsis: Fullscreen repaint on mac

Overview:
The change enables repaint of full-screen surroundings on Mac.

Full Screen is comprised of the full-screen black bacground with a
top level site positioned somewhere on the background possibly containing
a tree of child sites.  The position of the top-level site is controlled
by the application (GUI code).
The repaint of the background needs to occur in areas not occupied by top
level site whenever the position or size of the top level site changes.

Full screen mode has also been modified to create and destroy the full-screen
window on every entry/exit as OS related repaint problems have been observed
otherwise.  This also simplifies the maintenance of full-screen state.

Minor clean-up of mac surface port management.

Files Modified:
/video/sitelib/basesite.cpp
/video/sitelib/platform/mac/maceventgrabber.cpp
/video/sitelib/platform/mac/macsite.cpp
/video/sitelib/platform/mac/macsurf.cpp
/video/sitelib/pub/platform/mac/macsite.h

Image Size and Heap Use impact (Client -Only):
Negligible

Platforms and Profiles Affected:
All

Distribution Libraries Affected:
none

Distribution library impact and planned action:
n/a

Platforms and Profiles Build Verified:
system id: macos-gcc4-xcode22,
target: LitePlayer
profile: helix-client-playerx
branch: playerx
Options: nodll

Windows will be verified after check-in.

Platforms and Profiles Functionality verified:
OS-X

Windows will be verified after check-in.

Branches:
HEAD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sitelib_diffs.txt
Type: application/octet-stream
Size: 16035 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070604/83ba89e1/sitelib_diffs.obj
-------------- next part --------------

From dsadowsk at adobe.com  Tue Jun  5 11:08:01 2007
From: dsadowsk at adobe.com (Dan Sadowski)
Date: Tue Jun  5 11:20:45 2007
Subject: [Helix-client-dev] Tools, OSX and Unicode
Message-ID: 

Several years ago at Macromedia, we used the COM interface from the old
RealPlayer SDK to develop a Director Xtra to support playback of RealMedia
files on windows and macintosh. Now we are part of Adobe, and find that we
need to update our playback module. With all the MacOS X changes, our old
CFM macintosh code no longer works at all, and I am trying to update it to
be MachO based and work with the current RealPlayer application and Helix
SDK. Also we are trying to update both the mac and win Xtras to work
properly with Unicode file names. I've been experimenting with the files
from the helix community site and I have three questions.

I reviewed the Helix Documentation an it mentions some python based tools to
help deal with name changes between the old RealPlayer SDK and the current
Helix SDK. I figured these tools would be good to review to see what changes
are required. But the current structure of the source code tree is different
than what is described in the documentation and I don't see those tools
anywhere. Are these tools available and I have just missed them? Or is there
just a document that describes the name/interface mapping?

I am setup with a CVS account, and installed the required version of Python
and the Ribosome build system is working OK. The "quickstart" instructions
worked just fine in getting me started. However, I am unable to get a
completely successful MacOS build. Some of the projects setup and build, but
others get errors due to header file conflicts. Before I start fiddling with
the source i'd like to know if it is possible to get a working mac build on
a helix client/player test application. Maybe I just don't have the proper
branch or settings? Looking at the "branches" page I am not entirely sure
what branch I should use to make an OSX build. If it is possible to get a
clean macintosh build of a player test app, can some one let me know what
settings I should select from the build menu to get it to work?

In volume 1 of the documentation, it mentions the importance of Unicode
support for file object plugins. However, when I look at the details in
volume 2 for various file methods, they all seem to work "char *" variables
for file names and paths. Are these UTF8 format names? Or are unicode names
supported in some other way?

Thanks for your attention,

Dan Sadowski
Senior Computer Scientist
Adobe Systems, Inc.


From bobclark at real.com  Tue Jun  5 11:55:14 2007
From: bobclark at real.com (Bob Clark)
Date: Tue Jun  5 12:10:08 2007
Subject: [Helix-client-dev] Tools, OSX and Unicode
In-Reply-To: 
References: 
Message-ID: 

Hi Dan.

> I am setup with a CVS account, and installed the required version  
> of Python
> and the Ribosome build system is working OK. The "quickstart"  
> instructions
> worked just fine in getting me started. However, I am unable to get a
> completely successful MacOS build. Some of the projects setup and  
> build, but
> others get errors due to header file conflicts. Before I start  
> fiddling with
> the source i'd like to know if it is possible to get a working mac  
> build on
> a helix client/player test application. Maybe I just don't have the  
> proper
> branch or settings? Looking at the "branches" page I am not  
> entirely sure
> what branch I should use to make an OSX build. If it is possible to  
> get a
> clean macintosh build of a player test app, can some one let me  
> know what
> settings I should select from the build menu to get it to work?

Right now, the RealPlayer work I've been doing is on the  
hxclient_1_5_0_cayenne branch, although Milko has been doing work in  
Atlas.

I'm not certain whether splay is building with 150Cay, but that's  
where I'd start.

Use SYSTEM_ID macos-gcc4-xcode22, bif hxclient_1_5_0_cayenne, profile  
helix-client-all-defines, and target splay. (Or splay_nodist or even  
splay_mp3 if splay doesn't build.)

You will need to run splay from the command line, something like:
$ ./splay.app/Contents/MacOS/splay foo.rm


You're correct that CFM builds no longer work -- the Mac builds are  
building Mach-O now. The macos-gcc4-xcode22 configuration is going to  
set up a confusing mishmash of #defines. This mess is largely  
historical, but since you worked with this long ago here's what  
#defines matter in 2007, if I'm remembering correctly:

These are obsolete and are NOT defined: _MACINTOSH, _MAC_CFM,  
__MWERKS__ (when referring to Mac), _CARBON. These mostly refer to OS  
9/CFM Mac code which has been turned off as we moved to OS X/Mach-O.

The #defines that ARE defined: _MAC_UNIX (sort of the catch-all for  
Mac code nowadays), _MAC_MACHO. Also _UNIX is defined now.

We've got plenty of cleanup on our plate, but hopefully with the  
parameters above you'll be able to get something functional and  
(again, hopefully) knowing about the #define unpleasantness will help  
you navigate these hazards. :-)

--Bob

-- 
Bob Clark
Lead Software Development Engineer
RealPlayer Mac/Unix
RealNetworks, Inc.


On Jun 5, 2007, at 11:08 AM, Dan Sadowski wrote:

> Several years ago at Macromedia, we used the COM interface from the  
> old
> RealPlayer SDK to develop a Director Xtra to support playback of  
> RealMedia
> files on windows and macintosh. Now we are part of Adobe, and find  
> that we
> need to update our playback module. With all the MacOS X changes,  
> our old
> CFM macintosh code no longer works at all, and I am trying to  
> update it to
> be MachO based and work with the current RealPlayer application and  
> Helix
> SDK. Also we are trying to update both the mac and win Xtras to work
> properly with Unicode file names. I've been experimenting with the  
> files
> from the helix community site and I have three questions.
>
> I reviewed the Helix Documentation an it mentions some python based  
> tools to
> help deal with name changes between the old RealPlayer SDK and the  
> current
> Helix SDK. I figured these tools would be good to review to see  
> what changes
> are required. But the current structure of the source code tree is  
> different
> than what is described in the documentation and I don't see those  
> tools
> anywhere. Are these tools available and I have just missed them? Or  
> is there
> just a document that describes the name/interface mapping?
>
> I am setup with a CVS account, and installed the required version  
> of Python
> and the Ribosome build system is working OK. The "quickstart"  
> instructions
> worked just fine in getting me started. However, I am unable to get a
> completely successful MacOS build. Some of the projects setup and  
> build, but
> others get errors due to header file conflicts. Before I start  
> fiddling with
> the source i'd like to know if it is possible to get a working mac  
> build on
> a helix client/player test application. Maybe I just don't have the  
> proper
> branch or settings? Looking at the "branches" page I am not  
> entirely sure
> what branch I should use to make an OSX build. If it is possible to  
> get a
> clean macintosh build of a player test app, can some one let me  
> know what
> settings I should select from the build menu to get it to work?
>
> In volume 1 of the documentation, it mentions the importance of  
> Unicode
> support for file object plugins. However, when I look at the  
> details in
> volume 2 for various file methods, they all seem to work "char *"  
> variables
> for file names and paths. Are these UTF8 format names? Or are  
> unicode names
> supported in some other way?
>
> Thanks for your attention,
>
> Dan Sadowski
> Senior Computer Scientist
> Adobe Systems, Inc.
>
>
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev



From milko at real.com  Tue Jun  5 12:19:01 2007
From: milko at real.com (Milko Boic)
Date: Tue Jun  5 12:33:29 2007
Subject: [Helix-client-dev] CN-Client: Fullscreen repaint on mac
Message-ID: <6.2.1.2.2.20070605121850.0726b348@mailone.real.com>

Modified by: milko@real.com
Date: 06:04:07
Project: Atlas port to Mac

Synopsis: Fullscreen repaint on mac

Overview:
The change enables repaint of full-screen surroundings on Mac.

Full Screen is comprised of the full-screen black bacground with a
top level site positioned somewhere on the background possibly containing
a tree of child sites.  The position of the top-level site is controlled
by the application (GUI code).
The repaint of the background needs to occur in areas not occupied by top
level site whenever the position or size of the top level site changes.

Full screen mode has also been modified to create and destroy the full-screen
window on every entry/exit as OS related repaint problems have been observed
otherwise.  This also simplifies the maintenance of full-screen state.

Minor clean-up of mac surface port management.

Files Modified:
/video/sitelib/basesite.cpp
/video/sitelib/platform/mac/maceventgrabber.cpp
/video/sitelib/platform/mac/macsite.cpp
/video/sitelib/platform/mac/macsurf.cpp
/video/sitelib/pub/platform/mac/macsite.h

Image Size and Heap Use impact (Client -Only):
Negligible

Platforms and Profiles Affected:
All

Distribution Libraries Affected:
none

Distribution library impact and planned action:
n/a

Platforms and Profiles Build Verified:
system id: macos-gcc4-xcode22,
target: LitePlayer
profile: helix-client-playerx
branch: playerx
Options: nodll

Windows will be verified after check-in.

Platforms and Profiles Functionality verified:
OS-X

Windows will be verified after check-in.

Branches:
HEAD


From ping at real.com  Tue Jun  5 12:38:37 2007
From: ping at real.com (Henry Ping)
Date: Tue Jun  5 12:53:03 2007
Subject: [Helix-client-dev] Tools, OSX and Unicode
In-Reply-To: 
Message-ID: 

Dan,

Welcome to the Helix community. I will try to answer your remaining 2
questions:

1. Tools
We have written scripts in Python to covert old RMA code to Helix(Kudo's to
Eric Hyche). They are in common/build/tools, there is readme.txt to explain
how they work. 

You can check out common/build manually from the command line:
"cvs -d :ext:[username]@cvs.helixcommunity.org:/cvsroot/common co build"

Here is a link that briefly explain the new source tree in Helix:
https://common.helixcommunity.org/2002/devdocs/sourcecode

Most name changes are simply replacing "RMA" with "HX", e.g.:
IRMAxxx -> IHXxxx
CRMAxxx -> CHXxxx

However, the CLSID/IID are kept the same. 

2. Unicode
UTF8 is the choice. Though not all the modules accepting char* parameter
support UTF8, this is what we are moving towards to.

Henry  

> -----Original Message-----
> From: helix-client-dev-bounces@helixcommunity.org 
> [mailto:helix-client-dev-bounces@helixcommunity.org] On 
> Behalf Of Dan Sadowski
> Sent: Tuesday, June 05, 2007 11:08 AM Ping
> To: helix-client-dev@helixcommunity.org
> Subject: [Helix-client-dev] Tools, OSX and Unicode
> 
> Several years ago at Macromedia, we used the COM interface 
> from the old RealPlayer SDK to develop a Director Xtra to 
> support playback of RealMedia files on windows and macintosh. 
> Now we are part of Adobe, and find that we need to update our 
> playback module. With all the MacOS X changes, our old CFM 
> macintosh code no longer works at all, and I am trying to 
> update it to be MachO based and work with the current 
> RealPlayer application and Helix SDK. Also we are trying to 
> update both the mac and win Xtras to work properly with 
> Unicode file names. I've been experimenting with the files 
> from the helix community site and I have three questions.
> 
> I reviewed the Helix Documentation an it mentions some python 
> based tools to help deal with name changes between the old 
> RealPlayer SDK and the current Helix SDK. I figured these 
> tools would be good to review to see what changes are 
> required. But the current structure of the source code tree 
> is different than what is described in the documentation and 
> I don't see those tools anywhere. Are these tools available 
> and I have just missed them? Or is there just a document that 
> describes the name/interface mapping?
> 
> I am setup with a CVS account, and installed the required 
> version of Python and the Ribosome build system is working 
> OK. The "quickstart" instructions worked just fine in getting 
> me started. However, I am unable to get a completely 
> successful MacOS build. Some of the projects setup and build, 
> but others get errors due to header file conflicts. Before I 
> start fiddling with the source i'd like to know if it is 
> possible to get a working mac build on a helix client/player 
> test application. Maybe I just don't have the proper branch 
> or settings? Looking at the "branches" page I am not entirely 
> sure what branch I should use to make an OSX build. If it is 
> possible to get a clean macintosh build of a player test app, 
> can some one let me know what settings I should select from 
> the build menu to get it to work?
> 
> In volume 1 of the documentation, it mentions the importance 
> of Unicode support for file object plugins. However, when I 
> look at the details in volume 2 for various file methods, 
> they all seem to work "char *" variables for file names and 
> paths. Are these UTF8 format names? Or are unicode names 
> supported in some other way?
> 
> Thanks for your attention,
> 
> Dan Sadowski
> Senior Computer Scientist
> Adobe Systems, Inc.
> 
> 
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev


From rmathew at real.com  Wed Jun  6 16:12:39 2007
From: rmathew at real.com (Rishi Mathew)
Date: Wed Jun  6 16:26:47 2007
Subject: [Helix-client-dev] Re: How Can I get the Helix Source Codes
In-Reply-To: <200706040846.l548kYFQ015694@www01.internal.helixcommunity. org>
References: <200706040846.l548kYFQ015694@www01.internal.helixcommunity.org>
Message-ID: <6.2.5.6.2.20070606161046.0624a5c0@real.com>

Henry,

Please always cc a mailing list.

You should be using the "hxclient_1_5_0_cayenne" branch. Please build 
this in a new folder. Also, please verify if you actually have X11 
support. If you do not, then you should turn off XWindows support.

Thanks,
Rishi.

At 01:46 AM 6/4/2007, Henry wrote:
>I use Ribosome to get the helix source codes,but there is something wrong,
>Build System Menu
>Ribosome v2.4.6
>-> Current Directory: /home/hlzhang
>[0] Set BIF branch (hxclient_2_0_3_cayenne)
>[1] Set Target(s) (client)
>[2] Set Profile (helix-client-all-defines)
>[3] run: build
>[4] Toggle make depend & makefiles (-e -n)
>[5] Toggle release (-trelease)
>[6] Toggle 'make clean'  (-c)
>[7] Toggle clobber (Dangerous!) (-C)
>[8] Toggle halt-on-error (-p green)
>[9] Toggle verbose mode (-v)
>[10] Toggle static build (-tnodll)
>[11] Checkout source for selected target now
>[12] Set Tag/Branch/Timestamp
>[13] Help Page (full help in build/doc/index.html)
>[14] run history: build
>[Q] Quit
>
>When i select "[11] Checkout source for selected target now",It's 
>will be succeed.
>But when i select "[3] run: build" to build,there will be failed:
>[#-00000001][2007-06-04 18:33:03][-1208027456][INFO ] : Ribosome v2.4.6
>[#-00000002][2007-06-04 18:33:03][-1208027456][INFO ] : Using Python v2.4.4
>[#-00000003][2007-06-04 18:33:03][-1208027456][INFO ] : Log dir: 
>/home/hlzhang/ribosome_logs
>[#-00000005][2007-06-04 18:33:03][-1208027456][INFO ] : Running tool: armerge
>g++ -Wl,-export-dynamic -o dbg/splay dbg/obj/main.o 
>dbg/obj/excontxt.o dbg/obj/exadvsnk.o dbg/obj/exerror.o dbg/obj/iids.o dbg
>/obj/print.o  dbg/splay_libs.a -L/usr/X11R6/lib -ldl -lm -lpthread
>dbg/obj/main.o(.text+0x1a9d): In function `main':
>/home/hlzhang/clientapps/simpleplayer/main.cpp:1268: undefined 
>reference to `XInitThreads'
>collect2: ld returned 1 exit status
>make: *** [dbg/splay] Error 1
>Time used: 5.70 seconds
>ERROR: UNIXCompile(clientapps/simpleplayer) ERROR: Make failed.
>
>--- Build System Error ------------------------------------
>Make failed.
>-----------------------------------------------------------
>leaving directory /home/hlzhang/./client/core
>    ...
>    ...
>Build complete in 06:34, 1 of 34 modules failed.


Rishi Mathew
Helix Community
RealNetworks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070606/04b2e228/attachment.html
From Arnel.Periquet at nokia.com  Thu Jun  7 07:52:07 2007
From: Arnel.Periquet at nokia.com (Arnel.Periquet@nokia.com)
Date: Thu Jun  7 08:07:35 2007
Subject: [Helix-client-dev] CR: S60 Progressive Download - sometimes underflow
	is not handled properly when download is paused
Message-ID: 



> "Nokia submits this code under the terms of a commercial contribution
> agreement with RealNetworks, and I am authorized to contribute this
> code under said agreement."
> 
> Modified by:  Arnel.Periquet@nokia.com
> 
> Reviewed by:
> 
> Date: 06-07-2007
> 
> Project: client/audiosvc
> 
> ErrorId: EOVL-737Q35
> 
> Synopsis:  S60 Progressive Download - sometimes underflow is not
> handled properly when download is paused
> 
> Rebuffering is not triggered because GoingToUnderflow() doesn't detect
> audio ran out of data to play. (See scenario description below). 
> The function basically does "return (nBlocksRemaining <
> m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, always
> returns FALSE because "nBlocksRemaining == 2" and
> "m_ulMinBlocksTobeQueuedAtStart==2". This is caused by
> "nBlocksRemaining" being derived from "currentTime" in the audio
> device and the device implementation in our case has a little bit
> (95-150ms) of data left in it when it stops playing. That little bit
> is just enough to cause the GoingToUnderflow() test to fail. 
> The solution is to provide a new value for m_ulMinimumStartupPushdown
> of 200ms. This value will be set under a Symbian only flag.
> Scenario: S60 Progressive Download 
> 1. Play an audio-only clip using the S60 Browser to trigger Helix in
> progressive download mode. 
> Result 
> (a) S60 download manager starts a download of the file. 
> (b) Helix TLC (i.e., S60 MMF plugin) is launched. 
> (c) Helix loads the S60 Progressive Download filesystem. 
> (d) Helix starts playing the clip. 
> 2. Pause the download on the S60 download manager. 
> Result 
> (a) download of the file is paused. 
> (b) Helix continues to play out what is in the file 
> (c) Helix runs out of file data and the filesystem continues to
> RetryRead(). 
> (d) Helix runs out of audio buffer to play. 
> (e) GoingToUnderflow() is continually called to check if we need to
> rebuffer, but it always returns FALSE. 
> 
> Root Cause: Implementation. 
> 
> File Modified: 
> hxaudses.h
> hxaudses.cpp
> helix-client-s60-32-common.pfi
> 
> Image Size and Heap Use impact: no major impact
> 
> Module Release Testing (STIF): Passed with known rate adaptation
> problems currently being addressed.
> 
> Test Case(s) Added: No. This case is reproduced by stopped the
> download manager, which is done manually on the hardware.
> 
> Memory Leak Check Performed: Yes
> 
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
> 
> Platforms and Profiles Functionality Verified: armv5, winscw
> 
> Branch: HEAD & 210CayS
> 
> Index: hxaudses.h
> ===================================================================
> RCS file: /cvsroot/client/audiosvc/pub/hxaudses.h,v
> retrieving revision 1.22.2.1
> diff -w -u -b -r1.22.2.1 hxaudses.h
> --- hxaudses.h	18 Jan 2006 19:26:18 -0000	1.22.2.1
> +++ hxaudses.h	6 Jun 2007 21:37:57 -0000
> @@ -97,6 +97,9 @@
>  #  define CHECK_AUDIO_INTERVAL            60  
>  #endif
>  
> +#ifdef HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES
> +#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  200
> +#endif
>  
>  // foward decls.
>  struct IHXCallback;
> 
> Index: hxaudses.cpp
> ===================================================================
> RCS file: /cvsroot/client/audiosvc/hxaudses.cpp,v
> retrieving revision 1.64.2.2
> diff -w -u -b -r1.64.2.2 hxaudses.cpp
> --- hxaudses.cpp	23 Jan 2006 09:42:33 -0000	1.64.2.2
> +++ hxaudses.cpp	6 Jun 2007 21:35:51 -0000
> @@ -631,7 +631,7 @@
>      if (m_pPreferences)
>      {
>          ReadPrefUINT32(m_pPreferences, "MinimumAudioPushdown",
> m_ulMinimumPushdown);
> -        ReadPrefUINT32(m_pPreferences,
> "MinimumAudioStartupInitalPushdown", m_ulMinimumStartupPushdown);
> +        ReadPrefUINT32(m_pPreferences,
> "MinimumAudioStartupInitialPushdown", m_ulMinimumStartupPushdown);
>          ReadPrefUINT32(m_pPreferences, "CheckAudioPct",
> m_nPercentage);
>      }
>      HXLOGL2(HXLOG_ADEV, "Setting callback granulatiry percentage to
> %d", m_nPercentage );
> @@ -2984,6 +2984,11 @@
>          if( lMsInAudioDevice>0 )
>          {
>              ulRetVal =
> (ULONG32)floor(lMsInAudioDevice/m_dGranularity);
> +            HXLOGL4(HXLOG_ADEV, "\tBlocksWritten(%lu) /MsWritten(%lu)
> /MsInDevice(%d) CurTime(%lu)",
> +                    m_ulBlocksWritten,
> +                    ulMsWritten,
> +                    lMsInAudioDevice,
> +                    ulCurTime);
>          }
>          else
>          {
> @@ -4082,10 +4087,9 @@
>          bRetVal = (nBlocksRemaining TRUE : FALSE;
>          if( bRetVal )
>          {
> -            HXLOGL2( "IsRebufferRequired: BlockRemaining: %d
> BlockToStart: %lu",
> +            HXLOGL2(HXLOG_ADEV, "IsRebufferRequired: BlockRemaining:
> %d  BlockToStart: %lu",
>                       nBlocksRemaining,
> -                     m_ulMinBlocksTobeQueuedAtStart
> -                     );
> +                    m_ulMinBlocksTobeQueuedAtStart);
>          }
>      }
>      return bRetVal;
> 
> Index: helix-client-s60-32-common.pfi
> ===================================================================
> RCS file:
> /cvsroot/ribosome/build/umakepf/helix-client-s60-32-common.pfi,v
> retrieving revision 1.6
> diff -w -u -b -r1.6 helix-client-s60-32-common.pfi
> --- helix-client-s60-32-common.pfi	5 Apr 2007 18:40:48 -0000
> 1.6
> +++ helix-client-s60-32-common.pfi	6 Jun 2007 21:39:59 -0000
> @@ -65,6 +65,7 @@
>  
>  #Features in S60 3.2 platform
>  
> +project.AddDefines('HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES')
>  project.AddDefines('HELIX_FEATURE_DRM_SECURE_OUTPUT')
>  project.AddDefines('HELIX_FEATURE_S60_PROGDOWN')
>  project.AddDefines('HELIX_FEATURE_S60_VIDEO_CUSTOM_INTERFACE')
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070607/f9151af1/attachment-0001.html
From gang.1.shen at nokia.com  Thu Jun  7 09:42:00 2007
From: gang.1.shen at nokia.com (gang.1.shen@nokia.com)
Date: Thu Jun  7 09:56:09 2007
Subject: [Helix-client-dev] Trickplay 
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>

Hi, Eric,

I have a question regarding "trickplay" design in
https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP-SOD-001-T
rickPlay.html.

How does Helix avoid a overflow during fast forward? If fileformat
(optionally) deliver packets differently based on the magnitude of the
playback velocity, there would be more packets delivered to video
renderer than needed in a fast forward playback. Which component will
drop these extra frames?

Thanks,

Gang Shen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070607/e10054d0/attachment.html
From gang.1.shen at nokia.com  Thu Jun  7 09:51:27 2007
From: gang.1.shen at nokia.com (gang.1.shen@nokia.com)
Date: Thu Jun  7 10:05:32 2007
Subject: [Helix-client-dev] Trickplay 
In-Reply-To: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12CE@daebe102.NOE.Nokia.com>

A typo: "If fileformat (optionally) doesn't deliver packets differently
...."

________________________________

From: helix-client-dev-bounces@helixcommunity.org
[mailto:helix-client-dev-bounces@helixcommunity.org] 
Sent: Thursday, June 07, 2007 11:42 AM
To: ehyche@real.com; helix-client-dev@helixcommunity.org
Subject: [Helix-client-dev] Trickplay 



Hi, Eric, 

I have a question regarding "trickplay" design in
https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP-SOD-001-T
rickPlay.html
 .

How does Helix avoid a overflow during fast forward? If fileformat
(optionally) deliver packets differently based on the magnitude of the
playback velocity, there would be more packets delivered to video
renderer than needed in a fast forward playback. Which component will
drop these extra frames?

Thanks, 

Gang Shen 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070607/5006d22c/attachment.html
From ehyche at real.com  Thu Jun  7 09:59:55 2007
From: ehyche at real.com (Eric Hyche)
Date: Thu Jun  7 10:13:57 2007
Subject: [Helix-client-dev] RE: Trickplay 
In-Reply-To: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
Message-ID: <00cb01c7a925$46fb8000$db68a8c0@EHYCHED620>


The renderer makes the decision about when frames
are dropped. If the user specified that it
should autoswitch from all-frames mode to keyframe-mode,
then the renderer will try to play all the frames
it can. When it realizes that it is dropping frames
about a certain rate, then it will tell the client
core that it wants to go to keyframe-mode. At that
point, the client core tells the file format plugin
that it is going to keyframe mode.

The file format may or may not at that point start
providing just keyframes. But the fileformat proxy
in the client core will from that point on filter
out everything but keyframe packets.

Does that answer your question?

Eric

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: gang.1.shen@nokia.com [mailto:gang.1.shen@nokia.com] 
> Sent: Thursday, June 07, 2007 12:42 PM
> To: ehyche@real.com; helix-client-dev@helixcommunity.org
> Subject: Trickplay 
> 
> Hi, Eric, 
> 
> I have a question regarding "trickplay" design in 
> https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP
> -SOD-001-TrickPlay.html 
>  P-SOD-001-TrickPlay.html> .
> 
> How does Helix avoid a overflow during fast forward? If 
> fileformat (optionally) deliver packets differently based on 
> the magnitude of the playback velocity, there would be more 
> packets delivered to video renderer than needed in a fast 
> forward playback. Which component will drop these extra frames?
> 
> Thanks, 
> 
> Gang Shen 
> 
> 


From ehyche at real.com  Thu Jun  7 10:27:41 2007
From: ehyche at real.com (Eric Hyche)
Date: Thu Jun  7 10:41:37 2007
Subject: [Helix-client-dev] CR: S60 Progressive Download - sometimes
	underflowis not handled properly when download is paused
In-Reply-To: 
References: 
Message-ID: <00d301c7a929$27ca6f80$db68a8c0@EHYCHED620>


Looks good.

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: helix-client-dev-bounces@helixcommunity.org 
> [mailto:helix-client-dev-bounces@helixcommunity.org] On 
> Behalf Of Arnel.Periquet@nokia.com
> Sent: Thursday, June 07, 2007 10:52 AM
> To: helix-client-dev@helixcommunity.org
> Subject: [Helix-client-dev] CR: S60 Progressive Download - 
> sometimes underflowis not handled properly when download is paused
> 
> 
> 
> 	"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:  Arnel.Periquet@nokia.com 
> 
> 	Reviewed by: 
> 
> 	Date: 06-07-2007 
> 
> 	Project: client/audiosvc 
> 
> 	ErrorId: EOVL-737Q35 
> 
> 	Synopsis:  S60 Progressive Download - sometimes 
> underflow is not handled properly when download is paused 
> 
> 	Rebuffering is not triggered because GoingToUnderflow() 
> doesn't detect audio ran out of data to play. (See scenario 
> description below). 
> 
> 	The function basically does "return (nBlocksRemaining < 
> m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, 
> always returns FALSE because "nBlocksRemaining == 2" and 
> "m_ulMinBlocksTobeQueuedAtStart==2". This is caused by 
> "nBlocksRemaining" being derived from "currentTime" in the 
> audio device and the device implementation in our case has a 
> little bit (95-150ms) of data left in it when it stops 
> playing. That little bit is just enough to cause the 
> GoingToUnderflow() test to fail. 
> 
> 	The solution is to provide a new value for 
> m_ulMinimumStartupPushdown of 200ms. This value will be set 
> under a Symbian only flag.
> 
> 	Scenario: S60 Progressive Download 
> 	1. Play an audio-only clip using the S60 Browser to 
> trigger Helix in progressive download mode.
> 	Result
> 	(a) S60 download manager starts a download of the file.
> 	(b) Helix TLC (i.e., S60 MMF plugin) is launched.
> 	(c) Helix loads the S60 Progressive Download filesystem.
> 	(d) Helix starts playing the clip. 
> 	2. Pause the download on the S60 download manager.
> 	Result
> 	(a) download of the file is paused.
> 	(b) Helix continues to play out what is in the file
> 	(c) Helix runs out of file data and the filesystem 
> continues to RetryRead().
> 	(d) Helix runs out of audio buffer to play.
> 	(e) GoingToUnderflow() is continually called to check 
> if we need to rebuffer, but it always returns FALSE. 
> 
> 	Root Cause: Implementation. 
> 
> 	File Modified: 
> 	hxaudses.h 
> 	hxaudses.cpp 
> 	helix-client-s60-32-common.pfi 
> 
> 	Image Size and Heap Use impact: no major impact 
> 
> 	Module Release Testing (STIF): Passed with known rate 
> adaptation problems currently being addressed. 
> 
> 	Test Case(s) Added: No. This case is reproduced by 
> stopped the download manager, which is done manually on the hardware.
> 
> 	Memory Leak Check Performed: Yes 
> 
> 	Platforms and Profiles Build Verified: 
> helix-client-s60-32-mmf-mdf-arm 
> 
> 	Platforms and Profiles Functionality Verified: armv5, winscw 
> 
> 	Branch: HEAD & 210CayS 
> 
> 	Index: hxaudses.h 
> 	
> =================================================================== 
> 	RCS file: /cvsroot/client/audiosvc/pub/hxaudses.h,v 
> 	retrieving revision 1.22.2.1 
> 	diff -w -u -b -r1.22.2.1 hxaudses.h 
> 	--- hxaudses.h  18 Jan 2006 19:26:18 -0000      1.22.2.1 
> 	+++ hxaudses.h  6 Jun 2007 21:37:57 -0000 
> 	@@ -97,6 +97,9 @@ 
> 	 #  define CHECK_AUDIO_INTERVAL            60  
> 	 #endif 
> 	  
> 	+#ifdef HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES 
> 	+#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  200 
> 	+#endif 
> 	  
> 	 // foward decls. 
> 	 struct IHXCallback; 
> 
> 	Index: hxaudses.cpp 
> 	
> =================================================================== 
> 	RCS file: /cvsroot/client/audiosvc/hxaudses.cpp,v 
> 	retrieving revision 1.64.2.2 
> 	diff -w -u -b -r1.64.2.2 hxaudses.cpp 
> 	--- hxaudses.cpp        23 Jan 2006 09:42:33 -0000      
> 1.64.2.2 
> 	+++ hxaudses.cpp        6 Jun 2007 21:35:51 -0000 
> 	@@ -631,7 +631,7 @@ 
> 	     if (m_pPreferences) 
> 	     { 
> 	         ReadPrefUINT32(m_pPreferences, 
> "MinimumAudioPushdown", m_ulMinimumPushdown); 
> 	-        ReadPrefUINT32(m_pPreferences, 
> "MinimumAudioStartupInitalPushdown", m_ulMinimumStartupPushdown); 
> 	+        ReadPrefUINT32(m_pPreferences, 
> "MinimumAudioStartupInitialPushdown", m_ulMinimumStartupPushdown); 
> 	         ReadPrefUINT32(m_pPreferences, 
> "CheckAudioPct", m_nPercentage); 
> 	     } 
> 	     HXLOGL2(HXLOG_ADEV, "Setting callback granulatiry 
> percentage to %d", m_nPercentage ); 
> 	@@ -2984,6 +2984,11 @@ 
> 	         if( lMsInAudioDevice>0 ) 
> 	         { 
> 	             ulRetVal = 
> (ULONG32)floor(lMsInAudioDevice/m_dGranularity); 
> 	+            HXLOGL4(HXLOG_ADEV, "\tBlocksWritten(%lu) 
> /MsWritten(%lu) /MsInDevice(%d) CurTime(%lu)", 
> 	+                    m_ulBlocksWritten, 
> 	+                    ulMsWritten, 
> 	+                    lMsInAudioDevice, 
> 	+                    ulCurTime); 
> 	         } 
> 	         else 
> 	         { 
> 	@@ -4082,10 +4087,9 @@ 
> 	         bRetVal = 
> (nBlocksRemaining 	         if( bRetVal ) 
> 	         { 
> 	-            HXLOGL2( "IsRebufferRequired: 
> BlockRemaining: %d  BlockToStart: %lu", 
> 	+            HXLOGL2(HXLOG_ADEV, "IsRebufferRequired: 
> BlockRemaining: %d  BlockToStart: %lu", 
> 	                      nBlocksRemaining, 
> 	-                     m_ulMinBlocksTobeQueuedAtStart 
> 	-                     ); 
> 	+                    m_ulMinBlocksTobeQueuedAtStart); 
> 	         } 
> 	     } 
> 	     return bRetVal; 
> 
> 	Index: helix-client-s60-32-common.pfi 
> 	
> =================================================================== 
> 	RCS file: 
> /cvsroot/ribosome/build/umakepf/helix-client-s60-32-common.pfi,v 
> 	retrieving revision 1.6 
> 	diff -w -u -b -r1.6 helix-client-s60-32-common.pfi 
> 	--- helix-client-s60-32-common.pfi      5 Apr 2007 
> 18:40:48 -0000       1.6 
> 	+++ helix-client-s60-32-common.pfi      6 Jun 2007 
> 21:39:59 -0000 
> 	@@ -65,6 +65,7 @@ 
> 	  
> 	 #Features in S60 3.2 platform 
> 	  
> 	+project.AddDefines('HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES') 
> 	 project.AddDefines('HELIX_FEATURE_DRM_SECURE_OUTPUT') 
> 	 project.AddDefines('HELIX_FEATURE_S60_PROGDOWN') 
> 	 project.AddDefines('HELIX_FEATURE_S60_VIDEO_CUSTOM_INTERFACE') 
> 
> 


From gang.1.shen at nokia.com  Thu Jun  7 11:36:06 2007
From: gang.1.shen at nokia.com (gang.1.shen@nokia.com)
Date: Thu Jun  7 11:50:10 2007
Subject: [Helix-client-dev] RE: Trickplay 
In-Reply-To: <00cb01c7a925$46fb8000$db68a8c0@EHYCHED620>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
	<00cb01c7a925$46fb8000$db68a8c0@EHYCHED620>
Message-ID: <1F7C330B210B764DBBE8B2D749F9A5DB03FF13E2@daebe102.NOE.Nokia.com>


Thanks a lot. That answers my question. 

It looks like there is a need for renderer to selectively push frames
(non-key frames) to decoders based on magnitude of velocity, for
all-frames mode. That would save decoder from decoding frames that are
supposed to be skipped. Is that what Helix has in its video renderer?
Btw, my concern is on our MDF renderer; we'd like to see how Helix
renderer works. 

-GS

-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com] 
Sent: Thursday, June 07, 2007 12:00 PM
To: Shen Gang.1 (Nokia-TP-MSW/Dallas);
helix-client-dev@helixcommunity.org
Subject: RE: Trickplay 


The renderer makes the decision about when frames are dropped. If the
user specified that it should autoswitch from all-frames mode to
keyframe-mode, then the renderer will try to play all the frames it can.
When it realizes that it is dropping frames about a certain rate, then
it will tell the client core that it wants to go to keyframe-mode. At
that point, the client core tells the file format plugin that it is
going to keyframe mode.

The file format may or may not at that point start providing just
keyframes. But the fileformat proxy in the client core will from that
point on filter out everything but keyframe packets.

Does that answer your question?

Eric

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: gang.1.shen@nokia.com [mailto:gang.1.shen@nokia.com]
> Sent: Thursday, June 07, 2007 12:42 PM
> To: ehyche@real.com; helix-client-dev@helixcommunity.org
> Subject: Trickplay
> 
> Hi, Eric,
> 
> I have a question regarding "trickplay" design in 
> https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP
> -SOD-001-TrickPlay.html
>  P-SOD-001-TrickPlay.html> .
> 
> How does Helix avoid a overflow during fast forward? If fileformat 
> (optionally) deliver packets differently based on the magnitude of the

> playback velocity, there would be more packets delivered to video 
> renderer than needed in a fast forward playback. Which component will 
> drop these extra frames?
> 
> Thanks,
> 
> Gang Shen
> 
> 


From Arnel.Periquet at nokia.com  Thu Jun  7 12:34:34 2007
From: Arnel.Periquet at nokia.com (Arnel.Periquet@nokia.com)
Date: Thu Jun  7 12:49:14 2007
Subject: [Helix-client-dev] CN: S60 Progressive Download - sometimes
	underflow is not handled properly when download is paused
In-Reply-To: <00d301c7a929$27ca6f80$db68a8c0@EHYCHED620>
References: 
	<00d301c7a929$27ca6f80$db68a8c0@EHYCHED620>
Message-ID: 

 Checked into HEAD and CAY210S.

Thanks,
Arnel

>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com] 
>Sent: Thursday, June 07, 2007 12:28 PM
>To: Periquet Arnel (Nokia-TP-MSW/Dallas); 
>helix-client-dev@helixcommunity.org
>Subject: RE: [Helix-client-dev] CR: S60 Progressive Download - 
>sometimes underflowis not handled properly when download is paused
>
>
>Looks good.
>
>=============================================
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.  
>
>> -----Original Message-----
>> From: helix-client-dev-bounces@helixcommunity.org
>> [mailto:helix-client-dev-bounces@helixcommunity.org] On Behalf Of 
>> Arnel.Periquet@nokia.com
>> Sent: Thursday, June 07, 2007 10:52 AM
>> To: helix-client-dev@helixcommunity.org
>> Subject: [Helix-client-dev] CR: S60 Progressive Download - sometimes 
>> underflowis not handled properly when download is paused
>> 
>> 
>> 
>> 	"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:  Arnel.Periquet@nokia.com
>> 
>> 	Reviewed by: ehyche@real.com
>> 
>> 	Date: 06-07-2007
>> 
>> 	Project: client/audiosvc
>> 
>> 	ErrorId: EOVL-737Q35
>> 
>> 	Synopsis:  S60 Progressive Download - sometimes 
>underflow is not 
>> handled properly when download is paused
>> 
>> 	Rebuffering is not triggered because GoingToUnderflow() doesn't 
>> detect audio ran out of data to play. (See scenario description 
>> below).
>> 
>> 	The function basically does "return (nBlocksRemaining < 
>> m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario, always 
>> returns FALSE because "nBlocksRemaining == 2" and 
>> "m_ulMinBlocksTobeQueuedAtStart==2". This is caused by 
>> "nBlocksRemaining" being derived from "currentTime" in the audio 
>> device and the device implementation in our case has a little bit 
>> (95-150ms) of data left in it when it stops playing. That little bit 
>> is just enough to cause the
>> GoingToUnderflow() test to fail. 
>> 
>> 	The solution is to provide a new value for 
>m_ulMinimumStartupPushdown 
>> of 200ms. This value will be set under a Symbian only flag.
>> 
>> 	Scenario: S60 Progressive Download 
>> 	1. Play an audio-only clip using the S60 Browser to 
>trigger Helix in 
>> progressive download mode.
>> 	Result
>> 	(a) S60 download manager starts a download of the file.
>> 	(b) Helix TLC (i.e., S60 MMF plugin) is launched.
>> 	(c) Helix loads the S60 Progressive Download filesystem.
>> 	(d) Helix starts playing the clip. 
>> 	2. Pause the download on the S60 download manager.
>> 	Result
>> 	(a) download of the file is paused.
>> 	(b) Helix continues to play out what is in the file
>> 	(c) Helix runs out of file data and the filesystem continues to 
>> RetryRead().
>> 	(d) Helix runs out of audio buffer to play.
>> 	(e) GoingToUnderflow() is continually called to check 
>if we need to 
>> rebuffer, but it always returns FALSE.
>> 
>> 	Root Cause: Implementation. 
>> 
>> 	File Modified: 
>> 	hxaudses.h 
>> 	hxaudses.cpp 
>> 	helix-client-s60-32-common.pfi
>> 
>> 	Image Size and Heap Use impact: no major impact
>> 
>> 	Module Release Testing (STIF): Passed with known rate 
>adaptation 
>> problems currently being addressed.
>> 
>> 	Test Case(s) Added: No. This case is reproduced by stopped the 
>> download manager, which is done manually on the hardware.
>> 
>> 	Memory Leak Check Performed: Yes
>> 
>> 	Platforms and Profiles Build Verified: 
>> helix-client-s60-32-mmf-mdf-arm
>> 
>> 	Platforms and Profiles Functionality Verified: armv5, winscw
>> 
>> 	Branch: HEAD & 210CayS
>> 
>> 	Index: hxaudses.h
>> 	
>> =================================================================== 
>> 	RCS file: /cvsroot/client/audiosvc/pub/hxaudses.h,v 
>> 	retrieving revision 1.22.2.1 
>> 	diff -w -u -b -r1.22.2.1 hxaudses.h 
>> 	--- hxaudses.h  18 Jan 2006 19:26:18 -0000      1.22.2.1 
>> 	+++ hxaudses.h  6 Jun 2007 21:37:57 -0000 
>> 	@@ -97,6 +97,9 @@ 
>> 	 #  define CHECK_AUDIO_INTERVAL            60  
>> 	 #endif
>> 	  
>> 	+#ifdef HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES 
>> 	+#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  200 
>> 	+#endif
>> 	  
>> 	 // foward decls. 
>> 	 struct IHXCallback;
>> 
>> 	Index: hxaudses.cpp
>> 	
>> =================================================================== 
>> 	RCS file: /cvsroot/client/audiosvc/hxaudses.cpp,v 
>> 	retrieving revision 1.64.2.2 
>> 	diff -w -u -b -r1.64.2.2 hxaudses.cpp 
>> 	--- hxaudses.cpp        23 Jan 2006 09:42:33 -0000      
>> 1.64.2.2 
>> 	+++ hxaudses.cpp        6 Jun 2007 21:35:51 -0000 
>> 	@@ -631,7 +631,7 @@ 
>> 	     if (m_pPreferences) 
>> 	     { 
>> 	         ReadPrefUINT32(m_pPreferences, "MinimumAudioPushdown", 
>> m_ulMinimumPushdown);
>> 	-        ReadPrefUINT32(m_pPreferences, 
>> "MinimumAudioStartupInitalPushdown", m_ulMinimumStartupPushdown); 
>> 	+        ReadPrefUINT32(m_pPreferences, 
>> "MinimumAudioStartupInitialPushdown", m_ulMinimumStartupPushdown); 
>> 	         ReadPrefUINT32(m_pPreferences, "CheckAudioPct", 
>> m_nPercentage);
>> 	     } 
>> 	     HXLOGL2(HXLOG_ADEV, "Setting callback granulatiry 
>percentage to 
>> %d", m_nPercentage );
>> 	@@ -2984,6 +2984,11 @@ 
>> 	         if( lMsInAudioDevice>0 ) 
>> 	         { 
>> 	             ulRetVal =
>> (ULONG32)floor(lMsInAudioDevice/m_dGranularity); 
>> 	+            HXLOGL4(HXLOG_ADEV, "\tBlocksWritten(%lu) 
>> /MsWritten(%lu) /MsInDevice(%d) CurTime(%lu)", 
>> 	+                    m_ulBlocksWritten, 
>> 	+                    ulMsWritten, 
>> 	+                    lMsInAudioDevice, 
>> 	+                    ulCurTime); 
>> 	         } 
>> 	         else 
>> 	         { 
>> 	@@ -4082,10 +4087,9 @@ 
>> 	         bRetVal =
>> (nBlocksRemaining> 	         if( bRetVal ) 
>> 	         { 
>> 	-            HXLOGL2( "IsRebufferRequired: 
>> BlockRemaining: %d  BlockToStart: %lu", 
>> 	+            HXLOGL2(HXLOG_ADEV, "IsRebufferRequired: 
>> BlockRemaining: %d  BlockToStart: %lu", 
>> 	                      nBlocksRemaining, 
>> 	-                     m_ulMinBlocksTobeQueuedAtStart 
>> 	-                     ); 
>> 	+                    m_ulMinBlocksTobeQueuedAtStart); 
>> 	         } 
>> 	     } 
>> 	     return bRetVal;
>> 
>> 	Index: helix-client-s60-32-common.pfi
>> 	
>> =================================================================== 
>> 	RCS file: 
>> /cvsroot/ribosome/build/umakepf/helix-client-s60-32-common.pfi,v 
>> 	retrieving revision 1.6 
>> 	diff -w -u -b -r1.6 helix-client-s60-32-common.pfi 
>> 	--- helix-client-s60-32-common.pfi      5 Apr 2007 
>> 18:40:48 -0000       1.6 
>> 	+++ helix-client-s60-32-common.pfi      6 Jun 2007 
>> 21:39:59 -0000 
>> 	@@ -65,6 +65,7 @@
>> 	  
>> 	 #Features in S60 3.2 platform
>> 	  
>> 	+project.AddDefines('HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES') 
>> 	 project.AddDefines('HELIX_FEATURE_DRM_SECURE_OUTPUT') 
>> 	 project.AddDefines('HELIX_FEATURE_S60_PROGDOWN') 
>> 	 project.AddDefines('HELIX_FEATURE_S60_VIDEO_CUSTOM_INTERFACE')
>> 
>> 
>
>

From wotseb at hotmail.com  Mon Jun 11 01:59:52 2007
From: wotseb at hotmail.com (=?gb2312?B?d290c2ViIM300fM=?=)
Date: Mon Jun 11 02:13:04 2007
Subject: [Helix-client-dev] any interface function in sdk can disable auto
	popup web links?
In-Reply-To: <6.2.5.6.2.20070606161046.0624a5c0@real.com>
Message-ID: 

hello everyone,
   with realplayer activex, SetAutoGoToURL(boolean enable_start) method can 
enable or
disable auto-popup web links. Are there any interface function in SDK to 
implement
the function?


thx!

_________________________________________________________________
与联机的朋友进行交流,请使用 MSN Messenger:  http://messenger.msn.com/cn  


From wotseb at hotmail.com  Mon Jun 11 22:56:52 2007
From: wotseb at hotmail.com (=?gb2312?B?d290c2ViIM300fM=?=)
Date: Mon Jun 11 23:09:47 2007
Subject: [Helix-client-dev] HI ALL! How to disable/enable popup web
	hyperlinks when playing real video? thx~
In-Reply-To: <00d301c7a929$27ca6f80$db68a8c0@EHYCHED620>
Message-ID: 




>From: "Eric Hyche" 
>Reply-To: ehyche@real.com
>To: Arnel.Periquet@nokia.com, helix-client-dev@helixcommunity.org
>Subject: RE: [Helix-client-dev] CR: S60 Progressive Download - 
sometimesunderflowis not handled properly when download is paused
>Date: Thu, 7 Jun 2007 13:27:41 -0400
>
>
>Looks good.
>
>=============================================
>Eric Hyche (ehyche@real.com)
>Technical Lead
>RealNetworks, Inc.
>
> > -----Original Message-----
> > From: helix-client-dev-bounces@helixcommunity.org
> > [mailto:helix-client-dev-bounces@helixcommunity.org] On
> > Behalf Of Arnel.Periquet@nokia.com
> > Sent: Thursday, June 07, 2007 10:52 AM
> > To: helix-client-dev@helixcommunity.org
> > Subject: [Helix-client-dev] CR: S60 Progressive Download -
> > sometimes underflowis not handled properly when download is paused
> >
> >
> >
> > 	"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:  Arnel.Periquet@nokia.com
> >
> > 	Reviewed by:
> >
> > 	Date: 06-07-2007
> >
> > 	Project: client/audiosvc
> >
> > 	ErrorId: EOVL-737Q35
> >
> > 	Synopsis:  S60 Progressive Download - sometimes
> > underflow is not handled properly when download is paused
> >
> > 	Rebuffering is not triggered because GoingToUnderflow()
> > doesn't detect audio ran out of data to play. (See scenario
> > description below).
> >
> > 	The function basically does "return (nBlocksRemaining <
> > m_ulMinBlocksTobeQueuedAtStart)". The test, in my scenario,
> > always returns FALSE because "nBlocksRemaining == 2" and
> > "m_ulMinBlocksTobeQueuedAtStart==2". This is caused by
> > "nBlocksRemaining" being derived from "currentTime" in the
> > audio device and the device implementation in our case has a
> > little bit (95-150ms) of data left in it when it stops
> > playing. That little bit is just enough to cause the
> > GoingToUnderflow() test to fail.
> >
> > 	The solution is to provide a new value for
> > m_ulMinimumStartupPushdown of 200ms. This value will be set
> > under a Symbian only flag.
> >
> > 	Scenario: S60 Progressive Download
> > 	1. Play an audio-only clip using the S60 Browser to
> > trigger Helix in progressive download mode.
> > 	Result
> > 	(a) S60 download manager starts a download of the file.
> > 	(b) Helix TLC (i.e., S60 MMF plugin) is launched.
> > 	(c) Helix loads the S60 Progressive Download filesystem.
> > 	(d) Helix starts playing the clip.
> > 	2. Pause the download on the S60 download manager.
> > 	Result
> > 	(a) download of the file is paused.
> > 	(b) Helix continues to play out what is in the file
> > 	(c) Helix runs out of file data and the filesystem
> > continues to RetryRead().
> > 	(d) Helix runs out of audio buffer to play.
> > 	(e) GoingToUnderflow() is continually called to check
> > if we need to rebuffer, but it always returns FALSE.
> >
> > 	Root Cause: Implementation.
> >
> > 	File Modified:
> > 	hxaudses.h
> > 	hxaudses.cpp
> > 	helix-client-s60-32-common.pfi
> >
> > 	Image Size and Heap Use impact: no major impact
> >
> > 	Module Release Testing (STIF): Passed with known rate
> > adaptation problems currently being addressed.
> >
> > 	Test Case(s) Added: No. This case is reproduced by
> > stopped the download manager, which is done manually on the hardware.
> >
> > 	Memory Leak Check Performed: Yes
> >
> > 	Platforms and Profiles Build Verified:
> > helix-client-s60-32-mmf-mdf-arm
> >
> > 	Platforms and Profiles Functionality Verified: armv5, winscw
> >
> > 	Branch: HEAD & 210CayS
> >
> > 	Index: hxaudses.h
> >
> > ===================================================================
> > 	RCS file: /cvsroot/client/audiosvc/pub/hxaudses.h,v
> > 	retrieving revision 1.22.2.1
> > 	diff -w -u -b -r1.22.2.1 hxaudses.h
> > 	--- hxaudses.h  18 Jan 2006 19:26:18 -0000      1.22.2.1
> > 	+++ hxaudses.h  6 Jun 2007 21:37:57 -0000
> > 	@@ -97,6 +97,9 @@
> > 	 #  define CHECK_AUDIO_INTERVAL            60
> > 	 #endif
> >
> > 	+#ifdef HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES
> > 	+#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  200
> > 	+#endif
> >
> > 	 // foward decls.
> > 	 struct IHXCallback;
> >
> > 	Index: hxaudses.cpp
> >
> > ===================================================================
> > 	RCS file: /cvsroot/client/audiosvc/hxaudses.cpp,v
> > 	retrieving revision 1.64.2.2
> > 	diff -w -u -b -r1.64.2.2 hxaudses.cpp
> > 	--- hxaudses.cpp        23 Jan 2006 09:42:33 -0000
> > 1.64.2.2
> > 	+++ hxaudses.cpp        6 Jun 2007 21:35:51 -0000
> > 	@@ -631,7 +631,7 @@
> > 	     if (m_pPreferences)
> > 	     {
> > 	         ReadPrefUINT32(m_pPreferences,
> > "MinimumAudioPushdown", m_ulMinimumPushdown);
> > 	-        ReadPrefUINT32(m_pPreferences,
> > "MinimumAudioStartupInitalPushdown", m_ulMinimumStartupPushdown);
> > 	+        ReadPrefUINT32(m_pPreferences,
> > "MinimumAudioStartupInitialPushdown", m_ulMinimumStartupPushdown);
> > 	         ReadPrefUINT32(m_pPreferences,
> > "CheckAudioPct", m_nPercentage);
> > 	     }
> > 	     HXLOGL2(HXLOG_ADEV, "Setting callback granulatiry
> > percentage to %d", m_nPercentage );
> > 	@@ -2984,6 +2984,11 @@
> > 	         if( lMsInAudioDevice>0 )
> > 	         {
> > 	             ulRetVal =
> > (ULONG32)floor(lMsInAudioDevice/m_dGranularity);
> > 	+            HXLOGL4(HXLOG_ADEV, "\tBlocksWritten(%lu)
> > /MsWritten(%lu) /MsInDevice(%d) CurTime(%lu)",
> > 	+                    m_ulBlocksWritten,
> > 	+                    ulMsWritten,
> > 	+                    lMsInAudioDevice,
> > 	+                    ulCurTime);
> > 	         }
> > 	         else
> > 	         {
> > 	@@ -4082,10 +4087,9 @@
> > 	         bRetVal =
> > (nBlocksRemaining > 	         if( bRetVal )
> > 	         {
> > 	-            HXLOGL2( "IsRebufferRequired:
> > BlockRemaining: %d  BlockToStart: %lu",
> > 	+            HXLOGL2(HXLOG_ADEV, "IsRebufferRequired:
> > BlockRemaining: %d  BlockToStart: %lu",
> > 	                      nBlocksRemaining,
> > 	-                     m_ulMinBlocksTobeQueuedAtStart
> > 	-                     );
> > 	+                    m_ulMinBlocksTobeQueuedAtStart);
> > 	         }
> > 	     }
> > 	     return bRetVal;
> >
> > 	Index: helix-client-s60-32-common.pfi
> >
> > ===================================================================
> > 	RCS file:
> > /cvsroot/ribosome/build/umakepf/helix-client-s60-32-common.pfi,v
> > 	retrieving revision 1.6
> > 	diff -w -u -b -r1.6 helix-client-s60-32-common.pfi
> > 	--- helix-client-s60-32-common.pfi      5 Apr 2007
> > 18:40:48 -0000       1.6
> > 	+++ helix-client-s60-32-common.pfi      6 Jun 2007
> > 21:39:59 -0000
> > 	@@ -65,6 +65,7 @@
> >
> > 	 #Features in S60 3.2 platform
> >
> > 	+project.AddDefines('HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES')
> > 	 project.AddDefines('HELIX_FEATURE_DRM_SECURE_OUTPUT')
> > 	 project.AddDefines('HELIX_FEATURE_S60_PROGDOWN')
> > 	 project.AddDefines('HELIX_FEATURE_S60_VIDEO_CUSTOM_INTERFACE')
> >
> >
>
>
>_______________________________________________
>Helix-client-dev mailing list
>Helix-client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev

_________________________________________________________________
享用世界上最大的电子邮件系统— MSN Hotmail。  http://www.hotmail.com  


From pablo_hel at wp.pl  Tue Jun 12 15:11:46 2007
From: pablo_hel at wp.pl (=?ISO-8859-2?Q?Pawel_Mary=B6?=)
Date: Tue Jun 12 15:24:31 2007
Subject: [Helix-client-dev] RTCP NADU APP not send ???
Message-ID: <466f1a22008fd@wp.pl>

Hello

I read the text on the site
https://helix-client.helixcommunity.org/2005/devdocs/3G6-SOD-3gppRel6
and I am a little confused.
I compile Helix DNA SERVER 11.1 and Helix DNA Client HEAD
than I must to test 3gpp future in Helix implementation in my researches.
Don't know why I don't receive in this moment RTCP NADU APP packets for 
streaming content.

I am sorry for any language mistake in my message.
Please for help
Pawel

----------------------------------------------------
Wroc?aw Non Stop - eksplozja kultury we Wroc?awiu! 
22 czerwca - 1 lipca 2007. 
W ramach festiwalu wyst?pi? m.in. Iggy Pop & The Stooges!
wwW.wroclawnonstop.pl http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Figgypop.html&sid=1189



From mark.hingston at avegasystems.com  Tue Jun 12 16:53:04 2007
From: mark.hingston at avegasystems.com (mark)
Date: Tue Jun 12 17:03:54 2007
Subject: [Helix-client-dev] RM Internet Radio Questions
Message-ID: <1181692384.5584.3.camel@caolila>


Hi,

I'm working on implementing a client that is able to play real media
internet radio. I have two questions. I asked these questions on helix
irc, but was told to post my questions here for a more definitive
answer.

1. Can a Real Media internet radio stream change sample rate mid stream?
If so can anyone point me towards some documentation that specifies
how/when this happens?

2. Are there any radio stations out there that serve Real Media AAC
content? Thus far i can only find stations that serve Real Media streams
containing Cook content. Just trying to find out if i will need to
support AAC within the rm container to have full support for Real Media
internet radio.

If anyone can shed any light on these questions or point me in the right
direction, it would be most appreciated.

Thanks,
Mark.


From ehyche at real.com  Wed Jun 13 08:34:01 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Jun 13 08:46:29 2007
Subject: [Helix-client-dev] RM Internet Radio Questions
In-Reply-To: <1181692384.5584.3.camel@caolila>
References: <1181692384.5584.3.camel@caolila>
Message-ID: <002301c7add0$45155fe0$db68a8c0@EHYCHED620>


> -----Original Message-----
> From: helix-client-dev-bounces@helixcommunity.org 
> [mailto:helix-client-dev-bounces@helixcommunity.org] On Behalf Of mark
> Sent: Tuesday, June 12, 2007 7:53 PM
> To: helix-client-dev@helixcommunity.org
> Subject: [Helix-client-dev] RM Internet Radio Questions
> 
> 
> Hi,
> 
> I'm working on implementing a client that is able to play real media
> internet radio. I have two questions. I asked these questions on helix
> irc, but was told to post my questions here for a more definitive
> answer.
> 
> 1. Can a Real Media internet radio stream change sample rate 
> mid stream? If so can anyone point me towards some documentation that
specifies
> how/when this happens?
> 

I don't know that there are any radio stations that do that, but there
is no problem from the client's point-of-view with that
happening.

> 2. Are there any radio stations out there that serve Real Media AAC
> content? Thus far i can only find stations that serve Real 
> Media streams containing Cook content. Just trying to find out if i will
need to
> support AAC within the rm container to have full support for 
> Real Media internet radio.
> 

Certainly any radio station *could* broadcast using AAC, but they
would be targeting RealPlayer 10 and greater. I do not have access
to any statistics saying how many radio stations are using AAC,
but it's almost certain that you *should* support it, since 
any station *could* broadcast using AAC.

Eric

=============================================
Eric Hyche (ehyche@real.com)
Technical Lead
RealNetworks, Inc. 

> If anyone can shed any light on these questions or point me 
> in the right
> direction, it would be most appreciated.
> 
> Thanks,
> Mark.
> 
> 
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
> 


From ehyche at real.com  Wed Jun 13 08:38:02 2007
From: ehyche at real.com (Eric Hyche)
Date: Wed Jun 13 08:50:33 2007
Subject: [Helix-client-dev] RE: Trickplay 
In-Reply-To: <1F7C330B210B764DBBE8B2D749F9A5DB03FF13E2@daebe102.NOE.Nokia.com>
References: <1F7C330B210B764DBBE8B2D749F9A5DB03FF12B6@daebe102.NOE.Nokia.com>
	<00cb01c7a925$46fb8000$db68a8c0@EHYCHED620>
	<1F7C330B210B764DBBE8B2D749F9A5DB03FF13E2@daebe102.NOE.Nokia.com>
Message-ID: <002401c7add0$d4fde3c0$db68a8c0@EHYCHED620>


> -----Original Message-----
> From: gang.1.shen@nokia.com [mailto:gang.1.shen@nokia.com] 
> Sent: Thursday, June 07, 2007 2:36 PM
> To: ehyche@real.com; helix-client-dev@helixcommunity.org
> Subject: RE: Trickplay 
> 
> 
> Thanks a lot. That answers my question. 
> 
> It looks like there is a need for renderer to selectively push frames
> (non-key frames) to decoders based on magnitude of velocity, for
> all-frames mode. That would save decoder from decoding frames that are
> supposed to be skipped. Is that what Helix has in its video renderer?
> Btw, my concern is on our MDF renderer; we'd like to see how Helix
> renderer works. 
> 

In the base video renderer (from which the RealVideo renderer and
MP4 video renderer and WMV renderer derive), we have decided to
try and render as much as we can in all-frames mode before switching
to keyframe mode. Of course, the TLC can override this decision
by simply setting keyframe mode to TRUE when it calls SetVelocity().
If you *know* on your platform, for instance, that all-frames mode
is not feasible beyond 1x or 2x then you can always have the TLC
enforce that when it calls SetVelocity.

Eric

> -GS
> 
> -----Original Message-----
> From: ext Eric Hyche [mailto:ehyche@real.com] 
> Sent: Thursday, June 07, 2007 12:00 PM
> To: Shen Gang.1 (Nokia-TP-MSW/Dallas);
> helix-client-dev@helixcommunity.org
> Subject: RE: Trickplay 
> 
> 
> The renderer makes the decision about when frames are dropped. If the
> user specified that it should autoswitch from all-frames mode to
> keyframe-mode, then the renderer will try to play all the 
> frames it can.
> When it realizes that it is dropping frames about a certain rate, then
> it will tell the client core that it wants to go to keyframe-mode. At
> that point, the client core tells the file format plugin that it is
> going to keyframe mode.
> 
> The file format may or may not at that point start providing just
> keyframes. But the fileformat proxy in the client core will from that
> point on filter out everything but keyframe packets.
> 
> Does that answer your question?
> 
> Eric
> 
> =============================================
> Eric Hyche (ehyche@real.com)
> Technical Lead
> RealNetworks, Inc.  
> 
> > -----Original Message-----
> > From: gang.1.shen@nokia.com [mailto:gang.1.shen@nokia.com]
> > Sent: Thursday, June 07, 2007 12:42 PM
> > To: ehyche@real.com; helix-client-dev@helixcommunity.org
> > Subject: Trickplay
> > 
> > Hi, Eric,
> > 
> > I have a question regarding "trickplay" design in 
> > https://helix-client.helixcommunity.org/nonav/2005/devdocs/TKP
> > -SOD-001-TrickPlay.html
> >  > P-SOD-001-TrickPlay.html> .
> > 
> > How does Helix avoid a overflow during fast forward? If fileformat 
> > (optionally) deliver packets differently based on the 
> magnitude of the
> 
> > playback velocity, there would be more packets delivered to video 
> > renderer than needed in a fast forward playback. Which 
> component will 
> > drop these extra frames?
> > 
> > Thanks,
> > 
> > Gang Shen
> > 
> > 
> 


From mangeshsk at gmail.com  Wed Jun 13 21:52:04 2007
From: mangeshsk at gmail.com (Mangesh Kulkarni)
Date: Wed Jun 13 22:04:25 2007
Subject: [Helix-client-dev] [INFO] Basic Video Renderer
Message-ID: 

Hello,
I'm working on porting Helix DNA Client for ARM.
I'm looking out for any statement of design or any design documents
related to Basic Video Renderer and also any API documents if any.

Any pointers are most welcome.

Thanks
Mangesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070614/69d1cad9/attachment.html
From milko at real.com  Tue Jun 19 15:10:57 2007
From: milko at real.com (Milko Boic)
Date: Tue Jun 19 15:21:58 2007
Subject: [Helix-client-dev] CR-Client: Atlas port to Mac
Message-ID: <6.2.1.2.2.20070619150838.09ec51e0@mailone.real.com>


Modified by: milko@real.com
Date: 06:19:07
Project: Atlas on Mac

Synopsis: Nimbus support for Firefox on Mac

Overview:
The change allows execution of video Atlas based Firefox plugins on Mac.
The need for changes stems from different GUI/graphics framework Firefox
was built with in contrast to Safari.

Firefox is much more QuickDraw intensive in manipulating GrafPort origins and
clipping regions which exposed few additional areas in the code that needed
to be properly managed for origin and clipping region changes.

Files Modified:
/video/sitelib/platform/mac/macsite.cpp
/video/sitelib/platform/mac/macsurf.cpp
/video/sitelib/pub/platform/mac/macsite.h
/video/sitelib/pub/platform/mac/macsurf.h

Image Size and Heap Use impact (Client -Only):
Small increase.

Platforms and Profiles Affected:
All

Distribution Libraries Affected:
none

Distribution library impact and planned action:
n/a

Platforms and Profiles Build Verified:
system id: macos-gcc4-xcode22,
target: LitePlayer
profile: helix-client-playerx
branch: playerx
Options: nodll

Windows will be verified after check-in.

Platforms and Profiles Functionality verified:
OS-X

Linux and Windows will be verified after check-in.

Branches:
HEAD




-------------- next part --------------
A non-text attachment was scrubbed...
Name: video_diffs9.txt
Type: application/octet-stream
Size: 13121 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20070619/067f13be/video_diffs9-0001.obj
-------------- next part --------------

From gwright at real.com  Tue Jun 19 15:25:40 2007
From: gwright at real.com (Greg Wright)
Date: Tue Jun 19 15:36:36 2007
Subject: [Helix-client-dev] CR-Client: Atlas port to Mac
In-Reply-To: <6.2.1.2.2.20070619150838.09ec51e0@mailone.real.com>
References: <6.2.1.2.2.20070619150838.09ec51e0@mailone.real.com>
Message-ID: <467857E4.90702@real.com>

Looks good.
--greg.


Milko Boic wrote:
> 
> Modified by: milko@real.com
> Date: 06:19:07
> Project: Atlas on Mac
> 
> Synopsis: Nimbus support for Firefox on Mac
> 
> Overview:
> The change allows execution of video Atlas based Firefox plugins on Mac.
> The need for changes stems from different GUI/graphics framework Firefox
> was built with in contrast to Safari.
> 
> Firefox is much more QuickDraw intensive in manipulating GrafPort 
> origins and
> clipping regions which exposed few additional areas in the code that needed
> to be properly managed for origin and clipping region changes.
> 
> Files Modified:
> /video/sitelib/platform/mac/macsite.cpp
> /video/sitelib/platform/mac/macsurf.cpp
> /video/sitelib/pub/platform/mac/macsite.h
> /video/sitelib/pub/platform/mac/macsurf.h
> 
> Image Size and Heap Use impact (Client -Only):
> Small increase.
> 
> Platforms and Profiles Affected:
> All
> 
> Distribution Libraries Affected:
> none
> 
> Distribution library impact and planned action:
> n/a
> 
> Platforms and Profiles Build Verified:
> system id: macos-gcc4-xcode22,
> target: LitePlayer
> profile: helix-client-playerx
> branch: playerx
> Options: nodll
> 
> Windows will be verified after check-in.
> 
> Platforms and Profiles Functionality verified:
> OS-X
> 
> Linux and Windows will be verified after check-in.
> 
> Branches:
> HEAD
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev


From milko at real.com  Fri Jun 22 12:52:52 2007
From: milko at real.com (Milko Boic)
Date: Fri Jun 22 13:03:03 2007
Subject: [Helix-client-dev] CN-Client: Atlas port to Mac
Message-ID: <6.2.1.2.2.20070622125244.03e57b38@mailone.real.com>


Modified by: milko@real.com
Date: 06:19:07
Project: Atlas on Mac

Synopsis: Nimbus support for Firefox on Mac

Overview:
The change allows execution of video Atlas based Firefox plugins on Mac.
The need for changes stems from different GUI/graphics framework Firefox
was built with in contrast to Safari.

Firefox is much more QuickDraw intensive in manipulating GrafPort origins and
clipping regions which exposed few additional areas in the code that needed
to be properly managed for origin and clipping region changes.

Files Modified:
/video/sitelib/platform/mac/macsite.cpp
/video/sitelib/platform/mac/macsurf.cpp
/video/sitelib/pub/platform/mac/macsite.h
/video/sitelib/pub/platform/mac/macsurf.h

Image Size and Heap Use impact (Client -Only):
Small increase.

Platforms and Profiles Affected:
All

Distribution Libraries Affected:
none

Distribution library impact and planned action:
n/a

Platforms and Profiles Build Verified:
system id: macos-gcc4-xcode22,
target: LitePlayer
profile: helix-client-playerx
branch: playerx
Options: nodll

Windows will be verified after check-in.

Platforms and Profiles Functionality verified:
OS-X

Linux and Windows will be verified after check-in.

Branches:
HEAD






From Mala.Shivaprasad at motorola.com  Mon Jun 25 07:14:40 2007
From: Mala.Shivaprasad at motorola.com (Shivaprasad Mala-A12814)
Date: Mon Jun 25 07:25:16 2007
Subject: [Helix-client-dev] Query on Helix Client
Message-ID: <0B28F3C8F2581D419709A71814CA59D701830952@ZMY16EXM67.ds.mot.com>


Hi,

I am application developer and just signed in to the Helix community. 
I need to develop an application which would do the following:
- Streaming playback control, i.e., play, pause, stop with my own RTSP
and not with the RTSP provided in Helix.
- Use my own signalling stack, e.g, SIP, to establish a streaming
session
- Use the GUI and RTP/RTCP provided by Helix engine

My query is does Helix provide support 
- To put in our own RTSP, remove/disable RTSP with Helix client? 
- Does Helix support SIP?
- Can we interface our SIP/RTSP with the RTP/RTCP provided by Helix?

With regards,
-Mala.

From milko at real.com  Mon Jun 25 21:51:54 2007
From: milko at real.com (Milko Boic)
Date: Mon Jun 25 22:01:17 2007
Subject: [Helix-client-dev] Query on Helix Client
In-Reply-To: <0B28F3C8F2581D419709A71814CA59D701830952@ZMY16EXM67.ds.mot .com>
References: <0B28F3C8F2581D419709A71814CA59D701830952@ZMY16EXM67.ds.mot.com>
Message-ID: <6.2.1.2.2.20070625214102.03d48be0@mailone.real.com>

At 07:14 AM 6/25/2007, Shivaprasad Mala-A12814 wrote:

>Hi,
>
>I am application developer and just signed in to the Helix community.
>I need to develop an application which would do the following:
>- Streaming playback control, i.e., play, pause, stop with my own RTSP
>and not with the RTSP provided in Helix.
>- Use my own signalling stack, e.g, SIP, to establish a streaming
>session
>- Use the GUI and RTP/RTCP provided by Helix engine
>
>My query is does Helix provide support
>- To put in our own RTSP, remove/disable RTSP with Helix client?

RTSP and RTP (transport) are not in separate higher level modules.
Replacement of RTSP would need to occur at class level and be fairly involved.

Disabling of RTSP stack should be easily doable.

>- Does Helix support SIP?

No.

>- Can we interface our SIP/RTSP with the RTP/RTCP provided by Helix?

Not as is.  However, it would work with some fairly minor modifications.
The route I would propose is to modify Helix to allow it operate in 
RTSP-less mode when launched via SDP file.  This should not be hard as it 
should involve simply skipping through the states in RTSP state machine.
Thus, Helix would use its RTSP stack in "silent" mode.

Singling of RTSP silent mode is up for discussion.
It can be communicated in the Helix request header via a custom property, 
for example.

Milko


>With regards,
>-Mala.
>
>_______________________________________________
>Helix-client-dev mailing list
>Helix-client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev



From nirajkale9 at gmail.com  Wed Jun 27 02:55:30 2007
From: nirajkale9 at gmail.com (Niraj Kale)
Date: Wed Jun 27 03:04:33 2007
Subject: [Helix-client-dev] payload type 101
Message-ID: 

Hi,
I am trying to implement RTSP client for BREW.
I am getting data from Helix server RTSP protocol.
It sends data in RTP format and gives payload type 101. I save the
data in a file. and try to play it back. but it gives wrong result.
Please inform how to decode payload type 101.

Thanks,

From weima.gm at gmail.com  Thu Jun 28 01:27:48 2007
From: weima.gm at gmail.com (wei ma)
Date: Thu Jun 28 01:37:21 2007
Subject: [Helix-client-dev] jsr135 kit build problem
Message-ID: <46837104.1070908@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have sent a same email to player dev, just found that client dev may
be a better place for this question.

Greetings,
   I have tried to build jsr135 on an Open SUSE machine.

The following is my environment
==============================================
Build System (V2.4.7)
time: Thu Jun 28 11:08:56 2007
outfile: build.out
branch: helix
platform: linux-2.2-libc6-i586
distribution/archive from: linux-2.2-libc6-i386
build Type: debug
build options: debug
profile: /home/weima/cvs/build/umakepf/helix-client-all-defines
copy target: debug
target(s): jsr135kit
$Id: umake.py,v 1.60 2007/06/13 01:12:50 jfinnecy Exp $
C Compiler: gcc
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
- --with-local-prefix=/usr/local --infodir=/usr/share/info
- --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
- --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
- --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
- --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
- --with-system-zlib --enable-shared --enable-__cxa_atexit
- --enable-libstdcxx-allocator=new --program-suffix=-4.1
- --enable-version-specific-runtime-libs --without-system-libunwind
- --with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)

C++ Compiler: g++
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
- --with-local-prefix=/usr/local --infodir=/usr/share/info
- --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
- --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
- --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
- --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
- --with-system-zlib --enable-shared --enable-__cxa_atexit
- --enable-libstdcxx-allocator=new --program-suffix=-4.1
- --enable-version-specific-runtime-libs --without-system-libunwind
- --with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
================================================================

Build System Menu
Ribosome v2.4.7
- -> Current Directory: /home/weima/cvs/helix10
[0] Set BIF branch (helix)
[1] Set Target(s) (jsr135kit)
[2] Set Profile (helix-client-all-defines)
[3] run: build
[4] Toggle make depend & makefiles (-e -n)
[5] Toggle release (-trelease)
[6] Toggle 'make clean'  (-c)
[7] Toggle clobber (Dangerous!) (-C)
[8] Toggle halt-on-error (-p green)
[9] Toggle verbose mode (-v)
[10] Toggle static build (-tnodll)
[11] Checkout source for selected target now
[12] Set Tag/Branch/Timestamp
[13] Help Page (full help in build/doc/index.html)
[14] run history: build
[Q] Quit
Enter selection or flags:


I got two build errors. Following is the error message from build.out

================================================
make[1]: Entering directory
`/home/weima/cvs/helix10/datatype/flash/flashhost'
g++ --permissive -pipe -W -Wreturn-type -fno-rtti -fno-exceptions
- -mcpu=pentium -march=pentium  -O0 -g -DDEBUG -D_DEBUG
- -I../../../common/runtime/pub -I/usr/X11R6/include
- -I../../../common/include -I../../../common/dbgtool/pub
- -I../../../common/fileio/pub -I../../../common/lang/xml/pub
- -I../../../common/util/pub -I../../../common/container/pub
- -I../../../common/system/pub -I../../../common/log/logutil/pub
- -I../../../client/common/system/pub -I../../../client/core
- -I../../../client/core/pub -I../../../datatype/smil/include
- -I../../../client/include -I../../../datatype/common/basehost/pub
- -I../../../datatype/flash/flv/common/pub -I../../../video/include
- -I../../../video/colconverter/pub -I../../../video/sitelib/pub
- -I../../../common/import/gecko-sdk/version_1_8_0_4/linux/include -I./pub
- -I. -include dbg/datatype_flash_flashhost_flashhostlib_ribodefs.h -fPIC
- -DPIC -o dbg/obj/flashhostlib/flash_guest_player_ns.o -c
flash_guest_player_ns.cpp
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
flash_guest_player_ns.cpp: In member function ?virtual HX_RESULT
CFlashGuestPlayerNS::AttachWindow(HXxWindow*)?:
flash_guest_player_ns.cpp:1271: error: ?m_hdc? was not declared in this
scope
flash_guest_player_ns.cpp:1276: error: ?m_hwnd? was not declared in this
scope
flash_guest_player_ns.cpp: In static member function ?static bool
CFlashGuestPlayerNS::NPN_Invoke(NPP_t*, NPObject*, void*, const
NPVariant*, uint32_t, NPVariant*)?:
flash_guest_player_ns.cpp:2613: error: exception handling disabled, use
- -fexceptions to enable
make[1]: *** [dbg/obj/flashhostlib/flash_guest_player_ns.o] Error 1
make[1]: Leaving directory
`/home/weima/cvs/helix10/datatype/flash/flashhost'
make: *** [copy] Error 2
Time used: 2.50 seconds
ERROR: UNIXCompile(datatype/flash/flashhost) ERROR: Make failed.

- --- Build System Error ------------------------------------
Make failed.
.
.
.
entering directory player/kit/jsr135
UNIXCompile(player/kit/jsr135): generating makefiles
UMAKE: Umakefil -> Makefile in player/kit/jsr135
UMAKE: Applying profile
/home/weima/cvs/build/umakepf/helix-client-all-defines.pf
ERROR: UNIXCompile(player/kit/jsr135) ERROR: dll target without exported
functions

- --- Build System Error ------------------------------------
dll target without exported functions
- -----------------------------------------------------------
.
========================================================

I understand that jsr135 was built on Windows System, and I may have to
modify the source code to compile it on Linux. I am wondering what
should I do to solve the build problem with flash_guest_player_ns.cpp.

Thanks.
Wei



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGg3EEH3K/m+A7SqQRAjRFAJ46siIS6hBaBLYQYN+vbtMaq2fVUwCfZIr8
12ITf+dwHLOU2HBUfqTvBIU=
=Y9JZ
-----END PGP SIGNATURE-----

 

Site Map   |   Terms of Use   |   Privacy Policy   |   Contact Us

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.