- From: Jeroen Wijering <mail@jeroenwijering.com>
- Date: Fri, 2 Jul 2010 09:28:17 +0200
Hello, The Flash player exposes a string of metrics: http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/net/NetStreamInfo.html The most useful ones are: *) droppedFrames: it can be used to determine whether the client can play the video without stuttering. *) maxBytesPerSecond: it can be used to determine the bandwidth of the connection. In addition to this, the metadata embedded in the video is interesting. For example: *) width & height: already available *) duration: already avaliable *) bitrates: for comparison against maxBytesPerSecond. *) seekpoints: for anticipating seek results in the UI *) content metadata (e.g. ID3 or MP4 Images) Here's an example with the exposed metadata printed on top of the player: http://developer.longtailvideo.com/trac/testing/?plugins=metaviewer&file=%2Fplayer%2Ftesting%2Ffiles%2Fbunny.mp4&height=260&width=500&autostart=true&mute=true Kind regards, Jeroen >> One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular. > > I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful? > > Regards, > Maciej > >> >> -Kevin >> >> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote: >> >> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote: >> >> >> >> >> I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient: >> >> >> >> A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened. >> >> B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor. >> >> C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>. >> >> D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms. >> >> E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W). >> >> F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode. >> >> >> >> I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate. >> > >> > Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen ? text and UI elements displayed by attacker will look noticeably different. >> >> That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though. >> >> - Maciej >> >> >
Received on Friday, 2 July 2010 00:28:17 UTC