Your Digital Media Has Never Looked So Good

 
dootv
Posts: 7
Joined: Mon Aug 27, 2012 11:12 pm

Re: HLS Troubleshooting

Wed Sep 26, 2012 8:52 pm

claudioc wrote:
i need to know what the limits are to the resolutions, for example netflix claims up to 1080p, but im unable to get a non-scrambled hls stream above 704x400, i can raise the bitrate nice and high, but i would like to be able to do live streaming up to 720p and 1080p myself i have the equipment for that already, its just a matter of the profile settings and so on now being accepted, and i dont see these settings listed any where, so im simply basing my highest available settings 704x400 @ 3000kbps (again bitrate im sure isnt the limiter here)

So please devs shed some light on the specs allowed, and perhaps why 720p live streaming isnt possible when on demand functions perfectly fine up to 1080p with my current setup. I would like to be able to provide a 1024x576 @ 3000 kbps which is seriously nice quality for a live stream.

** Also i would like to add for those of you who tried 10 seconds x 8 segments rolling window, let me further recommend 25 seconds x 8 segments, in my experience the cheapest dedicated server hosting is in europe. and the latency and routing are generally a problem for some people in usa that might want to save some money but at the same time cover europe and asia with there services, and that lower setting, is generally going to be the cause of it, im sure some will argue but i tested vigorously for a very long time here now, and 25000 miliseconds x 8 , has sincerely not buffered coming from Gbit in .NL to East Coast USA here to my Roku, so this does indeed mean international solutions are possible for HLS without the use of an expensive CDN, i was able to get Adobe Interactive Media Server 4.5.x working very well the built in apache 2.2 hosts the mp4 / xml files for my on demand perfectly even up to 1080p from webroot folder, and otherwise that setup will host HLS you dont need to pay insane prices for a CDN company to do something you can do yourself. **


claudioc, our setup is similar where our stream is coming from Asia with high latency. Are you using Wowza for your live streaming?
 
User avatar
RokuKevin
Roku Engineering
Topic Author
Posts: 796
Joined: Tue Sep 22, 2009 2:29 pm

Re: HLS Troubleshooting

Tue Oct 09, 2012 11:07 am

When using 25 second segments, you are trading off startup time and quick bitrate switches for more tolerance to variance in network bitrate and longer round trip times.

--Kevin
 
JasonH
Posts: 2
Joined: Wed Oct 24, 2012 10:09 am

Re: HLS Troubleshooting

Wed Oct 24, 2012 10:19 am

HLS Backup Stream Loading Prior to Primary Stream:
I have a question about the HLS backups streams and how Roku handles the playback of the primary and backup streams. With our configuration we are seeing Roku loading the backup stream first and then pretty quickly adapting and in the process switching to the primary stream. But our backup stream is not in sync with the primary stream so the switch between primary and backup is pretty disorientating.

Couple of questions:

1. Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?
2. Is it uncommon or common to have the primary and backup streams out of sync (as we do in our configuration)?

Thank you,
JasonH
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9232
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

Re: HLS Troubleshooting

Wed Oct 24, 2012 10:34 am

JasonH wrote:
HLS Backup Stream Loading Prior to Primary Stream:
I have a question about the HLS backups streams and how Roku handles the playback of the primary and backup streams. With our configuration we are seeing Roku loading the backup stream first and then pretty quickly adapting and in the process switching to the primary stream. But our backup stream is not in sync with the primary stream so the switch between primary and backup is pretty disorientating.

Couple of questions:

1. Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?
2. Is it uncommon or common to have the primary and backup streams out of sync (as we do in our configuration)?

Thank you,
JasonH

Someone at Roku will need to confirm, but I don't think the Roku supports backup streams. In my (limited) experience with those playlists that have backup streams (two or more streams with the same bitrate), the Roku tends to either pick one randomly, or uses the first in the list. I'm not sure which, but it seemed like the former, as you'd expect it to stick with the first for every bitrate otherwise.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
 
User avatar
RokuJoel
Posts: 1752
Joined: Mon Nov 14, 2011 5:22 pm

Re: HLS Troubleshooting

Wed Oct 24, 2012 10:41 am

