Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Level 7

Secure HLS Streaming from Akamai (bug report and workaround)

Hoping this post saves somebody the time and frustration I wasted:

When requesting a secure, live HLS stream from Akamai (master.m3u8?[token]), Akamai will return two cookies ("_alid_, "hdntl") that must included in the subsequent requests for a particular stream's manifest (m3u8). There appears to be a bug in the Roku's roVideoScreen in that even if you use "EnableCookies", only ONE of the two cookies is returned with subsequent requests.

My workaround is to grab the other cookie with an initial roUrlTransfer request, and then manually add it to the header. This method, however could fail if whatever configuration makes Roku ignore the "hdntl" cookie begins ignoring the "_alid_" cookies instead (eg: order in the header perhaps). Ignoring of the "_alid_" would be even more problematic as the cookie will eventually change with subsequent segment requests.

This is just my dev code (not cleaned up), but hopefully it will help:


req = CreateObject("roUrlTransfer")
req.SetPort(CreateObject("roMessagePort"))
req.SetUrl(radioFeed)
req.EnableCookies()
req.EnableFreshConnection(true)
if (req.AsyncGetToString())
event = wait(30000, req.GetPort())
if type(event) = "roUrlEvent"
if (event.GetResponseCode() <> 200)
DisplayDialog("No Live Feed", "Please check back later.")
return
endif

headers = event.GetResponseHeadersArray()
elseif event = invalid
print "AsyncGetToString timeout"
req.AsyncCancel()
return
else
print "AsyncGetToString unknown event"
return
endif
endif

for each header in headers
val = header.LookupCI("Set-Cookie")
if (val <> invalid)
if (val.Left(5) = "hdntl")
hdntl = val.Left(Instr(1,val,";")-1)
endif
endif
end for

port = CreateObject("roMessagePort")
screen = CreateObject("roVideoScreen")
screen.SetMessagePort(port)
screen.EnableCookies()
screen.AddHeader("Cookie",hdntl)
stream = {
HDBranded: true
IsHD: true
StreamBitrates: [0]
StreamUrls: [radioFeed]
StreamQualities: [0]
StreamFormat: "hls"
Live: true
}
screen.SetContent(stream)
screen.Show()


Another issue I have is that I cannot get the Roku player to adjust to a higher bitrate stream (it only takes the first), despite ample bandwidth (confirmed with roSystemLog bandwidth). The only way I can force it to the higher is with MinBandwidth, in which case, it plays without buffering (but obviously I'm hurting potential viewers with lower bandwidth). Here is the manifest returned by Akamai:


#EXTM3U
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=698000,RESOLUTION=640x360,CODECS="avc1.77.30, mp4a.40.2"
http://REMOVED-lh.akamaihd.net/i/REMOVED@51143/index_650_av-p.m3u8?sd=10&rebase=on
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=698000,RESOLUTION=640x360,CODECS="avc1.77.30, mp4a.40.2"
http://texaggies-lh.akamaihd.net/i/REMOVED@51143/index_650_av-b.m3u8?sd=10&rebase=on
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=1548000,RESOLUTION=1280x720,CODECS="avc1.77.30, mp4a.40.2"
http://REMOVED-lh.akamaihd.net/i/REMOVED@51143/index_1500_av-p.m3u8?sd=10&rebase=on
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=1548000,RESOLUTION=1280x720,CODECS="avc1.77.30, mp4a.40.2"
http://REMOVED-lh.akamaihd.net/i/REMOVED@51143/index_1500_av-b.m3u8?sd=10&rebase=on
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=48000,CODECS="mp4a.40.2"
http://REMOVED-lh.akamaihd.net/i/REMOVED@51143/index_650_a-p.m3u8?sd=10&rebase=on
#EXT-X-STREAM-INFSmiley TongueROGRAM-ID=1,BANDWIDTH=48000,CODECS="mp4a.40.2"
http://REMOVED-lh.akamaihd.net/i/REMOVED@51143/index_650_a-b.m3u8?sd=10&rebase=on


Anybody have any ideas?
0 Kudos
4 Replies
Highlighted
Roku Employee
Roku Employee

Re: Secure HLS Streaming from Akamai (bug report and workaro

Do you have a SwitchingStrategy set? Try Stream.switchingStrategy="full-adaptation"

Without that, no bitrate switching is likely to occur.

- Joel
0 Kudos
Highlighted
Level 7

Re: Secure HLS Streaming from Akamai (bug report and workaro

Thanks Joel! I thought that was already the default, but looking back at the docs, I see it is probably not. You might pass long that the docs are little unclear as to the actual default value as they read:

...Default is "no-adaptation"...


but, it also says:

"full-adaptation".... This is the new default.


When I tried the value, it did switch to the higher stream (1548kbps) for a moment, but then switch back to the lower (698kbps) and remained. All the while, the syslog was reporting bandwidth between 3000-4000. Strange that bandwidth reporting number anyway; network throughput at 50mbps, confirmed during test.

Any thoughts?
0 Kudos
Highlighted
Roku Employee
Roku Employee

Re: Secure HLS Streaming from Akamai (bug report and workaro

"ooshwa" wrote:
When I tried the value, it did switch to the higher stream (1548kbps) for a moment, but then switch back to the lower (698kbps) and remained. All the while, the syslog was reporting bandwidth between 3000-4000. Strange that bandwidth reporting number anyway; network throughput at 50mbps, confirmed during test.

Any thoughts?


Network throughput and measured bandwidth are different things. Measured bandwidth is an average of the rate that data is being received from the content source and can be affected by lots of factors. There have been many discussions of this in the past.

viewtopic.php?f=34&t=64720
0 Kudos
Highlighted
Level 7

Re: Secure HLS Streaming from Akamai (bug report and workaro

Hi,
We were facing the same problem. We tried the workaround suggested by ooshwa and it worked.
However the stream stops after a few minutes with error code "unknown error" Tried to play around with adaptation strategy etc , but no effect. The error is accompanied by a screen close event, so no further recovery is possible. Any ideas on how to debug this further would be deeply appreciated

Satish
0 Kudos