Android Multimedia Framework Summary (iv) MediaPlayer from Java layer to C + + layer class relationship and prepare and other processes

Reprint please the head source link and the tail two-dimensional code reproduced together, this article from: http://blog.csdn.net/hejjunlin/article/details/52420803

In the previous chapter, the paper analyzes the process of MediaPlayer from creation to Setdatasource, and despite the code, but does not know the dependent call relationship between the various libraries from the MediaPlayer ecology, in this article will make a supplement to the overall understanding. Look at today's agenda:

• MediaPlayer diagram of the relationship between each so library
• MediaPlayer dependency graphs between each specific class
• Prepare the execution of the process
• Prepareasync Execution Process
• Prepare and Prepareasync differences
• Start execution process
• Pause execution Process

MediaPlayer diagram of the relationship between each so library

In each so, Libmedia.so is located at the core, and its provision of JNI to the upper layer is primarily in Java MediaPlayer class, class Libmedia_ Jni.so provides an interface to Java by calling the MediaPlayer class, and implements the Android.media.MediaPlayer class.
Libmediaplayerservice.so is a media server that implements the functionality of the server by inheriting libmedia.so classes, while the other part of Libmedia.so communicates through the IPC and libmediaplayerservice.so. The true functionality of libmediaplayerservice.so is decoded by calling Opencore player. Opencore is a multimedia framework, from the macro point of view, it mainly contains two main aspects of the content:

• Pvplayer: Provides the function of media Player to complete the playback (Playback) function of various audio and video streams
• Pvauthor: Provides the ability to record media streams, complete various audio, video streaming, and still image capture functions
• Pvplayer and Pvauthor are provided to developers in the form of an SDK that can build a variety of applications and services on top of this SDK. Multimedia applications that are often used in mobile terminals, such as media players, cameras, VCRs, recorders, and so on.
• Opencore organized codec and other building, unified interface, MediaPlayer call Opencore things, not too concerned about the lower codec is what, This library is no longer used in 6.0, instead it is stagefright, much simpler than opencore.
  The header file for the MediaPlayer section is in the frameworks/base/include/media/directory, which is the directory of the Libmedia.so library source files frameworks/base/media/libmedia/ corresponding to the. The main header files are as follows:
  
  • IMediaPlayerClient.h
  • Mediaplayer.h
  • IMediaPlayer.h
  • IMediaPlayerService.h
  • MediaPlayerInterface.h

In these header files Mediaplayer.h provides an interface to the upper layer, while the other header files provide some interface classes (that is, classes that contain pure virtual functions) that must be inherited by the implementation class to be able to use.

MediaPlayer dependency graphs between each specific class

The entire MediaPlayer can be run in the client and server two sections, which run in two processes, using the binder mechanism for IPC communication. In terms of frame structure, IMediaPlayerService.h, IMediaPlayerClient.h and MediaPlayer.h Three classes define Meidaplayer interfaces and schemas, MediaPlayerService.cpp and mediaplayer.cpp two files for Meidaplayer architecture implementation, Me Idaplayer the implementation of the specific function in Pvplayer (library libopencoreplayer.so).

Prepare the execution of the process

Prepare player is playback, this is a synchronous method, when Setdatasource and showing surface, you should start to call prepare or Prepareasync method, for file type, call prepare method will temporarily block , until MediaPlayer was ready for playback. Then call the native layer Android_media_mediaplayer_prepare method:

The above-mentioned we in the previous article, have introduced, 1 getvideosurfacetexture is to get a igraphicbufferproducer type pointer, 2 is setvideosurfacetexture, This is the last part of XXX introduced, here no longer elaborate. 3 is a decision and notify method, here is sent to the Mp->prepare method call state feed, if not OK, notify related error or throw an exception. We know there is a Prepareasync method, our previous ideas are along the MediaPlayer in the Create method.

Prepareasync the execution of the process

If this is the case, a network URL sent over, the video is very large: it is necessary to use the asynchronous prepare

Look at the Prepareasync method in MediaPlayer: Prepare the player for the next playback, which is an async method, when Setdatasource and showing surface, You should start calling the prepare or Prepareasync method, and for the stream type, you should call the Prepareasync method to return immediately, rather than block when there is not enough stream data to be buffered.

