组播屏幕共享、Android屏幕共享开发小结

           因近期项目需要，实现了一套多种网络拓扑、多种应用场景的多平台屏幕共享系统，包括组播屏幕共享、服务器转发屏幕共享、P2P屏幕共享，暂支持Windows屏幕共享给Windows，Windows屏幕共享给Android等，后续加入android、IOS的相互共享。下文进行简单的总结，具体细节请参考 www.mediapro.cc

• 应用场景

   1、一对一屏幕共享

                                      

同一局域网内，发送端将自身屏幕和音频共享给指定的接收端，常用于办公会议、游戏电影投屏等场合。

系统通过集成QOS-FEC-NACK传输库点对点版SDK实现对弱网的支持（SDK支持Windows\Android\嵌入式Linux\IOS），系统总体延时可控制在120ms以内。注意SDK支持全双工通讯，本应用场景中仅使用到单向的传输。

      2、一对多组播屏幕共享

同一局域网内，发送端将自身屏幕和音频共享给一组接收端，常用于教学等场合。

优点：通过组播技术的使用，无需架设转发服务器即可实现一对多分发。

缺点：由于WIFI(802.11)网络对于组播和广播在数据链路层无法提供类似单播的保障，WIFI下的组播容易出现较高的丢包率，因此本方案更适合有线网络。

                               

       系统通过集成QOS-FEC传输库点对点版SDK实现对弱网的支持（SDK支持Windows\Android\嵌入式Linux\IOS），系统总体延时可控制在120ms以内。因为数据流是单向因此无法使用NACK丢包重传机制。

       3、一对多公网屏幕共享

        当需要实现异地跨公网一对多屏幕共享时，就需要在公网上架设媒体转发服务器。SRTP-Server是在RTP-FEC-QOS传输层基础上建立了一套轻量级RTP直播转发服务器集群，可用于一对多、多对多等场合的音视频实时互动，客户端支持全平台包括PC客户端、浏览器、Android、IOS、嵌入式Linux，关于SRTP-Server更详细介绍请移步：www.mediapro.cc

        SRTP-Server有集群版本和非集群版本，集群版本用于同一房间大规模的公开课等场合，非集群版本则用于同一个房间数十人规模的屏幕共享（房间数目、总的接收端数目受限于服务器带宽、内存、CPU）。

                        

       客户端（包括发送端和接收端）通过集成SRTP-Server配套的SDK可实现同一房间多路流直播，比如发送屏幕共享的同时发送摄像头数据。SRTP-Server基于房间模式，不同的房间相互隔离。

                                      

      通过公网服务器转发的方式可实现异地多人屏幕共享，但也存在无法避免的缺点：

      A、系统延时受网络线路影响较大，网络条件较好的阿里云服务器上，延时可以控制在300ms内。

      B、服务器带宽成本随用户数、视频码率而增长。

      当然本系统也可部署到内网，实现一对多的WIFI屏幕共享，解决组播对WIFI支持不佳的问题。

       4、一对一公网P2P屏幕共享

       公网上当仅需要一对一的屏幕共享时，我们可以使用P2P技术来节省服务器带宽成本。SRTP-Server-P2P版转发服务器支持客户端一对一P2P双向传输。SDK在P2P不成功或者丢包率较高的情况下会自动切换回服务器转发模式，实现了STUN和TURN的功能。

                                   

      P2P方式大幅节省了服务器带宽成本，但也对服务质量产生了一定影响，体现在以下几点：

      A、不同运营商的客户端之间P2P即便可以打通，或许可以承载低码率的视频通话业务，但无法承载高码率的屏幕共享业务。

      B、因网络原因在P2P和转发之间切换对用户的使用体验产生影响。

• 一些注意事项

• 组播需要关闭发送端的本地回环模式，降低发送端开销。
• 对于内网两台机器走P2P时应使用内网地址通讯而不用对方的出口IP，虽然二者均可以互通，但内网IP效率更高。
• 由于屏幕共享码率较高，尽量使用非阻塞的socket，设置socket的系统缓存到512KB以上，避免因socket缓存原因引入系统丢包。
• 使用微软WASAPI采集扬声器音频时，会出现无音频播放时，采集回调无调用的情况，这对于直播没有影响，但会影响录制的TS素材。比如录制文件一开始没有音频数据仅有视频数据，则某些播放器会直接跳到存在音频的部分播放。解决的方法是：发送端自行输出静音数据。
• 因为屏幕共享对于分辨率要求较高，高分辨率编码将对发送端机器形成压力，建议优先使用硬编码，若不支持再使用X264。PC上目前主流硬编码有Intel CPU自带的核心显卡QsvEncode和英伟达显卡带的NviEncode。高版本的ffmpeg对二者提供了支持，不过采集到的编码码流需要进行统一过滤处理，比如过滤直播中无用的NAL_AUD和NAL_FILLER_DATA，前者因为我们UDP自身加入了边界，后者纯属冗余数据，经过这样处理可以大幅节省带宽。
• 由于屏幕共享码率较高，FEC处理需要开启动态Group模式，在不增加冗余度的情况下增强连续丢包的抵抗力。
• 屏幕画面变化相比摄像头画面变化来得剧烈，使用硬编码时码率波动更大，发送端可开启Smooth平滑发送，接收端视业务情况开启接收缓存。

  组播接收端启动界面：

        

  发送端启动界面：

                                    

  屏幕共享客户端、服务器相关执行程序、硬编码封装源码等可从github获取：https://github.com/waterfoxfox

https://github.com/waterfoxfox/MulticastSDK​​​​​​​