GingerBread 上的 MediaPlayer 框架和 Apple 的 HTTP 实时流媒体支持
根据发行说明，StageFright 取代了 GingerBread 版本中的 OpenCore 框架。似乎有很多讨论说：从 Android 2.3 开始默认支持 Apple 的 HTTP Live 流媒体。甚至维基百科也提到了这一点。
但是，当我尝试运行 Apple 提供的 测试流 时使用与 API 演示捆绑在一起的 MediaPlayerDemo_Video.java 我得到了 以下异常：
setDataSource('http://devimages.apple.com/iphone/samples/bipbop/gear1/
prog_index.m3u8')
connect to devimages.apple.com:80/iphone/samples/bipbop/gear1/
prog_index.m3u8 @0
INFO/NuCachedSource2(34): ERROR_END_OF_STREAM
error (1, -2147483648)
ERROR/MediaPlayerDemo(667): error: Prepare failed.: status=0x1
java.io.IOException: Prepare failed.: status=0x1
at android.media.MediaPlayer.prepare(Native Method)
at
com.video.stream.MediaPlayerDemo_Video.playVideo(MediaPlayerDemo_Video.java:
125)
at
com.video.stream.MediaPlayerDemo_Video.surfaceCreated(MediaPlayerDemo_Video.java:
181)
...
surfaceChanged called
Displayed com.video.stream/.MediaPlayerDemo_Video: +1s652ms (total
+7s427ms)
GC_EXPLICIT freed 2K, 55% free 2514K/5511K, external 716K/1038K,
paused 183ms
GC_EXPLICIT freed 17K, 52% free 2782K/5767K, external 716K/1038K,
paused 87ms
GC_EXPLICIT freed 68K, 50% free 2972K/5895K, external 2544K/3109K,
paused 104ms
request time failed: java.net.SocketException: Address family not
supported by protocol
---相关代码(MediaPlayerDemo_Video.java)：
path = "http://devimages.apple.com/iphone/samples/bipbop/gear1/
prog_index.m3u8";
mMediaPlayer = new MediaPlayer();
mMediaPlayer.setDataSource(path);
mMediaPlayer.setDisplay(holder);
mMediaPlayer.prepare();
mMediaPlayer.setOnBufferingUpdateListener(this);
mMediaPlayer.setOnCompletionListener(this);
mMediaPlayer.setOnPreparedListener(this);
mMediaPlayer.setOnVideoSizeChangedListener(this);
mMediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
问题：
1. GingerBread构建真的支持Apple的HTTP Live Streaming吗 协议？
2.上面出了什么问题？
请帮忙。
According to the release notes, StageFright replaces the OpenCore framework in the GingerBread release. It seems that there have been numerous discussion that says: Apple's HTTP Live streaming is supported by default since Android 2.3. Even the Wikipedia mentions this.
However, when I try to run the test stream provided by Apple using the MediaPlayerDemo_Video.java bundled with API Demos I get the
following exceptions:
setDataSource('http://devimages.apple.com/iphone/samples/bipbop/gear1/
prog_index.m3u8')
connect to devimages.apple.com:80/iphone/samples/bipbop/gear1/
prog_index.m3u8 @0
INFO/NuCachedSource2(34): ERROR_END_OF_STREAM
error (1, -2147483648)
ERROR/MediaPlayerDemo(667): error: Prepare failed.: status=0x1
java.io.IOException: Prepare failed.: status=0x1
at android.media.MediaPlayer.prepare(Native Method)
at
com.video.stream.MediaPlayerDemo_Video.playVideo(MediaPlayerDemo_Video.java:
125)
at
com.video.stream.MediaPlayerDemo_Video.surfaceCreated(MediaPlayerDemo_Video.java:
181)
...
surfaceChanged called
Displayed com.video.stream/.MediaPlayerDemo_Video: +1s652ms (total
+7s427ms)
GC_EXPLICIT freed 2K, 55% free 2514K/5511K, external 716K/1038K,
paused 183ms
GC_EXPLICIT freed 17K, 52% free 2782K/5767K, external 716K/1038K,
paused 87ms
GC_EXPLICIT freed 68K, 50% free 2972K/5895K, external 2544K/3109K,
paused 104ms
request time failed: java.net.SocketException: Address family not
supported by protocol
---relevant code(MediaPlayerDemo_Video.java):
path = "http://devimages.apple.com/iphone/samples/bipbop/gear1/
prog_index.m3u8";
mMediaPlayer = new MediaPlayer();
mMediaPlayer.setDataSource(path);
mMediaPlayer.setDisplay(holder);
mMediaPlayer.prepare();
mMediaPlayer.setOnBufferingUpdateListener(this);
mMediaPlayer.setOnCompletionListener(this);
mMediaPlayer.setOnPreparedListener(this);
mMediaPlayer.setOnVideoSizeChangedListener(this);
mMediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
Questions:
1. Does GingerBread build really support Apple's HTTP Live Streaming
protocol?
2. What went wrong above?
Please help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我已经找到了一些数据，我将通过回答我自己的问题来更新此线程。如果有人有建议或其他考虑因素需要提出，请添加。
Honeycomb构建附带的Stagefright框架支持HTTP Live Streaming。该文档读取了规范草案的大部分部分，但没有明确提及哪些部分。视频和音频应符合Android 支持的媒体格式 .
我能够播放采用
AES-128加密的内容保护流。不过，模拟器的性能（不幸的是，我没有该设备）并不好。音频和视频严重不同步。流媒体应用程序必须在真实设备上进行测试。您无法通过 https 传输数据。此外，为了检测流是否符合 HTTPLive 标准，您必须将 URL 的
"http://"部分替换为"httplive： //"Alright, I have found some data and I am going to update this thread by answering my own question. If someone has suggestions or other considerations to bring to table please add.
Stagefrightframework that comes withHoneycombbuild supportsHTTP Live Streaming. The documentation reads most parts of the draft specification without mentioning explicitly which parts.The video and audio should conform to media formats supported by Android.
I was able to play content-protected streams employing
AES-128encryption. Though, the performance of the emulator(unfortunately, I did not have the device) was not good. Audio and Video were terribly out of sync. Streaming applications HAVE to be tested on real devices.You cannot stream your data over https. Also, in order to detect that the stream conforms to HTTPLive standard you'll have to replace
"http://"part of the URL with"httplive://"Gingerbread 确实支持使用 httplive:// 方案前缀播放一些 HLS 流，但支持的编解码器非常有限，并且很容易构建一个完全有效的流，从而导致媒体框架崩溃并无法播放。
我的经验表明，这种崩溃通常发生在加载或解码第一个段时，即使对于加密内容也是如此，但不会请求密钥，这表明框架忽略了 KEY 行。
当然，对于那些只需要支持市场上最新设备的人来说，ICS 中对 HLS 的支持似乎是合理的（尽管仍然不完美），但是我们这些需要某种向后兼容性的人显然被冷落了， RTSP 似乎是流媒体（相对于渐进式下载）的唯一选择，而 RTSP 本身在 Android 中的实现很差。
Gingerbread does support playing some HLS streams using the httplive:// scheme prefix but the codecs supported are very limited and it's very easy to construct a perfectly valid stream that crashes the media framework and fails to play.
My experiences have shown that this crash normally occurs while loading or decoding the first segment, even for encrypted content, but that the key does not get requested suggesting that the framework is ignoring the KEY lines.
Of course, for those who only need to support the very newest devices on the market, the support for HLS in ICS appears reasonable (though still imperfect) however those of us who need some kind of backwards compatibility are left decidedly out in the cold, and it seems the only option for streaming (as opposed to progressive download) is RTSP, which itself is poorly implimented in Android.