<br><br><div class="gmail_quote">On 11 August 2012 05:43, Chris Pinkham <span dir="ltr"><<a href="mailto:cpinkham@bc2va.org" target="_blank">cpinkham@bc2va.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">* On Fri Aug 10, 2012 at 10:22:12PM +1000, Anthony Giggins wrote:<br>
> Silly Question and Semi OT, I've been reading the HLS streaming documents<br>
> from apple and I know they "recommend" a fail back stream of 64k audio only<br>
> however what happens if no failback stream is provided? and is there a<br>
> simple way to test this without recompiling and patching?<br>
<br>
</div>I think that it's more of a requirement than a recommendation if you<br>
are an iOS developer. I believe you have to support the fallback<br>
stream if you're working on an server/app combination for inclusion in<br>
the app store. MythTV's HLS encoder supports a 64Kbit audio-only<br>
fallback stream specifically due to this requirement. I added the<br>
second stream early on for the iOS app that Robert created.<br>
<div class="im"><br>
> Personnaly for video I'd much rather it pause and wait for buffers to fill<br>
> then to get audio only, airvideo does a decent job at handling this<br>
> although they have their own player<br>
<br>
</div>I think they're thinking more about users on slow cell networks than<br>
users using WiFi at home.<br>
<br>
--<br>
Chris<br></blockquote></div><br>seems its dropping out if the wifi signal strength drops low it will on occasion failback to audio only also hence my wanting to be able to disable the audio only stream.<br><br>Cheers,<br>
<br>Anthony<br>