From mahmoudhammoud at gmail.com Mon Sep 1 05:29:19 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Mon Sep 1 03:50:51 2008
Subject: [Helix-client-dev] Re: Threads
In-Reply-To: <48B831EE.6070501@real.com>
References: <209f73910808270922w7904207chd5f55a0f0c239127@mail.gmail.com>
<48B5C57C.20907@real.com>
<209f73910808291021iea166fam2ade088f4b866fc2@mail.gmail.com>
<48B831EE.6070501@real.com>
Message-ID: <209f73910809010529kca8936age8a0951fcfce9aa7@mail.gmail.com>
Thanks a lot Greg for your time and support. So are HXEvent's functions
GetMessage and PostMessage the right things to look at in my case? What
about the Wait() and SignalEvent() functions? How should they exacly be
used? A small example would be very helpful.
Regards,
Mahmoud
On Fri, Aug 29, 2008 at 7:29 PM, Greg Wright wrote:
> Mahmoud Hammoud wrote:
>
>> Thanks Greg,
>> I took a look at the code and now I think I managed to create my own
>> thread to perform some operations in the background. Just a small question
>> on the subject: Suppose I want to know if a specific event has occured in
>> that thread (e.g. a condition is now satisfied, or a specific message has
>> been received...), is there a straightforward way to do that?
>>
>
> Sounds like you just need any of a number of inter-thread communication
> techniques. Depending on what you need you can use mutex-guarded
> member vars, events, semaphores. We also often use the scheduler
> to arrange callbacks onto the main app thread. You can use this to
> call back into some class when a certain event happens. Take a look
> at the helix code for Scheduler->, RelativeEnter and other calls.
>
> --greg.
>
> Thanks again,
>> Mahmoud
>>
>> On Wed, Aug 27, 2008 at 11:22 PM, Greg Wright > gwright@real.com>> wrote:
>>
>> Mahmoud Hammoud wrote:
>>
>> Dear all,
>> I would like to create my own additional thread to do some
>> things within rtspclnt.cpp. I tried to add a HXThread * data
>> member m_pMyThread to the RTSPClientProtocol class and then at
>> the point where I want to start the thread, I am calling
>> HXThread::MakeThread(m_pMyThread) and then
>> m_pMyThread->CreateThread(MyRoutine, this). This result in an
>> HX_ASSERT error which eventually leads the client to crash. I
>> guess I am missing something here (what please?). Should
>> MyRoutine have a special structure? Can someone give me a brief
>> step by step guide on how to create, start and manage a thread?
>> The "Threading Model" document on the Helix Community web pages
>> provides only an abstract overview, I would really appreciate
>> your help.
>>
>>
>> The best source of information is other parts of the code base the
>> use threads. It would help to know what your assert is.
>>
>> Also, be aware that you are not free to call into the engine on
>> any given thread you want, very little of it is actually thread
>> safe that way.
>>
>> --greg.
>>
>>
>> Best Regards,
>> Mahmoud Hammoud
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080901/a2aafc7c/attachment.html
From js at reciva.com Tue Sep 2 03:50:36 2008
From: js at reciva.com (John Stirling)
Date: Tue Sep 2 02:15:36 2008
Subject: [Helix-client-dev] preventing aac playback
Message-ID: <48BD1A7C.9080207@reciva.com>
We've been applying this patch in order to selectively disable playback
of AAC content.
This does prevent AAC content from playing. It currently just starts the
stream, doesn't play anything and sticks there without reporting any
errors to the TLC. We'd like it to behave as if the raac.so plugin
didn't exist (HXR_NO_RENDERER).
I've tried a few things, but can't seem to find the correct thing to
make this work. Can someone advise on how to do this.
John
-------------- next part --------------
? datatype/aac/codec/fixpt/decoder/Makefile
? datatype/aac/codec/fixpt/decoder/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/armv4l-rel
? datatype/aac/codec/fixpt/decoder/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/Makefile
? datatype/aac/codec/fixpt/decoder/hxwrap/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/armv4l-rel
? datatype/aac/codec/fixpt/decoder/hxwrap/raac.exp
? datatype/aac/codec/fixpt/decoder/hxwrap/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/rlink
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.upp
? datatype/aac/fileformat/Makefile
? datatype/aac/fileformat/Umakefil.upp
? datatype/aac/fileformat/aacff.exp
? datatype/aac/fileformat/aacffdll.mak
? datatype/aac/fileformat/aacffdll.upp
? datatype/aac/fileformat/armv4l-rel
? datatype/aac/fileformat/rel
? datatype/aac/fileformat/rlink
? datatype/aac/parser/Makefile
? datatype/aac/parser/Umakefil.upp
? datatype/aac/parser/armv4l-rel
? datatype/aac/parser/rel
? datatype/aac/payload/Makefile
? datatype/aac/payload/Umakefil.upp
? datatype/aac/payload/armv4l-rel
? datatype/aac/payload/rel
Index: datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp
===================================================================
RCS file: /nexus/proj/InternetRadio/cvs/helix_cayenne_20070820/datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 aacdecdll.cpp
--- datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 1 Jul 2008 15:35:05 -0000 1.1.1.1
+++ datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 2 Sep 2008 10:46:15 -0000
@@ -46,6 +46,10 @@
#include "aacdecdll.h"
#include "aacconstants.h"
+#include
+#include
+#include
+
const char* const CAACDec::m_pszCodecName = "RealAudio 10";
CAACDec::CAACDec()
@@ -80,6 +84,15 @@
//
STDMETHODIMP CAACDec::QueryInterface(REFIID riid, void** ppvObj)
{
+ /* This file controls whether we are allowed to use the AAC plugin */
+ #define ENABLE_FILE "/tmp/enable_plugin_aac"
+
+ /* Only allow AAC plugin to be used if there if file
+ * /tmp/enable_plugin_aac exists */
+ struct stat s;
+ if (stat(ENABLE_FILE, &s) == 0)
+ {
+ printf("HELIX: AAC Plugin Manually Enabled\n");
if (IsEqualIID(riid, IID_IHXAudioDecoder))
{
AddRef();
@@ -92,6 +105,11 @@
*ppvObj = this;
return HXR_OK;
}
+ }
+ else
+ {
+ printf("HELIX: AAC Plugin Manually Disabled\n");
+ }
*ppvObj = NULL;
From mahmoudhammoud at gmail.com Wed Sep 3 04:58:58 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Wed Sep 3 03:19:59 2008
Subject: [Helix-client-dev] Threads Again
Message-ID: <209f73910809030458x7301dc89r6be1f6fcbdc6c99c@mail.gmail.com>
Dear Greg, All,
When I try to define a new member ?n RTSPClientProtocol of type HXThread*
(to create a thread from within the class and perform some background
operations...), I get the following error when I stream the file from the
server:
Report(3, -2147221308, "Unable to play request. Internal stream error.
rtsp://127.0.0.1:1554/hulk.mp4", 0, "(NULL)", "HXR_SERVER_ALERT")
Why is this happening, although the thread is being successfully created
(I'm calling HXThread::MakeThread, and then
m_pMyThread->CreateThread(MyThreadRoutine, (void *)this))? I'm getting this
error even if I dont actually create the thread, that is, only by defining
the member as part of the RTSPClientProtocol class. Did I miss something
here? Creating threads as part of threngin.cpp doesnt cause any problems,
but then I have to find a communication pathway between the thread created
over there and the RTSPClientProtocol class, hence my current situation.
Thanks,
Mahmoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080903/42bf352c/attachment-0001.html
From js at reciva.com Thu Sep 4 03:29:18 2008
From: js at reciva.com (John Stirling)
Date: Thu Sep 4 01:53:49 2008
Subject: [Helix-client-dev] http fsys - dlna compliance 7.4.32.2 -
MTMaximum Byte Size Transfers
In-Reply-To: <005601c8d0c5$5db61d50$e58e17ac@EHYCHED620>
References: <4857E3DC.9010502@reciva.com> <4857ED01.4030708@real.com>
<4857EE41.5030107@reciva.com>
<005601c8d0c5$5db61d50$e58e17ac@EHYCHED620>
Message-ID: <48BFB87E.4020202@reciva.com>
We tested with an atlas build and it still crashes.
We're getting fairly close to needing to get this fixed.
Is helix used in any DLNA certified products ? It seems like this would
be a fairly common requirement , at least for the bigger brands. So any
chance this could get fixed by someone at helix/real ? If not, could
someone more familiar with httpfsys give us some assistance in fixing this ?
John
Eric Hyche wrote:
> I would guess that Content-Length's or Chunked-Encoding-Size's
> greater than 4GB will be a problem. Content-Length is probably
> not as big of a problem.
>
> Eric
>
> =============================================
> 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 John Stirling
>> Sent: Tuesday, June 17, 2008 1:03 PM
>> To: Greg Wright
>> Cc: helix-client-dev@helixcommunity.org
>> Subject: Re: [Helix-client-dev] http fsys - dlna compliance
>> 7.4.32.2 - MTMaximum Byte Size Transfers
>>
>> Greg Wright wrote:
>>
>>> John Stirling wrote:
>>>
>>>> We're running our cayene build through the DLNA compliance
>>>>
>> test suite.
>>
>>>> There is a requirement to handle content-length, chunk-size, range
>>>> fields with values up to 2^48. Currently this test crashes helix -
>>>> the crash point being an attempt to dynamically allocate 2Gb in
>>>> CHTTPFileObject::DecodeChunkedEncoding. It looks like
>>>>
>> helix is only
>>
>>>> set upo to deal with a max of 2^32 currently ?
>>>>
>>>> Before I look into this in detail, is anyone aware if this
>>>>
>> has been
>>
>>>> fixed in a later version of httpfsys ? If not, any pointers to an
>>>> easy fix appreciated. I'm currently assuming that converting
>>>> appropriate variables in httpfsys to u64 will probably do it (I'm
>>>> working on the defintion of 'appropriate')
>>>>
>>> I assume it is crashing because the alloc returns NULL (no
>>>
>> alloc that
>>
>>> size possible) and the NULL is de-refed?
>>>
>>> We did do some work in this area to detect bad chunk sizes
>>>
>> I remember.
>>
>>> And, that method on 310Atlas is different then on 150Cay.
>>>
>> So, my guess
>>
>>> would be yes. You still wouldn't be able to just alloc any amount of
>>> memory you want, but it shouldn't crash. The only way to
>>>
>> tell though,
>>
>>> for you case, is to test it.
>>>
>>>
>> Apart from avoiding this specific crash, do you think atlas is also
>> likely to handle content-length, chunk-size etc values
>> greater than 32 bit ?
>>
>>
>>> --greg.
>>>
>>>
>>>
>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Helix-client-dev mailing list
>>>> Helix-client-dev@helixcommunity.org
>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>
>>>>
>> _______________________________________________
>> 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/20080904/017991e8/attachment.html
From milko at real.com Fri Sep 5 21:47:04 2008
From: milko at real.com (Milko Boic)
Date: Fri Sep 5 20:07:58 2008
Subject: [Helix-client-dev] Re: [Masf-restricted-dev] CR/CN: Fixed
thread-safety issues in HXScheduler
In-Reply-To: <9b8350410809051814i242b4335lf74aaf943194f20b@mail.gmail.co
m>
References: <9b8350410809051814i242b4335lf74aaf943194f20b@mail.gmail.com>
Message-ID: <6.2.1.2.2.20080905214222.0d226138@mailone.real.com>
Excellent find and fix!!!
Please commit to the following additional branches as well:
hxclient_3_1_0_atlas
HEAD
Thanks,
Milko
At 06:14 PM 9/5/2008, Petar Basic wrote:
>Modified by: pbasic at real.com
>Date: 2008/09/06
>Project: strummer
>
>Synopsis:
>Fixed thread-safety issues in HXScheduler
>
>Details:
>There was a race condition in ClientPQ class.
>ClientPQ is derived from PQ which accepts CHXID object as an argument
>to the constructor. ClientPQ is obviously designed as a thread-safe
>wrapper around PQ, but each instance of ClientPQ uses its own mutex
>object. However, this is not enough. Since CHXID object can be
>shared among PQ instances, it must be protected by a single mutex.
>Instantiations of ClientPQ in HXScheduler are critical to this case
>since HXScheduler uses 3 ClientPQ objects which share a single CHXID.
>HXOptimizedScheduler currently uses only 1 ClientPQ object.
>
>1.) Additional assert statements which can detect race condition have
>been added to CHXID class.
>2.) ClientPQ is modified to accept externally created mutex. In this
>way CHXID object can be protected through common mutex by multiple
>ClientPQ instances.
>3.) Destruction of PQ base in ClientPQ destructor has been made thread-safe.
>4.) HXScheduler has been modified to use a single mutex with all of
>its ClientPQ instances.
>5.) Although it was not necessary at this time, HXOptimizedScheduler
>has been modified in the same way as HXScheduler to prepare it for
>possible future updates.
>
>Testing:
>Performed over 1200 transcoding transfers to USB memory during single
>VFMM session without crashes or lockups. Also performed simultaneous
>transfers to 2 USB devices without crashes or lockups.
>
>Files Modified:
>common/util/pub/id.h
>common/system/pub/pq.h
>common/system/pq.cpp
>client/common/system/pub/clientpq.h
>client/common/system/clientpq.cpp
>client/common/system/pub/hxsched.h
>client/common/system/hxsched.cpp
>client/common/system/pub/hxoptsc.h
>client/common/system/hxoptsc.cpp
>
>Platforms and Profiles Build Verified:
>system id: win32-i386-vc7
>profile: helix-dtdr-all-defines
>
>Platforms and Profiles Functionality Verified:
>x86 Windows XP SP2
>
>Branch:
>hxclient_3_4_0_atlas
>
>Copyright assignment:
>I am a RealNetworks employee or contractor.
>
>Content-Type: application/octet-stream; name="common_util.diff"
>X-Attachment-Id: f_fkrjl7q00
>Content-Disposition: attachment; filename=common_util.diff
>
>Content-Type: application/octet-stream; name="common_system.diff"
>X-Attachment-Id: f_fkrjlb201
>Content-Disposition: attachment; filename=common_system.diff
>
>Content-Type: application/octet-stream; name="client_common_system.diff"
>X-Attachment-Id: f_fkrjld282
>Content-Disposition: attachment; filename=client_common_system.diff
>
>_______________________________________________
>Masf-restricted-dev mailing list
>Masf-restricted-dev@lists.helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/masf-restricted-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080905/c1529f7d/attachment.html
From pbasic at real.com Sun Sep 7 04:55:32 2008
From: pbasic at real.com (Petar Basic)
Date: Sun Sep 7 03:15:39 2008
Subject: [Helix-client-dev] CR/CN: Fixed thread-safety issues in HXScheduler
In-Reply-To: <9b8350410809051814i242b4335lf74aaf943194f20b@mail.gmail.com>
References: <9b8350410809051814i242b4335lf74aaf943194f20b@mail.gmail.com>
Message-ID: <9b8350410809070455h788ce994s8ab03008893d4f61@mail.gmail.com>
Modified by: pbasic at real.com
Reviewed by: milko, gwright
Date: 2008/09/06
Project: strummer
Synopsis:
Fixed thread-safety issues in HXScheduler
Details:
There was a race condition in ClientPQ class.
ClientPQ is derived from PQ which accepts CHXID object as an argument
to the constructor. ClientPQ is obviously designed as a thread-safe
wrapper around PQ, but each instance of ClientPQ uses its own mutex
object. However, this is not enough. Since CHXID object can be
shared among PQ instances, it must be protected by a single mutex.
Instantiations of ClientPQ in HXScheduler are critical to this case
since HXScheduler uses 3 ClientPQ objects which share a single CHXID.
HXOptimizedScheduler currently uses only 1 ClientPQ object.
1.) Additional assert statements which can detect race condition have
been added to CHXID class.
2.) ClientPQ is modified to accept externally created mutex. In this
way CHXID object can be protected through common mutex by multiple
ClientPQ instances.
3.) Destruction of PQ base in ClientPQ destructor has been made thread-safe.
4.) HXScheduler has been modified to use a single mutex with all of
its ClientPQ instances.
5.) Although it was not necessary at this time, HXOptimizedScheduler
has been modified in the same way as HXScheduler to prepare it for
possible future updates.
Testing:
Performed over 1200 transcoding transfers to USB memory during single
VFMM session without crashes or lockups. Also performed simultaneous
transfers to 2 USB devices without crashes or lockups.
Files Modified:
common/util/pub/id.h
common/system/pub/pq.h
common/system/pq.cpp
client/common/system/pub/clientpq.h
client/common/system/clientpq.cpp
client/common/system/pub/hxsched.h
client/common/system/hxsched.cpp
client/common/system/pub/hxoptsc.h
client/common/system/hxoptsc.cpp
Platforms and Profiles Build Verified:
system id: win32-i386-vc7
profile: helix-dtdr-all-defines
Platforms and Profiles Functionality Verified:
x86 Windows XP SP2
Branch:
HEAD
hxclient_3_4_0_atlas
hxclient_3_1_0_atlas
Copyright assignment:
I am a RealNetworks employee or contractor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_util.diff
Type: application/octet-stream
Size: 2078 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080907/28d60412/common_util-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_system.diff
Type: application/octet-stream
Size: 2354 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080907/28d60412/common_system-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_common_system.diff
Type: application/octet-stream
Size: 10121 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080907/28d60412/client_common_system-0001.obj
From pbasic at real.com Sun Sep 7 05:02:54 2008
From: pbasic at real.com (Petar Basic)
Date: Sun Sep 7 03:22:56 2008
Subject: [Helix-client-dev] Re: [Masf-restricted-dev] CR/CN: Fixed
thread-safety issues in HXScheduler
In-Reply-To: <6.2.1.2.2.20080905214222.0d226138@mailone.real.com>
References: <9b8350410809051814i242b4335lf74aaf943194f20b@mail.gmail.com>
<6.2.1.2.2.20080905214222.0d226138@mailone.real.com>
Message-ID: <9b8350410809070502y65d81cf6na7e530f0c8d74f5c@mail.gmail.com>
Commited to:
HEAD
hxclient_3_4_0_atlas
hxclient_3_1_0_atlas
Petar
On Sat, Sep 6, 2008 at 6:47 AM, Milko Boic wrote:
>
> Excellent find and fix!!!
>
> Please commit to the following additional branches as well:
> hxclient_3_1_0_atlas
> HEAD
>
> Thanks,
> Milko
>
> At 06:14 PM 9/5/2008, Petar Basic wrote:
>
> Modified by: pbasic at real.com
> Date: 2008/09/06
> Project: strummer
>
> Synopsis:
> Fixed thread-safety issues in HXScheduler
>
> Details:
> There was a race condition in ClientPQ class.
> ClientPQ is derived from PQ which accepts CHXID object as an argument
> to the constructor. ClientPQ is obviously designed as a thread-safe
> wrapper around PQ, but each instance of ClientPQ uses its own mutex
> object. However, this is not enough. Since CHXID object can be
> shared among PQ instances, it must be protected by a single mutex.
> Instantiations of ClientPQ in HXScheduler are critical to this case
> since HXScheduler uses 3 ClientPQ objects which share a single CHXID.
> HXOptimizedScheduler currently uses only 1 ClientPQ object.
>
> 1.) Additional assert statements which can detect race condition have
> been added to CHXID class.
> 2.) ClientPQ is modified to accept externally created mutex. In this
> way CHXID object can be protected through common mutex by multiple
> ClientPQ instances.
> 3.) Destruction of PQ base in ClientPQ destructor has been made thread-safe.
> 4.) HXScheduler has been modified to use a single mutex with all of
> its ClientPQ instances.
> 5.) Although it was not necessary at this time, HXOptimizedScheduler
> has been modified in the same way as HXScheduler to prepare it for
> possible future updates.
>
> Testing:
> Performed over 1200 transcoding transfers to USB memory during single
> VFMM session without crashes or lockups. Also performed simultaneous
> transfers to 2 USB devices without crashes or lockups.
>
> Files Modified:
> common/util/pub/id.h
> common/system/pub/pq.h
> common/system/pq.cpp
> client/common/system/pub/clientpq.h
> client/common/system/clientpq.cpp
> client/common/system/pub/hxsched.h
> client/common/system/hxsched.cpp
> client/common/system/pub/hxoptsc.h
> client/common/system/hxoptsc.cpp
>
> Platforms and Profiles Build Verified:
> system id: win32-i386-vc7
> profile: helix-dtdr-all-defines
>
> Platforms and Profiles Functionality Verified:
> x86 Windows XP SP2
>
> Branch:
> hxclient_3_4_0_atlas
>
> Copyright assignment:
> I am a RealNetworks employee or contractor.
>
> Content-Type: application/octet-stream; name="common_util.diff"
> X-Attachment-Id: f_fkrjl7q00
> Content-Disposition: attachment; filename=common_util.diff
>
> Content-Type: application/octet-stream; name="common_system.diff"
> X-Attachment-Id: f_fkrjlb201
> Content-Disposition: attachment; filename=common_system.diff
>
> Content-Type: application/octet-stream; name="client_common_system.diff"
> X-Attachment-Id: f_fkrjld282
> Content-Disposition: attachment; filename=client_common_system.diff
>
> _______________________________________________
> Masf-restricted-dev mailing list
> Masf-restricted-dev@lists.helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/masf-restricted-dev
>
From js at reciva.com Mon Sep 8 01:24:32 2008
From: js at reciva.com (John Stirling)
Date: Sun Sep 7 23:48:48 2008
Subject: [Helix-client-dev] preventing aac playback
In-Reply-To: <48BD1A7C.9080207@reciva.com>
References: <48BD1A7C.9080207@reciva.com>
Message-ID: <48C4E140.7060408@reciva.com>
Any response to this ?
John Stirling wrote:
> We've been applying this patch in order to selectively disable
> playback of AAC content.
>
> This does prevent AAC content from playing. It currently just starts
> the stream, doesn't play anything and sticks there without reporting
> any errors to the TLC. We'd like it to behave as if the raac.so plugin
> didn't exist (HXR_NO_RENDERER).
>
> I've tried a few things, but can't seem to find the correct thing to
> make this work. Can someone advise on how to do this.
>
> John
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ? datatype/aac/codec/fixpt/decoder/Makefile
> ? datatype/aac/codec/fixpt/decoder/Umakefil.upp
> ? datatype/aac/codec/fixpt/decoder/armv4l-rel
> ? datatype/aac/codec/fixpt/decoder/rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/Makefile
> ? datatype/aac/codec/fixpt/decoder/hxwrap/Umakefil.upp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/armv4l-rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/raac.exp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/rlink
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.mak
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.upp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.mak
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.upp
> ? datatype/aac/fileformat/Makefile
> ? datatype/aac/fileformat/Umakefil.upp
> ? datatype/aac/fileformat/aacff.exp
> ? datatype/aac/fileformat/aacffdll.mak
> ? datatype/aac/fileformat/aacffdll.upp
> ? datatype/aac/fileformat/armv4l-rel
> ? datatype/aac/fileformat/rel
> ? datatype/aac/fileformat/rlink
> ? datatype/aac/parser/Makefile
> ? datatype/aac/parser/Umakefil.upp
> ? datatype/aac/parser/armv4l-rel
> ? datatype/aac/parser/rel
> ? datatype/aac/payload/Makefile
> ? datatype/aac/payload/Umakefil.upp
> ? datatype/aac/payload/armv4l-rel
> ? datatype/aac/payload/rel
> Index: datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp
> ===================================================================
> RCS file: /nexus/proj/InternetRadio/cvs/helix_cayenne_20070820/datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 aacdecdll.cpp
> --- datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 1 Jul 2008 15:35:05 -0000 1.1.1.1
> +++ datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 2 Sep 2008 10:46:15 -0000
> @@ -46,6 +46,10 @@
> #include "aacdecdll.h"
> #include "aacconstants.h"
>
> +#include
> +#include
> +#include
> +
> const char* const CAACDec::m_pszCodecName = "RealAudio 10";
>
> CAACDec::CAACDec()
> @@ -80,6 +84,15 @@
> //
> STDMETHODIMP CAACDec::QueryInterface(REFIID riid, void** ppvObj)
> {
> + /* This file controls whether we are allowed to use the AAC plugin */
> + #define ENABLE_FILE "/tmp/enable_plugin_aac"
> +
> + /* Only allow AAC plugin to be used if there if file
> + * /tmp/enable_plugin_aac exists */
> + struct stat s;
> + if (stat(ENABLE_FILE, &s) == 0)
> + {
> + printf("HELIX: AAC Plugin Manually Enabled\n");
> if (IsEqualIID(riid, IID_IHXAudioDecoder))
> {
> AddRef();
> @@ -92,6 +105,11 @@
> *ppvObj = this;
> return HXR_OK;
> }
> + }
> + else
> + {
> + printf("HELIX: AAC Plugin Manually Disabled\n");
> + }
>
> *ppvObj = NULL;
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20080908/c93bb5f6/attachment.html
From js at reciva.com Mon Sep 8 01:24:57 2008
From: js at reciva.com (John Stirling)
Date: Sun Sep 7 23:49:05 2008
Subject: [Helix-client-dev] http fsys - dlna compliance 7.4.32.2
- MTMaximum Byte Size Transfers
In-Reply-To: <48BFB87E.4020202@reciva.com>
References: <4857E3DC.9010502@reciva.com>
<4857ED01.4030708@real.com> <4857EE41.5030107@reciva.com> <005601c8d0c5$5db61d50$e58e17ac@EHYCHED620>
<48BFB87E.4020202@reciva.com>
Message-ID: <48C4E159.5030602@reciva.com>
Any response to this ?
John Stirling wrote:
> We tested with an atlas build and it still crashes.
>
> We're getting fairly close to needing to get this fixed.
>
> Is helix used in any DLNA certified products ? It seems like this
> would be a fairly common requirement , at least for the bigger brands.
> So any chance this could get fixed by someone at helix/real ? If not,
> could someone more familiar with httpfsys give us some assistance in
> fixing this ?
>
> John
>
>
> Eric Hyche wrote:
>> I would guess that Content-Length's or Chunked-Encoding-Size's
>> greater than 4GB will be a problem. Content-Length is probably
>> not as big of a problem.
>>
>> Eric
>>
>> =============================================
>> 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 John Stirling
>>> Sent: Tuesday, June 17, 2008 1:03 PM
>>> To: Greg Wright
>>> Cc: helix-client-dev@helixcommunity.org
>>> Subject: Re: [Helix-client-dev] http fsys - dlna compliance
>>> 7.4.32.2 - MTMaximum Byte Size Transfers
>>>
>>> Greg Wright wrote:
>>>
>>>> John Stirling wrote:
>>>>
>>>>> We're running our cayene build through the DLNA compliance
>>>>>
>>> test suite.
>>>
>>>>> There is a requirement to handle content-length, chunk-size, range
>>>>> fields with values up to 2^48. Currently this test crashes helix -
>>>>> the crash point being an attempt to dynamically allocate 2Gb in
>>>>> CHTTPFileObject::DecodeChunkedEncoding. It looks like
>>>>>
>>> helix is only
>>>
>>>>> set upo to deal with a max of 2^32 currently ?
>>>>>
>>>>> Before I look into this in detail, is anyone aware if this
>>>>>
>>> has been
>>>
>>>>> fixed in a later version of httpfsys ? If not, any pointers to an
>>>>> easy fix appreciated. I'm currently assuming that converting
>>>>> appropriate variables in httpfsys to u64 will probably do it (I'm
>>>>> working on the defintion of 'appropriate')
>>>>>
>>>> I assume it is crashing because the alloc returns NULL (no
>>>>
>>> alloc that
>>>
>>>> size possible) and the NULL is de-refed?
>>>>
>>>> We did do some work in this area to detect bad chunk sizes
>>>>
>>> I remember.
>>>
>>>> And, that method on 310Atlas is different then on 150Cay.
>>>>
>>> So, my guess
>>>
>>>> would be yes. You still wouldn't be able to just alloc any amount of
>>>> memory you want, but it shouldn't crash. The only way to
>>>>
>>> tell though,
>>>
>>>> for you case, is to test it.
>>>>
>>>>
>>> Apart from avoiding this specific crash, do you think atlas is also
>>> likely to handle content-length, chunk-size etc values
>>> greater than 32 bit ?
>>>
>>>
>>>> --greg.
>>>>
>>>>
>>>>
>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Helix-client-dev mailing list
>>>>> Helix-client-dev@helixcommunity.org
>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>
>>>>>
>>> _______________________________________________
>>> Helix-client-dev mailing list
>>> Helix-client-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>
>>>
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20080908/d793cc38/attachment-0001.html
From mahmoudhammoud at gmail.com Mon Sep 8 09:36:17 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Mon Sep 8 07:56:02 2008
Subject: [Helix-client-dev] Preferences
Message-ID: <209f73910809080936r63de8f2eo8bae36538f5f3852@mail.gmail.com>
Greg, All,
How can preferences for the Helix client be set e.g. MAX_UDP_PORT and
similar variables? Is there a specific preferences file I should be looking
for?
Thanks,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080908/b75b8a2d/attachment.html
From gwright at real.com Mon Sep 8 09:50:32 2008
From: gwright at real.com (Greg Wright)
Date: Mon Sep 8 08:10:22 2008
Subject: [Helix-client-dev] Re: Preferences
In-Reply-To: <209f73910809080936r63de8f2eo8bae36538f5f3852@mail.gmail.com>
References: <209f73910809080936r63de8f2eo8bae36538f5f3852@mail.gmail.com>
Message-ID: <48C557D8.4070505@real.com>
Mahmoud Hammoud wrote:
> Greg, All,
>
> How can preferences for the Helix client be set e.g. MAX_UDP_PORT and
> similar variables? Is there a specific preferences file I should be
> looking for?
The pref file can change location depending on what
player you are using. What are you using for a player (splay,
HelixPlayer, etc.).
Try looking for ~/.helix ~/.realplayerrc
It will just be a plain text file with name/value pairs.
That is true for linux anyway, on windows we use the registry.
--greg.
>
> Thanks,
>
> Mahmoud Hammoud
From mahmoudhammoud at gmail.com Mon Sep 8 11:40:35 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Mon Sep 8 10:00:25 2008
Subject: [Helix-client-dev] Re: Preferences
In-Reply-To: <48C557D8.4070505@real.com>
References: <209f73910809080936r63de8f2eo8bae36538f5f3852@mail.gmail.com>
<48C557D8.4070505@real.com>
Message-ID: <209f73910809081140m74b74518n6b83e8a164ca9900@mail.gmail.com>
I'm using splay (cayenne_1_5_0 branch) and building under Windows. So the
preferences in my case are registry entries? Can you tell me where exactly,
because I also have Real Player installed and I dont know if it also has its
own preferences as registry entries.
Regards,
Mahmoud
On Mon, Sep 8, 2008 at 6:50 PM, Greg Wright wrote:
> Mahmoud Hammoud wrote:
>
>> Greg, All,
>> How can preferences for the Helix client be set e.g. MAX_UDP_PORT and
>> similar variables? Is there a specific preferences file I should be looking
>> for?
>>
>
> The pref file can change location depending on what
> player you are using. What are you using for a player (splay,
> HelixPlayer, etc.).
>
> Try looking for ~/.helix ~/.realplayerrc
>
> It will just be a plain text file with name/value pairs.
>
> That is true for linux anyway, on windows we use the registry.
>
> --greg.
>
> Thanks,
>> Mahmoud Hammoud
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080908/d73ecd09/attachment.html
From rmathew at real.com Mon Sep 8 21:52:30 2008
From: rmathew at real.com (Rishi Mathew)
Date: Mon Sep 8 20:12:11 2008
Subject: [Helix-client-dev] http fsys - dlna compliance 7.4.32.2
- MTMaximum Byte Size Transfers
In-Reply-To: <48C4E159.5030602@reciva.com>
References: <4857E3DC.9010502@reciva.com> <4857ED01.4030708@real.com>
<4857EE41.5030107@reciva.com>
<005601c8d0c5$5db61d50$e58e17ac@EHYCHED620>
<48BFB87E.4020202@reciva.com> <48C4E159.5030602@reciva.com>
Message-ID: <6.2.5.6.2.20080908214338.04423e60@real.com>
Hey John,
We havent tested for DLNA compliance internally, this has been
typically done by partners like yourself. You will need to drive
this, we can provide you the help that you need to fix this issue.
If you ask specific questions related to the code/architecture,
someone will definitely answer.
Cheers,
Rishi.
At 01:24 AM 9/8/2008, John Stirling wrote:
>Any response to this ?
>
>John Stirling wrote:
>>We tested with an atlas build and it still crashes.
>>
>>We're getting fairly close to needing to get this fixed.
>>
>>Is helix used in any DLNA certified products ? It seems like this
>>would be a fairly common requirement , at least for the bigger
>>brands. So any chance this could get fixed by someone at helix/real
>>? If not, could someone more familiar with httpfsys give us some
>>assistance in fixing this ?
>>
>>John
>>
>>
>>Eric Hyche wrote:
>>>
>>>I would guess that Content-Length's or Chunked-Encoding-Size's
>>>greater than 4GB will be a problem. Content-Length is probably
>>>not as big of a problem.
>>>
>>>Eric
>>>
>>>=============================================
>>>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 John Stirling
>>>>Sent: Tuesday, June 17, 2008 1:03 PM
>>>>To: Greg Wright
>>>>Cc:
>>>>helix-client-dev@helixcommunity.org
>>>>Subject: Re: [Helix-client-dev] http fsys - dlna compliance
>>>>7.4.32.2 - MTMaximum Byte Size Transfers
>>>>
>>>>Greg Wright wrote:
>>>>
>>>>>
>>>>>John Stirling wrote:
>>>>>
>>>>>>
>>>>>>We're running our cayene build through the DLNA compliance
>>>>>>
>>>>
>>>>test suite.
>>>>
>>>>>>
>>>>>>There is a requirement to handle content-length, chunk-size, range
>>>>>>fields with values up to 2^48. Currently this test crashes helix -
>>>>>>the crash point being an attempt to dynamically allocate 2Gb in
>>>>>>CHTTPFileObject::DecodeChunkedEncoding. It looks like
>>>>>>
>>>>
>>>>helix is only
>>>>
>>>>>>
>>>>>>set upo to deal with a max of 2^32 currently ?
>>>>>>
>>>>>>Before I look into this in detail, is anyone aware if this
>>>>>>
>>>>
>>>>has been
>>>>
>>>>>>
>>>>>>fixed in a later version of httpfsys ? If not, any pointers to an
>>>>>>easy fix appreciated. I'm currently assuming that converting
>>>>>>appropriate variables in httpfsys to u64 will probably do it (I'm
>>>>>>working on the defintion of 'appropriate')
>>>>>>
>>>>>
>>>>>I assume it is crashing because the alloc returns NULL (no
>>>>>
>>>>
>>>>alloc that
>>>>
>>>>>
>>>>>size possible) and the NULL is de-refed?
>>>>>
>>>>>We did do some work in this area to detect bad chunk sizes
>>>>>
>>>>
>>>>I remember.
>>>>
>>>>>
>>>>>And, that method on 310Atlas is different then on 150Cay.
>>>>>
>>>>
>>>>So, my guess
>>>>
>>>>>
>>>>>would be yes. You still wouldn't be able to just alloc any amount of
>>>>>memory you want, but it shouldn't crash. The only way to
>>>>>
>>>>
>>>>tell though,
>>>>
>>>>>
>>>>>for you case, is to test it.
>>>>>
>>>>>
>>>>
>>>>Apart from avoiding this specific crash, do you think atlas is also
>>>>likely to handle content-length, chunk-size etc values
>>>>greater than 32 bit ?
>>>>
>>>>
>>>>>
>>>>>--greg.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Helix-client-dev mailing list
>>>>>>Helix-client-dev@helixcommunity.org
>>>>>>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>
>>>>>>
>>>>
>>>>_______________________________________________
>>>>Helix-client-dev mailing list
>>>>Helix-client-dev@helixcommunity.org
>>>>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Helix-client-dev mailing list
>>Helix-client-dev@helixcommunity.org
>>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
>
>_______________________________________________
>Helix-client-dev mailing list
>Helix-client-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
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/20080908/1edd7459/attachment.html
From mahmoudhammoud at gmail.com Tue Sep 9 08:57:02 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Tue Sep 9 07:16:32 2008
Subject: [Helix-client-dev] SDB
Message-ID: <209f73910809090857t5893d56cgf444081daed22340@mail.gmail.com>
Dear Greg, All,
This is to revisit the problem I earlier presented, namely with regard to
requesting a higher bit-rate from the server once an upcoming state of bad
connectivity is detected. I have implemented the solution you proposed, and
now I am able to have "more" data on hand by calling
SetDeliveryBandwidth(...) where appropriate. One problem remains however: I
would like to have playback continue from the buffered content even if there
is no connection at all (e.g. the user enters an area with no network
coverage in a wireless scenario...), that is, even if no incoming data is
detected anymore at the sockets. To simulate this during testing, I am just
disabling my LAN connection to see if playback continues (knowing that we
have reasonably enough data on hand), but playback seems to be pausing
indefinitely (in other instances I get a HXR_NET_SOCKET_INVALID error and
splay crashes...).
Note that when I let playback reach the point where the sending bit-rate
becomes 0 bps (i.e. all the data that we need have been already
buffered...), and then simulate this "no connection" condition, playback
DOES continue uninterrupted. Basically what I need is this to happen also in
intermediate "no connection" phases. Could you provide me with your valuable
insight please?
Best Regards,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080909/4b4bf412/attachment-0001.html
From jrathore at real.com Tue Sep 9 17:18:26 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Tue Sep 9 15:37:51 2008
Subject: [Helix-client-dev] preventing aac playback
In-Reply-To: <48C4E140.7060408@reciva.com>
References: <48BD1A7C.9080207@reciva.com> <48C4E140.7060408@reciva.com>
Message-ID: <009e01c912da$bef02730$f58016ac@corp.real.com>
Hi John,
One way to disable the AAC support would be to remove the two macros, by
adding
project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_RAAC')
project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_AAC')
in the profile file and rebuilding. Then HXR_NO_RENDERER error will be
returned.
Thanks,
Jyotsana
_____
From: helix-client-dev-bounces@helixcommunity.org
[mailto:helix-client-dev-bounces@helixcommunity.org] On Behalf Of John
Stirling
Sent: Monday, September 08, 2008 1:25 AM
To: helix-client-dev@lists.helixcommunity.org
Subject: Re: [Helix-client-dev] preventing aac playback
Any response to this ?
John Stirling wrote:
We've been applying this patch in order to selectively disable playback of
AAC content.
This does prevent AAC content from playing. It currently just starts the
stream, doesn't play anything and sticks there without reporting any errors
to the TLC. We'd like it to behave as if the raac.so plugin didn't exist
(HXR_NO_RENDERER).
I've tried a few things, but can't seem to find the correct thing to make
this work. Can someone advise on how to do this.
John
_____
? datatype/aac/codec/fixpt/decoder/Makefile
? datatype/aac/codec/fixpt/decoder/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/armv4l-rel
? datatype/aac/codec/fixpt/decoder/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/Makefile
? datatype/aac/codec/fixpt/decoder/hxwrap/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/armv4l-rel
? datatype/aac/codec/fixpt/decoder/hxwrap/raac.exp
? datatype/aac/codec/fixpt/decoder/hxwrap/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/rlink
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.upp
? datatype/aac/fileformat/Makefile
? datatype/aac/fileformat/Umakefil.upp
? datatype/aac/fileformat/aacff.exp
? datatype/aac/fileformat/aacffdll.mak
? datatype/aac/fileformat/aacffdll.upp
? datatype/aac/fileformat/armv4l-rel
? datatype/aac/fileformat/rel
? datatype/aac/fileformat/rlink
? datatype/aac/parser/Makefile
? datatype/aac/parser/Umakefil.upp
? datatype/aac/parser/armv4l-rel
? datatype/aac/parser/rel
? datatype/aac/payload/Makefile
? datatype/aac/payload/Umakefil.upp
? datatype/aac/payload/armv4l-rel
? datatype/aac/payload/rel
Index: datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp
===================================================================
RCS file:
/nexus/proj/InternetRadio/cvs/helix_cayenne_20070820/datatype/aac/codec/fixp
t/decoder/hxwrap/aacdecdll.cpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 aacdecdll.cpp
--- datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 1 Jul 2008
15:35:05 -0000 1.1.1.1
+++ datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 2 Sep 2008
10:46:15 -0000
@@ -46,6 +46,10 @@
#include "aacdecdll.h"
#include "aacconstants.h"
+#include
+#include
+#include
+
const char* const CAACDec::m_pszCodecName = "RealAudio 10";
CAACDec::CAACDec()
@@ -80,6 +84,15 @@
//
STDMETHODIMP CAACDec::QueryInterface(REFIID riid, void** ppvObj)
{
+ /* This file controls whether we are allowed to use the AAC plugin */
+ #define ENABLE_FILE "/tmp/enable_plugin_aac"
+
+ /* Only allow AAC plugin to be used if there if file
+ * /tmp/enable_plugin_aac exists */
+ struct stat s;
+ if (stat(ENABLE_FILE, &s) == 0)
+ {
+ printf("HELIX: AAC Plugin Manually Enabled\n");
if (IsEqualIID(riid, IID_IHXAudioDecoder))
{
AddRef();
@@ -92,6 +105,11 @@
*ppvObj = this;
return HXR_OK;
}
+ }
+ else
+ {
+ printf("HELIX: AAC Plugin Manually Disabled\n");
+ }
*ppvObj = NULL;
_____
_______________________________________________
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/20080909/f7b12a5c/attachment.html
From js at reciva.com Wed Sep 10 00:50:33 2008
From: js at reciva.com (John Stirling)
Date: Tue Sep 9 23:14:31 2008
Subject: [Helix-client-dev] preventing aac playback
In-Reply-To: <009e01c912da$bef02730$f58016ac@corp.real.com>
References: <48BD1A7C.9080207@reciva.com> <48C4E140.7060408@reciva.com>
<009e01c912da$bef02730$f58016ac@corp.real.com>
Message-ID: <48C77C49.6030809@reciva.com>
Hi Jyotsana,
We ideally want a way of doing this dynamically rather than at compile time.
Can anyone point me at the relevant bit of code ?
John
Jyotsana Rathore wrote:
>
> Hi John,
>
>
>
> One way to disable the AAC support would be to remove the two macros,
> by adding
>
> project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_RAAC')
>
> project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_AAC')
>
> in the profile file and rebuilding. Then HXR_NO_RENDERER error will be
> returned.
>
>
>
> Thanks,
>
> Jyotsana
>
>
>
> ------------------------------------------------------------------------
>
> *From:* helix-client-dev-bounces@helixcommunity.org
> [mailto:helix-client-dev-bounces@helixcommunity.org] *On Behalf Of
> *John Stirling
> *Sent:* Monday, September 08, 2008 1:25 AM
> *To:* helix-client-dev@lists.helixcommunity.org
> *Subject:* Re: [Helix-client-dev] preventing aac playback
>
>
>
> Any response to this ?
>
>
> John Stirling wrote:
>
> We've been applying this patch in order to selectively disable
> playback of AAC content.
>
> This does prevent AAC content from playing. It currently just starts
> the stream, doesn't play anything and sticks there without reporting
> any errors to the TLC. We'd like it to behave as if the raac.so plugin
> didn't exist (HXR_NO_RENDERER).
>
> I've tried a few things, but can't seem to find the correct thing to
> make this work. Can someone advise on how to do this.
>
> John
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> ? datatype/aac/codec/fixpt/decoder/Makefile
> ? datatype/aac/codec/fixpt/decoder/Umakefil.upp
> ? datatype/aac/codec/fixpt/decoder/armv4l-rel
> ? datatype/aac/codec/fixpt/decoder/rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/Makefile
> ? datatype/aac/codec/fixpt/decoder/hxwrap/Umakefil.upp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/armv4l-rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/raac.exp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/rel
> ? datatype/aac/codec/fixpt/decoder/hxwrap/rlink
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.mak
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.upp
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.mak
> ? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.upp
> ? datatype/aac/fileformat/Makefile
> ? datatype/aac/fileformat/Umakefil.upp
> ? datatype/aac/fileformat/aacff.exp
> ? datatype/aac/fileformat/aacffdll.mak
> ? datatype/aac/fileformat/aacffdll.upp
> ? datatype/aac/fileformat/armv4l-rel
> ? datatype/aac/fileformat/rel
> ? datatype/aac/fileformat/rlink
> ? datatype/aac/parser/Makefile
> ? datatype/aac/parser/Umakefil.upp
> ? datatype/aac/parser/armv4l-rel
> ? datatype/aac/parser/rel
> ? datatype/aac/payload/Makefile
> ? datatype/aac/payload/Umakefil.upp
> ? datatype/aac/payload/armv4l-rel
> ? datatype/aac/payload/rel
> Index: datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp
> ===================================================================
> RCS file: /nexus/proj/InternetRadio/cvs/helix_cayenne_20070820/datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 aacdecdll.cpp
> --- datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 1 Jul 2008 15:35:05 -0000 1.1.1.1
> +++ datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 2 Sep 2008 10:46:15 -0000
> @@ -46,6 +46,10 @@
> #include "aacdecdll.h"
> #include "aacconstants.h"
>
> +#include
> +#include
> +#include
> +
> const char* const CAACDec::m_pszCodecName = "RealAudio 10";
>
> CAACDec::CAACDec()
> @@ -80,6 +84,15 @@
> //
> STDMETHODIMP CAACDec::QueryInterface(REFIID riid, void** ppvObj)
> {
> + /* This file controls whether we are allowed to use the AAC plugin */
> + #define ENABLE_FILE "/tmp/enable_plugin_aac"
> +
> + /* Only allow AAC plugin to be used if there if file
> + * /tmp/enable_plugin_aac exists */
> + struct stat s;
> + if (stat(ENABLE_FILE, &s) == 0)
> + {
> + printf("HELIX: AAC Plugin Manually Enabled\n");
> if (IsEqualIID(riid, IID_IHXAudioDecoder))
> {
> AddRef();
> @@ -92,6 +105,11 @@
> *ppvObj = this;
> return HXR_OK;
> }
> + }
> + else
> + {
> + printf("HELIX: AAC Plugin Manually Disabled\n");
> + }
>
> *ppvObj = NULL;
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> 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/20080910/91d2fb5a/attachment-0001.html
From js at reciva.com Wed Sep 10 00:54:12 2008
From: js at reciva.com (John Stirling)
Date: Tue Sep 9 23:18:05 2008
Subject: [Helix-client-dev] http fsys - dlna compliance 7.4.32.2
- MTMaximum Byte Size Transfers
In-Reply-To: <6.2.5.6.2.20080908214338.04423e60@real.com>
References: <4857E3DC.9010502@reciva.com> <4857ED01.4030708@real.com>
<4857EE41.5030107@reciva.com>
<005601c8d0c5$5db61d50$e58e17ac@EHYCHED620>
<48BFB87E.4020202@reciva.com> <48C4E159.5030602@reciva.com>
<6.2.5.6.2.20080908214338.04423e60@real.com>
Message-ID: <48C77D24.9080803@reciva.com>
I was hoping someone familiar with httpfsys could point me in the right
direction. It's not easy to work out what's going on in there.
I've already fixed a couple of other minor DLNA blockers in there, but
this one seems like it needs a big change and I'm fairly nervous about
breaking something else in the meantime.
John
Rishi Mathew wrote:
> Hey John,
>
> We havent tested for DLNA compliance internally, this has been
> typically done by partners like yourself. You will need to drive this,
> we can provide you the help that you need to fix this issue. If you
> ask specific questions related to the code/architecture, someone will
> definitely answer.
>
> Cheers,
> Rishi.
>
> At 01:24 AM 9/8/2008, John Stirling wrote:
>> Any response to this ?
>>
>> John Stirling wrote:
>>> We tested with an atlas build and it still crashes.
>>>
>>> We're getting fairly close to needing to get this fixed.
>>>
>>> Is helix used in any DLNA certified products ? It seems like this
>>> would be a fairly common requirement , at least for the bigger
>>> brands. So any chance this could get fixed by someone at helix/real
>>> ? If not, could someone more familiar with httpfsys give us some
>>> assistance in fixing this ?
>>>
>>> John
>>>
>>>
>>> Eric Hyche wrote:
>>>>
>>>> I would guess that Content-Length's or Chunked-Encoding-Size's
>>>> greater than 4GB will be a problem. Content-Length is probably
>>>> not as big of a problem.
>>>>
>>>> Eric
>>>>
>>>> =============================================
>>>> 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 John Stirling
>>>>> Sent: Tuesday, June 17, 2008 1:03 PM
>>>>> To: Greg Wright
>>>>> Cc:
>>>>>
>>>>> helix-client-dev@helixcommunity.org
>>>>> Subject: Re: [Helix-client-dev] http fsys - dlna compliance
>>>>> 7.4.32.2 - MTMaximum Byte Size Transfers
>>>>>
>>>>> Greg Wright wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> John Stirling wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> We're running our cayene build through the DLNA compliance
>>>>>>>
>>>>>>>
>>>>>
>>>>> test suite.
>>>>>
>>>>>
>>>>>>>
>>>>>>> There is a requirement to handle content-length, chunk-size, range
>>>>>>> fields with values up to 2^48. Currently this test crashes helix -
>>>>>>> the crash point being an attempt to dynamically allocate 2Gb in
>>>>>>> CHTTPFileObject::DecodeChunkedEncoding. It looks like
>>>>>>>
>>>>>>>
>>>>>
>>>>> helix is only
>>>>>
>>>>>
>>>>>>>
>>>>>>> set upo to deal with a max of 2^32 currently ?
>>>>>>>
>>>>>>> Before I look into this in detail, is anyone aware if this
>>>>>>>
>>>>>>>
>>>>>
>>>>> has been
>>>>>
>>>>>
>>>>>>>
>>>>>>> fixed in a later version of httpfsys ? If not, any pointers to an
>>>>>>> easy fix appreciated. I'm currently assuming that converting
>>>>>>> appropriate variables in httpfsys to u64 will probably do it (I'm
>>>>>>> working on the defintion of 'appropriate')
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I assume it is crashing because the alloc returns NULL (no
>>>>>>
>>>>>>
>>>>>
>>>>> alloc that
>>>>>
>>>>>
>>>>>>
>>>>>> size possible) and the NULL is de-refed?
>>>>>>
>>>>>> We did do some work in this area to detect bad chunk sizes
>>>>>>
>>>>>>
>>>>>
>>>>> I remember.
>>>>>
>>>>>
>>>>>>
>>>>>> And, that method on 310Atlas is different then on 150Cay.
>>>>>>
>>>>>>
>>>>>
>>>>> So, my guess
>>>>>
>>>>>
>>>>>>
>>>>>> would be yes. You still wouldn't be able to just alloc any amount
>>>>>> of
>>>>>> memory you want, but it shouldn't crash. The only way to
>>>>>>
>>>>>>
>>>>>
>>>>> tell though,
>>>>>
>>>>>
>>>>>>
>>>>>> for you case, is to test it.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Apart from avoiding this specific crash, do you think atlas is also
>>>>> likely to handle content-length, chunk-size etc values
>>>>> greater than 32 bit ?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> --greg.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Helix-client-dev mailing list
>>>>>>>
>>>>>>> Helix-client-dev@helixcommunity.org
>>>>>>>
>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Helix-client-dev mailing list
>>>>>
>>>>> Helix-client-dev@helixcommunity.org
>>>>>
>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Helix-client-dev mailing list
>>>
>>> Helix-client-dev@helixcommunity.org
>>>
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>>
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>
>
> *Rishi Mathew
> *Helix Community
> *Real* Networks, 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/20080910/5ffa67fa/attachment.html
From mahmoudhammoud at gmail.com Thu Sep 11 02:35:12 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Thu Sep 11 00:54:24 2008
Subject: [Helix-client-dev] Fwd: SDB
In-Reply-To: <209f73910809090857t5893d56cgf444081daed22340@mail.gmail.com>
References: <209f73910809090857t5893d56cgf444081daed22340@mail.gmail.com>
Message-ID: <209f73910809110235u79677ffdyed8227bd047d3979@mail.gmail.com>
Hi Greg,
Any chance I could get some answers to the problem below?
Thanks again,
Mahmoud
---------- Forwarded message ----------
From: Mahmoud Hammoud
Date: Tue, Sep 9, 2008 at 5:57 PM
Subject: SDB
To: Greg Wright
Cc: helix-client-dev@helixcommunity.org
Dear Greg, All,
This is to revisit the problem I earlier presented, namely with regard to
requesting a higher bit-rate from the server once an upcoming state of bad
connectivity is detected. I have implemented the solution you proposed, and
now I am able to have "more" data on hand by calling
SetDeliveryBandwidth(...) where appropriate. One problem remains however: I
would like to have playback continue from the buffered content even if there
is no connection at all (e.g. the user enters an area with no network
coverage in a wireless scenario...), that is, even if no incoming data is
detected anymore at the sockets. To simulate this during testing, I am just
disabling my LAN connection to see if playback continues (knowing that we
have reasonably enough data on hand), but playback seems to be pausing
indefinitely (in other instances I get a HXR_NET_SOCKET_INVALID error and
splay crashes...).
Note that when I let playback reach the point where the sending bit-rate
becomes 0 bps (i.e. all the data that we need have been already
buffered...), and then simulate this "no connection" condition, playback
DOES continue uninterrupted. Basically what I need is this to happen also in
intermediate "no connection" phases. Could you provide me with your valuable
insight please?
Best Regards,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080911/e7fefbff/attachment.html
From gwright at real.com Thu Sep 11 08:48:33 2008
From: gwright at real.com (Gregory Wright)
Date: Thu Sep 11 07:07:35 2008
Subject: [Helix-client-dev] Re: SDB
In-Reply-To: <209f73910809110235u79677ffdyed8227bd047d3979@mail.gmail.com>
References: <209f73910809090857t5893d56cgf444081daed22340@mail.gmail.com>
<209f73910809110235u79677ffdyed8227bd047d3979@mail.gmail.com>
Message-ID: <41A3D528-7E2C-4D4E-821E-B974F4CFD6DA@real.com>
On Sep 11, 2008, at 2:35 AM, Mahmoud Hammoud wrote:
> Hi Greg,
>
> Any chance I could get some answers to the problem below?
The people, from Real here, that monitor these lists are pretty busy
right now getting demos
and talks ready for the Helix Summit starting next Monday.
https://helixcommunity.org/summit/2008/
I am gone that whole week as well.
But, from your description below, perhaps the loss of keep-alive, ping/
pong, packets are
causing the pauses. Maybe we try to send statistic packets and error
out or something. In
either case, put break points in ReportRebufferStatus and Pause to see
why/who it causing
the pauses.
--greg.
>
> Thanks again,
>
> Mahmoud
>
> ---------- Forwarded message ----------
> From: Mahmoud Hammoud
> Date: Tue, Sep 9, 2008 at 5:57 PM
> Subject: SDB
> To: Greg Wright
> Cc: helix-client-dev@helixcommunity.org
>
>
> Dear Greg, All,
>
> This is to revisit the problem I earlier presented, namely with
> regard to requesting a higher bit-rate from the server once an
> upcoming state of bad connectivity is detected. I have implemented
> the solution you proposed, and now I am able to have "more" data on
> hand by calling SetDeliveryBandwidth(...) where appropriate. One
> problem remains however: I would like to have playback continue from
> the buffered content even if there is no connection at all (e.g. the
> user enters an area with no network coverage in a wireless
> scenario...), that is, even if no incoming data is detected anymore
> at the sockets. To simulate this during testing, I am just disabling
> my LAN connection to see if playback continues (knowing that we have
> reasonably enough data on hand), but playback seems to be pausing
> indefinitely (in other instances I get a HXR_NET_SOCKET_INVALID
> error and splay crashes...).
>
> Note that when I let playback reach the point where the sending bit-
> rate becomes 0 bps (i.e. all the data that we need have been already
> buffered...), and then simulate this "no connection" condition,
> playback DOES continue uninterrupted. Basically what I need is this
> to happen also in intermediate "no connection" phases. Could you
> provide me with your valuable insight please?
>
> Best Regards,
>
> Mahmoud Hammoud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080911/14fb0db3/attachment-0001.html
From jrathore at real.com Fri Sep 12 18:23:10 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Fri Sep 12 16:41:54 2008
Subject: [Helix-client-dev] preventing aac playback
In-Reply-To: <48C77C49.6030809@reciva.com>
References: <48BD1A7C.9080207@reciva.com> <48C4E140.7060408@reciva.com>
<009e01c912da$bef02730$f58016ac@corp.real.com>
<48C77C49.6030809@reciva.com>
Message-ID: <008801c9153f$4ab8ae70$f58016ac@corp.real.com>
Hi John,
In that case, you can apply your patch in CAACFileFormat::HXCreateInstance()
function in datatype\aac\fileformat\aacff.cpp. I recommend adding and using
a preference e.g. "DisableAACSupport"
Thanks,
Jyotsana
_____
From: John Stirling [mailto:js@reciva.com]
Sent: Wednesday, September 10, 2008 12:51 AM
To: Jyotsana Rathore
Cc: helix-client-dev@lists.helixcommunity.org
Subject: Re: [Helix-client-dev] preventing aac playback
Hi Jyotsana,
We ideally want a way of doing this dynamically rather than at compile time.
Can anyone point me at the relevant bit of code ?
John
Jyotsana Rathore wrote:
Hi John,
One way to disable the AAC support would be to remove the two macros, by
adding
project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_RAAC')
project.RemoveDefines('HELIX_FEATURE_AUDIO_CODEC_AAC')
in the profile file and rebuilding. Then HXR_NO_RENDERER error will be
returned.
Thanks,
Jyotsana
_____
From: helix-client-dev-bounces@helixcommunity.org
[mailto:helix-client-dev-bounces@helixcommunity.org] On Behalf Of John
Stirling
Sent: Monday, September 08, 2008 1:25 AM
To: helix-client-dev@lists.helixcommunity.org
Subject: Re: [Helix-client-dev] preventing aac playback
Any response to this ?
John Stirling wrote:
We've been applying this patch in order to selectively disable playback of
AAC content.
This does prevent AAC content from playing. It currently just starts the
stream, doesn't play anything and sticks there without reporting any errors
to the TLC. We'd like it to behave as if the raac.so plugin didn't exist
(HXR_NO_RENDERER).
I've tried a few things, but can't seem to find the correct thing to make
this work. Can someone advise on how to do this.
John
_____
? datatype/aac/codec/fixpt/decoder/Makefile
? datatype/aac/codec/fixpt/decoder/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/armv4l-rel
? datatype/aac/codec/fixpt/decoder/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/Makefile
? datatype/aac/codec/fixpt/decoder/hxwrap/Umakefil.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/armv4l-rel
? datatype/aac/codec/fixpt/decoder/hxwrap/raac.exp
? datatype/aac/codec/fixpt/decoder/hxwrap/rel
? datatype/aac/codec/fixpt/decoder/hxwrap/rlink
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_dll.upp
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.mak
? datatype/aac/codec/fixpt/decoder/hxwrap/umake_lib.upp
? datatype/aac/fileformat/Makefile
? datatype/aac/fileformat/Umakefil.upp
? datatype/aac/fileformat/aacff.exp
? datatype/aac/fileformat/aacffdll.mak
? datatype/aac/fileformat/aacffdll.upp
? datatype/aac/fileformat/armv4l-rel
? datatype/aac/fileformat/rel
? datatype/aac/fileformat/rlink
? datatype/aac/parser/Makefile
? datatype/aac/parser/Umakefil.upp
? datatype/aac/parser/armv4l-rel
? datatype/aac/parser/rel
? datatype/aac/payload/Makefile
? datatype/aac/payload/Umakefil.upp
? datatype/aac/payload/armv4l-rel
? datatype/aac/payload/rel
Index: datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp
===================================================================
RCS file:
/nexus/proj/InternetRadio/cvs/helix_cayenne_20070820/datatype/aac/codec/fixp
t/decoder/hxwrap/aacdecdll.cpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 aacdecdll.cpp
--- datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 1 Jul 2008
15:35:05 -0000 1.1.1.1
+++ datatype/aac/codec/fixpt/decoder/hxwrap/aacdecdll.cpp 2 Sep 2008
10:46:15 -0000
@@ -46,6 +46,10 @@
#include "aacdecdll.h"
#include "aacconstants.h"
+#include
+#include
+#include
+
const char* const CAACDec::m_pszCodecName = "RealAudio 10";
CAACDec::CAACDec()
@@ -80,6 +84,15 @@
//
STDMETHODIMP CAACDec::QueryInterface(REFIID riid, void** ppvObj)
{
+ /* This file controls whether we are allowed to use the AAC plugin */
+ #define ENABLE_FILE "/tmp/enable_plugin_aac"
+
+ /* Only allow AAC plugin to be used if there if file
+ * /tmp/enable_plugin_aac exists */
+ struct stat s;
+ if (stat(ENABLE_FILE, &s) == 0)
+ {
+ printf("HELIX: AAC Plugin Manually Enabled\n");
if (IsEqualIID(riid, IID_IHXAudioDecoder))
{
AddRef();
@@ -92,6 +105,11 @@
*ppvObj = this;
return HXR_OK;
}
+ }
+ else
+ {
+ printf("HELIX: AAC Plugin Manually Disabled\n");
+ }
*ppvObj = NULL;
_____
_______________________________________________
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/20080912/5648b868/attachment-0001.html
From pbasic at real.com Sun Sep 14 04:28:00 2008
From: pbasic at real.com (Petar Basic)
Date: Sun Sep 14 02:46:18 2008
Subject: [Helix-client-dev] CR/CN: Removed obsolete assertion in
MediaPlatform
Message-ID: <9b8350410809140428y6f0adfeejadc43b9baef30d6@mail.gmail.com>
Modified by: pbasic at real.com
Date: 2008/09/14
Project: strummer
Synopsis:
Removed obsolete assertion in MediaPlatform
Details:
One obsolete assertion can be removed now, since we fixed the mutex
around IDs used by scheduler (see CR: "Fixed thread-safety issues in
HXScheduler").
Files Modified:
client/medpltfm/chxmedpltfm.cpp
Platforms and Profiles Build Verified:
system id: win32-i386-vc7
profile: helix-dtdr-all-defines
Platforms and Profiles Functionality Verified:
x86 Windows XP SP2
Branch:
HEAD
hxclient_3_4_0_atlas
hxclient_3_1_0_atlas
Copyright assignment:
I am a RealNetworks employee or contractor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_medpltfm.310.diff
Type: application/octet-stream
Size: 2237 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080914/c3e141bb/client_medpltfm.310.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_medpltfm.340.diff
Type: application/octet-stream
Size: 2250 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080914/c3e141bb/client_medpltfm.340.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_medpltfm.head.diff
Type: application/octet-stream
Size: 2223 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080914/c3e141bb/client_medpltfm.head.obj
From narendra1310 at gmail.com Mon Sep 15 23:30:09 2008
From: narendra1310 at gmail.com (Narendra Parimi)
Date: Mon Sep 15 21:48:03 2008
Subject: [Helix-client-dev] Re: [Player-dev] Bad owner or permissions on
~/.ssh/config
In-Reply-To: <6.2.5.6.2.20080911130348.03c80f50@real.com>
References: <327debbd0809100018k3b1a746en7226b2e8b3235338@mail.gmail.com>
<6.2.5.6.2.20080911130348.03c80f50@real.com>
Message-ID: <327debbd0809152330k46e3f820haa6878052bd3cc79@mail.gmail.com>
Hi rishi,
i want to know how to build realplayer souce for "windows" . i have
build directory in my source path. but quick start quide provides
information to build players in linux , macintosh ans solaris os only . they
didnt mentioned it for windows os. only they gave information to get build
directory in windows.
I have done all things to get build directory , now i want to build
realplayer souce with the help of this build . i need instructions to
forward.
please help me
thanks in advance
shi Mathew wrote:
> Instead of using cygwin window, you should add the path-to-cygwin to your
> System path (add it to the end) and then open a Windows "cmd" terminal.
>
> Cheers,
> Rishi.
>
>
> At 12:18 AM 9/10/2008, Narendra Parimi wrote:
>
> I am trying to check ssh from cygwin in my windows system.
>
> I used the command:
> ssh -l "myusername" cvs.helicommunity.org
>
> i am getting this line
> Bad owner or permissions on ~/.ssh/config
>
> "myusername" is my helixcommunity username in the above command.
>
> please tell me what is wrong with ~/.ssh/config ?
>
>
> thanks and regards
>
> _______________________________________________
> Player-dev mailing list
> Player-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/player-dev
>
>
> *Rishi Mathew
> *Helix Community
> *Real* Networks, 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/20080916/91ce835f/attachment.html
From jrathore at real.com Wed Sep 17 12:37:04 2008
From: jrathore at real.com (Jyotsana Rathore)
Date: Wed Sep 17 10:54:37 2008
Subject: [Helix-client-dev] Re: [Player-dev] Bad owner or permissions
on~/.ssh/config
In-Reply-To: <327debbd0809152330k46e3f820haa6878052bd3cc79@mail.gmail.com>
References: <327debbd0809100018k3b1a746en7226b2e8b3235338@mail.gmail.com><6.2.5.6.2.20080911130348.03c80f50@real.com>
<327debbd0809152330k46e3f820haa6878052bd3cc79@mail.gmail.com>
Message-ID: <00f401c918fc$c385f090$f58016ac@corp.real.com>
Hi Narendra,
Realplayer source code for Windows is only internally available. You can
however, build the command line player which uses the same underlying
digital media platform that realplayer does.
Here's the quick start guide for building the Helix DNA client:
https://helix-client.helixcommunity.org/2004/devdocs/quickstart
Thanks,
Jyotsana
_____
From: helix-client-dev-bounces@helixcommunity.org
[mailto:helix-client-dev-bounces@helixcommunity.org] On Behalf Of Narendra
Parimi
Sent: Monday, September 15, 2008 11:30 PM
To: Rishi Mathew
Cc: narendra@chennai.novatium.com; helix-client-dev@helixcommunity.org;
player-dev@helixcommunity.org
Subject: [Helix-client-dev] Re: [Player-dev] Bad owner or permissions
on~/.ssh/config
Hi rishi,
i want to know how to build realplayer souce for "windows" . i have
build directory in my source path. but quick start quide provides
information to build players in linux , macintosh ans solaris os only . they
didnt mentioned it for windows os. only they gave information to get build
directory in windows.
I have done all things to get build directory , now i want to build
realplayer souce with the help of this build . i need instructions to
forward.
please help me
thanks in advance
shi Mathew wrote:
Instead of using cygwin window, you should add the path-to-cygwin to your
System path (add it to the end) and then open a Windows "cmd" terminal.
Cheers,
Rishi.
At 12:18 AM 9/10/2008, Narendra Parimi wrote:
I am trying to check ssh from cygwin in my windows system.
I used the command:
ssh -l "myusername" cvs.helicommunity.org
i am getting this line
Bad owner or permissions on ~/.ssh/config
"myusername" is my helixcommunity username in the above command.
please tell me what is wrong with ~/.ssh/config ?
thanks and regards
_______________________________________________
Player-dev mailing list
Player-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/player-dev
Rishi Mathew
Helix Community
Real Networks, 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/20080917/ce81df6d/attachment-0001.html
From mahmoudhammoud at gmail.com Thu Sep 18 09:42:33 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Thu Sep 18 07:59:50 2008
Subject: [Helix-client-dev] Video Scaling
Message-ID: <209f73910809180942p8f2dc4bt9cdc41135ea60a2b@mail.gmail.com>
Hi All,
If I would like to scale a video (up/down) to specific dimensions knowing
that it is originally 640x480 for example. Where is the best point to
perform that? What functions would allow me to do such scaling? My OS is
windows (maybe this is relevant for the site implementation).
Thanks a lot,
Mahmoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080918/81cbe835/attachment.html
From ehyche at real.com Thu Sep 18 13:13:48 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 18 11:30:59 2008
Subject: [Helix-client-dev] Video Scaling
In-Reply-To: <209f73910809180942p8f2dc4bt9cdc41135ea60a2b@mail.gmail.com>
References: <209f73910809180942p8f2dc4bt9cdc41135ea60a2b@mail.gmail.com>
Message-ID: <00cb01c919cb$0f89bbb0$2e9d3310$@com>
All you have to do is re-size your site. The site and surface
will take care of everything else.
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: helix-client-dev-bounces@helixcommunity.org [mailto:helix-client-dev-bounces@helixcommunity.org]
>On Behalf Of Mahmoud Hammoud
>Sent: Thursday, September 18, 2008 12:43 PM
>To: helix-client-dev@helixcommunity.org
>Subject: [Helix-client-dev] Video Scaling
>
>Hi All,
>
>If I would like to scale a video (up/down) to specific dimensions knowing that it is originally
>640x480 for example. Where is the best point to perform that? What functions would allow me to do such
>scaling? My OS is windows (maybe this is relevant for the site implementation).
>
>Thanks a lot,
>
>Mahmoud
From mahmoudhammoud at gmail.com Fri Sep 19 04:54:23 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Fri Sep 19 03:11:39 2008
Subject: [Helix-client-dev] Video Scaling
In-Reply-To: <00cb01c919cb$0f89bbb0$2e9d3310$@com>
References: <209f73910809180942p8f2dc4bt9cdc41135ea60a2b@mail.gmail.com>
<00cb01c919cb$0f89bbb0$2e9d3310$@com>
Message-ID: <209f73910809190454me2250c6p440c6a12b89c15fe@mail.gmail.com>
Thank you Eric,
Could you please point me to the function responsible for this site
"re-sizing" and where exactly I should call it?
Thanks again,
Mahmoud
On Thu, Sep 18, 2008 at 10:13 PM, Eric Hyche wrote:
> All you have to do is re-size your site. The site and surface
> will take care of everything else.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
> >-----Original Message-----
> >From: helix-client-dev-bounces@helixcommunity.org [mailto:
> helix-client-dev-bounces@helixcommunity.org]
> >On Behalf Of Mahmoud Hammoud
> >Sent: Thursday, September 18, 2008 12:43 PM
> >To: helix-client-dev@helixcommunity.org
> >Subject: [Helix-client-dev] Video Scaling
> >
> >Hi All,
> >
> >If I would like to scale a video (up/down) to specific dimensions knowing
> that it is originally
> >640x480 for example. Where is the best point to perform that? What
> functions would allow me to do such
> >scaling? My OS is windows (maybe this is relevant for the site
> implementation).
> >
> >Thanks a lot,
> >
> >Mahmoud
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080919/fb091aac/attachment.html
From blogostef at mediadigits.com Fri Sep 19 07:40:21 2008
From: blogostef at mediadigits.com (Blogostef)
Date: Fri Sep 19 05:59:08 2008
Subject: [Helix-client-dev] Linux platform: splay client for AAC and HE-AAC
codecs
Message-ID:
Hi everyone,
I am beginning development with the Helix DNA Client and I followed
the tutorial to have a command line player for mp3s. I would like to
have AAC and HE-AAC supported. I compiled the following splay client:
SYSTEM_ID= linux-2.2-libc6-gcc32-i586
Branch: hxclient_1_5_0_cayenne
Target: splay_audio_all
Profile: helix-client-local-audio-all
The compilation runs fine and I get a splay executable and the
following share objects: atrc.so
authmgr.so
clntcore.so
cook.so
httpfsys.so
hxsdp.so
hxxml.so
mp3fformat.so
mp3render.so
ralf.so
ramfformat.so
ramrender.so
rarender.so
rmfformat.so
rn5auth.so
sipr.so
smplfsys.so
I manage to play mp3s and real media files (that I created with
Real player on Windows since I could not have the Producer compile on
Linux :(, but it's another story,...). I guess that these real media
files are using the cook codec. The problem is that my splay
executable won't play my aac files (I did not try with he-aac so
far).
My aac files are wrapped in mp4 containers (I created some with Real
Player and some with I-tunes quick-time encoder).
I have the following questions:
*Do I need special settings for the compilation in order to have
aac and he-aac support? *Do I need a special licence to have a mp4
container support for audio? (or do I need to use real media as
container to play aac encoded audio?) *And a last question, I know
that it is possible to use ogg as a container for aac or he-aac. Does
helix support such combination (ogg+aac, or ogg+he-aac)?
Best regards,
St?phane.
PS: Here is an exemple of what happens when I attempt playing an
aac encoded audio file in a mp4 audio container. [bmwft@localhost
debug]$ ./splay -s /media/data/audioTestData/test1-aac-64QT.m4a
Simpleplayer is looking for the client core at ./clntcore.so
Common DLL path DT_Common=.
Plugin path DT_Plugins=.
Codec path DT_Codecs=.
Starting play #1...
opening
file:///media/data/audioTestData/test1-aac-64QT.m4a on
player 0
Starting player 0...
Playback complete. Stopping all players...
Done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080919/2a83df53/attachment.html
From ehyche at real.com Fri Sep 19 08:54:03 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 19 07:11:03 2008
Subject: [Helix-client-dev] Video Scaling
In-Reply-To: <209f73910809190454me2250c6p440c6a12b89c15fe@mail.gmail.com>
References: <209f73910809180942p8f2dc4bt9cdc41135ea60a2b@mail.gmail.com>
<00cb01c919cb$0f89bbb0$2e9d3310$@com>
<209f73910809190454me2250c6p440c6a12b89c15fe@mail.gmail.com>
Message-ID: <007d01c91a6f$f0717830$d1546890$@com>
IHXSite::SetSize()
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: Mahmoud Hammoud [mailto:mahmoudhammoud@gmail.com]
>Sent: Friday, September 19, 2008 7:54 AM
>To: ehyche@real.com
>Cc: Jyotsana Rathore; helix-client-dev@helixcommunity.org
>Subject: Re: [Helix-client-dev] Video Scaling
>
>Thank you Eric,
>
>Could you please point me to the function responsible for this site "re-sizing" and where exactly I
>should call it?
>
>Thanks again,
>
>Mahmoud
>
>
>On Thu, Sep 18, 2008 at 10:13 PM, Eric Hyche wrote:
>
>
> All you have to do is re-size your site. The site and surface
> will take care of everything else.
>
> Eric
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>
> >-----Original Message-----
> >From: helix-client-dev-bounces@helixcommunity.org [mailto:helix-client-dev-
>bounces@helixcommunity.org]
> >On Behalf Of Mahmoud Hammoud
> >Sent: Thursday, September 18, 2008 12:43 PM
> >To: helix-client-dev@helixcommunity.org
> >Subject: [Helix-client-dev] Video Scaling
> >
> >Hi All,
> >
> >If I would like to scale a video (up/down) to specific dimensions knowing that it is originally
> >640x480 for example. Where is the best point to perform that? What functions would allow me to
>do such
> >scaling? My OS is windows (maybe this is relevant for the site implementation).
> >
> >Thanks a lot,
> >
> >Mahmoud
>
>
>
From mahmoudhammoud at gmail.com Tue Sep 23 08:00:02 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Tue Sep 23 06:16:07 2008
Subject: [Helix-client-dev] IHXSite::SetSize()
Message-ID: <209f73910809230800h7d12149ek8493fe21f4bb656d@mail.gmail.com>
Hi All,
I posted a question last week where I wanted to change the dimensions of my
video and Eric suggested that I should resize the site using
IHXSite::SetSize(). Does this mean that I can call this function at any
point? Where is the size of the site being set initially (maybe it would be
easier for me to just change it from there). Can someone tell me what's
wrong with this code?
bool ResizeSite()
{
HX_RESULT retVal = HXR_FAIL;
IHXClientEngine* pEngine = NULL;
IUnknown * pPlayer = NULL;
IHXSiteManager2* pSiteMgr2 = NULL;
IHXSite* pSite = NULL;
m_pContext->QueryInterface(IID_IHXClientEngine, (void**)&pEngine);
//Assuming 1 player, 1 site
if(pEngine)
{
pEngine->GetPlayer(0,pPlayer);
// Get the IHXSiteManager2 interface
if(pPlayer)
{
retVal = pPlayer->QueryInterface(IID_IHXSiteManager2, (void**)
&pSiteMgr2);
if(SUCCEEDED(retVal))
{
retVal = pSiteMgr2->GetSiteAt(0, pSite);
if(SUCCEEDED(retVal))
{
HXxSize new_size;
new_size.cx = 200;
new_size.cy = 200;
//pSite->AddRef(); //Is this necessary?
pSite->SetSize(new_size);
return true;
}
HX_RELEASE(pSite);
}
pSiteMgr2->Release();
}
HX_RELEASE(pPlayer);
}
HX_RELEASE(pEngine);
return false;
}
Thanks a lot,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080923/88cb2668/attachment-0001.html
From deepakj at real.com Tue Sep 23 17:40:47 2008
From: deepakj at real.com (deepakj@real.com)
Date: Tue Sep 23 15:56:49 2008
Subject: [Helix-client-dev] CR: Changes in hxclient_3_1_0_atlas.bif for
better Fix of Bug 8682
Message-ID: <48394.122.163.69.47.1222216847.squirrel@mailone.real.com>
Project: RealPlayer for Netbook
Synopsis: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
Overview:
datatype_dist_wm_video_codec_wmv8 is now also defined in
hxclient_3_1_0_atlas.bif. It was already in
hxclient_3_1_0_atlas_restricted.bif
NOTE: datatype_dist_wm_video_codec_wmv8 module definitions exist in both
hxclient_1_5_0_cayenne.bif and hxclient_1_5_0_cayenne_restricted.bif
Now we are using HELIX_FEATURE_WM macro which will be defined in
hxclient_3_1_0_atlas.bif. As a result, the macro will only be defined if
the module is actually built.
Files Modified:
build/BIF/hxclient_3_1_0_atlas.bif
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
Linux
Distribution Libraries Affected:
None.
Distribution library impact and planned action:
None.
Platforms and Profiles Build Verified:
Profile: helix_client_all_defines
Target: linux_realplayer
BIF: realplay_gtk_atlas_restricted
Files Attached:
hxclient_3_1_0_atlas.diff
Thanks,
Deepak Jain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxclient_3_1_0_atlas.diff
Type: text/x-patch
Size: 1076 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080923/2988c45d/hxclient_3_1_0_atlas.bin
From blogostef at mediadigits.com Wed Sep 24 01:42:28 2008
From: blogostef at mediadigits.com (Stephane Turlier)
Date: Tue Sep 23 23:55:54 2008
Subject: [Helix-client-dev] Linux platform: splay client for AAC and HE-AAC
codecs
Message-ID: <346b42de958af4f9143cae4eb1ec7e91@localhost>
Hello,
I come again to you because I am having a hard time to have the aac
playback on a simple player client on Linux. I tried to do it this way.
* I build with ribosome a splay_audio_all client based on the cayenne
1_5_0 branche, and I save the files compiled in the \debug folder to
another folder, lets call it \splay_player. This splay_audio_all client is
able to playback mp3s and ras but no m4a file. Indeed it does not have the
libraries for it.
* I build with ribosome a datatype_mp4_audio_renderer and I copy the
compiled files to my \splay_player folder.
But still, my splay player won't play my m4a files (using aac codec).
I think I am missing something (like building dependencies, etc), but I
can't see what, I am really stuck.
Thanks in advance for your answers.
Regards,
Stephane.
From gwright at real.com Wed Sep 24 10:18:57 2008
From: gwright at real.com (Greg Wright)
Date: Wed Sep 24 08:34:37 2008
Subject: [Helix-client-dev] Linux platform: splay client for AAC and HE-AAC
codecs
In-Reply-To: <346b42de958af4f9143cae4eb1ec7e91@localhost>
References: <346b42de958af4f9143cae4eb1ec7e91@localhost>
Message-ID: <48DA7681.9000405@real.com>
Not AAC specific, but, by *far* the best combination to build is:
splay
helix-client-all-defines
That is the largest build, but includes support for
everything. It is also tested the most. Once that works
for you, you can then start parsing down the build if
needed. There are so many combinations available to build
splay that some don't always work if they have not been
built/used by anyone in a long time.
--greg.
Stephane Turlier wrote:
> Hello,
>
> I come again to you because I am having a hard time to have the aac
> playback on a simple player client on Linux. I tried to do it this way.
>
> * I build with ribosome a splay_audio_all client based on the cayenne
> 1_5_0 branche, and I save the files compiled in the \debug folder to
> another folder, lets call it \splay_player. This splay_audio_all client is
> able to playback mp3s and ras but no m4a file. Indeed it does not have the
> libraries for it.
>
> * I build with ribosome a datatype_mp4_audio_renderer and I copy the
> compiled files to my \splay_player folder.
>
> But still, my splay player won't play my m4a files (using aac codec).
>
> I think I am missing something (like building dependencies, etc), but I
> can't see what, I am really stuck.
>
> Thanks in advance for your answers.
>
> Regards,
>
> Stephane.
>
>
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>
From deepakj at real.com Wed Sep 24 17:27:38 2008
From: deepakj at real.com (deepakj@real.com)
Date: Wed Sep 24 15:43:27 2008
Subject: [Helix-client-dev] CR[RESENDING]: Changes in
hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
Message-ID: <36728.122.163.69.66.1222302458.squirrel@mailone.real.com>
Resending.
---------------------------- Original Message ----------------------------
Subject: CR: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
From: deepakj@real.com
Date: Tue, September 23, 2008 5:40 pm
To: helix-client-dev@helixcommunity.org
--------------------------------------------------------------------------
Project: RealPlayer for Netbook
Synopsis: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
Overview:
datatype_dist_wm_video_codec_wmv8 is now also defined in
hxclient_3_1_0_atlas.bif. It was already in
hxclient_3_1_0_atlas_restricted.bif
NOTE: datatype_dist_wm_video_codec_wmv8 module definitions exist in both
hxclient_1_5_0_cayenne.bif and hxclient_1_5_0_cayenne_restricted.bif
Now we are using HELIX_FEATURE_WM macro which will be defined in
hxclient_3_1_0_atlas.bif. As a result, the macro will only be defined if
the module is actually built.
Files Modified:
build/BIF/hxclient_3_1_0_atlas.bif
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
Linux
Distribution Libraries Affected:
None.
Distribution library impact and planned action:
None.
Platforms and Profiles Build Verified:
Profile: helix_client_all_defines
Target: linux_realplayer
BIF: realplay_gtk_atlas_restricted
Files Attached:
hxclient_3_1_0_atlas.diff
Thanks,
Deepak Jain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hxclient_3_1_0_atlas.diff
Type: text/x-patch
Size: 1076 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080924/4d54e810/hxclient_3_1_0_atlas.bin
From mahmoudhammoud at gmail.com Thu Sep 25 01:07:05 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Wed Sep 24 23:22:40 2008
Subject: [Helix-client-dev] HXThreadedSocket
Message-ID: <209f73910809250107w33b8a7d9m35e061e381700e84@mail.gmail.com>
Dear All,
First of all I would like to thank you a lot (especially Jyotsana, Greg, and
Eric) for your constant support, this mailing list has been very helpful and
at the same time really informative.
I have a question regarding how packets make it through from the low-level
socket implementation in HXThreadedSocket, to the (RTP/UDP) transport layer
(with m_pOwner->ReadFromDone(...) in rtspclnt.cpp) and finally reach the
"application" layer. From what I know, this is roughly what happens:
1) The UDP sockets are created with
RTSPClientProtocol::CreateUDPSockets(...), which is called in InitSockets(
).
2) In the net thread, the chain HXThreadedSocket::EventPending(...),
HandleRead( ), m_pSock->ReadFrom(...), m_inbound.AddTail(pBuf, pAddr) gets
executed (for read events).
HERE IS MY MISSING LINK, where does this m_inbound structure get read again
i.e. what happens between this point and m_pOwner->ReadFromDone(...) in
RTSPClientProtocol::UDPResponseHelper::EventPending(...)? Where do the
packets (pBuf) get dequeued from m_inbound and then reach this point to be
passed to the transport layer?
Thank you again,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080925/9e21f401/attachment.html
From ehyche at real.com Thu Sep 25 08:48:38 2008
From: ehyche at real.com (Eric Hyche)
Date: Thu Sep 25 07:04:10 2008
Subject: [Helix-client-dev] CR[RESENDING]: Changes in
hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
In-Reply-To: <36728.122.163.69.66.1222302458.squirrel@mailone.real.com>
References: <36728.122.163.69.66.1222302458.squirrel@mailone.real.com>
Message-ID: <00c401c91f26$2e426010$8ac72030$@com>
This looks good to me.
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: helix-client-dev-bounces@helixcommunity.org [mailto:helix-client-dev-bounces@helixcommunity.org]
>On Behalf Of deepakj@real.com
>Sent: Wednesday, September 24, 2008 8:28 PM
>To: helix-client-dev@helixcommunity.org
>Subject: [Helix-client-dev] CR[RESENDING]: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug
>8682
>
>Resending.
>
>---------------------------- Original Message ----------------------------
>Subject: CR: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
>From: deepakj@real.com
>Date: Tue, September 23, 2008 5:40 pm
>To: helix-client-dev@helixcommunity.org
>--------------------------------------------------------------------------
>
>Project: RealPlayer for Netbook
>
>Synopsis: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
>
>Overview:
>
>datatype_dist_wm_video_codec_wmv8 is now also defined in hxclient_3_1_0_atlas.bif. It was already in
>hxclient_3_1_0_atlas_restricted.bif
>NOTE: datatype_dist_wm_video_codec_wmv8 module definitions exist in both hxclient_1_5_0_cayenne.bif
>and hxclient_1_5_0_cayenne_restricted.bif
>
>Now we are using HELIX_FEATURE_WM macro which will be defined in hxclient_3_1_0_atlas.bif. As a
>result, the macro will only be defined if the module is actually built.
>
>Files Modified:
>build/BIF/hxclient_3_1_0_atlas.bif
>
>Image Size and Heap Use impact (Client -Only):
>None.
>
>Platforms and Profiles Affected:
>Linux
>
>Distribution Libraries Affected:
>None.
>
>Distribution library impact and planned action:
>None.
>
>Platforms and Profiles Build Verified:
>Profile: helix_client_all_defines
>Target: linux_realplayer
>BIF: realplay_gtk_atlas_restricted
>
>Files Attached:
>hxclient_3_1_0_atlas.diff
>
>Thanks,
>Deepak Jain
From deepakj at real.com Thu Sep 25 09:09:32 2008
From: deepakj at real.com (deepakj@real.com)
Date: Thu Sep 25 07:25:00 2008
Subject: [Helix-client-dev] CR[RESENDING]: Changes in
hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
In-Reply-To: <00c401c91f26$2e426010$8ac72030$@com>
References: <36728.122.163.69.66.1222302458.squirrel@mailone.real.com>
<00c401c91f26$2e426010$8ac72030$@com>
Message-ID: <33060.122.163.69.26.1222358972.squirrel@mailone.real.com>
Thanks Eric,
Changes have been checked-in.
Thanks,
Deepak Jain
> This looks good to me.
>
> =======================================
> Eric Hyche (ehyche@real.com)
> Principal Engineer
> RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: helix-client-dev-bounces@helixcommunity.org
>> [mailto:helix-client-dev-bounces@helixcommunity.org]
>>On Behalf Of deepakj@real.com
>>Sent: Wednesday, September 24, 2008 8:28 PM
>>To: helix-client-dev@helixcommunity.org
>>Subject: [Helix-client-dev] CR[RESENDING]: Changes in
>> hxclient_3_1_0_atlas.bif for better Fix of Bug
>>8682
>>
>>Resending.
>>
>>---------------------------- Original Message
>> ----------------------------
>>Subject: CR: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug
>> 8682
>>From: deepakj@real.com
>>Date: Tue, September 23, 2008 5:40 pm
>>To: helix-client-dev@helixcommunity.org
>>--------------------------------------------------------------------------
>>
>>Project: RealPlayer for Netbook
>>
>>Synopsis: Changes in hxclient_3_1_0_atlas.bif for better Fix of Bug 8682
>>
>>Overview:
>>
>>datatype_dist_wm_video_codec_wmv8 is now also defined in
>> hxclient_3_1_0_atlas.bif. It was already in
>>hxclient_3_1_0_atlas_restricted.bif
>>NOTE: datatype_dist_wm_video_codec_wmv8 module definitions exist in both
>> hxclient_1_5_0_cayenne.bif
>>and hxclient_1_5_0_cayenne_restricted.bif
>>
>>Now we are using HELIX_FEATURE_WM macro which will be defined in
>> hxclient_3_1_0_atlas.bif. As a
>>result, the macro will only be defined if the module is actually built.
>>
>>Files Modified:
>>build/BIF/hxclient_3_1_0_atlas.bif
>>
>>Image Size and Heap Use impact (Client -Only):
>>None.
>>
>>Platforms and Profiles Affected:
>>Linux
>>
>>Distribution Libraries Affected:
>>None.
>>
>>Distribution library impact and planned action:
>>None.
>>
>>Platforms and Profiles Build Verified:
>>Profile: helix_client_all_defines
>>Target: linux_realplayer
>>BIF: realplay_gtk_atlas_restricted
>>
>>Files Attached:
>>hxclient_3_1_0_atlas.diff
>>
>>Thanks,
>>Deepak Jain
>
>
From blogostef at mediadigits.com Thu Sep 25 10:30:38 2008
From: blogostef at mediadigits.com (Stephane Turlier)
Date: Thu Sep 25 08:48:26 2008
Subject: [Helix-client-dev] Linux platform: splay client for AAC and HE-AAC
codecs
In-Reply-To: <48DA7681.9000405@real.com>
References: <346b42de958af4f9143cae4eb1ec7e91@localhost>
<48DA7681.9000405@real.com>
Message-ID: <3746e0a5bf7639762ced026874c5a437@localhost>
Thanks for your reply Greg,
Unfortunately, such settings won't build on my configuration (I tried both
helix and cayenne 1_5_0 branches). Actually most of the image and video
modules won't build and I had very little time today to investigate on it.
Besides I am for the moment more interested in the audio modules (that do
build and work since I achieved playback of mp3 and ra).
However, I have some questions: is it normal that the splay_audio_all does
not have support for aac or is-it just my config that does not build it
properly?
I am using the system variable SYSTEM_ID= linux-2.2-libc6-gcc32-i586 as
indicated in the quick start tutorial. But I am actually running a Fedora
Core 9 with linux-2.6 and gcc 4.3! Is-it part of the reason? Does any-one
use such development environment and could give some feedback?
Regards,
Stephane.
On Wed, 24 Sep 2008 10:18:57 -0700, Greg Wright wrote:
> Not AAC specific, but, by *far* the best combination to build is:
>
> splay
> helix-client-all-defines
>
> That is the largest build, but includes support for
> everything. It is also tested the most. Once that works
> for you, you can then start parsing down the build if
> needed. There are so many combinations available to build
> splay that some don't always work if they have not been
> built/used by anyone in a long time.
>
> --greg.
>
>
>
> Stephane Turlier wrote:
>> Hello,
>>
>> I come again to you because I am having a hard time to have the aac
>> playback on a simple player client on Linux. I tried to do it this way.
>>
>> * I build with ribosome a splay_audio_all client based on the
> cayenne
>> 1_5_0 branche, and I save the files compiled in the \debug folder to
>> another folder, lets call it \splay_player. This splay_audio_all client
> is
>> able to playback mp3s and ras but no m4a file. Indeed it does not have
> the
>> libraries for it.
>>
>> * I build with ribosome a datatype_mp4_audio_renderer and I copy
> the
>> compiled files to my \splay_player folder.
>>
>> But still, my splay player won't play my m4a files (using aac codec).
>>
>> I think I am missing something (like building dependencies, etc), but I
>> can't see what, I am really stuck.
>>
>> Thanks in advance for your answers.
>>
>> Regards,
>>
>> Stephane.
>>
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
From dyek at real.com Thu Sep 25 11:30:10 2008
From: dyek at real.com (Daniel Yek)
Date: Thu Sep 25 09:45:36 2008
Subject: [Helix-client-dev] Linux platform: splay client for AAC and HE-AAC
codecs
In-Reply-To: <3746e0a5bf7639762ced026874c5a437@localhost>
References: <346b42de958af4f9143cae4eb1ec7e91@localhost> <48DA7681.9000405@real.com>
<3746e0a5bf7639762ced026874c5a437@localhost>
Message-ID: <48DBD8B2.3020206@real.com>
Stephane Turlier wrote:
> Thanks for your reply Greg,
>
> Unfortunately, such settings won't build on my configuration (I tried both
> helix and cayenne 1_5_0 branches). Actually most of the image and video
> modules won't build and I had very little time today to investigate on it.
>
Hi Stephane,
We usually encourage developers to get over the problems of building
with these settings though. Getting through that could probably resolves
the problem, yourself.
> Besides I am for the moment more interested in the audio modules (that do
> build and work since I achieved playback of mp3 and ra).
>
> However, I have some questions: is it normal that the splay_audio_all does
> not have support for aac or is-it just my config that does not build it
> properly?
>
Are raac.so, mp4arender.so, and mp4fformat.so getting built? If so, AAC
and HE-AAC support should probably be there.
(I don't see raac.so, nor mp4*.so, in your initial post. That might be
the problem. Also you mentioned building datatype_mp4_audio_renderer,
but that probably didn't include the decoder -- I didn't check when I'm
typing this out.)
If not, and if you would like, you can investigate into building
aacff.so if it helps. Also, read to the bottom of my response.
> I am using the system variable SYSTEM_ID= linux-2.2-libc6-gcc32-i586 as
> indicated in the quick start tutorial.
> But I am actually running a Fedora
> Core 9 with linux-2.6 and gcc 4.3! Is-it part of the reason? Does any-one
> use such development environment and could give some feedback?
>
This:
SYSTEM_ID=linux-2.2-libc6-gcc32-i586
is the right setting for Linux (x86 machine, of course) for most cases.
In fact, most of the time other SYSTEM_ID simply won't work well,
because of the existence of some SYSTEM_ID specific .pcf files and more
importantly the availability of distribution binaries for the SYSTEM_ID.
Think of it that the SYSTEM_ID requires Linux 2.2 and continues to work
for Linux 2.6. There is some amount of work to change the SYSTEM_ID to
be more intuitive, but for no much any other gain.
When working with systems with selinux turned on, such as Fedora, it is
essential to make sure that selinux isn't preventing the .so files and
the application from being loaded.
Running the following command after every build usually solves the
selinux problem (quick and dirty):
chcon -t texrel_shlib_t *.so
I know that raac.so file is linked with some object files not compiled
with -fPIC and thus is causing problems with selinux. So, apply chcon
command above on it as the minimum.
I think the most sensible thing for us to do is to integrate the selinux
chcon support into Ribosome, the Helix build system, so that developers
don't need to be aware of selinux problem or have to install the product
built so that the product can handle chcon operations during
installation. I'll have to do that much later when I have the time,
unless someone submit a patch.
--
Daniel Yek.
> Regards,
>
> Stephane.
>
>
> On Wed, 24 Sep 2008 10:18:57 -0700, Greg Wright wrote:
>
>> Not AAC specific, but, by *far* the best combination to build is:
>>
>> splay
>> helix-client-all-defines
>>
>> That is the largest build, but includes support for
>> everything. It is also tested the most. Once that works
>> for you, you can then start parsing down the build if
>> needed. There are so many combinations available to build
>> splay that some don't always work if they have not been
>> built/used by anyone in a long time.
>>
>> --greg.
>>
>>
>>
>> Stephane Turlier wrote:
>>
>>> Hello,
>>>
>>> I come again to you because I am having a hard time to have the aac
>>> playback on a simple player client on Linux. I tried to do it this way.
>>>
>>> * I build with ribosome a splay_audio_all client based on the
>>>
>> cayenne
>>
>>> 1_5_0 branche, and I save the files compiled in the \debug folder to
>>> another folder, lets call it \splay_player. This splay_audio_all client
>>>
>> is
>>
>>> able to playback mp3s and ras but no m4a file. Indeed it does not have
>>>
>> the
>>
>>> libraries for it.
>>>
>>> * I build with ribosome a datatype_mp4_audio_renderer and I copy
>>>
>> the
>>
>>> compiled files to my \splay_player folder.
>>>
>>> But still, my splay player won't play my m4a files (using aac codec).
>>>
>>> I think I am missing something (like building dependencies, etc), but I
>>> can't see what, I am really stuck.
>>>
>>> Thanks in advance for your answers.
>>>
>>> Regards,
>>>
>>> Stephane.
>>>
From mahmoudhammoud at gmail.com Fri Sep 26 08:50:22 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Fri Sep 26 07:05:37 2008
Subject: [Helix-client-dev] Fwd: HXThreadedSocket
In-Reply-To: <209f73910809250107w33b8a7d9m35e061e381700e84@mail.gmail.com>
References: <209f73910809250107w33b8a7d9m35e061e381700e84@mail.gmail.com>
Message-ID: <209f73910809260850g70e99ed9ub25be610326dfdbc@mail.gmail.com>
Hi All,
Could someone please take a quick look at my question? This is quite
important. In relation to it, I would also like to know the difference
between IHXSocket and CHXSocket. Where is the function IHXSocket::ReadFrom
which is called in HXThreadedSocket::HandleRead( ) actually implemented? I
really appreciate your help.
All the best,
Mahmoud
---------- Forwarded message ----------
From: Mahmoud Hammoud
Date: Thu, Sep 25, 2008 at 10:07 AM
Subject: HXThreadedSocket
To: helix-client-dev@helixcommunity.org
Cc: Jyotsana Rathore , Gregory Wright ,
ehyche@real.com
Dear All,
First of all I would like to thank you a lot (especially Jyotsana, Greg, and
Eric) for your constant support, this mailing list has been very helpful and
at the same time really informative.
I have a question regarding how packets make it through from the low-level
socket implementation in HXThreadedSocket, to the (RTP/UDP) transport layer
(with m_pOwner->ReadFromDone(...) in rtspclnt.cpp) and finally reach the
"application" layer. From what I know, this is roughly what happens:
1) The UDP sockets are created with
RTSPClientProtocol::CreateUDPSockets(...), which is called in InitSockets(
).
2) In the net thread, the chain HXThreadedSocket::EventPending(...),
HandleRead( ), m_pSock->ReadFrom(...), m_inbound.AddTail(pBuf, pAddr) gets
executed (for read events).
HERE IS MY MISSING LINK, where does this m_inbound structure get read again
i.e. what happens between this point and m_pOwner->ReadFromDone(...) in
RTSPClientProtocol::UDPResponseHelper::EventPending(...)? Where do the
packets (pBuf) get dequeued from m_inbound and then reach this point to be
passed to the transport layer?
Thank you again,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080926/83f8da48/attachment.html
From ehyche at real.com Fri Sep 26 10:41:42 2008
From: ehyche at real.com (Eric Hyche)
Date: Fri Sep 26 08:56:58 2008
Subject: [Helix-client-dev] RE: HXThreadedSocket
In-Reply-To: <209f73910809260850g70e99ed9ub25be610326dfdbc@mail.gmail.com>
References: <209f73910809250107w33b8a7d9m35e061e381700e84@mail.gmail.com>
<209f73910809260850g70e99ed9ub25be610326dfdbc@mail.gmail.com>
Message-ID: <00fc01c91fff$24b0fc30$6e12f490$@com>
Here is a link that may help:
https://helix-client.helixcommunity.org/2008/devdocs/Network_layer_helix.html
Eric
=======================================
Eric Hyche (ehyche@real.com)
Principal Engineer
RealNetworks, Inc.
>-----Original Message-----
>From: Mahmoud Hammoud [mailto:mahmoudhammoud@gmail.com]
>Sent: Friday, September 26, 2008 11:50 AM
>To: helix-client-dev@helixcommunity.org
>Cc: Jyotsana Rathore; Gregory Wright; ehyche@real.com
>Subject: Fwd: HXThreadedSocket
>
>Hi All,
>
>Could someone please take a quick look at my question? This is quite important. In relation to it, I
>would also like to know the difference between IHXSocket and CHXSocket. Where is the function
>IHXSocket::ReadFrom which is called in HXThreadedSocket::HandleRead( ) actually implemented? I really
>appreciate your help.
>
>All the best,
>
>Mahmoud
>
>
>---------- Forwarded message ----------
>From: Mahmoud Hammoud
>Date: Thu, Sep 25, 2008 at 10:07 AM
>Subject: HXThreadedSocket
>To: helix-client-dev@helixcommunity.org
>Cc: Jyotsana Rathore , Gregory Wright , ehyche@real.com
>
>
>
>Dear All,
>
>First of all I would like to thank you a lot (especially Jyotsana, Greg, and Eric) for your constant
>support, this mailing list has been very helpful and at the same time really informative.
>
>I have a question regarding how packets make it through from the low-level socket implementation in
>HXThreadedSocket, to the (RTP/UDP) transport layer (with m_pOwner->ReadFromDone(...) in rtspclnt.cpp)
>and finally reach the "application" layer. From what I know, this is roughly what happens:
>
>1) The UDP sockets are created with RTSPClientProtocol::CreateUDPSockets(...), which is called in
>InitSockets( ).
>
>2) In the net thread, the chain HXThreadedSocket::EventPending(...), HandleRead( ), m_pSock-
>>ReadFrom(...), m_inbound.AddTail(pBuf, pAddr) gets executed (for read events).
>
>HERE IS MY MISSING LINK, where does this m_inbound structure get read again i.e. what happens between
>this point and m_pOwner->ReadFromDone(...) in
>RTSPClientProtocol::UDPResponseHelper::EventPending(...)? Where do the packets (pBuf) get dequeued
>from m_inbound and then reach this point to be passed to the transport layer?
>
>Thank you again,
>
>Mahmoud Hammoud
>
From mahmoudhammoud at gmail.com Tue Sep 30 06:55:24 2008
From: mahmoudhammoud at gmail.com (Mahmoud Hammoud)
Date: Tue Sep 30 05:09:41 2008
Subject: [Helix-client-dev] UDP Sockets
Message-ID: <209f73910809300655p573fef74tbbad0057ace0d81@mail.gmail.com>
Dear All,
I would really appreciate reasonably detailed answers to the following 2
questions (urgent), this would represent a gread push to my project. I am
developing under windows and interested in RTP transport over UDP of mp4
media.
1) Where exactly (class::function) are the socket API functions sendto(...)
and recvfrom(...) called at the server and client respectively? I am just
interested in the actual transmission through the socket API (i.e. at the
lowest level) and I am quite frustrated with all the OS abstractions
available within the source code.
2) Suppose I comment the function calls in 1), to replace them by similar
ones but on a socket (only one) I create myself, still passing the received
"buffers" appropriately to the upper layers, would this work? I know that
each stream in the presentation (audio and video) has its own UDP socket,
but does this mean that the socket IO functions are called in a threaded
manner and that the data received on the audio stream's socket will be
stored in a transport buffer for that stream (and same for video)? That is,
are the different streams buffered separately at the transport layer (based
on the stream number maybe)?
Thank you in advance,
Mahmoud Hammoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20080930/efe5d2b5/attachment-0001.html
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.