Posts Tagged ‘flv’

Saturday, November 8th, 2008

The YouTube Chromeless Player works with AS3/ActionScript 3.

The demo shows great examples of the player with just the window canvas (chromeless) from both javascript and inside of flash.

The project is hosted on Google Code [youtubechromelesswrapper-as3]

Looks like they maybe had a contribution for this, so do it where you can.

This is something we’ve been wanting to provide for a while, and the YouTube API team greatly appreciates the work of developer Matthew Richmond of The Chopping Block for making it happen. Thanks Matthew!

Links

Capabilities/API

Public Methods

player.loadVideoById(id:String, startSeconds:Number = 0):void
Loads and plays video based on specified id.
player.cueNewVideo(id:String, startSeconds:Number = 0):void
Loads but does not automatically play video based on specified id.
player.clearVideo():void
Clears currently cued/loaded video.
player.setSize(w:Number, h:Number):void
Sets the size of YouTubePlayer instance.
player.play():void
Plays the currently cued/loaded video.
player.pause():void
Pauses the currently cued/loaded video.
player.stop():void
Stops the currently cued/loaded video.
player.seekTo(seconds:Number):void
Seeks to specified time within the currently cued/loaded video.
player.getPlayerState():String
Returns the current state of the currently cued/loaded video.
player.getBytesLoaded():Number
Returns the value of current bytes loaded of the currently cued/loaded video.
player.getBytesTotal():Number
Returns the value of total bytes loaded of the currently cued/loaded video.
player.getCurrentTime():Number
Returns the current position in time of the currently cued/loaded video.
player.getDuration():Number
Returns the current duration of the currently cued/loaded video.
player.getStartBytes():Number
Returns the start bytes of the currently cued/loaded video.
player.setVolume(newVolume:Number):void
Sets the volume of the currently cued/loaded video.
player.getVolume():Number
Returns the current volume of the currently cued/loaded video.
player.mute():void
Stores the current volume and changes the volume of the currently cued/loaded video to 0.
player.unmute():void
Returns the volume of the currently cued/loaded video to the last stored value when muted.
player.getEmbedCode():String
Returns the current YouTube embed code of the currently cued/loaded video.
player.getVideoUrl():String
Returns the current YouTube video url of the currently cued/loaded video.

Events

YouTubeLoaderEvent.LOADED
Fired once the Chromeless Player has successfully completed loading and is ready to accept operations calls.
YouTubeLoaderEvent.STATE_CHANGE
Fired whenever the player’s state changes. The YouTubeLoader class translates the JavaScript API numbers to their related string values, the YouTubeLoaderEvent class stores the current event in a variable called state. Possible values are unstarted, ended, playing, paused, buffering, video cued. When the SWF is first loaded, it will broadcast an unstarted event. When the video is cued and ready to play, it will broadcast a video cued event.
YouTubeLoaderEvent.IO_ERROR
Fired when an error in the player occurs. There are two error codes possible: 100 is broadcasted when the video requested is not found. This occurs when a video has been removed (for any reason), or it has been marked as private. 101 is broadcasted when the video requested does not allow playback in the embedded players.
Thursday, May 1st, 2008

Adobe is taking the inside lane in the industry it seems with the Open Screen Project. What does this mean? It seems like SWF and FLV formats are now largely open and licenses removed. With the XFL format possibly on its way (probably based on mxml) to replace closed .FLA files it is pretty clear that Adobe and Flash will see a large uptick in the mindshare. As well as looking to create a broader mobile platform for the flash player.

The Open Screen Project will address potential technology fragmentation by enabling the runtime technology to be updated seamlessly over the air on mobile devices. The consistent runtime environment is intended to provide optimal performance across a variety of operating systems and devices, and ultimately provide the best experience to consumers.

To support this mission, and as part of Adobe’s ongoing commitment to enable Web innovation, Adobe will continue to open access to Adobe Flash technology, accelerating the deployment of content and rich Internet applications (RIAs). This work will include:

  • Removing restrictions on use of the SWF and FLV/F4V specifications
  • Publishing the device porting layer APIs for Adobe Flash Player
  • Publishing the Adobe Flash® Cast™ protocol and the AMF protocol for robust data services
  • Removing licensing fees – making next major releases of Adobe Flash Player and Adobe AIR for devices free

This is big. It has mutiple prongs. Adobe would like to make Flash a common mobile standard, hrm no Apple on this list (it is probably a slight move there against that).

Adobe would also like to continue their lead of web video. And they finally are recognizing the closed format of SWF is not as desirable as an open one, there is still considerable control for Adobe over the player. But they get insights and contributions from many large companies to help make it work on their platform, engraining the format further. The providers, especially mobile and internet tv, will want to provide good user experiences to compete with the iPhone and regular T.V. respectively. Flash being open helps both of those markets.

Adobe is also moving further to open source key formats and technologies like the recent Flex 3 SDK and now the AMF format which was a roadblock. This is probably good news for servers like Red5 and also many other media servers and remoting services in many more place. AMF is particularly nice because it is a binary, extremely compact and limited bloat format. Without it being open it loses much of its benefit as a standard. Being open and a further crunching from the XML bloat services, this can be very good for many reasons such as throughput and faster services, apps and games with remote data.

Another reason is the desktop market. They want Flash to work flawlessly on Linux but they don’t’ have the manpower for a 2% market share. So this is a very smart move for the desktop players (AIR, and Linux Flash).

The only thing that partially makes it scary is the line up, Sony, Verizon, etc. As long as these are contributors and not partners in DRM crime then we have something. Hopefully they are in it to make better entertainment and mobile platforms cheaper.

Being able to peer into the code and a move to allow better open integration makes it a better platform, where better stuff can be built on top of that. Let’s hope it is done right. Everyone is making Apple look really closed and locked down lately.