not particularly well yet, though it's entirely possible that's my fault. i should probably first mention that my test streams are a mix of the following:
720p (actual res 1248x702) 29.97fps ~1600kbps
1024x576 29.97fps ~1000kbps
480x270 29.97fps ~600kbps
480x270 29.97fps ~350kbps
480x270 29.97fps ~150kbps
my ipad, iphone, and quicktime are all able to switch between bitrates seamlessly but the Roku here seems to want to stick on one bitrate when playing my testing urls, e.g.:
http://10.0.22.104:1935/rtplive/smil:21 ... ylist.m3u8the smil file (on wowza) in question contains:
<smil>
<head>
</head>
<body>
<switch>
<video src="21034.stream" system-bitrate="150000"/>
<video src="21033.stream" system-bitrate="350000"/>
<video src="21032.stream" system-bitrate="600000"/>
<video src="21031.stream" system-bitrate="1000000"/>
<video src="21030.stream" system-bitrate="1700000"/>
</switch>
</body>
</smil>
I have a transparent bridge in between my client lab and the server which artificially introduces a cap onto the bits/second (in half-second bursts) that can flow across the link. It works quite fine when testing the ios devices, QT, and apple's mediastreamvalidator, but I don't have similar luck with the Roku yet when reducing the flow below 1.5mbps.
I'm playing the stream and monitoring the flow with tcpdump to see what the roku is requesting from wowza. In general, it seems to prefer the 1.0Mbps stream and stays put to whatever it requested first. In case it's useful to someone else, the tcpdump statement I'm using on the bridge to match HTTP requests to my server is:
tcpdump -i em0 host 10.0.22.104 and "tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420"
A request for the "smil" playlist.m3u8 file just now results in this playlist:
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=150000
http://10.0.22.104:1935/rtplive/_defins ... =723115122#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=350000
http://10.0.22.104:1935/rtplive/_defins ... =723115122#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=600000
http://10.0.22.104:1935/rtplive/_defins ... =723115122#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1000000
http://10.0.22.104:1935/rtplive/_defins ... =723115122#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1700000
http://10.0.22.104:1935/rtplive/_defins ... =723115122what I see is the roku frequently request (every 10s) most of the children .m3u8 playlists but only retrieve one stream's worth of .ts segments. It tends to start with either the 1000 or 1700kbps streams. If there's insufficient bandwidth to maintain the stream, it will go back to the buffering screen and continue to make requests, skipping some .ts segments instead of switching bitrates to a lower bitrate.
This is with the 2.8 OS installed on a brand new XD.
Any ideas? Am I doing something totally stupid?
Thanks,
-t
[edit] realized all streams are 29.97fps and keyframe-aligned to each other
