Android4.2.2的Stagefright维护编解码器的数据流
这里是他们自己的源代码阅读点滴总结属性,转请注明出处,谢谢。
欢迎和大家分享。qq:1037701636 email:gzzaigcn2012@gmail.com
Android源代码版本号Version:4.2.2; 硬件平台 全志A31
前沿:
在前面的博文中,基本提到的是stagefright相关的控制流,详细分析了android架构中的MediaExtractor、AwesomePlayer、StagefrightPlayer、OMXCodec等的创建。底层OMXNodinstance实例的创建。
分析了OMX最底层插件库、编解码器组件的架构以及怎样创建属于我们自己的OMX Plugin。
分析源代码架构的还有一个关键是数据流的分析,从这里開始。我们将对stagefright中的编解码缓存区进行分析:
1.
回到OMXCodec的创建过程的源代码:
status_t AwesomePlayer::initVideoDecoder(uint32_t flags) {
.......
mVideoSource = OMXCodec::Create(
mClient.interface(), mVideoTrack->getFormat(),//提取视频流的格式, mClient:BpOMX;mVideoTrack->getFormat()
false, // createEncoder,不创建编码器false
mVideoTrack,
NULL, flags, USE_SURFACE_ALLOC ? mNativeWindow : NULL);//创建一个解码器mVideoSource if (mVideoSource != NULL) {
int64_t durationUs;
if (mVideoTrack->getFormat()->findInt64(kKeyDuration, &durationUs)) {
Mutex::Autolock autoLock(mMiscStateLock);
if (mDurationUs < 0 || durationUs > mDurationUs) {
mDurationUs = durationUs;
}
} status_t err = mVideoSource->start();//启动解码器OMXCodec。完毕解码器的init初始化操作
.............
}
在Android4.2.2下Stagefright多媒体架构中的A31的OMX插件和Codec组件博文我们对于OMXCodec::create已经做了具体的分析。这里来关注mVideoSource->start的相关功能,即OMXCodec::start的处理:
status_t OMXCodec::start(MetaData *meta) {
Mutex::Autolock autoLock(mLock);
........
return init();//进行初始化操作
}
这里调用init()的过程。将会进行buffer的申请操作。为兴许的流操作打下基础:
status_t OMXCodec::init() {
// mLock is held.
.........
err = allocateBuffers();//缓存区的分配
if (err != (status_t)OK) {
return err;
} if (mQuirks & kRequiresLoadedToIdleAfterAllocation) {
err = mOMX->sendCommand(mNode, OMX_CommandStateSet, OMX_StateIdle);
CHECK_EQ(err, (status_t)OK); setState(LOADED_TO_IDLE);
}
............
}
我们来看allocateBuffers的实现
2.关注allocateBuffersOnPort的实现
status_t OMXCodec::allocateBuffers() {
status_t err = allocateBuffersOnPort(kPortIndexInput);//输入缓存input口分配 if (err != OK) {
return err;
} return allocateBuffersOnPort(kPortIndexOutput);//输出缓存input口分配
}
这里分别将对输入和输出口进行Buffer的申请与分配。对于解码器,须要输入口来存储待解码的数据源,须要将解码后的数据源存储到输出口,而这也符合硬件的实现逻辑。
以输入缓存区分配为例展开分析:
status_t OMXCodec::allocateBuffersOnPort(OMX_U32 portIndex) {
.......
OMX_PARAM_PORTDEFINITIONTYPE def;
InitOMXParams(&def);
def.nPortIndex = portIndex;//输入口 err = mOMX->getParameter(
mNode, OMX_IndexParamPortDefinition, &def, sizeof(def));//获取输入口參数到def
..........
err = mOMX->allocateBuffer(
mNode, portIndex, def.nBufferSize, &buffer,
&info.mData);
........
info.mBuffer = buffer;//获取相应的buffer_id。有保存有底层的buffer的相关信息
info.mStatus = OWNED_BY_US;
info.mMem = mem;
info.mMediaBuffer = NULL;
...........
mPortBuffers[portIndex].push(info);//把当前的buffer恢复到mPortBuffers[2]中去
上述过程主要分为:
step1:先是获取底层解码器组件的当前的參数熟悉,一般这些參数都在建立OMX_Codec时完毕的初始配置,前一博文中已经提到过。
step2:进行allocateBuffer的处理,这个函数的调用终于交给底层的OMX组件来完毕,相关的实现将集成到A31的底层OMX编解码组件的处理流中进行分析。
step3:完毕对分配好的buffer信息info。维护在mPortBuffers[0]这个port中。
上述过程完毕了输入与输出的Buffer分配。为兴许解码操作buffer打下了基础。
3.mediaplay启动播放器
通过start的API调用。进入MediaplayerService::Client,再依次经过stagefrightplayer,AwesomePlayer。
触发play的videoevent的发生.
void AwesomePlayer::postVideoEvent_l(int64_t delayUs) {
ATRACE_CALL(); if (mVideoEventPending) {
return;
} mVideoEventPending = true;
mQueue.postEventWithDelay(mVideoEvent, delayUs < 0 ? 10000 : delayUs);
}
依据前一博文的分析可知,该事件相应的处理函数为AwesomePlayer::onVideoEvent(),该部分代码量较大。提取核心内容read的处理进行分析:
status_t err = mVideoSource->read(&mVideoBuffer, &options);//循环读数据实际的OMX_CODEC::read,读取到mVideoBuffer
read的核心是获取能够用于render的视频数据,这表明了read函数主要完毕了从视频源读取元数据,并调用解码器完毕解码生成可送显的数据。
4. read函数的实现
能够想象read函数的应该是一个比較复杂的过程。我们从OMX_Codec的read函数入手来分析:
status_t OMXCodec::read(
MediaBuffer **buffer, const ReadOptions *options) {
status_t err = OK;
*buffer = NULL; Mutex::Autolock autoLock(mLock); drainInputBuffers();//buffer,填充数据源 if (mState == EXECUTING) {
// Otherwise mState == RECONFIGURING and this code will trigger
// after the output port is reenabled.
fillOutputBuffers();
}
} ...........
}
read的核心逻辑总结为drainInputBuffers()和fillOutputBuffers(),我们对其依次进行深入的分析
5. drainInputBuffers()读取待解码的视频数据源到解码器的Inport
这里贴出其较为复杂的处理过程代码。主要分为下面3个部分进行分析:
(1)
bool OMXCodec::drainInputBuffer(BufferInfo *info) {if (mCodecSpecificDataIndex < mCodecSpecificData.size()) {
CHECK(!(mFlags & kUseSecureInputBuffers)); const CodecSpecificData *specific =
mCodecSpecificData[mCodecSpecificDataIndex]; size_t size = specific->mSize; if (!strcasecmp(MEDIA_MIMETYPE_VIDEO_AVC, mMIME)
&& !(mQuirks & kWantsNALFragments)) {
static const uint8_t kNALStartCode[4] =
{ 0x00, 0x00, 0x00, 0x01 }; CHECK(info->mSize >= specific->mSize + 4); size += 4; memcpy(info->mData, kNALStartCode, 4);
memcpy((uint8_t *)info->mData + 4,
specific->mData, specific->mSize);
} else {
CHECK(info->mSize >= specific->mSize);
memcpy(info->mData, specific->mData, specific->mSize);//copy前面的数据字段
} mNoMoreOutputData = false; CODEC_LOGV("calling emptyBuffer with codec specific data"); status_t err = mOMX->emptyBuffer(
mNode, info->mBuffer, 0, size,
OMX_BUFFERFLAG_ENDOFFRAME | OMX_BUFFERFLAG_CODECCONFIG,
0);//处理buffer
CHECK_EQ(err, (status_t)OK); info->mStatus = OWNED_BY_COMPONENT; ++mCodecSpecificDataIndex;
return true;
}...............(1)
这部分的内容主要是提取一部分解码器字段,填充到info->mData的存储空间中去。这部分主要基于视频源的格式,如mp4等在创建OXMCodec病configureCodec时就完毕了这个mCodecSpecificData字段的加入,应该些解码须要的特殊字段吧。
是否须要要看其视频源的格式。获取完这个字段信息后就是正式读取视频源的数据了。
(2)
for (;;) {
MediaBuffer *srcBuffer;
if (mSeekTimeUs >= 0) {
if (mLeftOverBuffer) {
mLeftOverBuffer->release();
mLeftOverBuffer = NULL;
} MediaSource::ReadOptions options;
options.setSeekTo(mSeekTimeUs, mSeekMode); mSeekTimeUs = -1;
mSeekMode = ReadOptions::SEEK_CLOSEST_SYNC;
mBufferFilled.signal(); err = mSource->read(&srcBuffer, &options);//读取视频源中的真实数据这里是MPEG4Source的read if (err == OK) {
int64_t targetTimeUs;
if (srcBuffer->meta_data()->findInt64(
kKeyTargetTime, &targetTimeUs)
&& targetTimeUs >= 0) {
CODEC_LOGV("targetTimeUs = %lld us", targetTimeUs);
mTargetTimeUs = targetTimeUs;
} else {
mTargetTimeUs = -1;
}
}
} else if (mLeftOverBuffer) {
srcBuffer = mLeftOverBuffer;
mLeftOverBuffer = NULL; err = OK;
} else {
err = mSource->read(&srcBuffer);
} if (err != OK) {
signalEOS = true;
mFinalStatus = err;
mSignalledEOS = true;
mBufferFilled.signal();
break;
} if (mFlags & kUseSecureInputBuffers) {
info = findInputBufferByDataPointer(srcBuffer->data());
CHECK(info != NULL);
} size_t remainingBytes = info->mSize - offset;//buffer中剩余的能够存储视频数据的空间 if (srcBuffer->range_length() > remainingBytes) {//当前读取的数据已经达到解码的数据量
if (offset == 0) {
CODEC_LOGE(
"Codec's input buffers are too small to accomodate "
"buffer read from source (info->mSize = %d, srcLength = %d)",
info->mSize, srcBuffer->range_length()); srcBuffer->release();
srcBuffer = NULL; setState(ERROR);
return false;
} mLeftOverBuffer = srcBuffer;//把没读取的buffer记录下来
break;
} bool releaseBuffer = true;
if (mFlags & kStoreMetaDataInVideoBuffers) {
releaseBuffer = false;
info->mMediaBuffer = srcBuffer;
} if (mFlags & kUseSecureInputBuffers) {
// Data in "info" is already provided at this time. releaseBuffer = false; CHECK(info->mMediaBuffer == NULL);
info->mMediaBuffer = srcBuffer;
} else {
CHECK(srcBuffer->data() != NULL) ;
memcpy((uint8_t *)info->mData + offset,
(const uint8_t *)srcBuffer->data()
+ srcBuffer->range_offset(),
srcBuffer->range_length());//copy数据源数据到输入缓存,数据容量srcBuffer->range_length()
} int64_t lastBufferTimeUs;
CHECK(srcBuffer->meta_data()->findInt64(kKeyTime, &lastBufferTimeUs));
CHECK(lastBufferTimeUs >= 0);
if (mIsEncoder && mIsVideo) {
mDecodingTimeList.push_back(lastBufferTimeUs);
} if (offset == 0) {
timestampUs = lastBufferTimeUs;
} offset += srcBuffer->range_length();//添加偏移量 if (!strcasecmp(MEDIA_MIMETYPE_AUDIO_VORBIS, mMIME)) {
CHECK(!(mQuirks & kSupportsMultipleFramesPerInputBuffer));
CHECK_GE(info->mSize, offset + sizeof(int32_t)); int32_t numPageSamples;
if (!srcBuffer->meta_data()->findInt32(
kKeyValidSamples, &numPageSamples)) {
numPageSamples = -1;
} memcpy((uint8_t *)info->mData + offset,
&numPageSamples,
sizeof(numPageSamples)); offset += sizeof(numPageSamples);
} if (releaseBuffer) {
srcBuffer->release();
srcBuffer = NULL;
} ++n; if (!(mQuirks & kSupportsMultipleFramesPerInputBuffer)) {
break;
} int64_t coalescedDurationUs = lastBufferTimeUs - timestampUs; if (coalescedDurationUs > 250000ll) {
// Don't coalesce more than 250ms worth of encoded data at once.
break;
}
}...........
该部分是提取视频源数据的关键,主要通过 err = mSource->read(&srcBuffer, &options)来完毕,mSource是在创建编解码器传入的,实际是一个相应于视频源格式的一个解析器MediaExtractor。比方在建立MP4的解析器MPEG4Extractor,通过新建一个new MPEG4Source。故终于这里调用的是MPEG4Source的read成员函数,事实上际也维护着整个待解码的原始视频流。
我们能够看大在read函数后。会将待解码的数据流以for循环依次读入究竟层的buffer空间中。仅仅有当满足当前读取的原始数据片段比底层的input口的buffer剩余空间小srcBuffer->range_length() > remainingBytes。那就能够继续读取,否则直接break后,去进行下一步操作。
或者假设一次待解码的数据时张是大于250ms也直接跳出。
这处理体现了处理的高效性。
终于视频原始数据存储在info->mData的底层输入空间中。
(3)
err = mOMX->emptyBuffer(
mNode, info->mBuffer, 0, offset,
flags, timestampUs);
触发底层的解码器组件进行处理。这部分留在兴许对A31的底层编解码API操作时进行分析。
6.fillOutputBuffers对输出buffer口的填充,即实现解码过程:
void OMXCodec::fillOutputBuffers() {
CHECK_EQ((int)mState, (int)EXECUTING);
...........
Vector<BufferInfo> *buffers = &mPortBuffers[kPortIndexOutput];输出port
for (size_t i = 0; i < buffers->size(); ++i) {
BufferInfo *info = &buffers->editItemAt(i);
if (info->mStatus == OWNED_BY_US) {
fillOutputBuffer(&buffers->editItemAt(i));
}
}
}
void OMXCodec::fillOutputBuffer(BufferInfo *info) {
CHECK_EQ((int)info->mStatus, (int)OWNED_BY_US); if (mNoMoreOutputData) {
CODEC_LOGV("There is no more output data available, not "
"calling fillOutputBuffer");
return;
} CODEC_LOGV("Calling fillBuffer on buffer %p", info->mBuffer);
status_t err = mOMX->fillBuffer(mNode, info->mBuffer); if (err != OK) {
CODEC_LOGE("fillBuffer failed w/ error 0x%08x", err); setState(ERROR);
return;
} info->mStatus = OWNED_BY_COMPONENT;
}
从上面的代码看来,fillOutputBuffer的实现比drainInputBuffers简单了非常多。
但同样的是。两者终于都讲控制权交给底层的解码器来完毕。
7.等待解码数据被fill到outbuffer中,OMXCodecObserver完毕回调处理
等待解码完毕的这部分内容在read函数中通过下面函数来实现:
while (mState != ERROR && !mNoMoreOutputData && mFilledBuffers.empty()) {
if ((err = waitForBufferFilled_l()) != OK) {//进入等待buffer被填充
return err;
}
}
上述表明,仅仅要mFilledBuffers为空则进入等待填充pthread_cond_timedwait。而这个线程被唤醒是通过底层的组件回调来完毕的。回调函数的注冊哎底层编解码器Node完毕的。实际终于的回调是交给OMXCodecObserver来完毕的:
struct OMXCodecObserver : public BnOMXObserver {
OMXCodecObserver() {
} void setCodec(const sp<OMXCodec> &target) {
mTarget = target;
} // from IOMXObserver
virtual void onMessage(const omx_message &msg) {
sp<OMXCodec> codec = mTarget.promote(); if (codec.get() != NULL) {
Mutex::Autolock autoLock(codec->mLock);
codec->on_message(msg);//OMX_Codec的on_message处理
codec.clear();
}
}
终于能够看到是由OMX_Codec->on_message来进行消息的处理。这部分的内容主要包含EMPTY_BUFFER_DONE和FILL_BUFFER_DONE两个message处理。对FILL_BUFFER_DONE完毕后的消息回调进行分析:
void OMXCodec::on_message(const omx_message &msg) {
if (mState == ERROR) {
/*
* only drop EVENT messages, EBD and FBD are still
* processed for bookkeeping purposes
*/
if (msg.type == omx_message::EVENT) {
ALOGW("Dropping OMX EVENT message - we're in ERROR state.");
return;
}
} switch (msg.type) { case omx_message::FILL_BUFFER_DONE://底层回调callback告知当前 ..............
mFilledBuffers.push_back(i);//当前的输出buffer信息维护在mFilledBuffers
mBufferFilled.signal();//发出信息用于渲染
能够看到这里对read线程进行了唤醒。
8.提取一个可用的解码后的数据帧
size_t index = *mFilledBuffers.begin();
mFilledBuffers.erase(mFilledBuffers.begin()); BufferInfo *info = &mPortBuffers[kPortIndexOutput].editItemAt(index);//从获取解码后的视频源
CHECK_EQ((int)info->mStatus, (int)OWNED_BY_US);
info->mStatus = OWNED_BY_CLIENT; info->mMediaBuffer->add_ref();//
if (mSkipCutBuffer != NULL) {
mSkipCutBuffer->submit(info->mMediaBuffer);
}
*buffer = info->mMediaBuffer;
获得了线程唤醒后的buffer,从这里获取到输出port相应的Bufferinfo。作为终于的BufferInfo信息返回给read函数
9
经过5、6、7、8的处理过程。read终于返回可用于显示的mVideoBuffer,接下去就是怎样送显的过程了。
能够看到以下的代码。将会创建一个渲染器mVideoRenderer来完毕这个解码后视频源的显示:
if ((mNativeWindow != NULL)
&& (mVideoRendererIsPreview || mVideoRenderer == NULL)) {//首次创建渲染器
mVideoRendererIsPreview = false; initRenderer_l();//初始化渲染器。新建一个AwesomeLocalRenderer
} if (mVideoRenderer != NULL) {
mSinceLastDropped++;
mVideoRenderer->render(mVideoBuffer);//启动渲染。即显示当前buffer
if (!mVideoRenderingStarted) {
mVideoRenderingStarted = true;
notifyListener_l(MEDIA_INFO, MEDIA_INFO_RENDERING_START);
} }
void AwesomePlayer::initRenderer_l() {
ATRACE_CALL(); if (mNativeWindow == NULL) {
return;
} sp<MetaData> meta = mVideoSource->getFormat(); int32_t format;
const char *component;
int32_t decodedWidth, decodedHeight;
CHECK(meta->findInt32(kKeyColorFormat, &format));
CHECK(meta->findCString(kKeyDecoderComponent, &component));
CHECK(meta->findInt32(kKeyWidth, &decodedWidth));
CHECK(meta->findInt32(kKeyHeight, &decodedHeight)); int32_t rotationDegrees;
if (!mVideoTrack->getFormat()->findInt32(
kKeyRotation, &rotationDegrees)) {
rotationDegrees = 0;
} mVideoRenderer.clear(); // Must ensure that mVideoRenderer's destructor is actually executed
// before creating a new one.
IPCThreadState::self()->flushCommands(); // Even if set scaling mode fails, we will continue anyway
setVideoScalingMode_l(mVideoScalingMode);
if (USE_SURFACE_ALLOC
&& !strncmp(component, "OMX.", 4)
&& strncmp(component, "OMX.google.", 11)
&& strcmp(component, "OMX.Nvidia.mpeg2v.decode")) {//使用硬件渲染器。除去上述的解码器
// Hardware decoders avoid the CPU color conversion by decoding
// directly to ANativeBuffers, so we must use a renderer that
// just pushes those buffers to the ANativeWindow.
mVideoRenderer =
new AwesomeNativeWindowRenderer(mNativeWindow, rotationDegrees);//通常是使用硬件渲染机制
} else {
// Other decoders are instantiated locally and as a consequence
// allocate their buffers in local address space. This renderer
// then performs a color conversion and copy to get the data
// into the ANativeBuffer.
mVideoRenderer = new AwesomeLocalRenderer(mNativeWindow, meta);
}
}
能够看到这里有2个渲染器的创建分支,OMX和OMX.google说明底层的解码器用的是软解码。那么他渲染器也使用所谓的本地渲染器实际是软渲染器。故这里我们使用的是AwesomeNativeWindowRenderer渲染器,其结构例如以下所述:
struct AwesomeNativeWindowRenderer : public AwesomeRenderer {
AwesomeNativeWindowRenderer(
const sp<ANativeWindow> &nativeWindow,
int32_t rotationDegrees)
: mNativeWindow(nativeWindow) {
applyRotation(rotationDegrees);
} virtual void render(MediaBuffer *buffer) {
ATRACE_CALL();
int64_t timeUs;
CHECK(buffer->meta_data()->findInt64(kKeyTime, &timeUs));
native_window_set_buffers_timestamp(mNativeWindow.get(), timeUs * 1000);
status_t err = mNativeWindow->queueBuffer(
mNativeWindow.get(), buffer->graphicBuffer().get(), -1);//直接使用queuebuffer进行渲染显示
if (err != 0) {
ALOGE("queueBuffer failed with error %s (%d)", strerror(-err),
-err);
return;
} sp<MetaData> metaData = buffer->meta_data();
metaData->setInt32(kKeyRendered, 1);
}
不是非常复杂,仅仅是实现了AwesomeRenderer渲染接口render。终于调用这个函数来实现对buffer的显示。这里看到非常熟悉的queueBuffer,大家能够回看我的博文Android4.2.2 SurfaceFlinger之图形渲染queueBuffer实现和VSYNC的存在感,这是通过应用程序的本地窗体mNativeWindow(由于播放器videoview继承了sufaceview,surfaceview类会创建一个本地的surface,其继承了本地窗体类)将当前buffer提交给SurfaceFlinger服务进行显示。具体内容不在展开。
至此我们完毕了stagefright下的编解码的数据流的相关操作,程序上复杂主要体如今emptybuffer和fillbuffer为主。
当然由于能力有限。在非常多细节上也没有进行非常具体的分析。也希望大家多交流。多学习。
版权声明:本文博主原创文章。博客,未经同意不得转载。
Android4.2.2的Stagefright维护编解码器的数据流的更多相关文章
- Android4.2.2下Stagefright下OMX编解码器组件的控制流
本文均属自己阅读源代码的点滴总结.转账请注明出处谢谢. 欢迎和大家交流. qq:1037701636 email:gzzaigcn2012@gmail.com Android源代码版本号Version ...
- StageFright框架流程解读
1. StageFright介绍 Android froyo版本号多媒体引擎做了变动,新加入�了stagefright框架,而且默认情况android选择stagefright,并没有全 ...
- 三种框架对比react vue 和Angular对比
https://blog.csdn.net/runOnWay/article/details/80103880 angular 优点 背靠谷歌 使用typescript 便于后端人员开发上手 完整 不 ...
- Android多媒体开发-stagefright及AwesomePlayer相关知识梳理
android的多媒体框架中, stagefright其实是AwesomePlayer的代理,就是个皮包公司. status_t StagefrightPlayer::setDataSource( c ...
- android媒体--stagefright概述【一】
近期杂七杂八的忙碌着,前几天看了下这部分主要是stagefright模块的,所以更改下名字 做了挺长时间的android平台的媒体开发,对之前的分析进行一个阶段性的总结. 一.android结构图(上 ...
- Ubuntu12.04下载Android4.0.1源码全过程,附若干问题解决[转]
学校里一直在做应用层开发,考虑到日后就业问题,这次决定研究源码和驱动,并进行编译.没想到就下载源码这一步折腾了我整整两天,期间遇到很多问题,哎,记录于此,希望日后再下源码的人不要再走无谓的弯路了.事实 ...
- Android4.0图库Gallery2代码分析(二) 数据管理和数据加载
Android4.0图库Gallery2代码分析(二) 数据管理和数据加载 2012-09-07 11:19 8152人阅读 评论(12) 收藏 举报 代码分析android相册优化工作 Androi ...
- Android4种网络连接方式HttpClient、HttpURLConnection、OKHttp和Volley优缺点和性能对比
比较的指标: 1.cpu 2.流量 3.电量 4.内存占用 5.联网时间 功能点: 1.重试机制 2.提供的扩展功能 3.易用性 4.是否https 5.是否支持reflect api,OkHttp有 ...
- 【Netty】(9)---Netty编解码器
Netty编解码器 在了解Netty编解码之前,先了解Java的编解码: 编码(Encode)称为序列化, 它将对象序列化为字节数组,用于网络传输.数据持久化或者其它用途. 解码(Decode)称为反 ...
随机推荐
- codility上的练习(3)
今天发现又出了lesson 3... 不过题目都很简单…… (1) Min-avg-slice 给定一个长度为n的整数数组,找到一个连续的子数组,数组元素的平均值最小. 数据范围N [1..10^5] ...
- windows Oracle DBases auto backUp
- 高龄“潮男”优衣库老板柳井正_榜样_奢华主义_YOKA时尚网
高龄"潮男"优衣库老板柳井正_榜样_奢华主义_YOKA时尚网 高龄"潮男"优衣库老板柳井正
- wait函数返回值总结,孤儿进程与僵尸进程[总结]
http://blog.csdn.net/astrotycoon/article/details/41172389 wait函数返回值总结 http://www.cnblogs.com/Anker/p ...
- Linux(gnu)环境动态链接库的搜索路径
摘自http://blog.csdn.net/saga1979/article/details/14161229 man ld.so(8)说,如果库依赖不包括“/”,那么它将按照下面的规则按顺序搜索: ...
- http://www.lanceyan.com/tech/mongodb/mongodb_repset1.html
http://www.lanceyan.com/tech/mongodb/mongodb_repset1.html
- EMCA创建em资料库时报错
说明:监听程序配置及启动正常.实例运行正常,远程或是本地sqlplus连接实例也正常.主机名显示正常,与主机名相关三个配置文件也没问题. emca报错: [oracle@rusky-oracle11g ...
- Silverlight学习(三)
最近对WCFRIA+MVVM+Prism有了初步的认识,能够简单的实现一些数据库的交互.这节主要讲的是Silverlight通过domainservice和ado.net实体数据模型与数据库的交互.本 ...
- win10系统安装 VS 2015 安装包下载
这个VS2015安装包 我找了好久才找到 能在WIN 10系统下安装 下面分享链接地址给大家: http://www.ithome.com/html/win10/215213.htm
- An error has occurred,See error log for more details
解决Eclipse3.2配合MyEclipse5.0M2使用时打开JSP发生“An error has occurred,See error log for more details”错误的解决方法 ...