Android 实现live555 RTSP代理播放器

简述

利用live555 实现RTSP拉流客户端，但想看下播放效果，所以结合Android MediaPlayer实现播放。
live555 实现RTSP交互及拉流过程，然后通过UDP，将数据传递给MediaPlayer播放。也就是相当于live555作为RTSP播放器的代理端。这种方案在HTTP/HLS协议的播放器上比较常见。
为什么这么做呢？
好处一个是可以自己实现流媒体交互部分，也可以自己控住媒体数据的缓存。
另一个原因就是比较简单啦。毕竟不用解封装、解码、同步、显示这么多步骤。

后面我还是会将其用mediacodec实现，废话不多说，现在先这样看下测试下流媒体交互部分。目标是播放一路节目，如CCTV风云剧场。
当然，我这么做的前提是使用的Android MediaPlayer本身已经扩展了对UDP播放的支持（其实就是用FFmpeg扩展支持的，但FFmpeg RTSP的支持实在不如live555）。

基本框架：

RTSP代理端实现

RTSP代理端实现核心基于live555的测试用例代码testRTSPClient.cpp。

1、JAVA层提供两个接口

package com.example.testplayer;
public class RTSPSource {
	static {
		System.loadLibrary("RTSTSource_jni");

	}
 	public native int start(String url);
 	public native void stop();
}

2、JNI实现

static jint jni_start(JNIEnv* env, jobject obj, jstring filename){
    int ret  = -1;
    const char* url = env->GetStringUTFChars(filename, NULL);
    ret = start(url);
    env->ReleaseStringUTFChars(filename, url);
    return (jint)ret;
}

static void jni_stop(JNIEnv* env, jobject obj){
    stop();   
    return;
}

可以看出没太多东西，主要还是在live555用例修改
3、RTSP交互
基于testRTSPClient.cpp修改：
1）live555 中，所有事件，包括socket的读写事件，延迟事件，触发事件，都在doEventLoop的循环中处理。所以需要将其放在另一个线程中执行，结果通过success变量来获取。主线程中等待1.5秒内RTSP交互完成。
如果流程已经走到continueAfterPLAY中，即说明RTSP交互已经完成，在其中将条件变量返回。

Boolean success = False;
pthread_t gRtspLoopID;
pthread_mutex_t successMutex;
pthread_cond_t successCond;

static void* rtspLoop(void* argv){
    // Begin by setting up our usage environment:
    TaskScheduler* scheduler = BasicTaskScheduler::createNew();
    UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler);

    openURL(*env, "rtspsource", (char* )argv);
    LOGE("--------------------All subsequent activity takes place within the event loop\n");
    eventLoopWatchVariable = 0;
    env->taskScheduler().doEventLoop(&eventLoopWatchVariable);  
    return NULL;
}

int start(const char* url) {
  if (url == NULL) {
    return -1;
  }

  pthread_mutex_init(&successMutex, NULL);
  pthread_cond_init(&successCond, NULL);
  pthread_create(&gRtspLoopID, NULL,rtspLoop,(void*)url);
  pthread_mutex_lock(&successMutex);
  pthread_cond_timeout_np(&successCond, &successMutex, 1500);//1.5s timeout
  pthread_mutex_unlock(&successMutex);

  if(success){
    LOGE("--------------------RTSP START SUCCESS!!!!");
    return 0;  
  }  
  LOGE("--------------------RTSP START FAIL!!!!");
  return -1;
}

void stop() {
    LOGE("--------------------RTSP STOP!!!!");
    eventLoopWatchVariable = 1;
    success = False;
    
    pthread_join(gRtspLoopID,NULL);
    pthread_mutex_destroy(&successMutex);
	pthread_cond_destroy(&successCond);
}


void continueAfterPLAY(RTSPClient* rtspClient, int resultCode, char* resultString) {
    success = False;

  ......省略

    LOGE("Started playing session\n") ;
    success = True;
    
    pthread_mutex_lock(&successMutex);
    pthread_cond_signal(&successCond);
    pthread_mutex_unlock(&successMutex);
  } while (0);
  ......省略

2）DummySink修改，之前在其他文章中说过Sink 接收端， 流的终点， 可理解为是消费者。
每次收取一帧数据，会调用到afterGettingFrame，通过continuePlaying又会处理获取下一帧数据，从而成为一个循环。这两个函数需要自己实现，测试用例的DummySink已经实现好了，但只是将流信息打印出来，在此可以将流媒体数据发送给MediaPlayer，socket可以直接用live555封装好的接口，数据发给127.0.0.1:14321。也可以在此dump流。

