vlc怎么播放rtsp服务器上的媒体

打开“媒体——流”选项
点击“添加”按钮选择流媒体文件，然后点击“串流”按钮
点击“下一个”后，在“目标设置”界面选择“RTSP”，然后点击添加 + 按钮
填上目标ip地址，并在“转码选项”中选择相应的编码类型（这个视情况而定），目标IP地址就是PC机器本机的IP地址
客户端, 点击“媒体——打开网络串流”，在d出的框中输入“rtsp://19216812:1234/tcp1”，点击“播放”按钮即可。

最近需要做实时录屏并把视频推流到RTSP服务器，具体流程是抓取屏幕内容(bitmap)，并把bitmap转化为YUV，接着把YUV编码成H264，再把H264码流推到RTSP服务器；把采集到的PCM编码为AAC，再把AAC推流至RTSP服务器。

看了雷神的一篇文章： 最简单的基于FFmpeg的推流器（以推送RTMP为例） ，他是把本地的视频文件推流至RTMP服务器，并不符合我的要求。
接着我找到另一篇文章： ffmpeg实现H264压缩并且推流至RTSP ，这篇文章只有图像编码，并没有音频编码，并且推流之后并没有播放成功。
我综合上面两位大佬的思路，和查找一些资料实现了这个功能。

RTSP服务器使用的是 HappyTime 的免费试用版本。

我抓到的bitmap是BGRA格式的，所以使用的图像格式是 AV_PIX_FMT_BGRA ， cropImage 是含有rgba图像的数组

调用：

由于我是实时抓取的屏幕， frame_yuv->pts 设为当前的时间戳，以保证能正常播放。

调用：

调用：
其中pcm_buff是包含pcm数据的数组

使用udp传输时传到1400多帧就断开链接了，原因不明，所以改用使用tcp协议传输

延迟有15秒左右

参考：
>序言

随着人工智能命题的提出，近年来涌现出一大批基于人工智能的呼叫中心业务服务商和集成商，仅智能外呼这一模块儿就将近百家公司在推广和运营。可以说整个基于人工智能技术的市场开始蓬勃的发展起来了。
简单介绍一下什么叫做智能语音交互平台。其实大实话就是在呼叫中心基础上，集成 ASR、 TTS、的呼叫服务平台。
那么如何我们自己去搭建智能语音系统呢？
我们先列出搭建智能外呼系统的搭建需要那些技术和服务：

个人认为：
[if !supportLists]·        [endif] 首先最重要的是交换机：

[if !supportLists]1    [endif]PBX也就是交换机，商用设备原厂包括像华为、Avaya、思科、东汇等这些生产硬件交换机，

[if !supportLists]2    [endif]还有就是目前FreeSitch、asterrisk、OpenPBX这些软件交换机。
[if !supportLists]·        [endif] 其次是AI技术: 及包含语音识别、语义理解、语音合成这三种技术是核心组成部分。语音识别相当于人的“耳朵”，接进电话后，对人的话语进行处理转义成系统能够识别的数据交由系统处理去识别。在进一步的话，可以转义为文字。语义理解相当于人的"大脑"，根据话语识别人的意图。语音合成，相当于人的”嘴巴“，识别人的意图之后，依照特定的回答方式，去回复和引导对话。
[if !supportLists]·        [endif] 再者是前端服务平台：即用户登录、配置呼叫流程，建立呼叫任务、统计呼叫数据、导出呼叫报表的网站，这个是终端用户唯一可以看到并且 *** 作的界面。
[if !supportLists]·        [endif] 最后是外呼线路：其中包括三大运营商以及其他小型的集成线路供应商，主要目的是外呼电话或者是接入电话。
也有人可能有疑问：”智能语音交互系统最重要的不是人工智能么，和交换机有啥关系？”为什么说最重要的是交换机呢，原因是不管我们是外呼还是接入电话、都需要前端服务平台把外呼请求发送给交换机，通过外呼线路而拨出去。换句话说交换机是控制整体的外呼情况。硬件的交换机，比如说像华为的交换机，价格在大约几万到几百万不等的价格。对于想要建立自己的智能语音交互系统来说，价格对于一些小型公司来说承受不起，而FreeSitch这种软交换则大大方便了小型公司建立自己的智能语音交互系统。
什么是FreeSwitch？
FreeSitch是一个电话的软交换解决方案，包括一个软电话和软交换机用以提供语音和聊天的产品驱动。FreeSitch 可以用作交换机引擎、PBX、多媒体网关以及多媒体服务器等。支持多种通讯技术标准，包括 SIP, H323, IAX2 以及 GoogleTalk ，同时也可以方便的与其他开源的PBX系统进行对接。而且具有很强的伸缩性。旨在为音频、视频、文字或任何其他形式的媒体，提供路由和互连 通信协议 。
FreeSwitch 的典型功能

