androidstagefright

Ⅰ opencore和stagefrighten的区别

OpenCore组织codec等等些组建统接口MediaPlayer调用OpenCore东西用太关层codec体解释OpenCore较新Android已经用代替Stagefright比OpenCore简洁 般＂框架＂都理解真干“东西”负责些具体干“东西”组织起层模块能完些通用功能让更/便调用具体干“东西”没＂框架＂实现同功

Ⅱ android手机有默认解码器吗

实际上系统中存在的解码器可以很多，但能够被应用使用的解码器是根据配置来的，在/system/etc/media_codecc.xml中配置。这个文件一般由硬件或者系统的生产厂家在build整个系统的时候提供，一般是保存在代码的device/[company]/[codename]目录下的，例如device/samsung/tuna/media_codecs.xml。这个文件配置了系统中有哪些可用的codec以及，这些codec对应的媒体文件类型。在这个文件里面，系统里面提供的软硬codec都需要被列出来。

也就是说，如果系统里面实际上包含了某个codec，但是并没有被配置在这个文件里，那么应用程序也无法使用到！

在这里配置文件里面，如果出现多个codec对应同样类型的媒体格式的时候，这些codec都会被保留起来。当系统使用的时候，将后选择第一个匹配的codec。除非是指明了要软解码还是硬解码，但是Android的framework层为上层提供服务的AwesomePlayer中在处理音频和视频的时候，对到底是选择软解还是硬解的参数没有设置。所以虽然底层是支持选择的，但是对于上层使用MediaPlayer的Java程序来说，还是只能接受默认的codec选取规则。

但是Android提供的命令行程序/system/bin/stagefright在播放音频文件的时候，倒是可以根据参数来选择到底使用软解码还是硬解码，但是该工具只支持播放音频，不支持播放视频。

一般来说，如果系统里面有对应媒体的硬件解码器的话，系统开发人员应该是会配置在media_codecs.xml中，所以大多数情况下，如果有硬件解码器，那么我们总是会使用到硬件解码器。极少数情况下，硬件解码器存在，但不配置，我猜测只可能是这个硬解码器还有bug，暂时还不适合发布。

Ⅲ stagefright是什么高危漏洞

这个关键漏洞位于Android的名为“Stagefright”的核心库中，这是一个原生的媒体播放库，供Android系统用来处理、记录和播放多媒体文件。
Stagefright是一个真正可以主动利用的安全漏洞，也就是说，只要黑客知道你的电话号码，然后发送一条恶意MMS给你，就能侵入 Android 手机，取得控制权，根本无需受害者任何交互。更可怕的是还能神不知鬼不觉，侵入系统后就删除讯息，不会让主人察觉。
不知道电话号码 照样黑你

但是，据最近的一项研究声称，现在根本不需要知道受害者的移动电话号码，照样可以感染他们的设备。

在此前获悉的攻击情形中，攻击者只能针对已知联系号码的手机来发动Stagefright攻击。这意味着攻击者需要提前知道目标设备的电话号码。
这样的攻击情形实际上不太可能发生，因为如果攻击者想要进行大规模的感染，即使他们有大量资金来发送国内和国际MMS的话，也得知道巨量目标设备的电话号码才行。
触发Stagefright漏洞的新方法

目前，趋势科技的安全研究人员已经发现了两种新的攻击方案，无需发送恶意的彩信就可以直接触发Stagefright漏洞：

通过Android应用触发漏洞

为访问互联网网页的攻击目标精心构造HTML漏洞利用

与之前的攻击手段相比，这两种新型的Stagefright攻击向量带来了更加严重的安全威胁，因为攻击者可以利用该BUG远程进行下列活动：

在不知道受害者的电话号码且不费一分钱的情况下，就能黑掉数以百万计的Android设备。

切取海量数据。

利用黑掉的Android设备打造僵尸网络，等等。
“精心构造的特殊MP4文件，能够破坏或利用媒体服务器的堆”，研究人员解释道，这就是利用应用程序触发Stagefright攻击的方法。

Ⅳ 【Android】stagefright utils media这些库都在哪

手机root之后，可以在/system/libs/下找到所有的so，NDK里没有的。或者你也可以下载源码，编译之后可以找到相应的so。LOCAL_LDLIBS += -L $(path-to-system-libs) -lcutils。

Ⅳ 安卓stagefright检测怎么用

1、 StageFright介绍
Android froyo版本多媒体引擎做了变动，新添加了stagefright框架，并且默认情况android选择stagefright，并没有完全抛弃opencore，主要是做了一个OMX层，仅仅是对 opencore的omx-component部分做了引用。stagefright是在MediaPlayerService这一层加入的，和opencore是并列的。Stagefright在 Android中是以shared library的形式存在(libstagefright.so)，其中的mole -- AwesomePlayer可用来播放video/audio。 AwesomePlayer提供许多API，可以让上层的应用程序(Java/JNI)来调用。

