J2ME 中将缓冲区旋转到播放器的替代方案？
由于许多 J2ME 手机上的（相当烦人的）限制，音频文件在完全下载后才能播放。 因此，为了播放实时流，我被迫一次下载块，并构造 ByteArrayInputStream，然后将其提供给播放器。
这种方法效果很好，只是每次流结束并且需要新的流时，都会有大约 1/4 秒的烦人间隙。 有什么办法可以解决这个问题，或者上面的问题吗？
Due to (quite annoying) limitations on many J2ME phones, audio files cannot be played until they are fully downloaded. So, in order to play live streams, I'm forced to download chunks at a time, and construct ByteArrayInputStreams, which I then feed to Players.
This works well, except that there's an annoying gap of about 1/4 of a second every time a stream ends and a new one is needed. Is there any way to solve this problem, or the problem above?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在最大数量的手机上使用 J2ME JSR135 适度可靠地播放长（3 分钟或更长）曲目的唯一好方法是在创建播放器时使用“file://”url，或者让输入流实际上来自 FileConnection。
最近的黑莓手机只有在有大量可用的 java 堆内存时才能使用 ByteArrayInputstream。
许多运行 Symbian 操作系统的手机允许您将文件放在 J2ME 应用程序的专用区域中，同时仍然能够在同一位置播放曲目。
The only good way to play long (3 minutes and more) tracks with J2ME JSR135, moderately reliably, on the largest number of handsets out there, is to use a "file://" url when you create the player, or to have the inputstream actually come from a FileConnection.
recent blackberry phones can use a ByteArrayInputstream only when they have a large java heap memory available.
a lot of phones running on the Symbian operating system will allow you to put files in a private area for the J2ME application while still being able to play tracks in the same location.
不幸的是，你无法消除这些差距，至少在我尝试过的任何设备上都是如此。 确实很烦人。 规范的一部分规定您不能通过 HTTP 传输音频或视频。
如果您想从服务器进行流式传输，唯一的方法是使用 RTSP服务器，尽管您需要检查您的设备对此的支持。
使用设备上的本地服务器 (rtsp://localhost...) 伪造 RTSP 也不起作用..我也尝试过。
Unfortunately you can't get rid of these gaps, at least not on any device I've tried it on. It's very annoying indeed. It's part of the spec that you can't stream audio or video over HTTP.
If you want to stream from a server, the only way to do it is to use an RTSP server instead though you'll need to check support for this on your device.
And faking RTSP using a local server on the device (rtsp://localhost...) doesn't work either.. I tried that too.
EDIT2：或者你可以看看这似乎正是你想要的： http://java.sun.com/javame/reference/apis/jsr135/javax/microedition/media/protocol/DataSource.html
我将创建两个 Player 类并确保在开始玩之前我已经收到了足够的块。 然后我将开始通过播放器一播放第一个块，并将第二个块加载到播放器二中。 然后我将使用 TimeBase 类来跟踪已经过去了多少时间，当我知道第一个块将结束时（您应该知道每个块必须播放多长时间），然后我将开始通过第二个播放器播放第二个块，将第三个块加载到第一个块中，依此类推，直到没有更多的块可以播放。
这里的关键是正确使用 TimeBase 类来知道何时进行转换。 我认为这应该消除块之间恼人的 1/4 秒间隙赌注。 我希望这能起作用，如果能的话请告诉我，因为这听起来真的很有趣。
编辑：Player.prefetch() 在这里也可以用于减少延迟。
EDIT2: Or you could just look at this which seems to be exactly what you want: http://java.sun.com/javame/reference/apis/jsr135/javax/microedition/media/protocol/DataSource.html
I would create two Player classes and make sure that I had received enough chunks before I started playing them. Then I would start playing the first chunk through player one and load the second one into player two. Then I would use the TimeBase class to keep track of how much time has passed and when I knew the first chunk would end (you should know how long each chunk has to play) then I would start playing the second chunk through the second player and load the third chunk into the first and so on and so forth until there are no more chunks to play.
The key here is using the TimeBase class properly to know when to make the transition. I think that that should get rid of the annoying 1/4 second gap bet between chunks. I hope that works, let me know if it does because it sounds really interesting.
EDIT: Player.prefetch() could also be useful here in reducing latency.