<br><br><div class="gmail_quote">On Wed, Aug 25, 2010 at 9:58 PM, Eric Carlson <span dir="ltr"><<a href="mailto:eric.carlson@apple.com">eric.carlson@apple.com</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"><br>
On Aug 25, 2010, at 6:06 PM, Herman Hassel wrote:<br>
<br>
> On 24.08.2010 01:17, Ian Hickson wrote:<br>
>> On Wed, 30 Jun 2010, Herman Hassel wrote:<br>
>>> I keep finding the media attributes "preload" and "autoplay"<br>
>>> insufficient for video playback.<br>
>> Before considering proposed alternatives, could you elaborate on how<br>
>> "preload" is insufficient? (It's impossible for me to evaluate how the<br>
>> proposed alternatives are better without knowing how the existing<br>
>> solutions are bad!)<br>
> Sure! At the moment I need to set preload to "none" or "metadata". Often we do use more than one video or audio element on the same page, and we do want the initial load of each page to be as low as possible. We do have some visitors with low bandwidth, or people who use their phones and are charged by their ISP by the MB. If we had only high bandwidth users and few elements on a page, we'd just use auto. We don't limit our media files to ranges or anything like that, we just want our users to have the best possible experience viewing the videos provided on the websites we make.<br>


><br>
> Whenever an end user starts a video or audio element that hasn't been preloaded, and the end user doesn't have good enough bandwidth to match the progressive download of the video file, we tend to get very stuttered and broken video for the first seconds, until either the speed of the stream picks up or the end users pause the playback themselves and wait for it to buffer up a bit. Now with audio this isn't such a big issue since the KB/s rate of audio files is so much smaller, but it's very noticeable with video.<br>


><br>
> I can also imagine scenarios where autoplay is set to "on" but the end user has low bandwidth, or scenarios where preload is set to "auto" but the end user clicks the play button too fast for the file to load. (yes, some of our end users are ninja's!)<br>


> We had the same issue with the experience of progressively downloaded media years ago, when I first started our early experiments with flash video (before every user had broadband), that was until we set the buffer attribute in flash, which fixed the whole issue.<br>


><br>
</div>  A static attribute that specifies a minimum buffer size or duration will only help users with exactly the bandwidth the for the attribute value - anyone with less bandwidth will still run out of data, and anyone with more bandwidth will have to wait longer than necessary.<br>


<div class="im"><br></div></blockquote><div><br></div><div>Well, in some cases (like a dedicated video site) you can have additional data on the user's bandwidth that the UA doesn't have. Historical playback data, for example, that shows the user's last N playbacks and the achieved bitrate.</div>

<div><br></div><div>At the very least it would be nice to be told how much had been loaded before playback began (maybe as part of an event). I suppose polling buffered would work, if buffered actually worked properly...</div>

<div><br></div><div>Theoretical scenario:</div><div><br></div><div>Listen for canplay -- this _should_ fire when just a couple frames are ready, yes?</div><div>Poll buffered state until desired buffer amount</div><div>Call play()</div>

<div><br></div><div>I don't think this actually works today though, largely due to bad implementations of buffered.</div><div><br></div><div>-Kevin</div><div><br></div><div><br></div></div>