Selection of Android video playback options--Analyze the advantages and disadvantages of video playback of Android platform

Https://zhuanlan.zhihu.com/p/27029577?utm_source=qq&utm_medium=social

Android I can also trust you how many series of article two audio and video playback

Audio and video playback in the current application is very common, the traditional application development to a certain stage of the introduction of audio and video resources, especially now short video is seen as the next growth point, and the associated entrepreneurial endless, as a developer how to choose the Audio video technology is very critical

MediaPlayer and Videoview provide us with a very convenient ability to play audio and video, almost without the need to write a few lines of code to complete.

We can also use MediaPlayer to combine Surfaceview or Textureview to achieve video playback , essentially the same as videoview, but with more flexibility.

Because of the encapsulation is too strong, it means that the customization becomes weaker. MediaPlayer provides setdatasource methods to support protocols such as http,file,content, but still cannot cope with complex requirements. So more flexible audiotrack, can let us directly transmit decoded after the byte[] to him, the problem is to do their own decoding. Decoding is not a simple matter, often we use MEDIACODEC (Android4.1) or external decoding library (such as ffmpeg) to achieve. Own to achieve the decoding to pay special attention do not lose hardware acceleration, audio Soft decoding is OK, video decoding soft decoding of the CPU pressure will be much larger.

In the audio and video business, often encounter such a number of problems need to set up proxy, or side-to-side cache, cache encryption, failure retry, network optimization and so on

Because we are unable to interfere with the MediaPlayer Network Request section, the original playback address, http/xxx.com/playurl , is generally converted to the cost machine proxy address Http://127.0.0.1:port Url=htt., so that MediaPlayer will come to request a proxy service on the port ports on this machine, in this proxy can do a lot of optimization logic, such as to the real send to the server side of the request and agent; Write the requested data to the disk cache. The proxy can request the server on demand (using the range parameter of HTTP) according to the disk cache, and some network optimization methods such as failure retry. This proxy layer also has a special meaning that can even take over the audio and video tag requests inside the webview.

This implementation in the actual operation of the occasional occurrence of the native agent can not start the situation, because the socket can not bind to the specified port, often we will specify in bind when the system to allocate an available port, So this failure is likely to be the root of the phone or some security management software disabled permissions.

In particular, the next side of the implementation of the cache, cache files allow empty, each cache file with another content index file, MediaPlayer itself will be based on the decoding situation issued multiple requests with range, based on the content index file to determine where the current request from the file read, The number of bytes to read from the file, how many bytes are read from the network, and the portion of the network read is written back to the file to ensure that the next request can be reused, so that the logic of a side-by-side cache is implemented, and even we can encrypt the local cache file. At the same time, the load percentage of this cache file can be used to do the buffering progress above the UI interface and monitor the download speed for network request optimization.

2.MediaPlayer of Looper. Novices tend not to care about the implementation of MediaPlayer, open its constructor in front of a few lines of code we will see that he is using the default looper of the current thread, if the current thread is not a looper thread, use Mainlooper. This is important because we know that even if MediaPlayer is running inside the service, and actually running on the main thread, the result is that all subsequent MediaPlayer callback operations are running in the main thread, which may be a time bomb hidden.

More elegant design We recommend that MediaPlayer callbacks and active operations (Stop,reset and so on) be put into work threads, and the serialization of operations is the simplest design and the most effective design . The approximate code form is this:

MediaPlayer in the playhandlerthread inside the initialization, it is guaranteed that he used the Looper is also this playhandlerthread, so that the callback will be triggered in this thread, At the same time we also do setdatasource in this thread and other active operations.

3. Video playback is also essentially implemented with MediaPlayer, so there is no special difference in reading data. Now the relatively hot little video needs to be displayed in the list page support scrolling play a video, click on the new page to continue to watch, generally using mediaplayer+textureview to achieve, MediaPlayer can adopt the global definition of the only one, It's just that the content bindings are displayed on different textureview at different times .

The biggest problem with 4.MediaPlayer is its compatibility . From our experience, there may be issues such as:

--Audio format support is not complete (ape,wma and other native systems are not supported),

--does not start playback after buffering,

--there was a sudden lack of sound during playback,

--Play there is a skip frame,

--mediaserver died;

--video playback only sound without a picture,

--Poor video format compatibility cannot be played and so on. These problems are basically impossible to solve on the basis of system.