这里 writeSocket函数的portNumBits portNum 参数，需要将端口调整为网络字节序，我一直以为是直接传端口号。因为没注意这个细节，当时调了一两个小时也没能播放，通过busybox netstat -apn 命令可以看到端口确实已经正确绑定。之后通过 tcpdump -i lo 命令，打印出回环地址的数据交互，才发现问题。。。
细节真是太重要了。

第二个修改是需要增加心跳发送，这个RTSP协议应该是有这个要求的，但live555的这个测试用例代码没实现，这样播放一会，CDN可能会将流断开（我测试的时候会这样）。心跳通过option和GetParameter都是可以的，这里是一分钟发一次。

void DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes,
				  struct timeval presentationTime, unsigned /*durationInMicroseconds*/) { 
#ifdef DEBUG_DUMP_TS
    if(mDumpFile) fwrite(fReceiveBuffer, frameSize, 1, mDumpFile);
#endif
#ifdef SOCKET_SEND
    if(mOutsock < 0){
        const Port port(11234);
        mOutsock = setupDatagramSocket(envir(),  port);
        if(mOutsock < 0) 
        { 
            envir() << "socket error\n";
        } 
    }
    
    struct in_addr sessionAddress;
    sessionAddress.s_addr = our_inet_addr("127.0.0.1");
    portNumBits portNum = htons(14321);
    writeSocket(envir(), mOutsock, sessionAddress, portNum, (unsigned char *)fReceiveBuffer, frameSize);
#endif
    gettimeofday(&presentationTime, NULL);
    if((int64_t)presentationTime.tv_sec - lastHartbitTime > 60){
        RTSPClient* rtspClient = (RTSPClient*)(fSubsession.miscPtr);
        StreamClientState& scs = ((ourRTSPClient*)rtspClient)->scs;  // alias
        rtspClient->sendGetParameterCommand(*scs.session, NULL,"");
        LOGE("sendGetParameterCommand\n");
        lastHartbitTime = (int64_t)presentationTime.tv_sec;
    }

  // Then continue, to request the next frame of data:
  continuePlaying();
}

3）第三个修改是我用来测试播放的这路节目RTSP的交互协议和标准协议有些扩展，这个就需要在RTSPClient里修改了，具体修改就不贴出来了。一般的RTSP live555不用修改就能支持。

MediaPlayer播放RTSP代理数据

这个如果MediaPlayer已经支持UDP播放，那就没什么了，像平常调用即可。
上面RTSP代理是将数据发给127.0.0.1:14321，如果是基于FFmpeg扩展的，那么在播放地址带上localport参数即可绑定端口。
看下FFmpeg UDP协议的open函数。

static int udp_open(URLContext *h, const char *uri, int flags)
  ......省略
        if (av_find_info_tag(buf, sizeof(buf), "udplite_coverage", p)) {
            s->udplite_coverage = strtol(buf, NULL, 10);
        }
        if (av_find_info_tag(buf, sizeof(buf), "localport", p)) {
            s->local_port = strtol(buf, NULL, 10);
        }

MediaPlayer播放简单示例如下：

public class ProxyPlayer implements OnPreparedListener{
......省略
	private MediaPlayer mPlayer;
	private RTSPSource mRTSP;
	public void setDataSource(String url){
		Log.e(TAG,"setDataSource  " + url);
		mRTSPUrl = url;
		try {
			mPlayer.setDataSource("udp://127.0.0.1:11234?localport=14321");
		} catch (Exception e) {			
			e.printStackTrace();
		}					
	}
	
	public void start(){
		int ret = mRTSP.start(mRTSPUrl);
		if(ret != 0){
			Log.e(TAG,"RTSP Start ERROR!!!");
			return;
		}
		mPlayer.prepareAsync();
	}	
......省略
}

总结

总体来说比较简单，主要在于live555的RTSP交互扩展支持及测试用例代码testRTSPClient.cpp测试用例代码的修改，还要就是一些JNI的实现工作。MediaPlayer部分比较简单，当然这前提是MediaPlayer对UDP的扩展支持之前已经实现了。
这个做法可以用来帮助我们调试流媒体协议，包括RTSP/HLS都可以这么干。其实很多HLS播放器APK，都采用代理的方式实现，因为这样可以很方便的嵌入我们自己的协议交互实现。

最后播放出一路CCTV节目，效果如下：

CPU和内存占用也正常。