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 <[email protected]> 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 >> >> >