If you have to have a backup stream, you'll need to build a mechanism to launch video playback of the backup if the initial playback fails. The backup stream should not be in the same playlist file as the primary stream. Instead, you would listen for a playback failure event and then trigger a new video playback function with the backup stream instead of the primary. You probably would want to exit playback altogether if the backup fails.

- Joel
 
User avatar
TheEndless
** Valued Community Member **
Posts: 9232
Joined: Mon Oct 04, 2004 10:15 am
Location: US
Contact:

Re: HLS Troubleshooting

Wed Oct 24, 2012 11:00 am

RokuJoel wrote:
If you have to have a backup stream, you'll need to build a mechanism to launch video playback of the backup if the initial playback fails. The backup stream should not be in the same playlist file as the primary stream. Instead, you would listen for a playback failure event and then trigger a new video playback function with the backup stream instead of the primary. You probably would want to exit playback altogether if the backup fails.

- Joel

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:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-DontLinkElementID_26 wrote:

Failover Protection
If your playlist contains alternate streams, they can not only operate as bandwidth or device alternates, but as failure fallbacks. Starting with iOS 3.1, if the client is unable to reload the index file for a stream (due to a 404 error, for example), the client attempts to switch to an alternate stream.

In the event of an index load failure on one stream, the client chooses the highest bandwidth alternate stream that the network connection supports. If there are multiple alternates at the same bandwidth, the client chooses among them in the order listed in the playlist.

You can use this feature to provide redundant streams that will allow media to reach clients even in the event of severe local failures, such as a server crashing or a content distributor node going down.

To implement failover protection, create a stream—or multiple alternate bandwidth streams—and generate a playlist file as you normally would. Then create a parallel stream, or set of streams, on a separate server or content distribution service. Add the list of backup streams to the playlist file, so that the backup stream at each bandwidth is listed after the primary stream. For example, if the primary stream comes from server ALPHA, and the backup stream is on server BETA, your playlist file might look something like this:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://ALPHA.mycompany.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://BETA.mycompany.com/lo/prog_index.m3u8
 
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://ALPHA.mycompany.com/md/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://BETA.mycompany.com/md/prog_index.m3u8

Note that the backup streams are intermixed with the primary streams in the playlist, with the backup at each bandwidth listed after the primary for that bandwidth.

You are not limited to a single backup stream set. In the example above, ALPHA and BETA could be followed by GAMMA, for instance. Similarly, you need not provide a complete parallel set of streams. You could provide a single low-bandwidth stream on a backup server, for example.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
 
User avatar
RokuJoel
Posts: 1752
Joined: Mon Nov 14, 2011 5:22 pm

Re: HLS Troubleshooting

Wed Oct 24, 2012 11:34 am

I'll pass on your feedback.

- Joel
 
JasonH
Posts: 2
Joined: Wed Oct 24, 2012 10:09 am

Re: HLS Troubleshooting

Wed Oct 24, 2012 12:31 pm

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.
 
User avatar
RokuJoel
Posts: 1752
Joined: Mon Nov 14, 2011 5:22 pm

Re: HLS Troubleshooting

Mon Oct 29, 2012 11:28 am

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
Posts: 2
Joined: Tue Feb 19, 2013 7:07 pm

Re: HLS Troubleshooting

Tue Feb 19, 2013 7:11 pm

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
 
User avatar
RokuMarkn
Roku Engineering
Posts: 1582
Joined: Mon Jun 09, 2008 9:20 am

Re: HLS Troubleshooting

Wed Feb 20, 2013 8:48 am

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
Posts: 2
Joined: Tue Feb 19, 2013 7:07 pm

Wowza nDVR Timeout and Buffering

Tue May 28, 2013 5:15 pm

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
Posts: 2
Joined: Thu Jun 13, 2013 8:54 am

Macroblocking on Bit Rate Switch

Thu Jun 13, 2013 9:08 am

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
Posts: 141
Joined: Wed Jun 06, 2012 10:42 am

Re: HLS Troubleshooting

Tue Aug 13, 2013 7:05 pm

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
Posts: 20
Joined: Mon Jun 13, 2011 1:17 pm

Re: HLS Troubleshooting

Fri Jan 31, 2014 5:57 pm

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

Who is online

Users browsing this forum: No registered users and 4 guests