This article is derived from the countercurrent fish yuiop:http://blog.csdn.net/hejjunlin/article/details/52420803

This is a native method, we look at the Android_media_mediaplayer_prepareasync method:

From the code, except in the final Process_media_player_call Mp->prepareasync () judgment state, different, the other and prepare are the same. Its operation results are notified to the Java layer by a callback.
Look at the Prepareasync function in Media/mediaplayer.h, C + + code:

The above code summarizes: First Judge Mflags, at this time is not preparing. Then start Mqueue (class Timedeventqueue). The state of the mflags is then modified to preparing, indicating that the audio and video stream is now being prepared to process the file. Then pass the instance a awesomeevent and then put it in the mqueue that was previously started to notify.
The result of processing in the queue is to call the Awesomeplayer::onprepareasyncevent function. The process behind is the initial resolution of the code, decoding the stream, you can also know the width and high properties of the video stream, and then notify prepared. No more tracking down. The prepare process is complete.

Next, we go back to the Java layer before the Scaninternalsubtitletracks () method in the Prepare method

The method is to scan the embedded captions and track them.

The execution process of start

The next analysis looks at the START process in MediaPlayer:

The above code summarizes: The Start method is used to start or re-resume playback, if playback was previously paused, playback will start from the paused state into the start state, if playback is already stopped, Or have never started before, playback will begin start.
3 in the execution Stayawake () is the screen operation:

• First PowerManager PM = (powermanager) getsystemservice (Context.power_service);
• Get the PowerManager instance through the Context.getsystemservice () method.
• The Wakelock instance is then generated by PowerManager's newwakelock (int flags, String tag). The INT flags indicates which wakelock to get, and the different lock has different effects on the CPU, screen, keyboard lights. Gets the Wakelock instance, obtains the corresponding lock through acquire (), then carries out the operation of the other business logic, and finally releases (release is required) using release ().
  about the int flags, the effects of the types of locks on the CPU, screen, keyboard:
  
  • Partial_wake_lock: Keep the CPU running, and the screen and keyboard lights may be off.
  • Screen_dim_wake_lock: Keep the CPU running, allow the screen to be displayed but may be gray, allow to turn off the keyboard light
  • Screen_bright_wake_lock: Keeps the CPU running, allowing the screen to be highlighted, allowing the keyboard light to be turned off
  • Full_wake_lock: Keep the CPU running, keep the screen highlighted, and the keyboard lights remain bright
  • Acquire_causes_wakeup: Normal wake-up lock does not actually turn on lighting. On the contrary, once opened they would have been kept still. When Wakelock is obtained, this flag causes the screen or/and keyboard to open immediately. A typical use is to immediately see those notifications that are important to the user.

Finally, with Updatesurfacescreenon (), update your surface on the screen. We'll go back to the top start method. Finally, the _start method is called into native JNI.

Starting with the middle Mp-start, transfer to the bottom C + +, introducing media/mediaplayer.h into the native, we go to this header file to see:

It can be seen from the interface that the MediaPlayer class implements a MediaPlayer basic playback operation, playback (start), Stop (stop), pause (pause), reset (reset), and so on.
Another class, Deathnotifier, is defined in the MediaPlayer class, which inherits the Deathrecipient class in the IBinder class, which is intended for interprocess communication:

The following process communicates with Mediaplayerservice through the IPC and does not analyze down.
Can be found after the start, the bottom to return a state, is OK or not OK. This goes back to Process_media_player_call to determine the state of the return, and then notify the callback function in the Java layer.

The execution process of pause

Next, take a look at the pause method,

Find the Android_media_mediaplayer_pause method in the corresponding JNI

Pause method, you can see the process similar to start, but also through Mp->pause () to return the corresponding state, and then notify Upper to pause

There is also a stop method that is similar and is no longer analyzed here.

The first time to get blog update reminders, as well as more Android dry, source code Analysis , Welcome to follow my public number, sweep the bottom QR code or long press to identify two-dimensional code, you can pay attention to.

If you feel good, easy to praise, but also to the author's affirmation, can also share this public number to you more people, original not easy

Android Multimedia Framework Summary (iv) MediaPlayer from Java layer to C + + layer class relationship and prepare and other processes