2、 StageFright数据流封装
2.1》由数据源DataSource生成MediaExtractor。通过MediaExtractor::Create(dataSource)来实现。Create方法通过两步来生成相应的 MediaExtractor（MediaExtractor.cpp）：
 通过dataSource->sniff来探测数据类型
 生成相应的Extractor：
if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MPEG4)
|| !strcasecmp(mime, "audio/mp4")) {
return new MPEG4Extractor(source);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_MPEG)) {
return new MP3Extractor(source, meta);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_AMR_NB)
|| !strcasecmp(mime, MEDIA_MIMETYPE_AUDIO_AMR_WB)) {
return new AMRExtractor(source);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_WAV)) {
return new WAVExtractor(source);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_OGG)) {
return new OggExtractor(source);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MATROSKA)) {
return new MatroskaExtractor(source);
} else if (!strcasecmp(mime, MEDIA_MIMETYPE_CONTAINER_MPEG2TS)) {
return new MPEG2TSExtractor(source);
}

2.2》把音视频轨道分离，生成mVideoTrack和mAudioTrack两个MediaSource。代码如下（AwesomePlayer.cpp）：
if (!haveVideo && !strncasecmp(mime, "video/", 6)) {
setVideoSource(extractor->getTrack(i));
haveVideo = true;
} else if (!haveAudio && !strncasecmp(mime, "audio/", 6)) {
setAudioSource(extractor->getTrack(i));
haveAudio = true;
}

2.3》得到的这两个MediaSource，只具有parser功能，没有decode功能。还需要对这两个MediaSource做进一步的包装，获取了两个MediaSource（具有parse和decode功能）：
mVideoSource = OMXCodec::Create(
mClient.interface(), mVideoTrack->getFormat(),
false, // createEncoder
mVideoTrack,
NULL, flags);
mAudioSource = OMXCodec::Create(
mClient.interface(), mAudioTrack->getFormat(),
false, // createEncoder
mAudioTrack);
当调用MediaSource.start()方法后，它的内部就会开始从数据源获取数据并解析，等到缓冲区满后便停止。在AwesomePlayer里就可以调用MediaSource的read方法读取解码后的数据。
 对于mVideoSource来说，读取的数据：mVideoSource->read(&mVideoBuffer, &options)交给显示模块进行渲染，mVideoRenderer->render(mVideoBuffer);
 对mAudioSource来说，用mAudioPlayer对mAudioSource进行封装，然后由mAudioPlayer负责读取数据和播放控制。

3、 StageFright的Decode
经过“数据流的封装”得到的两个MediaSource，其实是两个OMXCodec。AwesomePlayer和mAudioPlayer都是从MediaSource中得到数据进行播放。AwesomePlayer得到的是最终需要渲染的原始视频数据，而mAudioPlayer读取的是最终需要播放的原始音频数据。也就是说，从OMXCodec中读到的数据已经是原始数据了。
OMXCodec是怎么把数据源经过parse、decode两步以后转化成原始数据的。从OMXCodec::Create这个构造方法开始，它的参数：
 IOMX &omx指的是一个OMXNodeInstance对象的实例。
 MetaData ＆meta这个参数由MediaSource.getFormat获取得到。这个对象的主要成员就是一个KeyedVector<uint32_t, typed_data> mItems，里面存放了一些代表MediaSource格式信息的名值对。
 bool createEncoder指明这个OMXCodec是编码还是解码。
 MediaSource ＆source是一个MediaExtractor。
 char *matchComponentName指定一种Codec用于生成这个OMXCodec。
先使用findMatchingCodecs寻找对应的Codec，找到以后为当前IOMX分配节点并注册事件监听器：omx->allocateNode(componentName, observer, &node)。最后，把IOMX封装进一个OMXCodec：
sp<OMXCodec> codec = new OMXCodec(
omx, node, quirks,
createEncoder, mime, componentName,
source);
这样就得到了OMXCodec。
AwesomePlayer中得到这个OMXCodec后，首先调用mVideoSource->start()进行初始化。 OMXCodec初始化主要是做两件事：
 向OpenMAX发送开始命令。mOMX->sendCommand(mNode, OMX_CommandStateSet, OMX_StateIdle)
 调用allocateBuffers()分配两个缓冲区，存放在Vector<BufferInfo> mPortBuffers[2]中，分别用于输入和输出。
