<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 May 2013 21:04, Anthony Giggins <span dir="ltr">&lt;<a href="mailto:seven@seven.dorksville.net" target="_blank">seven@seven.dorksville.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><br><div>I must say I haven&#39;t had much luck with this bandwidth adaptation on my local WiFi atleast via Torc (fails back to the audio only stream almost 100% of the time), the same streams created by Torc will playback correctly via <cite><a href="http://www" target="_blank">http://www</a>.<b>mobilemyth</b>.net and never drops back to the audio only stream.<br>

<br>I can confirm the HLS trancoding is not falling behind as I have enabled all 4 cores</cite></div></div></div></blockquote><div><br></div><div>but which playback client are you using?<br><br></div><div>if torc, then it&#39;s the default iOS player.<br>
<br></div><div>It will go down bandwidth, when the available bandwidth isn&#39;t sufficient to stream the current one.<br></div><div>the myth backend only generates one video stream and one audio stream. So if the bandwidth isn&#39;t sufficient for video, that it falls back to the audio-only is the proper things to do.<br>
<br></div><div>One of the reason it&#39;s doing so is that myth marks the stream as &quot;live&quot; until the whole movie is decoded.... As such, when the bandwidth is too low, it will switch to audio rather than pause and wait for more data to come in.<br>
<br></div><div>Nothing you describe sounds abnormal... <br></div></div></div></div>