简介音视频是指针对各类基于听觉、视觉需求的非家用专业化应用场景，实现音视频信号采集、处理、传输、存储、控制、呈现的综合信息系统。 音视频较为复杂，属于应用性多学科融合行业，且需要对各门类技术进行良好的适用性优化和融合。 涉及电声学、建筑声学、心理声学、计算机及通讯技术、光学、电子技术、工程技术、艺术美学等众多领域， 、通常以音频系统、视频系统、控制系统为核心，根据功能需要还会搭配灯光或照明系统、内部通讯系统、舞台机械系统等。
音视频系统属于应用性多学科融合行业，不仅涉及的技术门类众多，且需要对各门类技术进行良好的适用性优化和融合。
分类本地文件， .pm4 .ps .ts
流媒体，通过网络传输
发展之前人类主要通过文字、绘画或面对面交流来实现信息的发布和传递， 到了后来当电话、留声机以及摄影枪、光学影戏机（电影机的前身）被相继发明后，声音和图像的记录、存留以及一定程度的远程传输才成为可能。 之后，箱式扬声器以及调音台诞生并日臻成熟，并被逐渐应用于现场扩声，以提高声音信息的受众范围，从而开启了现代扩声系统之门。 而后随着科技的进步，电视机、投影机、各类音视频处理以及 LED 显示、激光显示等设备相继问世并快速迭代， 人类也终于可以自由地对声音和图像进行拾取、记录、处理、传输、控制和呈现了。 音视频系统门类繁多，发展历程的时间线复杂，因此需要用高概括性的多种维度对其发展历程进行划分。
其中信号技术革新、应用目标提升及应用领域扩展三者互相促进，循环交互作用，共同推动了专业音视频系统的不断发展。
（1）信号技术的革新
专业音视频系统是实现音视频信号采集、处理、传输、存储、控制、呈现等功能的一种信息系统，其发展和音视频信号传输技术息息相关， 音视频信号技术主要经历了模拟信号阶段、数字信号阶段和网络信号阶段。
（2）应用目标的提升
随着技术的进步，人类对于视声信息传递所呈现的质量要求主要分为三个阶段：
A. 听见/看见：以能够获取主要信息为目标，特征上主要表现为足够的响度（声压级）、足够的亮度（流明或照度级）和对比度等，对系统和设备性能、功能的要求相对较低。
B. 听清/看清：以能够获取信息所有细节为目标，在"听见/看见"的基础上还要提供良好的传声增益和清晰度、均匀的声场、足够的显示尺寸及细致的分辨率等， 对系统和设备的性能、功能提出了较高的要求。
C.听好/看好（虚拟再现）：以通过电子方式重构相关信息的发送实景为目标，现在逐步展开尝试的 3D 沉浸声、3D 虚拟显示等均为向此目标迈进的初步探索， 它将对系统和设备的性能、功能提出更加严苛和革命性的创新要求。
（3）应用领域不断扩展
音视频最早应用于会议、广播和演出娱乐领域，用于相关信息的基础呈现，但随着音视频技术、软件及相关算法、控制手段的不断进步，系统的功能也越来越强大， 因此，应用领域也随之不断拓宽，逐渐渗入到人类社会的各个层面。目前，该系统可用于任何具有听觉、视觉需求的应用场景，其主要的专业应用领域如下所示：
企业，政府，医院，电影，电视，体育赛事直播，短视频等一些列的应用。
应用直播，实时播放一段视频，视频会议，远程会诊等。
录播，视频存储，回放等。
短视频，美颜，旋转等。
应用工具通用工具: FFMPEG, VLC, OPENCV等
RTSP、RTMP、HTTP、SIP协议是常见的几种音视频解决方案传输协议。
(1)、RTMP协议
RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。 该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。
RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。
支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。
(2)、RTSP协议
RTSP(Real Time Streaming Protocol)，RFC2326，实时流传输协议， 是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。 RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。
HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应; 使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。 RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制， 传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容， 它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。 而前面提到的允许同时多个串流需求控制(Multicast)，除了可以降低服务器端的网络用量。
因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP， 并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
(3)、HTTP协议
HTTP是一个客户端和服务器端请求和应答的标准（TCP）。 通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。 我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。 我们称这个应答服务器为源服务器（origin server）。
在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。
(4)、SIP协议
SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。
(5)、共同点
1、这几种协议都是在应用在应用层。
2、理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。
(6)、不同点
1、HTTP: 即超文本传送协议(ftp即文件传输协议)。
HTTP:(Real Time Streaming Protocol)，实时流传输协议。
RTMP全称Routing Table Maintenance Protocol（路由选择表维护协议）。
2、HTTP将所有的数据作为文件做处理。
http协议不是流媒体协议。
RTMP和RTSP协议是流媒体协议。
3、RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。
4、RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts, h264, h265, mp4格式的流,HTTP没有特定的流。
5、RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。 RTSP实时流协议 作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作。
常见问题花屏、绿屏、黑屏，卡顿，延迟较大，无法播放，口型对不上等。
其实黑屏、花屏、闪屏等问题，可能是推流端的问题，也可能是播放器的问题，遇到这些现象，用别的播放器（如 VLC，ffplay）试试，如果都出现同样的问题，那么多半是流本身的问题了，反之，则很可能是播放器的问题。
一般的问题从这四方面来看
1、摄像头的问题
可以询问出现问题的厂家是否有摄像头有预览画面，网络是否正常，状态是否正常等。
2、 编码失败
视频数据采集到后，下一步就是经过编码器，由于参数配置或者某些机型的硬编兼容性问题，很可能数据送入编码器后，编码失败，并无输出，从而导致没有视频数据送入到推流模块。 解决方案：一般推流 SDK 都会统计推流的实时视频帧率，CDN 服务端也会有一些帧率监控，因此，如果发现这些统计得到的推流帧率为 0，同时又确定不是没有采集到数据，那么多半是编码器的原因，可以想办法查看下该机型的日志看看具体的报错信息。
3、 网络传输
网络传输中丢包，抖动等。
4、 视频解码失败
当解码器遇到不支持的视频格式，或者数据内容/格式异常，则会解码失败，从而导致无解码视频输出。
5、 播放的问题
这种情况，多半出自 HLS 切片产生的码流，当主播用同一个地址推流，前半段只推了音频（可能是摄像头权限被禁用，也可能是选择了纯音频推流等等），然后接着又同时推了音视频流，那么，服务端 HLS 切片产生的文件，就会出现这样的情况。 基于 ffmpeg 的播放器，会在解析完视频头后初始化解码器，因此，对于这种码流，往往会出现仅有音频或者仅有视频播放的情况。