The most headache problem is MediaPlayer return errorcode Many are manufacturers to expand out, the document provides a few of the value of the basic is not clear what the problem. This poses a big problem for troubleshooting. The most headache is the MediaPlayer EventHandler inside the handling of the exception directly causes the program to crash, such as:

11-04 13:43:08.966:e/androidruntime (26482): Java.lang.RuntimeException:failure code: -3211-04 13:43:08.966:e/ Androidruntime (26482): at Android.media.MediaPlayer.invoke (mediaplayer.java:664) 11-04 13:43:08.966:e/ Androidruntime (26482): at Android.media.MediaPlayer.getInbandTrackInfo (mediaplayer.java:1692) 11-04 13:43:08.966:e /androidruntime (26482): at Android.media.MediaPlayer.scanInternalSubtitleTracks (mediaplayer.java:1851) 11-04 13:43:08.966:e/androidruntime (26482): at android.media.mediaplayer.access$600 (mediaplayer.java:529) 11-04 13:43:08.966:e/androidruntime (26482): at Android.media.mediaplayer$eventhandler.handlemessage (MediaPlayer.java : 2198) 11-04 13:43:08.966:e/androidruntime (26482): at Android.os.Handler.dispatchMessage (handler.java:102) 11-04 13:43:08.966:e/androidruntime (26482): at Android.os.Looper.loop (looper.java:137) 11-04 13:43:08.966:e/ Androidruntime (26482): at Android.app.ActivityThread.main (activitythread.java:4998) 11-04 13:43:08.966:e/andRoidruntime (26482): at Java.lang.reflect.Method.invokeNative (Native Method) 11-04 13:43:08.966:e/androidruntime ( 26482): At Java.lang.reflect.Method.invoke (method.java:515) 11-04 13:43:08.966:e/androidruntime (26482): at Com.andro Id.internal.os.zygoteinit$methodandargscaller.run (zygoteinit.java:777) 11-04 13:43:08.966:e/androidruntime (26482 ): At Com.android.internal.os.ZygoteInit.main (zygoteinit.java:593) 11-04 13:43:08.966:e/androidruntime (26482): at Da Lvik.system.NativeStart.main (Native Method)

In addition to the reflection to replace the MediaPlayer inside the EventHandler to catch the anomaly, the other is not particularly good way.

Developers can only throw a different path when they meet so many problems. The use of self-decoding in the market is also a lot of, the more mainstream is using MEDIACODEC and ffmpeg,ffmpeg more because of the MEDIACODEC version limitations, plus is already famous, by many developers favor. Most of the mainstream audio and video players are being retrofitted on top of this.

Exoplayer:https://github.com/google/exo, as Google in the Mediacodec package is also a good recommendation, compared to their own to extract ffmpeg code for Android adaptation compilation comes much easier

FFMEPG: Of course there are some out-of-the-box implementations: Https://github.com/search?o=d, the most famous is Ijkplayer, a beep, a cross-platform and a barrage. Making video barrage is really out of the box. FFmpeg powerful, the only drawback is the soft decoding, which is also the reason for his good compatibility, we know that hard decoding relies on the hardware of the various manufacturers to achieve compatibility naturally declined.

When using self-decoding, we recommend that you encapsulate your MediaPlayer as an interface added to the Android version above :

/** * Sets the data source (MediaDataSource) to use. * * @param dataSource the MediaDataSource for the media you want to play * @throws IllegalStateException if it is called in an invalid state * @throws IllegalArgumentException if dataSource is not a valid MediaDataSource */public void setDataSource(MediaDataSource dataSource)        throws IllegalArgumentException, IllegalStateException {    _setDataSource(dataSource);}

The advantage of this is that all implementations are transparent to MediaPlayer, we only need to define a good Mediadatasource interface, and then only need to focus on implementation , such as Httpdatasource,filedatasource, Memorydatasource and so on.

Perhaps self-decoding would introduce more uncertainty, but sooner or later this step would have to be taken.

(1) Recommended small app or not strong product use system decoding, in my above mentioned some of the solutions to improve should be able to meet most of the scenes.

(2) and those audio and video as the main business products have to face self-decoding to improve compatibility.

So we are making wheels again;)

Android video playback options--deep analysis of the advantages and disadvantages of video playback on Android platforms