- From: Shiv Kumar <skumar@exposureroom.com>
- Date: Mon, 20 Sep 2010 23:36:09 -0400
Rob, >Do you have use-cases where calling "load()" after the video stream ends would not be a reasonable solution? As you can imagine, getting an Html 5 video player to work as expected is a delicate balance, especially when having to deal with nuances between browser implementations. I don?t have a specific use case per-se, but I don know that calling load() is not a solution here because one has to use load to be able to switch the video from say a medium quality version to an HD version without glitches such that the user experience is seamless (that is the new version plays exactly where the low quality version left off. Of course during this switch I wouldn?t want the poster to re-appear. I feel, to keep things clean (clean from a browser implementation stand point and from an understanding standpoint) we need a method that allows specific control over the poster. At the moment, the poster is a stepchild of the video element. But if you look at popular video websites, the poster is an extremely important aspect of the player. Albeit, a simple aspect. At ExposureRoom we provide content producers a lot of options to do with the poster and they use it. Here are some contradictory cases that may serve as use cases to justify the need to have a spate method: 1. Some websites, don?t bother showing the poster after the video ends while providing the content producer to override. 2. Some websites (and mobile devices) default to showing the poster after the video ends and allowing the content producer to override 3. Some websites show the poster whenever the video is paused. Given the above cases, having a method the specifically controls the visibility of the poster (alone) will allow all of the above cases to be implemented. Shiv <http://exposureroom.com/> http://exposureroom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/0052681f/attachment-0001.htm>
Received on Monday, 20 September 2010 20:36:09 UTC