"RokuMarkn" wrote:
Just to be clear -- brightscript can PARSE xspf files, since they are just a type of XML. You could parse the xspf yourself and play the files individually (with buffering between each file). But if you want to pass in a playlist and have the video player play all the files in sequence, you need to use m3u8 (HLS).
"kbenson" wrote:"RokuMarkn" wrote:
Just to be clear -- brightscript can PARSE xspf files, since they are just a type of XML. You could parse the xspf yourself and play the files individually (with buffering between each file). But if you want to pass in a playlist and have the video player play all the files in sequence, you need to use m3u8 (HLS).
Theoretically one could parse and convert an XSPF into a m3u8 HLS file, right (or is some essential info missing)?
I remember reading here about there being problems mixing different video files in the m3u8, is that a limitation in the HLS spec or in Roku's implementation? If the latter, is there an ETR? It just seems like ads injected into m3u8 files would really provide the best user experience all around.
"TheEndless" wrote:"kbenson" wrote:"RokuMarkn" wrote:
Just to be clear -- brightscript can PARSE xspf files, since they are just a type of XML. You could parse the xspf yourself and play the files individually (with buffering between each file). But if you want to pass in a playlist and have the video player play all the files in sequence, you need to use m3u8 (HLS).
Theoretically one could parse and convert an XSPF into a m3u8 HLS file, right (or is some essential info missing)?
I remember reading here about there being problems mixing different video files in the m3u8, is that a limitation in the HLS spec or in Roku's implementation? If the latter, is there an ETR? It just seems like ads injected into m3u8 files would really provide the best user experience all around.
If I'm not mistaken, the HLS spec requires that all video segments be of the same length (time, not size), so you couldn't just build an M3U8 with various video clips. It might work, depending on the implementation, but if it's not to spec, you should plan on it not working at some point in the future.
"kbenson" wrote:"TheEndless" wrote:
If I'm not mistaken, the HLS spec requires that all video segments be of the same length (time, not size), so you couldn't just build an M3U8 with various video clips. It might work, depending on the implementation, but if it's not to spec, you should plan on it not working at some point in the future.
That's right, forgot about that. That's Roku specific though, isn't it? The Pantos draft includes a EXT-X-DISCONTINUITY tag to tell the client that a different file is following, right? I haven't done anything with HLS yet, so my practical experience is nil, I could easily be misinterpreting it's real use...
The EXT-X-DISCONTINUITY tag indicates that the media file following
it has different characteristics than the one that preceded it. The
set of characteristics that MAY change is:
o file format
o number and type of tracks
o encoding parameters
o encoding sequence
o timestamp sequence
"TheEndless" wrote:
The EXT-X-DISCONTINUITY tag indicates a new clip, but I'm pretty sure it still requires that the length be the same, as that's specified in the EXT-X-TARGETDURATION tag, which I don't think can be changed mid-file. In most of the M3U8 files I've worked with, EXT-X-DISCONTINUITY is usually used for pre-roll, mid-roll, and post-roll video (i.e., commercials), but the segments that make up those ads are still broken into EXT-X-TARGETDURATION segments...