Re: iPhone 3.1.2: weird AudioFileStreamParseBytes behavior with HTTP Live variant streams
Re: iPhone 3.1.2: weird AudioFileStreamParseBytes behavior with HTTP Live variant streams
- Subject: Re: iPhone 3.1.2: weird AudioFileStreamParseBytes behavior with HTTP Live variant streams
- From: James McCartney <email@hidden>
- Date: Fri, 22 Jan 2010 12:09:26 -0800
Without seeing examples of the streams, I don't know what I can do.
You should file a bug report with an example of streams that work and do not work.
Supplying 64K vs 16K might very well change the behavior if there is a large header of non audio data, or if you are starting in the middle of a packet.
What is the first byte that you are passing to AudioFileStreamParseBytes? Is it the first byte of a packet? Is it the start of an ID3 tag or other informational header? Is it some arbitrary point in the stream, i.e. not a packet boundary and perhaps not even a packet of audio?
Are you supplying a file type hint to AudioFileStreamOpen ?
On Jan 18, 2010, at 11:13 PM, John Michael Zorko wrote:
>
> Hello, all ...
>
> I'm seeing some strange behavior with AudioFileStreamParseBytes, in that it seems to think that a sequence of bytes I give it has no audio packets, yet at other times, it will identify audio packets in the same sequence of bytes. The context is this: i'm writing code to play HTTP Live (the Apple protocol) streams -- M3U8 files. These files describe several streams of the same content encoded at different bitrates, broken into small chunks (currently 5s each) and the streams are all encoded with AAC (64k, 32k and 16k).
>
> The context is this: the application starts and chooses a stream from the top-level M3U8 at a certain bitrate based on the the current connection type, downloads the first 5s chunk of that stream, then makes the determination of which bitrate stream (URL) to download the next 5s chunk from based on the measured bandwidth, and so on. For instance, if the application starts and WWAN is the current connection type, it will choose the lowest bitrate for the stream, and if the measured bandwidth is good (good WWAN or switch to WIFI), the next 5s chunk will be downloaded from a stream that is of a higher bitrate. This procedure continues until the entire stream has been played.
>
> What happens, though, is that for certain streams, switching the stream URL from, say, the 16K variant to the 64K variant between 5s chunks confuses AudioFileParseStreamBytes, making it think that a 5s chunk of audio has no audio packets when, had the stream _not_ changed, it would have identified the packets. I've tried passing the discontinuity flag into AudioFileStreamParseBytes when I change bitrate streams, but it still fails. I can get this to happen on demand with certain streams, but I don't know how to fix it. Is there a way of "resetting" an AudioFileStream short of closing it and opening it again?
>
> I'm really stumped on this. Any ideas would be welcome :-)
>
> Regards,
>
> John
>
>
>
> _______________________________________________
> 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
_______________________________________________
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