After fighting with Wowza for a day (a perfect example why I avoid Java like the plague and would never spend a nickel on anything written in it; I'm not going to spend a day trying to figure out why it's not happy with my standard java installation) it occurs to me that I'm going about this all wrong. I was looking at HLS for a couple of reasons, but I was mostly intrigued by the idea of video playlists and using them to string together a series of videos, like those that some digital video cameras produce, for seamless playback. I'm sure I'm oversimplifying it, but given that the code for parsing m3u files is now in the Roku DVP, wouldn't it be trivial to have a new StreamFormat, like "m3u" or something, that took an m3u file specifying a list of ANY videos that the Roku DVP is capable of playing, not just mpeg-ts?
Any thoughts? -JT
Roku Community Streaming Expert
Help others find this answer and click "Accept as Solution." If you appreciate my answer, maybe give me a Kudo.
Generic playlist support (as an alternative to the HLS provided support) is an interesting suggestion that we've been considering adding at some future date. However, I don't see it coming in the near future. We believe the HLS playlist support will be sufficient for most playlist use cases.
Also, there are some additional issues in using the HLS mechanism as a generic playlist mechanism. An HLS stream isn't really a traditional playlist, in the sense that the entire sequence of segments is considered to be one piece of content. The progress bar, for example, shows your position in the entire stream, not in each individual segment. That's probably not the behavior you'd want if you were using it as a playlist. An even bigger issue is that HLS streams are encoded so the PTS timestamps increment seamlessly across segments. If you just threw together a bunch of unrelated content, the timestamps would keep resetting when you cross segment boundaries, causing internal confusion in the decoder. And if the content was not encoded the same way (eg. an MPEG4/H.264 file followed by a WMV file) it would be pretty difficult to decode without a rebuffer which is what you're trying to avoid. There are other issues that would make the implementation difficult, so although it's not impossible, it's certainly not trivial.