31 Aug 08 [转] J2me流媒体技术实现讨论[3]

Jffmpeg应该是对 ffmpeg 这个C编写的工具的Java封装。

另一个封装的是
http://fobs.sourceforge.net/
FOBS, the C++ & JMF wrapper for ffmpeg.

Cleverpig said：“

Quote:

其实，感觉上可以自己编写一套流媒体规范的实现，比如将源文件指定为wav格式或者其它的raw格式，然后分段发送到mobile。。
但是这样做确实效率低，而且浪费带宽。本人研究了一下Tea Vui Huang的mobilecast实现有些心得，在此与大家讨论一下：
1。使用MMS发送radiocast：由于MMS服务可以使用图片、音乐等多媒体元素，而且技术比较成熟，所以将它作为radiocast的载体是方便的选择。而对于mobile用户来讲，cast的使用方式可以采用请求和订阅两种模式；

2。radio文件格式的选择：对于某些手机不能支持mp3格式文件，即使支持mp3也受到memory size的限制，所以采用更为普遍、压缩比更大的amr格式是比较好的choice；

3。amr文件的分割：由于目前大多数手机仅能支持100KB左右的彩信，所以最佳的cast长度应该是50秒。比如将大约5分钟的mp3文件分割为6个 amr章节文件，每个章节文件所包含的audio长度为45-50秒。而每个amr格式的压缩比将是普通mp3格式3-6倍。按照播放率为 600KB/min的mp3格式计算，保守地假定amr格式压缩比为mp3格式的6倍，amr格式的播放率为100KB/min，而45秒的amr文件大小为75KB。

所以Tea Vui Huang的做法是很clever的。”

我试验过了，利用ffmpeg的这两个参数，可以控制让ffmpeg来将一个大mp3劈分成许多小段的独立播放的amr文件。
-ss time_off set the start time offset
-t duration set the recording time

比如你写这么个perl文件，然后运行：

Code:

@inputFilename = "C:\\opt\\media\\changjin.wma";
@outputFilename = "C:\\opt\\media\\changjin";
for($i=1,$j=1;$i<=1000;$i+=10,$j++)
{
    system("C:\\software\\ffmpeg.exe -i @inputFilename -ac 1 -acodec amr_nb -t 10 -ss $i @outputFilename.$j.\".amr\"");
}

就把一个大文件拆分成许多小amr了，每一个amr文件只有17KB。

Qinjiwy said：“

Quote:

提一个优化的小建议
如果分段太小,播放的间断太多的话,用户感觉上和系统开销都不是很合适.

可以考虑多开几个线程, 另外,每个文件不一定要一样大,可以考虑
文件逐渐增大,从目前移动网速计算,
压缩比高的amr语音文件播放的时间要比下载的时间长.在第一次下载后开始播放的这段时间中,就
可以下载比第一次下载大的文件了,这样能减少网络开销

”

Cleverpig said“

Quote:

to qinjiwy：这个边收听边下载的方法可以作为一个应用程序选项，因为并不是每个人都需要不间断的听，也许只想听第一段试试看，如果好的话再继续听下去。而且有些人还可能直接从中间的部分收听，如果这时文件变大的话，可能等待时间更长。

”

Tags: audio, j2me, mobile, mtk, stream, 流媒体

Filed in java, mobile, mtk, video & audio with 0 Comments

31 Aug 08 [转] J2me流媒体技术实现讨论[2]

cleverpig said“

Quote:

之所以有些格式的媒体文件不支持分段播放，是因为它们文件中不含有索引信息。
就像在以顺序方式读取文件时无法seek一样。。
这个问题可以通过人工（或者用程序）将文件分割后部署放到服务器上来解决。

”
以及“

Quote:

随着iTunes4.9版的发布，podcaster（pod播客们）能够建立自己的podcast，并可以通过增加幻灯片式的图片使其更加吸引人。而且在附加信息中的URL还可使用户门自由的找到其他的podcast资源。这成为了podcast世界的“大地震”。目前这一特性移植到手机上是通过划分“ 章节”来完成的，即将podcast资源文件划分为多个章节，这样做才能让没有“重播/定位”能力的手机进行播放。

但是另一个挑战将摆在移动用户面前，例如：移动收听必须对中断事件进行管理。当我们正开始播放20-40分钟的podcast时，一个电话或者短信突然到来，这些情况将使播放被迫中断。此时我们只能选择重新打开podcast从头再听或者是没有心情从头听。另外媒体文件格式问题也是对移动用户的“噩梦”，大多数手机都不支持mp3或者AAC这种podcast的文件格式，但它们都支持.3gp的标准AMR格式文件。而且能够保存几兆mp3或者AAC文件）的手机目前也不是很普及。

但是Tea Vui Huang制作的javacast改变了这一切。这个软件就是将mp3音乐转换为手机可以播放的.3gp 标准amr（audio recording format）格式。大家可以到http://www.ringtone4me.com/看看，上面有一些具有此类功能软件链接。

javacast的作者——Tea Vui Huang也是Mobcast的作者, 已经制作了一套处理工具将转换Podcast到一个java Midlet中（用户只需要在手机中调用javacast无线下载这个j2me应用程序，并可以播放podcast）。这使那些podcasters们通过简单的增加一个下载这个midlet的链接就能很容易是获得他们的podcast。

”

Huang的Mobcast，确实非常著名，几个月以前，在我写toodouPodcastMidlet时就看过许多人介绍过他，但是就是连不上http://www.geocities.com/tvhuangsg/m…��睹真容。