AwesomePlayer开始播放后，通过mVideoSource->read(&mVideoBuffer, &options)读取数据。mVideoSource->read(&mVideoBuffer, &options)具体是调用OMXCodec.read来读取数据。而OMXCodec.read主要分两步来实现数据的读取：
 通过调用drainInputBuffers()对mPortBuffers[kPortIndexInput]进行填充，这一步完成 parse。由OpenMAX从数据源把demux后的数据读取到输入缓冲区，作为OpenMAX的输入。
 通过fillOutputBuffers()对mPortBuffers[kPortIndexOutput]进行填充，这一步完成 decode。由OpenMAX对输入缓冲区中的数据进行解码，然后把解码后可以显示的视频数据输出到输出缓冲区。
AwesomePlayer通过mVideoRenderer->render(mVideoBuffer)对经过parse和decode 处理的数据进行渲染。一个mVideoRenderer其实就是一个包装了IOMXRenderer的AwesomeRemoteRenderer：
mVideoRenderer = new AwesomeRemoteRenderer(
mClient.interface()->createRenderer(
mISurface, component,
(OMX_COLOR_FORMATTYPE)format,
decodedWidth, decodedHeight,
mVideoWidth, mVideoHeight,
rotationDegrees));

4、 StageFright处理流程
Audioplayer 为AwesomePlayer的成员，audioplayer通过callback来驱动数据的获取，awesomeplayer则是通过 videoevent来驱动。二者有个共性，就是数据的获取都抽象成mSource->Read()来完成，且read内部把parser和dec 绑在一起。Stagefright AV同步部分，audio完全是callback驱动数据流，video部分在onVideoEvent里会获取audio的时间戳，是传统的AV时间戳做同步。

4.1》AwesomePlayer的Video主要有以下几个成员：
 mVideoSource(解码视频)
 mVideoTrack(从多媒体文件中读取视频数据)
 mVideoRenderer(对解码好的视频进行格式转换，android使用的格式为RGB565)
 mISurface(重绘图层)
 mQueue(event事件队列)

4.2》stagefright运行时的Audio部分抽象流程如下：
 设置mUri的路径
 启动mQueue，创建一个线程来运行 threadEntry（命名为TimedEventQueue，这个线程就是event调度器）
 打开mUri所指定的文件的头部，则会根据类型选择不同的分离器（如MPEG4Extractor）
 使用 MPEG4Extractor对MP4进行音视频轨道的分离，并返回MPEG4Source类型的视频轨道给mVideoTrack
 根据 mVideoTrack中的编码类型来选择解码器，avc的编码类型会选择AVCDecoder，并返回给mVideoSource，并设置mVideoSource中的mSource为mVideoTrack
 插入onVideoEvent到Queue中，开始解码播放
 通过mVideoSource对象来读取解析好的视频buffer
如果解析好的buffer还没到AV时间戳同步的时刻，则推迟到下一轮操作
 mVideoRenderer为空，则进行初始化（如果不使用 OMX会将mVideoRenderer设置为AwesomeLocalRenderer）
 通过mVideoRenderer对象将解析好的视频buffer转换成RGB565格式，并发给display模块进行图像绘制
 将onVideoEvent重新插入event调度器来循环

4.3》数据由源到最终解码后的流程如下：
URI,FD
｜
DataSource
｜
MediaExtractor
|
mVideoTrack mAudioTrack//音视频数据流
｜
mVideoSource mAudioSource//音视频解码器
｜ |
mVideoBuffer mAudioPlayer
说明：
 设置DataSource，数据源可以两种URI和FD。URI可以http://，rtsp://等。FD是一个本地文件描述符，能过FD，可以找到对应的文件。
 由DataSource生成MediaExtractor。通过sp<MediaExtractor> extractor = MediaExtractor::Create(dataSource);来实现。 MediaExtractor::Create(dataSource)会根据不同的数据内容创建不同的数据读取对象。
 通过调用setVideoSource由MediaExtractor分解生成音频数据流（mAudioTrack）和视频数据流（mVideoTrack）。
 onPrepareAsyncEvent()如果DataSource是URL的话，根据地址获取数据，并开始缓冲，直到获取到mVideoTrack和mAudioTrack。mVideoTrack和mAudioTrack通过调用initVideoDecoder()和initAudioDecoder()来生成 mVideoSource和mAudioSource这两个音视频解码器。然后调用postBufferingEvent_l()提交事件开启缓冲。
 数据缓冲的执行函数是onBufferingUpdate()。缓冲区有足够的数据可以播放时，调用play_l()开始播放。play_l()中关键是调用了postVideoEvent_l()，提交了 mVideoEvent。这个事件执行时会调用函数onVideoEvent()。这个函数通过调用 mVideoSource->read(&mVideoBuffer, &options)进行视频解码。音频解码通过mAudioPlayer实现。
 视频解码器解码后通过mVideoSource->read读取一帧帧的数据，放到mVideoBuffer中，最后通过 mVideoRenderer->render(mVideoBuffer)把视频数据发送到显示模块。当需要暂停或停止时，调用cancelPlayerEvents来提交事件用来停止解码，还可以选择是否继续缓冲数据。

