DRM integration in Stagefright

讀研時的畢業論文就是DRM在行動裝置上的研究及實現。當初選完這個題就後悔了，這玩意兒在中國不可能有存在的可能性，也是不可能鋪開的。

Google在2.3以後也加入了DRM的支援，也許在國外，這玩意兒還真有存在的空間。

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 dive 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;  } 

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.

轉自：

http://freepine.blogspot.com/2010/11/drm-integration-in-stagefright.html