This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 17610 as part of operation convergence. Originally filed: 2012-06-27 01:20:00 +0000 Original reporter: Yang Sun <eric.sun@huawei.com> ================================================================================ #0 Yang Sun 2012-06-27 01:20:42 +0000 -------------------------------------------------------------------------------- During development of some cloud service using html5, we find it is benefitial to send frame to video element for display and interaction. But when we study the internal implementation, it seems that video element must decode metadata, then buffer enough amount of data for display. Even if we set the video attribute autoplay, we can not prevent the buffer behavior of video element, should it be better if video can support a non-buffer mode? I think video game, video interaction will be very popular in the future. We have consider using Canvas, but a little more complex, and we need direct video to Canvas using JS, which is not good for real time. Can anyone give some hint or comment? ================================================================================ #1 Odin Hørthe Omdal 2012-07-09 08:44:24 +0000 -------------------------------------------------------------------------------- I think maybe WebRTC is something you're looking for? ================================================================================
If you want it to play before it's buffered enough to play without stuttering, just call .play() on the element directly, don't bother with autoplay="". The autoplay="" attribute is specifically intended for buffering.