转换各种格式的video为3gp，转换各种格式的audio为amr，这些在开源软件mplayer手下是随手拈来，只需要看懂mplayer的各种参数即可做到了。所以拜mplayer所赐，我也能够制作手机看交通实况录像，都要感谢那些mplayer的开发人员！

“移动收听必须对中断事件进行管理”，这个确实需要考虑。当进入Paused状态时，需要通知播放线程暂停，同时连接线程暂时就不要去抓取服务器的媒体数据了；等界面切换回来后，播放线程继续replay，连接线程继续下载音乐。

斑竹说“可以通过人工（或者用程序）将文件分割后部署放到服务器上来解决”，我想也是，简单的文件分割是不够的，或者说仅仅适合于wav这种原始数据格式。应该事先将音乐文件用mencoder分解成一段一段的音乐文件放在服务器上，mencoder将处理每一段的格式问题保证能独立播放，这样手机下载起来只需要按照编号一段一段地下载即可，服务器不再需要运算和添加头信息。

美中不足，如果两个player切换播放，中间会有一个卡啪声。

cleverpig said“

Quote:

有兴趣的话可以看jffmpeg，是一种能够处理音频视频的java媒体框架。

”以及

“

Quote:

想了一下，提出一个“移动音频流网关”的想法：可以使用服务器采用“实时”转化格式的方式，将mp3、wav等格式音频转换为amr格式，当然也可以做分段，无论音频源是什么（甚至是podcast）都可以下载到手机上收听。但这样做的话，服务器的负载是个问题，尽管已用采集过的音频源不用再次处理。

”

其实，我原来写的toodouPodcast就是这么一个概念，由于那些播客们提供的音乐格式不符合手机播放，所以我都用toodouPodcast这么个java web service调用ffmpeg工具进行音频转换。转换格式，确实是一个很费CPU资源的事情，而且时间很长，如果用户多的话，对服务器压力极大。
那么现在做做分段也不错，这样，更适合手机用户。
Jffmpeg应该是对ffmpeg这个C编写的工具的Java封装。

另一个封装的是
http://fobs.sourceforge.net/
FOBS, the C++ & JMF wrapper for ffmpeg.

Tags: audio, j2me, mobile, mtk, stream, 流媒体

Filed in java, mobile, mtk, video & audio with 0 Comments

31 Aug 08 [转] J2me流媒体技术实现讨论[1]

看到很多很多人持续在问这个问题。

以前我也听说，好像kvm底层实现不太支持j2me来做streaming video/audio，但我不知道那人为什么这么说。

那么现在国外有一个人提出下面这种思路，并且号称在Nokia6260[相关数据：诺基亚 6260 Nokia62602.0 (3.0436.0) SymbianOS7.0s Series602.1 ProfileMIDP-2.0 ConfigurationCLDC-1.0]

上真实实现了(两种网络方式：蓝牙和GPRS都试验过)，但我怀疑他的前提条件是“你的手机必须允许同时实现player的多个实例进入prefetched状态（预读取声音流）”：

第一步：
声明两个Player；

第二步：
HttpConnection开始向服务器请求该audio文件的第一部分字节，我们定这次读取的字节数为18KB；

第三步：
等第一部分数据到位后，Player A开始realize和prefetch，并开始播放；

第四步：
在Player A播放同时，(18KB的amr数据可以播放10秒钟)，HttpConnection继续请求第二部分数据(假设GPRS每秒钟传输3KB，那么18KB需要传输6秒，算上前后通讯损失的时间，应该不会超过10秒钟)；

第五步：
第二部分数据到位后，假设Player A还没有播放完(这需要调整你的每一部份数据字节数来使得假设成立)，那么将数据喂给Player B让它realize和prefetch；

第六步：
Player A播放完后，得到事件通知，于是让Player B开始播放。

如此往复。

大家看看此种理论可否。
我自己在nokia 7610上测试了一下，我上面说的前提被证明是可行的：“你的手机必须允许同时实现player的多个实例进入prefetched状态（预读取声音流）”。真实Nokia手机确实可以如此：
两个线程中各自有一个Player，都开始做m_player.realize();和m_player.prefetch();，然后等候。

先播放线程1的Player，等她播放完后，
通过

Code:

/*
   * 本类实现了PlayerListener接口。通过这个事件来告知媒体已经播放完毕
   */
  public void playerUpdate(Player player, String event, Object data){
    if(event == PlayerListener.END_OF_MEDIA){
     try{
     System.out.println("playerUpdate>>PlayerListener.END_OF_MEDIA");
     stopGauge();
     playForeground();
     }catch(Exception e){
     e.printStackTrace();
    }
   }
 }

来通知第二个线程的Player播放。

这样是可以的。
qinjiwy说“可以,不过前提是该音频文件允许分段播放,有些音频文件就是不允许的.”，你说得对。确实有很多格式的媒体文件不支持分段播放。我所知道的是wav可以，mp3也可以。

服务端每次只读取这两种媒体文件的某一部分，如果是mp3文件的话，我暂时不知道是否每次需要加上特殊的头信息。

但是如果是WAV文件，那么肯定每次都要加上WAV特定的头，要不然Player也无法播放。

这种形式肯定是可行的。因为以前我在VC++上写Text To Speech程序时，就是这么做的：WAV文件的前若干个字节肯定是头信息，这是一定的，随后跟的全是RAW DATA；我每一次读取WAV的RAW DATA若干字节后，传给我的播放线程，他需要给这段RAW DATA前加上一个WAV HEADER，然后就可以正常播放了。

Tags: audio, j2me, mobile, mtk, stream, 流媒体