数日間検索しましたが、解決策が見つからないようです。ここの誰かが私を正しい方向に向けてくれることを願っています。
Cordova/Angular を使用してラジオ iOS アプリケーションを構築しています。HTML5 で再生して いる 1 つの mp3 ストリーム ( http://mp3lg3.tdf-cdn.com/5593/goo_102004.mp3 ) があります。
デバイスが数分間接続を失った場合でもストリームを続行し、接続が回復した場合は通常どおりストリーミングを続行する方法を見つけたいと考えています。現時点では、wifi をオフにするか、デバイスの電源を「機内モード」にすると、ストリームがすぐに停止します。
私はオーディオの世界にかなり慣れていないので、経験のある人が助けてくれることを願っています.
HTTP progressive streaming works by simply sending data in one continuous stream, while the receiving end plays back the data as it comes in. The nature of networks is that data comes in chunks, not quite continuously, so the client playing back the audio has a buffer of a couple seconds to survive the periodic bursts of data.
To survive a dropout of a minute, the client would have to receive more than a minute of data in the future. This is accomplished by buffering a minute of data on the server and then flushing that buffer as fast as possible to the client upon connect. While it won't get to the client simultaneously, it should get there reasonably fast and then you'll have that buffer which can survive a disconnection. That is, if your server is a minute ahead of the client and the client with a full 1-minute buffer loses its connection, it can continue playback for about a minute before having to drop out.
This is only half the problem though. What do you do when you reconnect? How does the client synchronize to the server? Unfortunately, there are no public servers doing live HTTP progressive that support a way to synchronize. I've done some experimenting myself with Range headers and what not which works, but requires a custom client. (VLC does work however...)
You also must consider the reason your audio is stopping immediately. If you are trying to simulate a network dropout or slow spot by turning on airplane mode, this is not an appropriate test. The OS disables the network interface, which immediately drops any TCP connections, immediately killing the pipe to the application. Most applications will stop playing at this point unless they had some additional buffer regardless of the network connection. In a situation where your network connection quality suffers, rarely is the TCP connection actually dropped... packets are just delayed causing the audio to eventually stop as the buffer runs out.
With all that, there are two solutions depending on your needs:
This is simple. Increase the server-side buffer that gets flushed to clients. I usually use 20 seconds.
Note that not all clients will accept such a large buffer. Some will lower the TCP window size, preventing the server from sending too much audio data.
(Note: If you can't figure out how to do this with your existing streaming server, buffer configuration is available on the AudioPump CDN which I have created. It isn't generally available yet, but you can e-mail me at brad@audiopump.co to try it.)
For this scenario, you need a whole new streaming protocol. HLS is what you want.
HLS works by segmenting your stream which must be requested by several HTTP requests anyway. Because of this, the client can change addresses (such as going from a mobile network to WiFi) and the stream will still work.
HLS is unfortunately not as well supported by clients, but the server-side is easy. Any HTTP server will do in most cases. The encoder is what needs to change, to encode and upload segments.
ライブ コンテンツのない通常のストリームであれば、バイト配列 (2 倍速) に変換して、通常の速度で再生できるかもしれません。ただし、少し複雑です。