Developers

[RokuJoel]

I'll pass on your feedback.

- Joel

[JasonH]

Joel, while I couldn't find specific reference to it in the official IETF HLS spec, here's Apple's documentation on how backup streams are meant to be presented in the playlist files for use with iOS. It'd be helpful if Roku supported this as well, as I'm running across more and more providers that are using this standard.

Thanks for the fast reply Joel and TheEndless. The streams we are working with follow Apple's documentation. So it sounds like that is part of the issue we are experiencing. I'll post back when we figure out how we end up handling this issue.

I second the request for following Apple's documentation as we are also seeing lots of movement toward following Apple's implementation.

[RokuJoel]

Hi folks, here is the official word from Engineering on Backup Streams:

Roku2 models do support HLS failover protection and will fallback to a backup stream with the same bitrate or, if no backup is available a lower bitrate variant.

Primary and backup streams should always be in sync, otherwise the failover protection does not work properly.

The Roku player should only access a backup stream if the primary stream failed to load.

If developers see different behavior they need to give us the steps to reproduce their issue and fix it (including a stream url we can test)

- Joel

[deltau2012]

Hello

I've been trying to find any information on this but we are using the nDVR addon with Wowza and streaming to the Roku with HLS. The DVR functionality works great, however when we start the stream, the Roku starts at the beginning. Is there any such code that is already made to work around this and start at the live point of the stream?

Thanks,
Trey

[RokuMarkn]

You can use the PlayStart metadata attribute to specify the start time. But see the discussion of HLS seeking near the end of http://sdkdocs.roku.com/display/RokuSDK ... ideoScreen

--Mark

[deltau2012]

Hey,

I am currently facing an issue between Wowza nDVR and Roku where a timeout occurs on Wowza when Roku is viewing a dvr portion of a currently live stream. It seams as though Roku buffers to a certain point and then stops or discontinues something that makes wowza think that a timeout with the roku has occured. At this point wowza then just closes the session and the roku plays the rest of what it has buffered. I've tested the wowza ndvr with my iphone and there are no issues with this. So I am narrowing it down to the roku side. Is there anywhere to see this communication between the roku and the server? All I can get so far is current segment data, but i'd like to see what and how much the Roku is buffering. There are sweat spots during the stream where roku will get into a good spot where the stream will never timeout but I cannot find this pattern.

Also Roku seems to loose the stream when I seek all the way to live. (it will play for about 5 seconds and then drop to the Loading Screen forever). This also does not occur on the iPhone. Is there anything on this?

I've look through everything under SDK and Forums today and still can't find anything.

Thanks,
-Trey

[djextrarice]

Currently publishing a multi bitrate HLS stream to Akamai with an Cisco Media Processor 7000 (aka Inlet Spinnaker 7000).

I used the default Inlet settings profile provided in the Roku Encoding guide. The stream looks good. I do see some macroblocking (?) on bit rate switching.

See photo

https://www.dropbox.com/s/sp007uulld8b8fk/roku-macroblock.PNG

Any idea on what I need to make sure I have setup to prevent this?

[bosborne]

We use an live stream encoder that publishes HLS to a CDN. For streams with variant playlists, sometimes the #EXT-X-MEDIA-SEQUENCE number in each of the variants get out of sync with one another. I'm working on this with the encoder developers, but they've told me that it is not part of the HLS spec that the player should use #EXT-X-MEDIA-SEQUENCE to keep variant switches in sync. I read over version 3 of the HLS spec and indeed could not find a requirement that these must be lined up.

If you read this section:
http://tools.ietf.org/html/draft-pantos ... tion-6.2.4

It reads:

Matching content in variant streams MUST have matching timestamps.
This allows clients to synchronize the streams.

The encoder meets these requirements. The segments in the playlists match up accordingly. Quicktime has no problem switching bit rates without any issue, and keeps the video in sync. However, when Roku does the switch, the video jumps all over the place because it must be doing some sort of calculation on #EXT-X-MEDIA-SEQUENCE

Can you pass this along to engineering to get some feedback?

[ooshwa]

It appears that if the first stream the Roku selects returns a 404, that the player aborts, rather than trying another. Can somebody confirm?

[dvyz]

Hello,
I am looking for the latest HLS version supported on Roku devices (Including Roku 1, 2, 3 and Dongle)
Please share with me an official info or a link.
It would be great if I can get the release dates/firmware version number etc. of the new version supported in the future release.
Thanks in advance.