[if !supportLists]·        [endif]在线计费、预付费功能。 

[if !supportLists]·        [endif]电话路由服务器。 

[if !supportLists]·        [endif]语音转码服务器。 

[if !supportLists]·        [endif]支持资源优先权和QoS的服务器。 

[if !supportLists]·        [endif]多点会议服务器。 

[if !supportLists]·        [endif]IVR、语音通知服务器。 

[if !supportLists]·        [endif]VoiceMail服务器。 

[if !supportLists]·        [endif]PBX应用和软交换。 

[if !supportLists]·        [endif]应用层网关。 

[if !supportLists]·        [endif]防火墙/NAT穿越应用。 

[if !supportLists]·        [endif]私有服务器。 

[if !supportLists]·        [endif]SIP网间互联网关。 

[if !supportLists]·        [endif]SBC及安全网关。 
FreeSwitch最典型的功能是作为一个服务器，并用电话客户端软件连接到它。虽然FreeSwitch支持众多的通信协议，但其最主要的协议还是SIP，通过SIP中继发起会话协议。

使用FreeSwitch这种软交换的好处在于，你只需要一台服务器就可以随时搭建自己的外呼中心，而且FreeSwitch支持跨平台运行。能够原生运行Windows、Linux、BSD等诸多32/64位平台。
FreeSwitch内部使用线程模型来处理并发请求，每个连接都在单独的线程中进行处理，不同的线程间通过Mutex互斥访问共享资源，并通过消息和异步事件等方式进行通信。FreeSwitch本身是比较稳定的，它是比较优秀的开源软件。另一方面来讲，FreeSwitch又是比较激进的，它的开发分支里会有大量的新特性加入，因此在测试不全面的情况下，很容易出现不稳定的情况。而在用于生产环境的情况下，系统的稳定性是系统能否正常被使用的关键。之前我们在做项目的过程中，就遇到一些FreeSwitch不稳定的情况，导致外呼情况不理想。举一个例子：我们在进行测试外呼的时候，语音通话断断续续，虽然前端服务平台可以很好的接受到数据的传输，但是，真正在与人工进行沟通的时候，会出现各种各样的沟通障碍，为了解决这一个问题，我们花费了几个月的时间，去研究FreeSwitch的结构特性。终于把这个问题解决掉。我们的项目才得以继续推动，最终得以真正落地部署实施。
也有人可能有疑问：”FreeSwitch软交换虽然重要，但是既然是智能语音交互系统人工智能不重要吗？”，重要，当然重要！容我慢慢道来~

AI 技术
1 通信原理
先简单解释一下正常打电话这个流程

流程：A→PSTN→B

解释：PSTN是Public

Switched Telephone Network，意思为公共交换电话网络，也就是我们的运营商的网络电话，

那我们平时如何给呼叫中心比如打电话是如何打的？：个人A打电话给呼叫中心16 打电话，拨通后听到录音，您好，拨打人工台，请按0键，按键之后，出现盲音，真正接通之后，客服接通了电话。

流程：A→PSTN→PBX→IVR→客服

解释：PBX也叫交换机、相当于整个呼叫中心的出入口

IVR也叫互动/交互式语音应答，语音导航，也就是相当于咨询业务请按键，这一环节，根据业务去分流到客服。

智能语音交互平台（智能机器人）落实到具体具体业务场景是如何实现的：

如：”个人A要在某一个大型酒店预订位子“，

A拨通后先听到了声音，“您好，我是机器人小岳，需要我帮您订位子是吗？
个人A说，“我不要和机器人说话，找个真人来”。
然后听到录音，“为您转接很贵的真人客服，排队中，请稍后”。
几分钟后接通，真人客服接了电话。

流程：A→PSTN→PBX→IVR（TTS→ASR→NLP→TTS）→ACD→客服

解释：在IVR部分：不再需要提示按键，而是直接问来电方需要办理什么业务，然后识别语音、理解意图后，根据用户的需求，回答后转入对应的业务队列排队。

上边是接通的流程，呼出的流程与之相反，就不在赘述了。
2 现在市场上的AI技术的运用
目前市场上的不管是ASR、TTS、NLP都被阿里百度科大讯飞等巨头公司所占据，这些技术在国内基本已经成为定局。像ASR这类引擎市场上大部分都是用的阿里云和讯飞云的，要不就是百度云。阿里云和讯飞云的识别率高一些，可以达到97%左右、百度的差一些，识别率在80%左右，我们当初在做项目的时候选择ASR做过测试，事实证明阿里云识别率更高同时也可以识别方言。因此，我们在做项目的时候，当仁不让的选择了阿里云的