5、 代码标记Log
依据第4》项StageFright描述的Vide视频播放流程，作Log标记跟踪视频DATA获取、CODEC过程。从AwesomePlayer.cpp中方法着手，步骤如下：
 在修改的/mydroid/frameworks/base/media/libstagefrigh/下，用mm编译，并调试直到生成相应的.so文件。注：允许单模块编译时，需事先在/mydroid下允许. ./build/envsetup.sh文件。
 在/mydroid/目录下make进行整体编译，生成system.img文件。说明：先单模块编译，后再整体编译的好处是，可以缩短调试编译的时间。
 将system.img文件到/android-sdk-linux/platforms/android-8/下。注意：事先备份原有的system.img。
 带sdcard启动模拟器，在/android-sdk-linux/tools/下运行./adb shell文件，再运行logcat
 打开Gallery选择视频文件运行，并同步查看log。

反馈结果如下：
I/ActivityManager( 61): Starting: Intent { act=android.intent.action.VIEW dat=content://media/external/video/media/5 typ=video/mp4 cmp=com.cooliris.media/.MovieView } from pid 327
I/RenderView( 327): OnPause RenderView com.cooliris.media.RenderView@4054a3b0
E/AwesomePlayer( 34): beginning AwesomePlayer... by jay remarked...
E/AwesomePlayer( 34): returning AwesomeEvent...by jay remarked...
E/AwesomePlayer( 34): returning AwesomeEvent...by jay remarked...
E/AwesomePlayer( 34): returning AwesomeEvent...by jay remarked...
E/AwesomePlayer( 34): returning AwesomeEvent...by jay remarked...
E/AwesomePlayer( 34): ending AwesomePlayer... by jay remarked...
E/AwesomePlayer( 34): setting video source now... by jay remarked...
E/AwesomePlayer( 34): setting Video Type... by jay remarked...
E/AwesomePlayer( 34): returning AwesomeEvent...by jay remarked...
E/AwesomePlayer( 34): beginning initVideoDecoder by jay remarked...
D/MediaPlayer( 327): getMetadata
I/ActivityManager( 61): Displayed com.cooliris.media/.MovieView: +1s761ms
E/AwesomePlayer( 34): beginning AwesomeLocalRenderer init ...by jay remarked...
E/AwesomePlayer( 34): returning open(libstagefrighthw.so) correctly by jay remarked...
E/MemoryHeapBase( 34): error opening /dev/pmem_adsp: No such file or directory
I/SoftwareRenderer( 34): Creating physical memory heap failed, reverting to regular heap.
E/AwesomePlayer( 34): ending AwesomeLocalRenderer init close ...by jay remarked...
E/AwesomePlayer( 34): returning AwesomeLocalRenderer...by jay remarked...
I/CacheService( 327): Starting CacheService

Ⅵ android4.4 stagefright 支持 rtsp吗

1.source：数据源，数据的来源不一定都是本地file，也有可能是网路上的各种协议例如：http、rtsp、HLS等。source的任务就是把数据源抽象出来，为下一个demux模块提供它需要的稳定的数据流。demux不用关信数据到底是从什么地方来的。

2.demux解复用：视频文件一般情况下都是把音视频的ES流交织的通过某种规则放在一起。这种规则就是容器规则。现在有很多不同的容器格式。如ts、mp4、flv、mkv、avi、rmvb等等。demux的功能就是把音视频的ES流从容器中剥离出来，然后分别送到不同的解码器中。其实音频和视频本身就是2个独立的系统。容器把它们包在了一起。但是他们都是独立解码的，所以解码之前，需要把它分别 独立出来。demux就是干这活的，他为下一步decoder解码提供了数据流。

3.decoder解码：解码器--播放器的核心模块。分为音频和视频解码器。影像在录制后, 原始的音视频都是占用大量空间, 而且是冗余度较高的数据. 因此, 通常会在制作的时候就会进行某种压缩 ( 压缩技术就是将数据中的冗余信息去除数据之间的相关性 ). 这就是我们熟知的音视频编码格式, 包括MPEG1（VCD）/ MPEG2（DVD）/ MPEG4 / H.264 等等. 音视频解码器的作用就是把这些压缩了的数据还原成原始的音视频数据. 当然, 编码解码过程基本上都是有损的 .解码器的作用就是把编码后的数据还原成原始数据。

4.output输出：输出部分分为音频和视频输出。解码后的音频（pcm）和视频（yuv）的原始数据需要得到音视频的output模块的支持才能真正的让人的感官系统（眼和耳）辨识到。
所以，播放器大致分成上述4部分。怎么抽象的实现这4大部分、以及找到一种合理的方式将这几部分组织并运动起来。是每个播放器不同的实现方式而已。