6

由于许多 J2ME 手机的(相当烦人的)限制,音频文件在完全下载之前无法播放。因此,为了播放实时流,我不得不一次下载块,并构建ByteArrayInputStreams,然后将其提供给玩家。

这很好用,除了每次流结束并且需要一个新的流时会有大约 1/4 秒的令人讨厌的间隙。有没有办法解决这个问题,或者上面的问题?

4

3 回答 3

2

使用 J2ME JSR135 播放长(3 分钟或更长时间)曲目的唯一好方法,适度可靠,在最大数量的手机上,是在创建播放器时使用“file://”url,或者输入流实际上来自 FileConnection。

最近的黑莓手机只有在有大的 Java 堆内存可用时才能使用 ByteArrayInputstream。

许多在 Symbian 操作系统上运行的手机将允许您将文件放在 J2ME 应用程序的私有区域中,同时仍然能够在同一位置播放曲目。

于 2009-04-27T12:49:28.893 回答
1

不幸的是,您无法摆脱这些差距,至少在我尝试过的任何设备上都没有。确实很烦人。您不能通过 HTTP 流式传输音频或视频,这是规范的一部分。

如果您想从服务器流式传输,唯一的方法是使用RTSP服务器,尽管您需要检查您的设备上对此的支持。

并且使用设备上的本地服务器(rtsp:// localhost ...)伪造RTSP也不起作用..我也试过了。

于 2009-04-27T07:09:07.057 回答
0

EDIT2:或者你可以看看这似乎正是你想要的:http: //java.sun.com/javame/reference/apis/jsr135/javax/microedition/media/protocol/DataSource.html

我会创建两个 Player 类,并确保在开始播放它们之前我已经收到了足够的块。然后我会开始通过播放器一播放第一个块并将第二个块加载到播放器二中。然后我会使用 TimeBase 类来跟踪已经过去了多少时间,当我知道第一个块将结束时(你应该知道每个块必须播放多长时间)然后我会开始通过第二个播放器播放第二个块并且将第三个块加载到第一个块中,依此类推,直到没有更多块可以播放。

这里的关键是正确使用 TimeBase 类来知道何时进行转换。我认为这应该消除块之间烦人的 1/4 秒间隔赌注。我希望这行得通,如果行得通,请告诉我,因为这听起来很有趣。

编辑: Player.prefetch() 在减少延迟方面也可能有用。

于 2009-04-25T00:43:32.103 回答