Roku Developer Program

[tiddy]

Apologies if this has been covered before, but there are a number of factors at play so I've had a difficult time searching.

I have a SD live stream coming from a Wowza 3 EC2 instance. It plays fine on iOS, Android, and Flash on the web and uses an authentication token as a query string parameter on the stream. The Wowza server hits my web server to confirm an authentication token on the stream URL, this works as designed on all platforms. I actually have two streams configured right now, with differing encoding properties, but ultimately both exhibit the same problem on the Roku described next:

On the Roku (gen 1, haven't tried it on my new XD) the channel fails to load most of the time, but if I continue to press play over and over, every 3-5 times it will successfully load and play the channel perfectly. This happens upon first loading the channel and trying or when going from one feed to the next.

My telnet session looks about the same in either case, a bunch of "Unexpected Message class: Invalid" messages in the message loop for appVdeoScreen.brs when it works or fails. So how do I get it work to the first time I choose the channel? Can I somehow increase some kind of timeout or wait time for the channel to buffer and play? Is that even the issue? I don't have much to go on, and encoding doesn't seem to be the problem since it will, on occasion, play without any issue.

[RokuJoel]

Can you PM me a link to an m3u8 file that you are trying to play?

- Joel

[tiddy]

Done. Thanks for the prompt response, looking forward to finding what I've done wrong...

[RokuJoel]

Can you PM me a printout of the AssociativeArray that you are handing to roVideoPlayer or roVideoScreen? Use the PrintAA function you can find in the videoplayer examples.

- Joel

[RokuJoel]

So what i'm seeing so far: on my end it plays well, then gets glitchy and rebuffers quite a bit after 5 minutes or so. Also the aspect ratio of this stream is wrong on a Roku2 device in SDTV mode (with video.streamqualities=["SD"]) but is correct in HDTV mode with video.streamqualities set to ["HD"]. Make sure that your encoder CPU is under 70% utilization, and that your upstream bandwidth is not fluctuating.

Test your channel each of the following 3 different parameter settings in your video player function (see the Component Reference under “SwitchingStrategy”):

video.SwitchingStrategy=”full-adaptation”
video.SwitchingStrategy=”minimum-adaptation”
video.SwitchingStrategy=”unaligned-segments”

- Joel

[tiddy]

This should be an SD stream off the source, but I'll confirm that. I do have the following set in my Roku app, and I'll adjust to make sure the source is in fact SD, as I has assumed. Could that cause the issue I'm seeing or is that more to eliminate potential issues and follow best practices?
item.StreamBitrates = 800
item.StreamQualities = "SD" ' changing this to ["HD"] for now

The CPU on the encoder (I'm using an encoding appliance) is about 40%. I get the same result on the Roku by turning off all encoding jobs except this one. A Wowza EC2 instance sits in between and is at about 21% peak. Both have tons of bandwidth to spare (I'm using about 2 mbit of a 7 mbit pipe) from the encoder to EC2.

The encoder is set to constant bitrate, would I see better behavior from a variable bitrate? Would changing the Bitrate itself help?

I'll follow up shortly after testing the SwitchingStrategy in about an hour when I'm back in front of the device.

Thanks for the suggestions...I know I'm close since I can eventually get it to play if I just press play enough times.

[tiddy]

The "minimum-adaptation" took the fewest retrys to eventually play, and changing the SD/HD seems to have no impact on that issue. None of the 3 made it play the first try, the default setting was the least successful so it sounds like I have alignment issues.

I was looking at the encoder again and I changed the output PIDs from an auto configuration to a manual one and I get several new options regarding transport stream shaping, key frames, PCR?, DTS Delay? and such. I can tinker with those, but I guess my reservation is that it does eventually play on the Roku, and plays perfectly on all other platforms. Perhaps the other platforms are slightly more tolerant of whatever encoding configuration I have yet to do.

Can I code my channel app to Auto Retry (repeat what I'm doing by pressing play over and over) or increase the wait time or tolerance for whatever is causing the Roku to stop trying to play on that attempt?

[RokuJoel]

"tiddy" wrote:
I was looking at the encoder again and I changed the output PIDs from an auto configuration to a manual one and I get several new options regarding transport stream shaping, key frames, PCR?, DTS Delay? and such.

Can I code my channel app to Auto Retry (repeat what I'm doing by pressing play over and over) or increase the wait time or tolerance for whatever is causing the Roku to stop trying to play on that attempt?

What kind of encoder are you using?

I wouldn't play around too much with those settings, unless you are sure you can get back to the original settings.

I believe that part, but not all of your problem, might be in the data you are handing to the video player object. As I said, I'm not seeing the problem on startup that you are seeing, I'm seeing glitchyness and rebuffering after the stream has been running for 10-15 minutes. The difference might be that I'm on a 100mbps internet connection, so I would suggest trying your device on a few other networks just to see if the behavior is the same or different.

Is there any way you can check that your wowza server is getting enough data and not suffering from buffer underruns? Any errors in your encoder log?

Yes, the Roku might be more sensitive than other devices to variances in the HLS stream, after all Apple created the HLS spec.

- Joel

[tiddy]

For the source encoder I am using a DVEO GearBox, it is a Linux appliance with loads of flexibility but not much in the way of documentation. It takes source video and streams to wowza in a number of formats, I'm using RTMP since wowza is optimized for that.

I have a few output streams configured so getting back to the original settings was no problem. I have been able to change settings to get it to stutter at what appear to be segment boundaries and I can change the segments from 5 seconds to 2 or 2.5 segments and see the result in the stream, but it still isn't perfect.

No errors on the encoder
No apparent buffer under runs or any indication of resource constraints. The same stream plays perfectly on my iPad.

The simplevideoplayer app plays the stream on the first try every time, but my app doesn't. Process of elimination should do the trick - I'm going to simplify my player code and try again.