2011-8-9 10:43:08

2011-8-9 10:43:08 组件版本号前面不能有空格编译好了 直接升级 VideoLAN计划是一个开发多媒体播放程序的计划。原本针对流影音有两个程序—VideoLAN Client (VLC) 及 VideoLAN Server (VLS) — 然而大部分的VLS功能都集成进VLC，所以就将程序名称改为VLC media player。这个计划原本是巴黎中央理工学院学生的专题计划。在2001年2月1日以GPL发布后，现在贡献者已经遍及世界。这个播放软件的三角锥图标是源自于交通三角锥[1]。目前的图标是2006年高分辨率的CGI（英语：电脑成像）[2]，用以取代先前手绘的低分辨率图标[3]。VLC media player具有跨平台的特性，可用于Linux、Microsoft Windows、Mac OS X、BeOS、BSD、Pocket PC及Solaris。VLC 在 Windows 和 Linux 上的操作接口基于 Qt4 。在Windows，Linux以及某些平台，VLC提供了一个Mozilla扩展，使得某些网站上附带的QuickTime及Windows Media多媒体文件，可以在非微软或苹果电脑的操作系统中，正常显示于Mozilla的浏览器下。从版本0.8.2开始，VLC亦提供了一个ActiveX的扩展，使用户可以在Internet Explorer下，正常显示某些网站上附带的QuickTime及Windows Media多媒体文件。VLC支持播放某些没有下载完成的视频文件部份内容。现在是mozilla扩展和activeX扩展 Class OverviewMediaPlayer class can be used to control playback of audio/video files and streams. An example on how to use the methods in this class can be found in VideoView. Please see Audio and Video for additional help using MediaPlayer. Topics covered here are: State Diagram Valid and Invalid States Permissions State DiagramPlayback control of audio/video files and streams is managed as a state machine. The following diagram shows the life cycle and the states of a MediaPlayer object driven by the supported playback control operations. The ovals represent the states a MediaPlayer object may reside in. The arcs represent the playback control operations that drive the object state transition. There are two types of arcs. The arcs with a single arrow head represent synchronous method calls, while those with a double arrow head represent asynchronous method calls. 同步调用 和异步调用 From this state diagram, one can see that a MediaPlayer object has the following states:When a MediaPlayer object is just created using new or after reset() is called, it is in the Idle state;创建或reset 后进入到idle状态 and after release() is called, it is in the End state. Between these two states is the life cycle of the MediaPlayer object. release 后就进入到结束状态 There is a subtle but important difference between a newly constructed MediaPlayer object and the MediaPlayer object after reset() is called.新创建的和调用reset后产生的有很轻微但很重要的区别。 It is a programming error to invoke methods such as getCurrentPosition(), getDuration(), getVideoHeight(), getVideoWidth(), setAudioStreamType(int), setLooping(boolean), setVolume(float, float), pause(), start(), stop(), seekTo(int), prepare() or prepareAsync() in the Idle state for both cases. If any of these methods is called right after a MediaPlayer object is constructed, the user supplied callback method OnErrorListener.onError() won't be called by the internal player engine and the object state remains unchanged; but if these methods are called right after reset(), the user supplied callback method OnErrorListener.onError() will be invoked by the internal player engine and the object will be transfered to the Error state. It is also recommended that once a MediaPlayer object is no longer being used, call release() immediately so that resources used by the internal player engine associated with the MediaPlayer object can be released immediately. Resource may include singleton resources such as hardware acceleration components and failure to call release() may cause subsequent instances of MediaPlayer objects to fallback to software implementations or fail altogether. Once the MediaPlayer object is in the End state, it can no longer be used and there is no way to bring it back to any other state. Furthermore, the MediaPlayer objects created using new is in the Idle state, while those created with one of the overloaded convenient create methods are NOT in the Idle state. In fact, the objects are in the Prepared state if the creation using create method is successful. In general, some playback control operation may fail due to various reasons, such as unsupported audio/video format, poorly interleaved audio/video, resolution too high, streaming timeout, and the like. Thus, error reporting and recovery is an important concern under these circumstances. Sometimes, due to programming errors, invoking a playback control operation in an invalid state may also occur. Under all these error conditions, the internal player engine invokes a user supplied OnErrorListener.onError() method if an OnErrorListener has been registered beforehand via setOnErrorListener(android.media.MediaPlayer.OnErrorListener). It is important to note that once an error occurs, the MediaPlayer object enters the Error state (except as noted above), even if an error listener has not been registered by the application. In order to reuse a MediaPlayer object that is in the Error state and recover from the error, reset() can be called to restore the object to its Idle state. It is good programming practice to have your application register a OnErrorListener to look out for error notifications from the internal player engine. IllegalStateException is thrown to prevent programming errors such as calling prepare(), prepareAsync(), or one of the overloaded setDataSource methods in an invalid state. Calling setDataSource(FileDescriptor), or setDataSource(String), or setDataSource(Context, Uri), or setDataSource(FileDescriptor, long, long) transfers a MediaPlayer object in the Idle state to the Initialized state. An IllegalStateException is thrown if setDataSource() is called in any other state. It is good programming practice to always look out for IllegalArgumentException and IOException that may be thrown from the overloaded setDataSource methods. A MediaPlayer object must first enter the Prepared state before playback can be started. There are two ways (synchronous vs. asynchronous) that the Prepared state can be reached: either a call to prepare() (synchronous) which transfers the object to the Prepared state once the method call returns, or a call to prepareAsync() (asynchronous) which first transfers the object to the Preparing state after the call returns (which occurs almost right way) while the internal player engine continues working on the rest of preparation work until the preparation work completes. When the preparation completes or when prepare() call returns, the internal player engine then calls a user supplied callback method, onPrepared() of the OnPreparedListener interface, if an OnPreparedListener is registered beforehand via setOnPreparedListener(android.media.MediaPlayer.OnPreparedListener). It is important to note that the Preparing state is a transient state, and the behavior of calling any method with side effect while a MediaPlayer object is in the Preparing state is undefined. An IllegalStateException is thrown if prepare() or prepareAsync() is called in any other state. While in the Prepared state, properties such as audio/sound volume, screenOnWhilePlaying, looping can be adjusted by invoking the corresponding set methods. To start the playback, start() must be called. After start() returns successfully, the MediaPlayer object is in the Started state. isPlaying() can be called to test whether the MediaPlayer object is in the Started state. While in the Started state, the internal player engine calls a user supplied OnBufferingUpdateListener.onBufferingUpdate() callback method if a OnBufferingUpdateListener has been registered beforehand via setOnBufferingUpdateListener(OnBufferingUpdateListener). This callback allows applications to keep track of the buffering status while streaming audio/video. Calling start() has not effect on a MediaPlayer object that is already in the Started state. Playback can be paused and stopped, and the current playback position can be adjusted. Playback can be paused via pause(). When the call to pause() returns, the MediaPlayer object enters the Paused state. Note that the transition from the Started state to the Paused state and vice versa happens asynchronously in the player engine. It may take some time before the state is updated in calls to isPlaying(), and it can be a number of seconds in the case of streamed content. Calling start() to resume playback for a paused MediaPlayer object, and the resumed playback position is the same as where it was paused. When the call to start() returns, the paused MediaPlayer object goes back to the Started state. Calling pause() has no effect on a MediaPlayer object that is already in the Paused state. Calling stop() stops playback and causes a MediaPlayer in the Started, Paused, Prepared or PlaybackCompleted state to enter the Stopped state. Once in the Stopped state, playback cannot be started until prepare() or prepareAsync() are called to set the MediaPlayer object to the Prepared state again. Calling stop() has no effect on a MediaPlayer object that is already in the Stopped state. The playback position can be adjusted with a call to seekTo(int). Although the asynchronuous seekTo(int) call returns right way, the actual seek operation may take a while to finish, especially for audio/video being streamed. When the actual seek operation completes, the internal player engine calls a user supplied OnSeekComplete.onSeekComplete() if an OnSeekCompleteListener has been registered beforehand via setOnSeekCompleteListener(OnSeekCompleteListener). Please note that seekTo(int) can also be called in the other states, such as Prepared, Paused and PlaybackCompleted state. Furthermore, the actual current playback position can be retrieved with a call to getCurrentPosition(), which is helpful for applications such as a Music player that need to keep track of the playback progress. When the playback reaches the end of stream, the playback completes. If the looping mode was being set to truewith setLooping(boolean), the MediaPlayer object shall remain in the Started state. If the looping mode was set to false , the player engine calls a user supplied callback method, OnCompletion.onCompletion(), if a OnCompletionListener is registered beforehand via setOnCompletionListener(OnCompletionListener). The invoke of the callback signals that the object is now in the PlaybackCompleted state. While in the PlaybackCompleted state, calling start() can restart the playback from the beginning of the audio/video source. Valid and invalid states