您所在位置：主题：[原创]移动流媒体开发小结
lostsky22
[专家分：30] 发布于 2008-12-05 10:52:00
[size=3]原来写的一篇文章，现在http://lostsky.ys168.com这个链接不可用了：） 换了新电脑，streamMediaDemo.jar找不到了，等找到了就上传。这里主要讲实现原理。
交流站点 [color=FF0000][url]http://www.591pic.com[/url][/color]
你可以从http://lostsky.ys168.com下载这个DEMO(在“开源项目”/streamMediaDemo.jar)，这个streamMedia
Demo.jar可直接在手机上安装，请确认你的手机支持Java应用程序MIDP2.0，支持 AMR音频格式的播放。程序
里测试用的流媒体服务器是我搭建在自己电脑上的，所以如果你想测试这个程序，请通知我打开服务器，我只要
能接入公网，也会打开流媒体服务。
接触J2ME技术到现在有将近半年了，对它的认识也逐渐从手机游戏转到更广阔的无线业务应用上。进公司做的
第一个项目是移动物流系统，那是第一次将J2ME用在企业级开发中。从这个项目开始，一直延续到现在在做的
MCS平台，我逐步坚定了J2ME更大的应用是在业务领域而非游戏的看法。一个月前，刚做完移动物流项目，和
老总闲谈时，他询问有关J2ME实现移动流媒体的可行性。这确实是个巨大诱人的市场，仅就企业业务而言：实
时监控(企业敏感场所监控...)，远程在线直播(警察，电力等特殊行业人员户外巡检，远程紧急救助...)，甚至移动
虚拟社区内的在线音视频服务，这块蛋糕是不可言语的大。然而，PC上成熟的流媒体技术，比如rtsp等，在手持
移动设备上的应用很少，这是因为支持的硬件和服务太少，而且J2ME目前还没有提供对流媒体开发的支持。所
以，我当时回答老总这个还有比较大的困难。后来一阵子，我上网了解和搜集了关于J2ME移动流媒体开发的一
些信息，也正如前所说，目前没有什么好的实现。但也看到了一些新的思路，在现有条件下实现流媒体的思路。
原理：
我们都知道，流媒体最大的优势在于体验速度快和信息的实时性，前者表现在：我们不需要将媒体全部下载完，
就能够迅速的消费媒体，一边消费一边下载，对于用户体验而言，基本不存在等待；后者表现为能应用在任何强
调实时交互的场合，比如远程协助，监控。我们可以将流媒体比喻为打开的水龙头，随用随取，不存在等待的情
况。目前流媒体传输的原理，都是一种“模拟-数字”的模式，即用足够“小”的分隔来实现一种“持续流”。
学过微积分或者模电数电的人都知道，模拟信号到数字信号的转换，是以足够小的信号段来实现信号的数字表示
的。同样，流媒体的传输并不象是名字所听起来的那么流畅，也是分段进行的，伴以多任务方式运行(一般是多
线程)，实现边消费边获取。用户体验到的自然是速度快，无停顿的服务。PC上的流媒体传输多半有专门厂商实
现，或者由其他应用程序开发人员实现，但在硬件资源，网络带宽，应用开发环境都很受限制的移动平台上，这
种实现对于应用开发层来说，非常困难，因为一切都受限于设备厂商的规范。所以，我们只能在语言自身层面
上，寻求变通解决的办法。根据流媒体的传输原理，如果能解决 1，数据流分段获取；2，多任务(边消费边下
载)，那么我们就能够模拟出流媒体的效果来。
实现：
移动设备上多媒体的应用，在J2ME中主要是由MMAPI(Mobile Media API)移动媒体API来提供支持。它提供了一
系列的接口来实现各种媒体应用，其中最核心的是Player对象，它控制着整个媒体应用的生命周期。具体说来，
Player有以下几个生命状态：unrealized,realized,prefetched,started,closed。分别代表未定位获取到资源，已定
位获取到资源，播放所需资源已就绪，播放开始，对象关闭资源已释放。通过相应的方法，可在各个状态之间转
换。具体可参阅API帮助和相关文档。对于本例的应用，主要是创建两个Player对象，使用多线程，实现一个播
放，另一个在后台进行资源获取与准备，当第一个对象播放完毕之后，第二个对象已准备就绪(需要结合网速通
过控制数据分段大小来实现)，可以接上去播放，如此往复，达到流媒体实时播放的效果。当然，需要写一个控
制器来对整个流程进行控制，比如，如何控制Player之间的切换，如何处理后台获取数据，程序运行时因为网络
原因出现的异常等等。解决了多任务，接下来就是数据分段。这是个很有意思的问题，因为实现它的途径有很
多。出于对开发速度的考虑，我没有通过编程实现，而是直接使用工具进行分割，如果到了商用，程序自动分割
才是合适的。媒体格式的选择也很重要。现在手机上网无非就是走cmwap和cmnet两个接入点，从性价比来看，
CMWAP包月无疑是唯一的选择。现行资费：非包月用户 cmwap和cmnet都是3分/KB，包月用户(现在只有CM
WAP能包月)，资费各地不同，不过一般都是5元包月，10MB流量；20元包月，50M流量之类的。超出部分都是
1分/KB。我选择的是AMR格式，它是现在主流手机普遍支持的一种音频格式。常见的MP3文件转换成AMR后，
大小/时间=1.5KB/秒，而现行GPRS网络的传输速率平均在24Kb/秒(即3KB/秒，不要相信理论峰值)，这样的就
能够保证在前面一部分播放期间，后一部分就可以下载并准备到位。而其他的格式，包括视频，在现行网络状况
下是不能满足这种传输条件的。不过听说上海年底前EGPRS将会实现全市覆盖，到时可以考虑实现在线视频。
明确了原理，只要对MMAPI，多线程和HTTP通信比较熟悉，就能比较快的开发出DEMO来。
体验：
我的机器是Nokia N70，在下午三点钟测试，下载很流畅，不存在延时问题，只是切换player的时候，会有小小
停顿，这属于底层的硬伤，是现行框架无法解决的。不过总的说来，效果还是超出预期。
注意：
开发时会碰到一些与原理无关的问题。
比如，数据怎么分段？这个可以参考JMF和一些第三方媒体处理框架，不过一般说来，都很消耗服务器资源，所
以我写DEMO时候，是手动分割媒体数据的(也是为了方便快速的开发：）)。
有些手持设备不支持AMR格式？
这个问题是下午碰到的，在ZZ的Nokia 6080手机上调试时就出现格式异常，后来下载了其他的AMR格式音频，
也无法播放，确认为格式不支持。在我自己的N70上就很好，大概S60系列都没有问题。
想法：
在线视频和音频，不是本例应用所指向的。因为那有赖于硬件厂商和底层开发组织提供真正的流媒体实现，而不
是象本例中这样的模拟，底层实现会具有更好的体验效果。我所考虑的是这种应用的反向，比如，手机作为信息
采集端，而实现在服务器端实时获取，这似乎具有更广阔的前景。目前忙于公司的MCS，等这个项目一期上线
之后，可以着手考虑实现。[/size]
交流站点 [color=FF0000][url]http://www.591pic.com[/url][/color]
你可以从http://lostsky.ys168.com下载这个DEMO(在“开源项目”/streamMediaDemo.jar)，这个streamMedia
Demo.jar可直接在手机上安装，请确认你的手机支持Java应用程序MIDP2.0，支持 AMR音频格式的播放。程序
里测试用的流媒体服务器是我搭建在自己电脑上的，所以如果你想测试这个程序，请通知我打开服务器，我只要
能接入公网，也会打开流媒体服务。
接触J2ME技术到现在有将近半年了，对它的认识也逐渐从手机游戏转到更广阔的无线业务应用上。进公司做的
第一个项目是移动物流系统，那是第一次将J2ME用在企业级开发中。从这个项目开始，一直延续到现在在做的
MCS平台，我逐步坚定了J2ME更大的应用是在业务领域而非游戏的看法。一个月前，刚做完移动物流项目，和
老总闲谈时，他询问有关J2ME实现移动流媒体的可行性。这确实是个巨大诱人的市场，仅就企业业务而言：实
时监控(企业敏感场所监控...)，远程在线直播(警察，电力等特殊行业人员户外巡检，远程紧急救助...)，甚至移动
虚拟社区内的在线音视频服务，这块蛋糕是不可言语的大。然而，PC上成熟的流媒体技术，比如rtsp等，在手持
移动设备上的应用很少，这是因为支持的硬件和服务太少，而且J2ME目前还没有提供对流媒体开发的支持。所
以，我当时回答老总这个还有比较大的困难。后来一阵子，我上网了解和搜集了关于J2ME移动流媒体开发的一
些信息，也正如前所说，目前没有什么好的实现。但也看到了一些新的思路，在现有条件下实现流媒体的思路。
原理：
我们都知道，流媒体最大的优势在于体验速度快和信息的实时性，前者表现在：我们不需要将媒体全部下载完，
就能够迅速的消费媒体，一边消费一边下载，对于用户体验而言，基本不存在等待；后者表现为能应用在任何强
调实时交互的场合，比如远程协助，监控。我们可以将流媒体比喻为打开的水龙头，随用随取，不存在等待的情
况。目前流媒体传输的原理，都是一种“模拟-数字”的模式，即用足够“小”的分隔来实现一种“持续流”。
学过微积分或者模电数电的人都知道，模拟信号到数字信号的转换，是以足够小的信号段来实现信号的数字表示
的。同样，流媒体的传输并不象是名字所听起来的那么流畅，也是分段进行的，伴以多任务方式运行(一般是多
线程)，实现边消费边获取。用户体验到的自然是速度快，无停顿的服务。PC上的流媒体传输多半有专门厂商实
现，或者由其他应用程序开发人员实现，但在硬件资源，网络带宽，应用开发环境都很受限制的移动平台上，这
种实现对于应用开发层来说，非常困难，因为一切都受限于设备厂商的规范。所以，我们只能在语言自身层面
上，寻求变通解决的办法。根据流媒体的传输原理，如果能解决 1，数据流分段获取；2，多任务(边消费边下
载)，那么我们就能够模拟出流媒体的效果来。
实现：
移动设备上多媒体的应用，在J2ME中主要是由MMAPI(Mobile Media API)移动媒体API来提供支持。它提供了一
系列的接口来实现各种媒体应用，其中最核心的是Player对象，它控制着整个媒体应用的生命周期。具体说来，
Player有以下几个生命状态：unrealized,realized,prefetched,started,closed。分别代表未定位获取到资源，已定
位获取到资源，播放所需资源已就绪，播放开始，对象关闭资源已释放。通过相应的方法，可在各个状态之间转
换。具体可参阅API帮助和相关文档。对于本例的应用，主要是创建两个Player对象，使用多线程，实现一个播
放，另一个在后台进行资源获取与准备，当第一个对象播放完毕之后，第二个对象已准备就绪(需要结合网速通
过控制数据分段大小来实现)，可以接上去播放，如此往复，达到流媒体实时播放的效果。当然，需要写一个控
制器来对整个流程进行控制，比如，如何控制Player之间的切换，如何处理后台获取数据，程序运行时因为网络
原因出现的异常等等。解决了多任务，接下来就是数据分段。这是个很有意思的问题，因为实现它的途径有很
多。出于对开发速度的考虑，我没有通过编程实现，而是直接使用工具进行分割，如果到了商用，程序自动分割
才是合适的。媒体格式的选择也很重要。现在手机上网无非就是走cmwap和cmnet两个接入点，从性价比来看，
CMWAP包月无疑是唯一的选择。现行资费：非包月用户 cmwap和cmnet都是3分/KB，包月用户(现在只有CM
WAP能包月)，资费各地不同，不过一般都是5元包月，10MB流量；20元包月，50M流量之类的。超出部分都是
1分/KB。我选择的是AMR格式，它是现在主流手机普遍支持的一种音频格式。常见的MP3文件转换成AMR后，
大小/时间=1.5KB/秒，而现行GPRS网络的传输速率平均在24Kb/秒(即3KB/秒，不要相信理论峰值)，这样的就
能够保证在前面一部分播放期间，后一部分就可以下载并准备到位。而其他的格式，包括视频，在现行网络状况
下是不能满足这种传输条件的。不过听说上海年底前EGPRS将会实现全市覆盖，到时可以考虑实现在线视频。
明确了原理，只要对MMAPI，多线程和HTTP通信比较熟悉，就能比较快的开发出DEMO来。
体验：
我的机器是Nokia N70，在下午三点钟测试，下载很流畅，不存在延时问题，只是切换player的时候，会有小小
停顿，这属于底层的硬伤，是现行框架无法解决的。不过总的说来，效果还是超出预期。
注意：
开发时会碰到一些与原理无关的问题。
比如，数据怎么分段？这个可以参考JMF和一些第三方媒体处理框架，不过一般说来，都很消耗服务器资源，所
以我写DEMO时候，是手动分割媒体数据的(也是为了方便快速的开发：）)。
有些手持设备不支持AMR格式？
这个问题是下午碰到的，在ZZ的Nokia 6080手机上调试时就出现格式异常，后来下载了其他的AMR格式音频，
也无法播放，确认为格式不支持。在我自己的N70上就很好，大概S60系列都没有问题。
想法：
在线视频和音频，不是本例应用所指向的。因为那有赖于硬件厂商和底层开发组织提供真正的流媒体实现，而不
是象本例中这样的模拟，底层实现会具有更好的体验效果。我所考虑的是这种应用的反向，比如，手机作为信息
采集端，而实现在服务器端实时获取，这似乎具有更广阔的前景。目前忙于公司的MCS，等这个项目一期上线
之后，可以着手考虑实现。[/size]