Android mediacodec states transition analysis

*Due to work needs, mediacodec needs to be used to realize playback, transcode and other functions. Therefore, during the learning process, the official mediacodec API documents of Google are translated. Due to the limitation of the author's level, there are inevitable errors and inappropriateness in the article. I hope to criticize and correct.

*Please indicate the source for Reprint: http://www.cnblogs.com/roger-yu/

There are three states in the life cycle of mediacodec: stopped, executing or released, where

The stopped state contains three sub states: uninitialized, configured and error

The executing status includes three sub statuses: flushed, running and end of stream

Since the state transition of mediacodec in different data processing modes will be slightly different, we will analyze the state transition in synchronous processing mode and asynchronous processing mode in detail

First, let's take a look at the flow chart of state transition, as follows:

1. When a mediacodec object instance is created by any of mediacodec.createbycodecname (...) or mediacodec.createcoderbytype (...) or mediacodec.createencoderbytype (...), codec will be in @ H_ 404_ 103@Uninitialized Status;

@H_ 404_ 103 @ 2. When you call mediacodec. Configure (...) method to configure codec, codec will enter @ H_ 404_ 103@Configured Status;

@H_ 404_ 103 @ 3. After that, you can call mediacodec. Start() method to start codec. Codec will turn to executing state. After start, codec will immediately enter @ H_ 404_ 103@Flushed Sub state. At this time, codec has all input and output buffers, and the client cannot operate these buffers;

@H_ 404_ 103 @ 4. Once the first input buffer is out of the queue, that is, the client obtains a valid input buffer index by calling mediacodec.dequeueinputbuffer (...) request, codec immediately enters @ H_ 404_ 103@Running Sub state, in which codec will carry out actual data processing (decoding and coding) and pass the main stages of its life cycle;

@H_ 404_ 103 @ 5. When the input end enters an input buffer with end of stream tag (queueinputbuffer (EOS)), codec will transfer to @ H_ 404_ 103@End Of stream sub state. In this state, codec will no longer accept new input buffer data, but will still process the input buffer that has been queued but has not been processed and generate the output buffer until @ H_ 404_ 103@end -When the of stream tag reaches the output end, the data processing process is terminated;

@H_ 404_ 103@@H_ 404_ 103 @ 6. In the executing state, you can call mediacodec. Flush() method to make codec enter @ H_ 404_ 103@Flushed Sub state;

@H_ 404_ 103@　　7. @H_ 404_ 103 @ in the executing state, you can call mediacodec. Stop() method to make codec enter @ H_ 404_ 103@@H_ 404_ 103@Uninitialized Sub state, you can reconfigure codec;

@H_ 404_ 103 @ 8. In rare cases, codec will encounter errors and enter @ H_ 404_ 103@Error State, you can call the mediacodec. Reset () method to make it available again;

@H_ 404_ 103 @ 9. When mediacodec data processing task is completed or mediacodec is no longer needed, mediacodec. Release() method can be used to release its resources.

First, let's take a look at the flow chart of state transition, as follows:

The state transition in asynchronous mode is similar to that in synchronous mode, with two main differences:

　　1. @H_ 404_ 103 @ call mediacodec. Start() method to start codec, and codec will be directly transferred to @ H_ 404_ 103@Running Sub state;

@H_ 404_ 103 @ 2. Enter @ h when calling mediacodec. Flash() method_ 404_ 103@Flushed After substatus, you must call @ H_ 404_ 103 @ mediacodec. Start() method codec will enter @ h_ 404_ 103@Running Sub state.

@H_ 404_ 103 @ in other cases, it is the same as that in synchronous mode, so it is not repeated here.

@H_ 404_ 103 @ wechat sweep, pay attention to the 90 diary and get more relevant information and source code -- although it doesn't face the sea, it's still blooming in spring