To simplify development of native libraries accessing OMX component via OMX service, stagefright supplies two useful client side classes, namely OMXCodec and ACodec respectively, here we attempt to explain their usage difference.
In media playback on mobile devices, one of the major factors affecting viewing experience is latency in rendering audio/video frames. If the media content resides locally, the latency to obtain media frames is neglectable. In case of playing back streamed content originated on Internet, network traffic latency may vary unpredictably; If obtaining media frames, frame decoding and rendering occurs in single thread, latency at each step will accumulate to a significant magnitude to cause noticeable slowness in rendering and lengthier response time to user controls.
OMXCodec and ACodec cater to the two separate usage scenarios. The handling of media frames and user controls in the former is synchronic and operates in one single thread,thus OMXCodec suits well for local media content decoding.
ACodec may get its initial letter from the term asynchronous.In ACodec, the reception of data/control commands and actual handling of the request are carried out in two separate threads. An ACodec interface function converts a command into an AMessage, and returns immediately after posting it to a message queue. This part runs in the playback thread. The actual message handler runs in a second thread. This arrangement improves on responsiveness of Stagefright, it accompanies with tremendous design complexity in order to track codec states (e.g. unitialized, loaded, loaded to idle, executing and so forth). Worth of the design complexity, ACodec is the best effort to serve playback of streamed data.
In the next few blogs, we will explore the design of OMXCodec and ACodec.
扫一扫
716
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
