Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
- Subject: Re: CPU at 100% [Was: AAC and AudioConverter error : '!pkd']
- From: William Stewart <email@hidden>
- Date: Thu, 29 Mar 2007 17:16:49 -0700
On 29/03/2007, at 2:11 AM, Edward Hervey wrote:
Hi,
I still haven't solved the issue, here is more information.
I am currently developing plugins for the GStreamer multimedia
framework in order to wrap and use the QuickTime audio decoder
components on MacOSX.
In order to better understand the code below, it is important to
know that GStreamer elements know nothing of the global pipeline, they
only receive data from upstream and push some downstream. They can
also receive stream information as caps (for example : the number of
channels, the sampling rate, the depth...).
This also means that, unlike with quicktime, there is no central
node (Movie, AudioFile) where plugins can request information. I can
therefore not use Functions like AudioFileReadPackets(), or any other
API that requests specific structures from upstream. I need to create
those structures in my plugin according to the stream information
received from upstream and the format currently used.
Basically you don't have enough information being passed to you. You
have to provide packet descriptions for many compressed formats
because they are NOT self framing, so you can't delineate where the
boundaries are.
You need to understand this, and have the layers above you provide
you with richer information than you are currently getting
Bill
Description of the problem:
I am using the AudioConverter API in order to wrap decoding of
compressed audio streams. Unfortunately I'm getting some big
inconsistencies, mostly related to returning
AudioStreamPacketDescription in the buffer_proc called from
AudioConverterFillComplexBuffer().
If I do NOT give an AudioStreamPacketDescription in the buffer_proc,
QDM2 and mp3 streams will decode fine, but AAC will complain about
needing those descriptions (FillComplexBuffer() returning '!pkd').
If I DO give an AudioStreamPacketDescription in the buffer_proc,
QDM2 will work fine, but both mp3 and AAC streams will take 100% cpu
as soon as the first call to the buffer_proc returns.
I tried testing this behaviour with the PlayAudioFileLite sample
code from the ADC website, since it has the closest behaviour. I
modified that sample code and added the same code I have in my
buffer_proc to give a valid ASPD. With that modification, the sample
code works fine. Therefore I am assuming that the values I use to fill
in the ASPD are valid.
I have also looked at what magic cookie is being set on the
AudioConverter in that sample code, and for the cases where my plugin
code is in sync with that (ex: mp3 has no magic cookie) I still do get
the 100% cpu usage situations.
I have exhausted all my research in API docs and header files and
cannot find what is wrong with the attached code.
I need to be able to decompress AAC and mp3. I would like to know
what is wrong with the given code in order to be able to decompress
those two formats.
Description of attachments:
mp3-100%-backtraces.txt : 3 backtraces of the state of the decoding
thread when taking 100% cpu for mp3 when returning ASPD
aac-100%-backtraces.txt : 3 backtraces of the state of the decoding
thread when taking 100% cpu for AAC when returning ASPD
audiodecoders.c : The main source code of the GStreamer plugin.
I haven't attached them because they are quite big , but I can
provide full debug logs of the failing runs (all the lines with
GST_LOG, GST_WARNING, GST_ERROR are in it).
Thankyou,
Edward
On 3/21/07, Edward Hervey <email@hidden> wrote:
Hi,
Yes that behaviour control is already in it, else it would have
never worked with mp3 in the first place. If I don't return the ASPD
for mp3, it will work with both my code and the PlayAudioFileLite,
but
if I return it it will fail with my code.
The 100% cpu is after the very first call where I DO return some
information. my input proc only gets called once and I'm returning
exactly the same information as in the PlayAudioFileLite example.
Edward
On 3/20/07, William Stewart <email@hidden> wrote:
> Check if your input proc is being called repeatedly - if you
have no
> more input data, then you need to return an error from your input
> proc; that is a signal that says "i have no input data now, stop
> bugging me" - the converter will return that error code to you (as
> the caller of the FillComplexBuffer call) and will try to give
you as
> much data as it can - probably not as much as you asked for -
because
> you didn't give it enough input
>
> HTH
>
> Bill
>
--
Edward Hervey
Multimedia editing developer / Fluendo S.A.
http://www.pitivi.org/
<aac-100%-backtraces.txt>
<mp3-100%-backtraces.txt>
<audiodecoders.c>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden