基于Android平台的WiFi_displaysink端的设计与实现

　　摘要：基于Android 4.2的WiFidirect功能实现WiFidisplay 的sink端系统，sink端通过与source端进行capatibility negotiation确定两者能共同支持的最高解码音视频格式。基于这套格式，sink端接收source端传递的流媒体数据并进行TS package提取，解复用（demux）和decoding，最终送入player进行实时播放。由于WiFidisplay最核心的要点是实现source端的界面在sink端的实时显示，因此在传输协议上选用实时性较好的RTP协议进行传输。
中国论文网 http://www.xzbu.com/8/view-4405962.htm
　　关键词：安卓；WiFidisplay；RTP实时传输
　　中图分类号：TP319 文献标识码：A 文章编号：16727800（2013）009010403
　　作者简介：陈子安（1987-），男，中国科学技术大学软件学院硕士研究生，研究方向为音视频编解码、嵌入式Android系统。
　　1WiFidisplay sink端基本架构
　　1.1WiFidisplay概述
　　WiFidisplay技术，是基于WiFi direct实现用户设备之间实时共享资源（图片、视频、音乐等）的技术。这种共享无需任何硬件连接（HDMI线），即可通过WiFi实时显示在电视、投影等大屏幕上。
　　从技术层面来看，WiFidisplay平台的应用主要是通过一个发送端（即Source，可以传送多媒体内容的WiFi终端，例如智能手机或平板电脑）和一个接收端（即Sink，可以接收并显示多媒体内容的WiFi设备，例如平板电视或投影机产品），建立一个点对点的连接，从而将手机拍摄的照片、影片或是网络上的高清视频内容完整地播放在拥有大屏幕的电视上；相反地，用户也可以通过手机或平板，直接观看电视或电脑屏幕上的内容^[1] 。
　　由图1所示，android4.2在framework层通过wifip2p Manager提供了对wifidirect的支持。WFDSink是java层的实现，通过调用WifiP2pManager并在WifiP2pManager中加入detect 具有流媒体传输能力的source的功能，完成source端和sink端wifi连接的建立^[2] 。WFDRTSPClient通过实现RTSP协议完成与source端的session建立。Session是一个基于RTP的会话，主要完成source端和sink端的能力交互，检测各自允许支持的最高音频传输格式和视频传输格式，并确认source端和sink端均支持HDCP协议（Highbandwidth Digitalcontent Copy Protection）。
　　source端通过建立的session将实时流媒体（或抓取的界面）以TS流的方式（transport stream）传送到sink端，sink端的WfdRealtime player 对传送的TS流先进行demux处理（为了提高传输过程的带宽利用率，音视频的传输都会在发送端先进行编码复用，因此接收端需要解复用），然后分别送到AV decoder里面进行解码，最后通过渲染并送入android的HWC Surface Flinger和Audio Flinger里呈现出来。
　　2WiFidisplay sink 端具体实现
　　Sink端系统主要分为WFDClient、Wifidirect_service、Wfdsession、WFDAVmanager、wfdrtspclient几个模块。
　　WFDClient 负责与Service端进行交互，查询WiFi display的状态，发送建立Session，连接Source的指令以及与用户的信息交互。
　　Wifidirect_service主要用于建立于Source端的wifi_direct连接，实现物理层的通信。Wfdsession将会在WiFidirect建立并完成Capatibility Negotiation之后建立流媒体传输的Session，建立Session的过程需要WFDrtspclient与Source端的rtsp通信。
　　WFDAVmanager与Android的Surfaceflinger和Audioflinger直接talk，实现WFD udp的数据接收，TS流解析，AV decoder以及AV renderer。
　　整个sink端的系统流程如图2所示。
　　2.1RTP/RTSP流传输协议实现
　　本文选用开源框架live555作为RTP/RTSP协议的实现框架。但由于live555不能观看实时采集的视频，不支持子目录的播放，因此在live555框架的基础上增加了live source、H264LiveStreamParser和H264VideoLiveMediaServerSubsession3个模块，如图3所示。
　　LiveSouree是实现doGetNextFrame接口的实时视频流的Source。由图3所示，LiveSouree继承了MediaSouree的功能，同时doGetNextFrame是MediaSource的纯虚函数，它允许其他的模块通过这个接口得到帧。
　　H264Videosink要求H264LivestreamParser通过MediaSource的接口每隔一段固定的时间段就传递数据给它。H264Livestreamparser是Livesouree的helper模块，它实现了doGetNextFrame，并且在doGetNextFrame的功能被其他模块调用时获得数据，比如RTPSink。H264 Livestream Parser为了达到与source行为一起工作的目的，还实现其他的细节处理功能。 　　H264VideoLiveMediaServerSubsession是一个用于管理Souree和Sink的类。
　　当一个用户连接到Media服务端时，H264 VideoLiveMediaServerSubsession对象被创建，直到连接断开才消失，当用户要从一个指定时间开始播放时，可以调用Seekstreamsource方法定位到指定的帧。H264 VideoLiveMediaServerSunsession创建的时候要创建LiveSource作为视频源。
　　2.2Demux （解复用）实现
　　Android并不支持对于MPEG TS流（MPEG定义的实时流传输标准）的复用和解复用功能^[3] 。而根据MPEG TS的协议要求，TS流的Media Data传输都是以复用后的Packet形式存在。因此在实现Sink端的时候，必须对Source端传输过来的TS Packet进行Demux（解复用）。
　　解复用的实现方法是遵循MPEG TS协议的包格式进行字段解析。TS流信息都是二进制编码，可根据标准中定义的包格式中各标识符字段的含义提取节目表（PAT表、PMT表），从而解析出各节目对应的音视频流。
　　Demux实现的基本流程是：先接收一个负载为PAT（Program Association Table）的数据包，在整个数据包里找到一个PMT包的ID。然后再接收一个含有PMT的数据包，在这个数据包里找到有关填入数据类型的ID^[4] 。之后就在接收到的TS包里找含有这个ID的负载内容，这个内容就是填入的信息。得到了PMT表的信息，就可以区分出TS Packet中的每一段数据分别属于哪一个节目的哪一路视频或者音频，这样就可以根据这些节目的信息分别将同属于一路节目的视频和音频送入对应的Decoder进行解码。
　　2.3AV decoder
　　AV decode 将实现对上述支持的音视频格式的解码。由于Android自带的Open Core不能支持上述的所有音视频格式的解码，需要自己编写Video Decoder和Audio Decoder。
　　Audio Decoder主要完成Audio的解码工作，包括与Audiotrack，Audioflinger的交互，Audio Decoder需要根据被解码的音频文件的格式、比特率，以及Audio Track的Buffer、Demux向Audio Decoder传送数据的速度等等一系列参数确定可用的最小Buffer Size。Audio Flinger向上对Audio Decoder提供调用接口，向下通过与Driver通信控制相应硬件，对于不同的格式，应该采取硬件解码还是软件解码，通过Audio Flinger获取硬件参数后如何确定解码算法，以及他们之间的Pipline交互，都是需要实现的部分。
　　Audio Decoder 首先获得编码的音频数据流，然后以帧为单位解码每一帧数据，这里需要根据对应音频的帧格式实现对应的变换算法，完成频谱包络解码，同时进行比特分配对尾数进行反量化处理，然后对频谱包络解码进行指数变换并和反量化后的信号合成滤波器组进行滤波，采样恢复，得到PCM数据^[5] 。再将PCM数据划分声道，并做均衡、划分音量等级等等一系列处理，然后调用Player播放。在播放过程中要完成与Player的交互，包括每一路音频的速率控制、暂停、快进、快退、回放等操作Decoder的相应处理。
　　Video Decoder 跟Audio Decoder的流程大致类似，不同的是Video Deocder除了需要与Player交互实现Video的播放各种功能以外，还需要与Graphics交互实现画面的呈现，WiFidisplay需要播放实时流，它是一个界面的完整展现^[6] 。Source端的界面抓取后传输过来，经过Video Decoder解码数据之后要送入图形图像处理模块进行显示，Video Decode需要根据图像输出的分辨率、刷新率等实时地调整送入Surface Flinger的数据速率，以及马赛克的处理、丢帧的处理等等。
　　3结语
　　WiFidisplay新一代的智能移动平台将彻底脱离“有线”传输高清数字信号的时代。本文基于ARM架构的嵌入式平台实现了WiFidisplay Sink端的功能，经过测试可与当前市面上主流的Source端配对良好并实时地传输Source发送的多媒体数据，具有良好的用户体验和可扩展性。
　　参考文献：
　　[1]宋碧莲，吴华平. 流媒体技术研究及其系统平台的设计与比较[J].计算机应用研究，2004，21（1）： 204207.
　　[2]ROB GORDON.Essential JNI：Java native interface，prentice hall PTR[J].12 million words，1998.
　　[3]ABHYUDAI SHANKER，SOMYA LAL.Android porting concepts[C]//2011 3rd.International Conference on Electronics Computer Technology，Kanyakumari.2011：916.
　　[4]陆其明. Directshow开发指南[M].北京：清华大学出版社，2010.
　　[5]董莉娜，谭连生.分层视频组播应用中的全局视频质量[J].计算机工程， 2006，32（11）：150155.
　　[6]陈逻.浅谈流媒体技术在校园网中的应用[J].宁夏师范学院学报：自然科学版，2010，31（3）：7274.
　　责任编辑（责任编辑：杜能钢）

原文地址：http://www.xzbu.com/8/view-4405962.htm