Roku Developer Program

[EnTerr]

Are there any provisions for using websockets on Roku platform?

Checking if i am (hopefully) missing something and there is API to do that already.

If not, best i can think of in B/S is to use tcp socket, then fudge HTTP (since websocket is "UPGRADE:" from http) and then manually deal with the frames. Re websocket over HTTPS though...

[sjb64]

I use them heavily in BRS, both as a requester to my own APIs on Azure, and as a web server to deliver some custom HLS needs to the app, where the box is both a producer and consumer.

[EnTerr]

But how?!
roUrlTransfer can do "ws://" | "wss://"?

[sjb64]

I use the roStreamSocket class when I do those, async calls with send and receive loops and a listener when using the Roku as a webserver (again for HLS), it's not simple and a small snippet code, but it does work once you get used to the class.

[EnTerr]

wow

[sjb64]

Lol, I wish it was all that, when I get a moment I'll organize some of the code into more readable and explainable segments then post it.

[EnTerr]

I am in awe that you'd channel HLS through a tailor-made proxy on Roku instead of on the server-side.

Re the websockets, i may end up writing my own code in non-BrightScript (for reasons non-related to language). So you are saying taking care of the "frames" in ws:// is not that scary? I can run with that.

[sjb64]

The reason I had to do that was VimeoPro (using Akamai) requires a bunch of security cookies for video playback, our videos are an intro, the main video, and a extro concatenated into a single HLS stream, each has its own distinct cookies, and there is no way to send 3 sets on an HLS master.

We didnt want to encode them together so we could have flexibility in our intros and extros. We didn't want to create hundreds of M3U8 on our server when they could be volatile, and didn't want Roku boxes FTPing to our servers when we couldn't predict volume, and that would have been a project anyway. So I hunt down the intro and extro TS files during startup (all async), download them to the box (they're quite small, a single TS segment), then create an M3U8 file on the box that links them together using Discontinuity tags. I had to create a web server anyway to feed the master M3U8, so feeding the intro/extro TS files was no big deal to add.

Sounds more complicated than it is, the hard part was getting through the multiple layers Akamai puts on external video access - reading and parsing M3U8s to find the appropriate final TS files.

[sjb64]

"EnTerr" wrote:
So you are saying taking care of the "frames" in ws:// is not that scary? I can run with that.

I didn't take care of it. Once we decided to do our own webservices, and more importantly that they would never be directly open to the public, but only used by our apps (Roku, C#, PHP, and so on), we didn't have to follow any standards on how we did it. So I say webservices, but that are actually simple socket services that expect requests in certain formats (similar to REST), and return a response or single/multiple record set payload that's compressed (massive compression is easy on highly predictable structured data) and encrypted and can be decoded quickly into appropriate data or record sets.

It sounds more complicated that it actually is.

[EnTerr]

Oh i see. I was asking specifically about "WebSocket" standard (RFC 6455), where you were talking about a proprietary socket exchange you created for web services. Regardless, what you said was informative and encouraging, thank you.

It seems amazing the degree you had to bend backwards for M3U8. Can't Roku play it locally?! M3U format supports local files like "tmp:/"...