4

I need to know where/how the MediaPlayer caches audio/video content when it is "streamed" via progressive download, by default.

We're evaluating options for an Android media player app. One item of concern is preventing the content from being copied (to the extent that is possible). Progressive download has a lot of upsides, but we need to make sure we're taking reasonable steps to protect the media. I must be doing the wrong searches in the wrong places, because I haven't been able to find any details on this. I've scoured the file system of our test device trying to find any cached files from our test progressive download app - to no avail (which is potentially good, for our purposes).

Chuck Spencer
  • 103
  • 1
  • 6

1 Answers1

5

In Android, MediaPlayer is a top-level class which abstracts the underlying player engine(s). In the MediaPlayer, the overall processing is divided as 3 major components as 

MediaTrack ==> OMXCodec / ACodec ==> Sink

Where MediaTrack is a track specific implementation which is based out of MediaExtractor which is the parser engine.

MediaExtractor is initialized with a DataSource which abstracts the input source. For your progressive download, the implementation of DataSource will be the main focus as this will provide the buffers to the downstream components. Since Android platform works on pull model, DataSource will control the rate of providing the data.

In AOSP, you could refer to a sample implementation as in http://androidxref.com/4.2.2_r1/xref/frameworks/base/media/java/android/media/MediaPlayer.java#2132 . Some further information on the HTTPSource implementation could be referred at http://androidxref.com/4.2.2_r1/xref/frameworks/av/media/libstagefright/HTTPBase.cpp#47

Ganesh
  • 5,880
  • 2
  • 36
  • 54
  • Thanks very much for the answer. It definitely pointed me in some helpful directions. I stepped through the MediaPlayer code in the debugger to try getting some insight into the DataSource implementation. Unfortunately I hit a dead-end when the MediaPlayer ultimately calls a native version of [setDataSource](http://androidxref.com/4.2.2_r1/xref/frameworks/base/media/java/android/media/MediaPlayer.java#962) – Chuck Spencer Mar 08 '13 at 18:24
  • 1
    From the JNI i.e. `android_media_mediaplayer`, the calls usually land up in `MediaPlayer.cpp`. From `MediaPlayer.cpp`, the calls for `player->setDataSource` is usually implemented by the player engine which could either be `StagefrightPlayer` or `NuPlayer`. In case of streaming playback, the calls would be processed by `NuPlayer`. – Ganesh Mar 08 '13 at 22:25
  • Thanks again. Unfortunately I've not been able to find any documentation on NuPlayer or StagefrightPlayer. If I had time to set up a linux dev rig and comb through the ASOP code, I would. But, unfortunately, I don't. I put a simple media app on an otherwise clean phone, streamed an mp3 via progressive download then did a pretty exhaustive search of the file system via DDMS. I found no identifiable or retrievable copy of the audio. This leads me to conclude that the player is either caching in memory or it's caching to the file system in some heavily obfuscated way. That might have to suffice. – Chuck Spencer Mar 11 '13 at 20:23
  • I was able to confirm via the logs that the AwesomePlayer is being used. Awesomeplayer appears to use NuCachedSource2 for its cache [seen here](http://androidxref.com/4.2.2_r1/xref/frameworks/av/media/libstagefright/AwesomePlayer.cpp#2030). And a quick glance at the [NuCachedSource2](http://androidxref.com/4.2.2_r1/xref/frameworks/av/media/libstagefright/NuCachedSource2.cpp) confirms that it's using a page cache system. Thanks Ganesh for steering me in this direction. – Chuck Spencer Mar 11 '13 at 20:57
  • 1
    @ChuckSpencer Thanks for confirming. Just to add my previous comment, I was observing `NuPlayer` in my setup for `RTSP` streaming. However, for `https` streaming, I could observe a similar path as you have mentioned. – Ganesh Mar 11 '13 at 23:46