Next phase of my life

My daughter was born a week ago. If you know me or my wife, please share our happiness! :-D

Casual thoughts on Stagefright

For the past 4+ years, I've mainly focused on Android multimedia area in my daily work. While the maintenance of Stagefright is much easier compared with OpenCORE,, there are still places which I think could be improved in future. Although I will not have the privilege of closely working on it any more after moving to my next occupation :)

Main issue
One of the biggest pains while working with Stagefright is various ANRs and tombstones related to mediaserver during stability test or user trials.
On one hand, Stagefright isn't mature and robust enough, there are some inherent issues limited by its structure, which makes it very difficult to fix all of them thoroughly. For example, you can easily reproduce an ANR while seeking and play/pause quickly during HTTP streaming due to the blocking read() call to network data and no way to cancel it gracefully, and the existing buffering mechanism doesn't work well because it can't predict which position to be read after seeking; and the potential deadlock between mediaserver and mediaplayer due to the subtle difference between calling mediaplayer from another application and from mediaserver itself (e.g. CameraService) as the binder transaction is skipped from intra-process call, etc.
On the other hand, even if you find the root cause and a potential solution, it's difficult to validate the fix because of the problem is highly impacted by network condition, race condition among threads, etc. Although we can simulate network traffic conditions with bandwidth control tools like netem, it still requires fine tuning and many tries if we don't hack into the code to force it to enter the situation. For lock related issues, I used to write simple CppUTest cases in many loops with different sleep time between function calls and then wish myself luck.

As an advocate of TDD and test automation, I think it would be ideal to have native media engine code written with testability in mind, such as incorporating gtest or other C++ test frameworks, so we can easily add unit test cases for newly reported issues. It would also help to facilitate the up-merge process of each release. Based on my experience, CTS and mediaframeworktest is far from sufficient to catch most of the issues we encountered before shipping the device.

In addition, with more and more features added into AOSP, it would help to unify different pieces of multimedia module into a more flexible architecture, to provide a generic pipeline for playback, recording, and transcoding etc, as well as an elegant way to support customized audio features, like LPA, tunnel mode, 5.1 channels, etc.

I guess it sounds greedy given that most of its code was written by only a couple of Google engineers in a short time with more and more functionality been added to each release. Keep moving, Stagefright!

The Seven Year Itch

It's the seventh year since I married my wife and it's also the seventh year of my working at Motorola Mobility:) While my wife is pregnant and we are looking forward to our first baby in the upcoming May, my journey at Motorola is going to an end at the same time with the process of most R&D positions in Beijing being terminated as part of the restructure plan of the company.

Hello Moto, Goodbye Moto~

Multimedia on JellyBean 4.2

Besides wireless display and some new camera hardware interface, it seems there isn't much change on Multimedia framework from the new released JellyBean 4.2 source code. Most of the patches are for bug-fixes and small code refactoring.
And same as 4.1, we can enable NuPlayer as the default media engine for local & http playback with a system property "media.stagefright.use-nuplayer".
However, compared to Awesomeplayer, there are still some functional gaps to fully switch to NuPlayer:

• Timed text support;
• BUFFERING related status update in GenericSource;
• Secure input buffer support for content protection, e.g. Widevine;
• Other minor improvements, such as preparing decode pipeline before PREPARED event, setLooping, changing surface texture while playing,etc.

Google has also added some code for fragmented MP4 parser, perhaps for MPEG-DASH but it's said to be experimental.

[1]frameworks/av JB 4.2 r_1 source code 

NuPlayer for HTTP live streaming

HTTP Live Streaming is separated from Stagefright on the recent release, which is basically another light-weighted playback engine, except it only supports the fixed container and codecs format currently.
It seems that the author really prefers rewriting than refactoring:)

Unlike Awesomeplayer, NuPlayer is built upon Stagefright's foundation classes, and leverages the Looper/Handlers mechanism to handle requests asynchronously by queuing them in a message loop, so there are less mutex/lock in place.

• NuPlayer::Source is the parser module. Actually its interface looks like a combination of MediaExtractor and MediaSource, and it also makes seekTo as an explicit API now.
• NuPlayer::Decoder connects to ACodec for AVC decoding, and to DecoderWrapper for AAC decoding, which in turn wrapps AAC software decoder in the OpenMAX style. ACodec is functionally similar as OMXCodec in Stagefright, besides the application of State pattern and passing MediaBuffers around with messages.
• NuPlayer::Render is responsible for rendering audio and also controls when to post video buffers back to NativeWindow for A/V sync.

Travel

I've been on travel to Libertyville for nearly two weeks. While it's a bit boring to live at a hotel, the good thing is I have a lot of spare time now, and I can freely surf the internet, so it's probably a good time for blogging:)

DRM integration in Stagefright

Google has pushed a change into AOSP which integrates DRM support into Stagefright recently:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=commitdiff;h=d5770917a50a828cb4337c2a392b3e4a375624b9#patch12

Before we delve into the change, there are basically two types of DRM schemes:
1. All of the data was stored under a uniform encryption layer (which is defined as DecryptApiType::CONTAINER_BASED in drm framework currently);
2. Encrypted data is embedded within a plain-text container format, so it can be decrypted packet by packet, thus also applicable for progressive download and streaming.

The entire commit is mainly composed of the following parts:
1)Extension in DataSource interface:

+    // for DRM
+    virtual DecryptHandle* DrmInitialization(DrmManagerClient *client) {
+        return NULL;
+    }
+    virtual void getDrmInfo(DecryptHandle **handle, DrmManagerClient **client) {};

FileSource implements those APIs, where it communicates with DRM service to open a decryption session. For CONTAINER based protection (e.g. OMA DRM v1), FileSource intercepts readAt() function and return the decrypted data transparently to its client -- file parser, which is thereby ignorant of the underlying protection mechanism.

2)Extension in MediaExtractor interface:

+    // for DRM
+    virtual void setDrmFlag(bool flag) {};
+    virtual char* getDrmTrackInfo(size_t trackID, int *len) {
+        return NULL;
+    }

The above APIs are used to retrieve context data, such as Protection Scheme Information Box in mp4/3gp files, to properly initialize the corresponding DRM plugin.

3)DRMExtractor and the DRM format sniffer:
SniffDRM is registered to identify DRM-protected files and its original container format. As mentioned, for CONTAINER_BASED encryption, FileSource handles data decryption transparently for parsers. For the other scheme, which are encrypted with sample/NAL as the basic unit, DRMExtractor is created to wrap the original MediaExtractor, to decrypt data after reading each sample/NAL from the original extractor. In this way, DRM related stuff is separated from actual file parsers.
However, as DRM is usually an extension based on the underlying container format, so it may not be as easily decoupled from file parser when it comes to other protection schemes. For example, Microsoft's PIFF extension to ISO base media format requires IV for each sample, and details of sub-sample encryption info if applicable, etc. Besides, it also imposes duplicate logic in DRM service to recognize the original container format for non-CONTAINER_BASED encryption.

4)Misc:
-changes in AwesomePlayer for rights management;
-changes in MPEG4Extractor to retrieve "sinf";
-etc.