Re: Getting wrong data format for stream
Re: Getting wrong data format for stream
- Subject: Re: Getting wrong data format for stream
- From: Tom Harrington <email@hidden>
- Date: Wed, 22 Jul 2009 15:45:11 -0600
James,
Thanks for the insight. Since this is a known audio stream whose
format does not change, should I just fill in the format data myself
instead of looking up the format property? Given a scenario where the
hinting process fails, should AudioQueueNewOutput be able to create a
working audio queue, if I supply the correct format?
Or, is there some way I can help out the hinting more than I am?
On Wed, Jul 22, 2009 at 12:16 PM, james mccartney<email@hidden> wrote:
>
> On Jul 22, 2009, at 10:45 AM, Tom Harrington wrote:
>
> [Sorry, I did mean to send this to the list...]
>
>
> [OK, then I repost my reply, with a couple of edits]
> Is it possible that the first buffer has no MP3 packet at all in it?
>
> Here's how the hinting works in the format recognizer:
>
> The format parsers can return YES, NO, or CANT DETERMINE to the question of
> whether the data is of their type.
>
> First any ID3 tags are skipped .
> Second, it asks the hinted format parser if the data is of that type. If it
> returns YES, then return.
> Then it checks the data against all the file format parsers to see if any
> return YES. If one does then return.
> Otherwise then as long as the hinted format parser does not return NO then
> we assume it is of that type.
>
> The MP3 parser returns YES if the first bytes are an MP3 packet header, else
> it returns CANT DETERMINE.
>
> So you may be in the situation where the first buffer does not start with a
> layer 3 packet and it does have some bytes that happen to look like a layer
> 1 packet.
>
>
> Alternatively you could have a stream that does have a valid MP3 packet at
> the beginning, but there is a corrupt packet very soon afterwards.
> If the parser cannot find several good packets in a row, then it may choose
> something else to return as the format.
> If you start in the middle of random data that is not MP3 it may lock onto
> something wrong.
>
>
> On Jul 22, 2009, at 10:43 AM, Tom Harrington wrote:
>
> On Wed, Jul 22, 2009 at 10:09 AM, james mccartney<email@hidden>
> wrote:
>
> On Jul 21, 2009, at 6:06 PM, james mccartney wrote:
>
> Are you supplying a buffer whose first byte begins an MPEG Layer 3 packet
>
> (optionally preceeded by an ID3 tag), or is it a buffer that starts in the
>
> middle of some random header data after which, at some point, there is MP3
>
> data. If the former, then the parser may be picking up on the first bytes
>
> that look like an MPEG packet header and reporting that as the format.
>
> oops. should be "if the latter". IOW starting in the middle of random data
>
> is the not good scenario.
>
> I had thought that hinting would resolve this-- I know that the stream
>
> is MP3, so I specify kAudioFileMP3Type when calling
>
> AudioFileStreamOpen(). That helps (without it I never get "ready to
>
> produce packets") but apparently it's not enough of a clue?
>
> I'm not familiar enough with shoutcast to be sure but it wouldn't
>
> surprise me if it's starting the stream in the middle of an MP3
>
> packet. Since hinting doesn't seem to be enough, does Core Audio
>
> provide any way for me to discard bytes until the start of the next
>
> packet?
>
> I thought maybe I should be passing
>
> kAudioFileStreamParseFlag_Discontinuity to AudioFileStreamParseBytes()
>
> when I start receiving data, but that doesn't seem to have helped.
>
> --
>
> Tom Harrington
>
> email@hidden
>
> AIM: atomicbird1
>
>
>
--
Tom Harrington
email@hidden
AIM: atomicbird1
_______________________________________________
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