Roku Developer Program

[skug67]

So I'm sure that I'm not alone in the fact that anything I record off the air starts life as an mpeg-ts/mpeg2 file. I would love the ability to transcode that on the fly into something that the Roku could play, rather than having to wait for the recording to end, then transcode to an h264/mp4 file. If I use MediaTomb in conjunction with djmount, I can get a directory listing of m3u files, each of which has a playlist which produces an mpeg-ts stream encoded with h264 (I'm sure there may be other ways to get to the same place, but this is what I've done so far). From what I've seen in the forums, that kind of stream is exactly what http-live-streaming produces. So (at least in theory) what I'm looking for should be do-able. But I'm clearly missing something -- I copied the contents of an m3u file produced in this way and copied it into the video directory for my MyMedia server, changing the name to mystream.m3u8. The file showed up in MyMedia, but it wouldn't play. But if I try to open the m3u8 file (ok, it's actually just a standard m3u file renamed with the m3u8 extension) directly with vlc, it plays just fine (and shows that the codec is in fact h264).

Anybody have any thoughts? It's often nice to be able to start watching a ballgame 1 hour late instead of being stuck with watching live over the air, or waiting 3-5 hours not only for the game to end but also for the transcoding to be done.

[renojim]

So you're using the myMedia server to serve up the m3u8 file and MediaTomb to serve the individual segments to the Roku, right? Can you post a sample m3u8 file, or just the first few lines if it has a million segments. Telnet to port 8085 on your Roku and I'll bet you see an error message printed out that says something like, "play failed: An unexpected problem (but not server timeout or HTTP error) has been detected". If you look at the main myMedia thread, you'll see at least one other person besides me has been able to get it to work, but he's not trying to serve up his own segments like you are. By the way, I think I wrote that the playlist has to be named mystream.m3u8. That's not true and any m3u8 file will be assumed to be an HLS playlist.

From my own experiments, some hls streams seem to work and some don't. I haven't figured out any rhyme or reason to it. I've been successful using vlc to transcode files/streams, but if I change some of the parameters it will suddenly stop working.

-JT

[skug67]

Here's the m3u8 file (which as I said is simply a renamed m3u file that is autogenerated by MediaTomb).

#EXTM3U
#EXTINF:2313,World_Cup_Soccer_-_2010-06-14_Group_Stage-_Italy_vs._Paraguay.mpg
http://192.168.0.159:49152/content/medi ... cmpeg/tr/1

For what it's worth, 192.168.0.159 is ip address of the machine that's hosting both MediaTomb and MyMedia. And 49152 is the port for the MediaTomb http interface. The rest of the url is (I believe) telling MediaTomb which file to serve and which script to use for transcoding (if I understand the process correctly the scripts direct the transcoded output to a FIFO which MediaTomb then sends out via the http interface). As I said before, if I access this m3u/meu8 via VLC (or enter the url manually) everything works fine -- I get the stream and vlc tells me that the video codec is h264. I haven't had a chance to telnet into the Roku while it's trying to run this. Hopefully I'll get the chance later tonight. Otherwise some time over the next couple of days.

Thanks for taking an interest. MyMedia is great (it's what I use for all my transcoded files and it does a wonderful job; I'm just trying to avoid the need for pre-transcoding).

[skug67]

For what it's worth, here's the output from the Roku via telnet:

Starting from position 0
Displaying video:
http://192.168.0.159:8081/media?name=my ... &key=video
displayHLS
streamformat hls
streamurls http://192.168.0.159:8081/media?name=my ... &key=video


album
artist HLS Playlist
length 0
streamqualities SD

streambitrates 0

url http://192.168.0.159:8081/media?name=my ... &key=video
title mystream
contenttype movie
releasedate
Unknown event: 20 msg:

[renojim]

If that's the whole m3u8 file, I don't think it's going to work. A normal HLS playlist m3u8 file would look something like this:

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:38
#EXTINF:10
http://192.168.1.103:1234/hls/nasa-0038.ts
#EXTINF:10
http://192.168.1.103:1234/hls/nasa-0039.ts
#EXTINF:10
http://192.168.1.103:1234/hls/nasa-0040.ts

It looks like MediaTomb is just creating one stream, not a bunch of segments, which isn't really how HLS works. I think we ought to be able to get MediaTomb to work with myMedia, but we'll have to take a different approach. I've been meaning to setup a Ubuntu virtual machine, so I guess now's as good a time as any. I'll see if I can get a MediaTomb server going in a virtual machine so I can see what it will take. I think it should be as easy as passing the http://192.168.0.159:49152/content/medi ... cmpeg/tr/1 url to the Roku as the source of the video, but the question is how to integrate that into myMedia.

I have an idea that will probably take less time than it will take me to get everything setup. PM me your email address and I'll send you a modified myMedia client that you can try. It will probably be tomorrow before I get a chance to get it finished.

-JT

[RokuKevin]

Note that when lining up segments in the playlist, the timestamps must lineup.... So it will not work in general to take arbitrary files and add them to an .m3u8 file, expecting them to play smoothly without buffering.

If those files are run through some sort of post-processing that makes the pts timestamps lineup in the different .ts file segments, the playlists will transition smoothly without buffering.

--Kevin

[skug67]

"RokuKevin" wrote:
Note that when lining up segments in the playlist, the timestamps must lineup.... So it will not work in general to take arbitrary files and add them to an .m3u8 file, expecting them to play smoothly without buffering.

If those files are run through some sort of post-processing that makes the pts timestamps lineup in the different .ts file segments, the playlists will transition smoothly without buffering.

--Kevin

But is it possible just to use a straightforward m3u (or some other mechanism) to access a single MPEG-TS file (with the right codecs)? Since HLS lets you access a series of them, why can't we just access a single one (and if we can, would it matter that the file is still open and being written by another process)?

[RokuKevin]

That would be out of spec.... HLS requires a segment duration:

#EXT-X-TARGETDURATION:10

--Kevin