クイックタイムにUIを失うことなく、iOSクライアントでHTTPライブストリーミングを使用してオーディオファイルストリームを再生します
セグメント化されたmp3オーディオコンテンツを提供するHTTPライブストリーミングサーバーのセットアップがあります（URLはplaylist.m3u8インデックスファイルを指します）。このオーディオストリームを使用するには、iOSクライアントアプリケーションを構築する必要がありますなし標準のAppleコントロール/ UIを使用します。バックグラウンドでストリームを再生する必要があります。コントロールを提供するために独自のカスタムUIを使用します。
コンテンツは純粋にオーディオであるため、UIを引き継ぐMPMoviePlayerControllerクラスは使用しません。 AVAudioPlayerを使用してみましたが、ネットワークストリーム用ではなく、エラーコード「-43」：NSOSStatusErrorDomainで再生に失敗します。
また、高さと幅が1ピクセルのUIWebViewを作成し、サーバー上のplaylist.m3u8ファイルを指すようにしました。これは機能しますが、残念ながら、UIWebViewは、iOS 3.xxデバイスのフルスクリーンでアプリ内で起動するQuickTimeプレーヤーに再生のタスクを委任するだけなので、UIが失われます。
基本的に、AppleはHTTPライブストリーミングを消費するためのクライアントAPIを提供していないようですaudioストリームと開発者は、再生するQuickTimeプレーヤーにUIを放棄することを余儀なくされていますQTロゴが画面を乱用しているストリーム。
誰かが上記で私を助けるための提案を持っているかどうか知りたいです。それ以外の場合、私の計画Bは、HTTPライブストリーミングを放棄し、有名な Matt Gallagher 従来のストリーミング実装を使用することです。ただし、少し心配です Appleのガイドライン セルラーネットワーク（私のアプリ）を介して大量のオーディオまたはビデオコンテンツを送信することが予想されるアプリでは、HTTPを使用する必要があることを明確に示唆しています生放送。これは、私のプランBの実装がAppleによって拒否される傾向があることを意味しますか？このガイドラインを回避する方法はありますか？
私は自分のアプリの1つでMattGallagherのオーディオストリーマーを使用しました。これは、PandoraやLastFMによく似たインターネットラジオアプリです。そして、はい、それはAppleによって受け入れられ、それ以来AppStoreにあります。
したがって、私の意見では、あなたの計画Bは実際にはそれほど危険ではありません。 :-)
ドキュメントによると：
再生は、ムービープレーヤーが所有するビューで行われ、フルスクリーンまたはインラインで行われます。
IOS 3.1以前では、このクラスはフルスクリーンのムービープレーヤーのみを実装していました。
Appleのサンプルストリームを使用した簡単なテストにより、やりたいことが可能であることが証明されます。
MPMoviePlayerController *player = [[MPMoviePlayerController alloc] initWithContentURL:[NSURL URLWithString:@"http://devimages.Apple.com/iphone/samples/bipbop/gear4/prog_index.m3u8"]];
player.movieSourceType = MPMovieSourceTypeStreaming;
player.view.hidden = YES;
[self.view addSubview:player.view];
[player play];