Forum Discussion

peppert's avatar
peppert
Visitor
15 years ago

Force bitrate switching?

Hey all:

I'd like to debug some keyframe issues in our proprietary HD encoders, and wondered if there's a way to force roku to select a specific bitrate mid-stream in the debug console?

Thanks,
-t
Roku Developer Program

10 Replies

  • RokuMarkn's avatar
    RokuMarkn
    Visitor
    15 years ago
    I assume you're talking about an HLS stream? There's no debug command to do this, but you can omit some segments from the m3u8 for the high bitrate streams (using a DISCONTINUITY tag) and the player will switch to another stream that does contain that segment.

    --Mark
  • peppert's avatar
    peppert
    Visitor
    15 years ago
    Thanks, Mark - can you confirm/deny that it will hls bitrates midstream at all, or is it just a best-shot guess at stream startup? I'm not actually seeing it increase at all any more when I throw it in automatic mode.
  • RokuMarkn's avatar
    RokuMarkn
    Visitor
    15 years ago
    If there are multiple variant streams defined by the top level m3u8 and they cover the same sequence numbers, then the player should switch between them based on bandwidth.

    --Mark
  • peppert's avatar
    peppert
    Visitor
    15 years ago
    ahhh i had been using different <media> tags for the distinct bitrates of each stream. i'll try the wowza smil method and see how it fares, thanks.
  • manuelalvarez's avatar
    manuelalvarez
    Visitor
    15 years ago
    peppert

    Please report back, I am also interested in finding out if Roku switching midstream between the bitrates.

    Regards,

    Manuel.-
  • peppert's avatar
    peppert
    Visitor
    15 years ago
    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.m3u8

    the 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 ... =723115122

    what 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
  • manuelalvarez's avatar
    manuelalvarez
    Visitor
    15 years ago
    I am also new with the Roku, but I have seen the same behavior, the Roku seems to select a stream and if there is not enough bandwidth to maintain it, instead of switching to a lower bitrate stream, it will rebuffer the first selected.

    I really hope this can be fixed. I am also using Wowza as the server.
  • rajeev_t's avatar
    rajeev_t
    Visitor
    13 years ago
    I had done some tests with Roku and get same results as mentioned by Peppert.
    About HLS standard Can we force client to always look for the highest bit rate defined in the manifest file? instead of looking for the lowest bit rate in the manifest file?
    Suppose we have following bitrates in the manifest file 1mbps ,750kbps,500kbps,250kbps, is there a possibility whatever client requests we can force it to highest bitrate? or its mandatory to be at lowerst