TTS我们选择的是讯飞的，选择的理由很简单，毕竟科大讯飞是人工智能领域巨头级的公司，质量当然有的保证。
3 AI 能力对接
在具体落地中，这个领域的常规参与者通常具备呼叫中心能力或者AI能力其中一种，而主要的对接点也就在于AI能力与呼叫中心设备去对接，而ASR/TTS与呼叫中心设备对接的常规协议主要是mrcp/sip。

媒体资源控制协议（Media Resource Control

Protocol, MRCP）是一种通讯协议，用于语音服务器向客户端提供各种语音服务(如语音识别和语音合成)。有两个版本的MRCP协议，版本2使用SIP作为控制协议，版本1使用RTSP。

实际对接的时候，会遇到不少技术问题，当我们ASR/TTS引擎做私有云部署，为了避免了内外网穿透时防火墙的诸多设置和语音流的时延。这在我们当时对接的时候也花费了好大一番功夫。
前端服务平台：

其中最重要的就是配置呼叫流程这一块儿了，
这一块儿很容易被忽视，但是这反而是可以出成绩的地方。一般来说一套最佳话术模板，可以以一敌万。心理学基础必须要有，一句话怎么说能让接电话的人最大概率的顺着自己的思路走，达成目的，从而形成特定细分领域机器人话术模板，得到最佳的外呼效果（接通率、通话时长、电销意愿、催收意愿）或者是接通效果（满意度）
其余的基本就是web端的东西了，具体功能点呢，即用户登录、配置呼叫流程，建立呼叫任务、统计呼叫数据、导出呼叫报表，这些功能点基本实现就可以，因为站在产品角度，产品最重要的价值就是可以呼通或者接通用户的电话，并且能够准确的识别用户的意图，并且准确的回答用户。这就是智能语音交互系统的最终目标，也一直是我们的最终目标。
外呼线路厂商：

一般如果是购买系统的话，是给提供线路的，只需交一些线路费用。如果是自己做项目的话，网上、淘宝上一大堆，费用可以谈，也给提供线路对接的接口。
结语

虽然现在市场上做智能语音交互系统的比较多，但一般只限于各个行业的电话销售，真正意义上的智能语音交互还是很少的。原因很简单，虽然原理不是很难但是真正落地实施的时候，遇到的困难非常的多，几乎是一步一个坑。好在现在已经真正的落地实施了，方方面面的效果都还是很不错的。一年多的辛苦没有白费。哈哈~

写这篇文章尝试给大家简单介绍一下智能语音交互系统，然才疏学浅，疏漏和不当之处在所难免，权当给大家抛砖引玉。
诸多细节限于主题和篇幅的要求不做详细记述，如有问题，欢迎随时交流。

播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。趣拍直播SDK可以满足以下所有的功能和应用场景，帮助开发者解决各种直播难题。

采集

手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据。其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。对于采集到的原始音视频的体积是非常大的，因此需要经过压缩技术来处理，降低视频的大小来提示传输效率。 在手机视频采集方面，iOS系统在硬件的兼容性方面做得比较好，系统本身提供了比较完整的视频采集的接口，使用起来也比较简单。但是，Android系统就比较麻烦了，千奇百怪的机型都有，适配起来非常难。我们在初期做了一项调研，发现Android的适配率还不到50%。

    2前处理

在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了。

美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的。滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好。

在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法。

3、编码

为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积。现在比较常用的视频编码是H264，但具有更高性能的H265编码技术正在飞速发展，并可能很快成为主流；在音频方面，通比较常用的是用AAC编码格式进行压缩，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。通俗点讲就是编码器将多张图像进行编码后产生一段段GOP（Group of Pictures），播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示。 在编码方面的核心是在分辨率、码率、帧率等参数中找到最佳平衡点，达到体积最小画面最优的效果，这些参数各家也都有自己的一套核心参数。

2012年8月，爱立信公司推出了首款H265编解码器，六个月后，国际电联(ITU)就正式批准通过了HEVC/H265标准，称之为高效视频编码(High Efficiency Video Coding)，相较于之前的H264标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于15Mbps的网络也能传输1080p的高清视频。国内，如阿里云、金山云都在推自己的H265编解码技术，随着直播的快速发展和对带宽的依赖，H265编解码技术已有全面取代H264的趋势。当然，全面推开应用还需要些时间。
另外，硬件编码已经成为手机直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在IOS平台上硬件编码的兼容性比较好，可以直接采用，但在 Android 平台上，Android的MediaCodec 编码器，针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的

    4、推流

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。 在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能还是非常有保障的。通常，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

---