移动最友好的自适应比特率流是HLS（HTTP实时流）。
HLS 使用主 m3u8 清单文件将不同的屏幕分辨率与媒体文件块映射，并根据客户端屏幕分辨率和网络波动提供适当的分辨率。
我已经检查了您的KitchenSink应用程序的代码，我看到您的媒体播放器正在提供mp4文件。你们中是否有人尝试用 m4u8 清单替换 mp3 链接？它应该工作吗？您是否考虑将现有解决方案包含在您的媒体播放器中 => https://github.com/videojs/videojs-contrib-hls .
媒体依赖于本机操作系统播放，因此如果操作系统支持本机编解码器，它就可以正常工作。
主要动机是避免媒体的问题性质，这是专利诉讼和复杂性的领域。
如果本机平台支持编解码器，它将起作用，我们使用 264，因为它得到普遍支持，这非常罕见。我们的模拟器使用 JavaFX 进行视频播放，它们的编解码器支持是"有问题的"，因此 264 可能是我们可以选择的唯一适用于模拟器和所有设备的方法。
话虽如此，如果你有一个编解码器的纯Java实现，你可以把它移植到代号一。上述编解码器的JavaScript版本也可能在Web浏览器组件中工作，但可能无法在模拟器中工作，因为JavaFX的Web视图在HTML5支持方面非常弱，但它可以在设备上工作。
KitchenSink/src/com/codename1/demos/kitchensink/Video中用演示m3u8链接替换了mp4媒体链接.java并在iPhone 6S/IOS 11.0.2和Galaxy Tab Note/Android 7.1.1上测试了生成的apk和ipa。
m3u8流媒体在Android和iPhone设备上可以正常工作。对于那些需要一些 m3u8 工作在示例中的人，请在 videojs contrib 存储库中帮助您自己 => https://github.com/videojs/videojs-contrib-hls .