rtp音视频同步问题解决方法
rtp同步方法的思考
由于音视频流是以两条独立的数据流在网络上传输的，如果网络质量相当差，那么在接收端收到的音视频数据流就有可能不是同步的了，为了克服这种不同步的现象，需要添加同步机制。的同步机制是使用开源库jrtplib3.7.1来实现的，严格遵守rtp协议标准。
解决的方案如下：
当有数据需要发送时，往数据中加入时间戳，在接收端，读取时间戳，进行比较，如果相同或相差很近，就提交播放，如果其中一个时间戳更大，就等待。
如果网络质量很差，那么存在两种不同步的情况：
1. 对于单条数据流来说，如果网络质量很差，可能出现数据流的接收不流畅，如果没有做流畅处理，那么就可能出现抖动现象，这需要使用rtp中的时间戳解决。
2. 对于多条数据流来说，如果网络质量很差，可能出现本应该同时播放的数据帧没有在同一时间到达，需要做同步处理。
解决第1个问题的方法是向每个发送的数据包加上时间戳，在rtp库中，时间戳表示在打包数据段中第一个采样所对应的时间，时间戳的启始值是随机的，后续的时间戳是在前一个时间戳上的增量，在SendPacket中的时间戳参数表示的是时间戳增量，所以数据流的同步需要计算出时间戳增量。
对于音频数据，由于音频数据的采样率是8000HZ,所以每采样一次需要时间是1/8000s，由于是每20ms封包一次，所以时间戳的增量是(20*10**-3)*8000=160。
对于视频数据，由于视频数据的采样率是90000Hz,所以每采样一次需要时间是1/90000s,如果帧率是25帧/s,所以时间戳增量是90000/25=3600。
在发送端，每发送一个数据包，都打上该数据包对于的时间戳值，只需要向SendPacket 的最后个参数传递时间戳增量，rtp库会自动算出时间戳，并加到发送的rtp数据包首部里边。
在接收端，当收到一个数据包时，获取该rtp数据包的时间戳值，计算出与前一个数据包的时间戳值的差值，乘以该媒体流的时间戳单位，就得出了当前数据包与前一个数据包之间的间隔的打包时间T。所以只要保证在与前一个数据包被提交过后T时间后再提交当前接收到的数据包，那么在rtp层就解决了上边提出的第一个问题。
解决第2个问题的方法是使用rtcp发送者报告数据包中的时间信息，发送者报告被发送的间隔时间是不固定的，它的大小与参与到会话中的同步源数量成正比。每个发送者报告中都有个ntp时间和rtp时间，该ntp时间表示在发送时间戳为该rtp时间的rtp包时的系统绝对时间，就是在发送这个rtp包时的系统时间，所以这两个时间值有对应关系，由于对于一个同步源，时间戳单位是固定的，所以可以由后
续的某个数据包的rtp时间戳timestamp1计算出这个数据包所对应的绝对时间，这个绝对时间就是在发送这个数据包时，发送端的系统时间
这个思路就是：
已知：ntp0，rtp0，rtp1，时间戳单位u，且ntp0与rtp0是表示同一时间值，只是测量标尺不同。
计算：ntp1，该ntp1与rtp1表示同一时间值
计算的公式：
ntp1 = ntp0 + (rtp1- rtp0)*u
使用这种方法就可以计算出每个收到的rtp数据包在发送端的系统时间，这个系统时间在发送端是单调递增的，所以可以通过这个值来同步多条数据流。
发送端（需要修改）：
if(mediatype == 0)
{
if(first_flag)
{
//usleep(125*266*30);
presampletime = RTPTime::CurrentTime();
status = rtpsession->SendPacket((void *)buf, len, payloadtype, false, 0);
first_flag = false;
}else
{
tmpcurtime = curtime = RTPTime::CurrentTime();
curtime-=presampletime;
interval = (uint32_t)(curtime.GetDouble() * 8000.0);
status = rtpsession->SendPacket((void *)buf, len, payloadtype, false, 160/*interval*/);
presampletime = tmpcurtime;
}
}else
{
GwRTPRecv::g_start_send = 1;
if(GwRTPRecv::g_skip_frame==1)
{
char buf123[]="#1234#";
status = rtpsession->SendPacket((void *)buf123, strlen(buf123), payloadtype,true,0);
GwRTPRecv::g_skip_frame = 2;
}
if(GwMpeg4Codec::g_key_frame)
{
if(buf[10] != 'I')
{
return false;
}else if(GwMpeg4Codec::g_key_frame==2)
{
GwMpeg4Codec::g_key_frame = 0;
first_flag = true;
}
}
if(first_flag)
{
presampletime = RTPTime::CurrentTime();
status = rtpsession->SendPacket((void *)buf, len, payloadtype, false, 0);
first_flag = false;
}else
{
tmpcurtime = curtime = RTPTime::CurrentTime();
curtime-=presampletime;
interval = (uint32_t)(curtime.GetDouble() * 90000.0);
status = rtpsession->SendPacket((void *)buf, len, payloadtype, false, interval);
presampletime = tmpcurtime;
}
接收端（需要修改）：
bool recved = false;
RTPPacket *pack;
uint8_t *data ;
RTPTime curtime(0,0);
uint32_t timestamp;
RTPTime delay_time(0, 0);
uint32_t rtcp_timestamp;
RTPNTPTime rtcp_ntptime(0,0);
double interval_time;
double interval_time_abs;
RTPSourceData* psourcedata;
char need_sync_flag = false;
if(mediatype == 0)
{
rtpsession->BeginDataAccess();
if (rtpsession->GotoFirstSourceWithData())
{
do
{
while ((pack = rtpsession->GetNextPacket()) != NULL) {
if(pack->GetPayloadType() != payloadtype)
{
rtpsession->DeletePacket(pack);
continue;
}
recvlen = pack->GetPayloadLength();
if(recvlen > pack_size|| recvlen <= 0 )
{
rtpsession->DeletePacket(pack);
continue;
}
timestamp = pack->GetTimestamp();
data = pack->GetPayloadData();
*len = recvlen;
memcpy(buf, data, recvlen);
recved = true;
psourcedata = rtpsession->GetCurrentSourceInfo();
if(psourcedata->SR_HasInfo())
{
rtcp_timestamp = psourcedata->SR_GetRTPTimestamp();
rtcp_ntptime = psourcedata->SR_GetNTPTimestamp();
recvd_rtcp = true;
}
if(recvd_rtcp)
{
RTPTime rtcpntptime(rtcp_ntptime);
uint32_t timestamp_bound = timestamp > rtcp_timestamp?(timestamp-rtcp_timestamp):(rtcp_timestamp-timestamp);
if(timestamp_bound > 0xffff0000)
{
interval_time_abs = (0xffffffff - timestamp_bound)/8000.0;
interval_time = timestamp < rtcp_timestamp?(interval_time_abs):(-interval_time_abs);
}else
{
interval_time_abs = timestamp_bound/8000.0;
interval_time = timestamp < rtcp_timestamp?(-interval_time_abs):(interval_time_abs);
}
RTPTime rtptime_interval(interval_time_abs);
if(interval_time > 0)
{
rtcpntptime+=rtptime_interval;
}else
{
rtcpntptime-=rtptime_interval;
}
audio_time_sem.lockSem();
audio_curtime = rtcpntptime;
audio_time_sem.unlockSem();
}
rtpsession->DeletePacket(pack);
goto aurecv_end;
}
} while (rtpsession->GotoNextSourceWithData());
}
aurecv_end:
rtpsession->EndDataAccess();
}else
{
rtpsession->BeginDataAccess();
if (rtpsession->GotoFirstSourceWithData())
{
do
{
while ((pack = rtpsession->GetNextPacket()) != NULL)
{
if(pack->GetPayloadType() != payloadtype)
{
rtpsession->DeletePacket(pack);
continue;
}
recvlen = pack->GetPayloadLength();
if(recvlen > pack_size|| recvlen <= 0 )
{
rtpsession->DeletePacket(pack);
continue;
}
timestamp = pack->GetTimestamp();
data = pack->GetPayloadData();
*len = recvlen;
memcpy(buf, data, recvlen);
recved = true;
if(pack->HasMarker() && strncmp((char*)data, "#1234#", 6) == 0)
{
rtpsession->DeletePacket(pack);
goto verecv_end;
}
if(buffer[0]=='#' && buffer[3]=='*' && buffer[2] == 'I')
{
first_flag = true;
}
psourcedata = rtpsession->GetCurrentSourceInfo();
if(psourcedata->SR_HasInfo())
{
rtcp_timestamp = psourcedata->SR_GetRTPTimestamp();
rtcp_ntptime = psourcedata->SR_GetNTPTimestamp();
recvd_rtcp = true;
}
if(recvd_rtcp)
{
RTPTime rtcpntptime(rtcp_ntptime);
uint32_t timestamp_bound = timestamp > rtcp_timestamp?(timestamp-rtcp_timestamp):(rtcp_timestamp-timestamp);
if(timestamp_bound > 0xffff0000)
{
interval_time_abs = (0xffffffff - timestamp_bound)/90000.0;
interval_time = timestamp < rtcp_timestamp?(interval_time_abs):(-interval_time_abs);
}else
{
interval_time_abs = timestamp_bound/90000.0;
interval_time = timestamp < rtcp_timestamp?(-interva
l_time_abs):(interval_time_abs);
}
RTPTime rtptime_interval(interval_time_abs);
if(interval_time > 0)
{
}else
{
rtcpntptime-=rtptime_interval;
}
audio_time_sem.lockSem();
RTPTime audio_curtime1 = audio_curtime;
audio_time_sem.unlockSem();
if((audio_curtime1.GetSeconds() != 0 ||audio_curtime1.GetMicroSeconds() != 0)) {
if(rtcpntptime < audio_curtime1)
{
RTPTime tmp = audio_curtime1;
if((tmp-=rtcpntptime) > RTPTime(0, 500000))
{
first_flag = true; /*make vedio stream receive faster*/
*len = 0;
recved = false; /*discard packet becase it is too late*/
goto verecv_end;
}
}else
{
if(first_sync_flag)
{
presynctime = RTPTime::CurrentTime();
first_sync_flag = false;
need_sync_flag = true;
}else
{
curtime = RTPTime::CurrentTime();
RTPTime tmp = curtime;
tmp -= presynctime;
if(tmp >= RTPTime(5,0))
{
need_sync_flag = true;
presynctime = curtime;
}
}
if(need_sync_flag)
{
while ( audio_recving && rtcpntptime > audio_curtime1 ) /*vedio advance*/
{
audio_time_sem.lockSem();
audio_curtime1 = audio_curtime;
audio_time_sem.unlockSem();
usleep(5);
}
first_flag = true;
}
}
}
}
if(first_flag)
{
preplaytime = RTPTime::CurrentTime();
pretimestamp = timestamp;
first_flag = false;
}else
{
double delay;
if(timestamp < pretimestamp)
{
delay = (0xffffffff - pretimestamp + timestamp)/90000.0;
}else
{
delay = (timestamp - pretimestamp)/90000.0;
}
RTPTime delay_time(delay);
curtime = RTPTime::CurrentTime();
curtime-=preplaytime;
if(delay_time > curtime)
{
delay_time -= curtime;
}
preplaytime = RTPTime::CurrentTime();
preplaytime+=delay_time;
pretimestamp = timestamp;
}
rtpsession->DeletePacket(pack);
goto verecv_end;
}
}while (rtpsession->GotoNextSourceWithData());
}
verecv_end:
rtpsession->EndDataAccess();
if(delay_time.GetSeconds() != 0 || delay_time.GetMicroSeconds() !=0) {
RTPTime::Wait(delay_time);
}
}
return recved;
视频流中的DTS／PTS到底是什么? DTS（解码时间戳）和PTS（显示时间戳）分别是解码器进行解码和显示帧时相对于SCR（系统参考）的时间戳。SCR可以理解为解码器应该开始从磁盘读取数据时的时间。 mpeg文件中的每一个包都有一个SCR时间戳并且这个时间戳就是读取这个数据包时的系统时间。通常情况下，解码器会在它开始读取mpeg流时启动系统时钟（系统时钟的初始值是第一个数据包的SCR值，通常为0但也可以不从0开始）。 DTS 时间戳决定了解码器在SCR时间等于DTS时间时进行解码，PTS时间戳也是类似的。通常，DTS/PTS 时间戳指示的是晚于音视频包中的SCR的一个时间。例如，如果一个视频数据包的SCR是100ms（意味着此包是播放100ms以后从磁盘中读取的），那么DTS/PTS值就差不多是200 /280ms，表明当SCR 到200ms时这个视频数据应该被解码并在80ms以后被显示出来（视频数据在一个buffer中一直保存到开始解码） 下溢通常发生在设置的视频数据流相关mux率太高。 如果mux率是1000000bits/sec（意味着解码器要以1000000bits/sec的速率读取文件），可是视频速率是2000000bits/sec（意味着需要以2000000bits/sec的速率显示视频数据），从磁盘中读取视频数据时速度不够快以至于1秒钟内不能够读取足够的视频数据 。这种情况下DTS/PTS时间戳就会指示视频在从硬盘中读出来之前进行解码或显示（DTS/PTS时间戳就要比包含它们的数据包中的SCR时间要早了）。 如今依靠解码器，这基本已经不是什么问题了（尽管MPEG文件因为应该没有下溢而并不完全符合MPEG 标准）。一些解码器（很多著名的基于PC的播放器）尽可能快的读取文件以便显示视频，可以的话直接忽略SCR。 注意在你提供的列表中，平均的视频流速率为～3Mbps（3000000bits/sec）但是它的峰值达到了14Mbps （相当大，DVD限制在9.8Mbps内）。这意味着mux率需要调整足够大以处理14Mbps的部分，bbMPEG 计算出来的mux率有时候太低而导致下溢。 你计划让视频流速率这么高么？这已经超过了DVD的说明了，而且很可能在大多数独立播放其中都不能播放。如果你不是这么计划，我会从1增加mquant的值并且在视频设置中将最大码流设置为9Mbps以保持一个小一点的码流。 如果你确实想让视频码率那么高，你需要增大mux率。从提供的列表可以得出bbMPEG使用14706800bits/sec或者1838350bytes /sec的mux率（总数据速率为：1838350bytes/sec （14706800bits/sec）行）。你在强制mux率字段设置的值应该是以bytes/sec为单位并被50整除。所以我会从36767（1838350/50）开始，一直增加直到不会再出现下溢错误为止
本技术公开了一种音视频同步的方法及监控系统，包括步骤：S1，采集音视频数据；S2，基于实时传输协议RTP传输音视频数据；S3，采用音视频同步技术处理数据。本技术基于实时传输协议RTP，采用音视频数据同步技术解决了现有技术中存在的音视频数据不同步以及音频处理效果不佳问题，能够播放同步的声音和图像数据，使得声音和图像数据更加真实、流畅。 技术要求 1.一种音视频同步的方法，其特征在于，其包括步骤： S1，采集音视频数据；
S2,基于实时传输协议RTP传输音视频数据； S3,采用音视频同步技术处理数据； S3中，音视频同步控制在数据接收端实施；音视频同步技术以音频为主媒体，视频为从媒体，接收音视频数据时设置缓冲区，通过比较音视频数据包的时间戳判断同步关系，实现音视频数据同步。 2.根据权利要求1所述的一种音视频同步的方法，其特征在于，所述步骤S3中，采用队列作为缓冲区，缓存音视频数据。 3.根据权利要求1所述的一种音视频同步的方法，其特征在于，所述步骤S3中，对于音频缓存，使用iOS系统提供的AudioQueue框架的队列处理音频数据。 4.根据权利要求1所述的一种音视频同步的方法，其特征在于，所述步骤S3中，音频队列的长度至少为3。 5.根据权利要求1所述的一种音视频同步的方法，其特征在于，所述步骤S3中，音视频数据的时间差在允许范围内，则认为音视频同步；否则认为音视频不同步，丢弃视频帧。 6.根据权利要求1所述的一种音视频同步的方法，其特征在于，所述步骤S3中，采用H264硬编解码技术处理音视频数据。 7.一种音视频同步的监控系统，其特征在于，包括设备端、服务器端和客户端，所述设备端通过互联网和防火墙与服务器端连接，所述客户端通过WiFi或4G或4G+网络与路由器连接，所述路由器通过互联网与服务端连接； 所述设备端采集音视频数据，并将音视频数据压缩编码、打包后通过互联网发送到服务器端； 所述服务器端包括流媒体服务器和SIP信令服务器，流媒体服务器将设备端采集到的音视频数据通过互联网和WiFi或4G或4G+网络转发到客户端，SIP信令服务器负责转发系统中的信令消息，同时负责管理客户端中各个终端设备，流媒体服务器通过ICE与SIP服务器进行通信；
rtp音视频同步问题解决方法 rtp同步方法的思考 由于音视频流是以两条独立的数据流在网络上传输的，如果网络质量相当差，那么在接收端收到的音视频数据流就有可能不是同步的了，为了克服这种不同步的现象，需要添加同步机制。的同步机制是使用开源库jrtplib3.7.1来实现的，严格遵守rtp协议标准。 解决的方案如下： 当有数据需要发送时，往数据中加入时间戳，在接收端，读取时间戳，进行比较，如果相同或相差很近，就提交播放，如果其中一个时间戳更大，就等待。 如果网络质量很差，那么存在两种不同步的情况： 1. 对于单条数据流来说，如果网络质量很差，可能出现数据流的接收不流畅，如果没有做流畅处理，那么就可能出现抖动现象，这需要使用rtp中的时间戳解决。 2. 对于多条数据流来说，如果网络质量很差，可能出现本应该同时播放的数据帧没有在同一时间到达，需要做同步处理。 解决第1个问题的方法是向每个发送的数据包加上时间戳，在rtp库中，时间戳表示在打包数据段中第一个采样所对应的时间，时间戳的启始值是随机的，后续的时间戳是在前一个时间戳上的增量，在SendPacket中的时间戳参数表示的是时间戳增量，所以数据流的同步需要计算出时间戳增量。 对于音频数据，由于音频数据的采样率是8000HZ,所以每采样一次需要时间是1/8000s，由于是每20ms封包一次，所以时间戳的增量是(20*10**-3)*8000=160。 对于视频数据，由于视频数据的采样率是90000Hz,所以每采样一次需要时间是1/90000s,如果帧率是25帧/s,所以时间戳增量是90000/25=3600。 在发送端，每发送一个数据包，都打上该数据包对于的时间戳值，只需要向SendPacket 的最后个参数传递时间戳增量，rtp库会自动算出时间戳，并加到发送的rtp数据包首部里边。 在接收端，当收到一个数据包时，获取该rtp数据包的时间戳值，计算出与前一个数据包的时间戳值的差值，乘以该媒体流的时间戳单位，就得出了当前数据包与前一个数据包之间的间隔的打包时间T。所以只要保证在与前一个数据包被提交过后T时间后再提交当前接收到的数据包，那么在rtp层就解决了上边提出的第一个问题。
ESS与AVB音频视频桥网络系统 基于以太网的数字音频传输技术 基于以太网的数字音频传输技术是专业音频行业的一个技术焦点，以其不依赖于控制系统而独立存在的特性，广泛的应用到很多项目中。不仅解决了多线路问题，还解决了远距离传输、数据备份、自动冗余等一系列在模拟传输时代无法面对的问题。 目前比较成熟的以太网音频传输技术主要有CobraNet和EtherSound技术，但这两种技术都各有千秋，在它们此基础上，Audinate于2003年推出了Dante这种融合了很多新技术的数字音频传输技术。 至于下一代网络音视频实时传输技术，新IEEE标准——音视频桥，简称AVB，以即插即用和自主开发的姿态面世，则是全世界现场演出行业所梦寐以求的系统解决方案。 CobraNet网络 CobraNet网络是美国PeakAudio公司开发的一种在以太网上传输专业非压缩音频信号的技术，工作在数据链路层（OSI二层）的低层传输协议，但无法穿过路由器，只能在局域网中传递，音频流不能大于8个数据包Bundle。它可以在100M以太网下单向可以传输64个48kHz、20bit的音频信号通道（48kHz、24bit信号为56路）；除音频信号外，还可以传输RS485串口通信数据及其它非同步IP数据；开放的MIB文件，支持SNMP。一般使用星型（或连星型）网络结构。 EtherSound网络 EtherSound网络是由法国Digigram公司开发的一种基于以太网传输音频信号的技术，工作在数据链路层（OSI二层）的低层传输协议，只能在局域网中传递。传输能力为单方向64个24bit、48kHz（或44.1kHz）采样频率的音频通道。不能传递串口信号以及其它IP数据，具有极低的延时。一般采用菊花链结构或以太网星型结构或者这两种结构的混合形式，通过以太网交换机互相连接。
各种音视频编解码学习详解 编解码学习笔记（一）：基本概念 媒体业务是网络的主要业务之间。尤其移动互联网业务的兴起，在运营商和应用开发商中，媒体业务份量极重，其中媒体的编解码服务涉及需求分析、应用开发、释放license收费等等。最近因为项目的关系，需要理清媒体的codec，比较搞的是，在豆丁网上看运营商的规范标准，同一运营商同样的业务在不同文档中不同的要求，而且有些要求就我看来应当是历史的延续，也就是现在已经很少采用了。所以豆丁上看不出所以然，从wiki上查。中文的wiki信息量有限，很短，而wiki的英文内容内多，删减版也减肥得太过。我在网上还看到一个山寨的中文wiki，长得很像，红色的，叫―天下维客‖。wiki的中文还是很不错的，但是阅读后建议再阅读英文。 我对媒体codec做了一些整理和总结，资料来源于wiki，小部分来源于网络博客的收集。网友资料我们将给出来源。如果资料已经转手几趟就没办法，雁过留声，我们只能给出某个轨迹。 基本概念 编解码 编解码器（codec）指的是一个能够对一个信号或者一个数据流进行变换的设备或者程序。这里指的变换既包括将信号或者数据流进行编码（通常是为了传输、存储或者加密）或者提取得到一个编码流的操作，也包括为了观察或者处理从这个编码流中恢复适合观察或操作的形式的操作。编解码器经常用在视频会议和流媒体等应用中。 容器 很多多媒体数据流需要同时包含音频数据和视频数据，这时通常会加入一些用于音频和视频数据同步的元数据，例如字幕。这三种数据流可能会被不同的程序，进程或者硬件处理，但是当它们传输或者存储的时候，这三种数据通常是被封装在一起的。通常这种封装是通过视频文件格式来实现的，例如常见的*.mpg, *.avi, *.mov, *.mp4, *.rm, *.ogg or *.tta. 这些格式中有些只能使用某些编解码器，而更多可以以容器的方式使用各种编解码器。 FourCC全称Four-Character Codes，是由4个字符（4 bytes）组成，是一种独立标示视频数据流格式的四字节，在wav、avi档案之中会有一段FourCC来描述这个AVI档案，是利用何种codec来编码的。因此wav、avi大量存在等于―IDP3‖的FourCC。 视频是现在电脑中多媒体系统中的重要一环。为了适应储存视频的需要，人们设定了不同的视频文件格式来把视频和音频放在一个文件中，以方便同时回放。视频档实际上都是一个容器里面包裹着不同的轨道，使用的容器的格式关系到视频档的可扩展性。 参数介绍 采样率 采样率（也称为采样速度或者采样频率）定义了每秒从连续信号中提取并组成离散信号的采样个数，它用赫兹（Hz）来表示。采样频率的倒数叫作采样周期或采样时间，它是采样之间的时间间隔。注意不要将采样率与比特率（bit rate，亦称―位速率‖）相混淆。 采样定理表明采样频率必须大于被采样信号带宽的两倍，另外一种等同的说法是奈奎斯特频率必须大于被采样信号的带宽。如果信号的带宽是100Hz，那么为了避免混叠现象采样频率必须大于200Hz。换句话说就是采样频率必须至少是信号中最大频率分量频率的两倍，否则就不能从信号采样中恢复原始信号。 对于语音采样： ?8,000 Hz - 电话所用采样率, 对于人的说话已经足够 ?11,025 Hz ?22,050 Hz - 无线电广播所用采样率 ?32,000 Hz - miniDV 数码视频camcorder、DAT (LP mode)所用采样率 ?44,100 Hz - 音频CD, 也常用于MPEG-1 音频（VCD, SVCD, MP3）所用采样率
浅析DirectShow音视频同步解决完整方案 多媒体处理，不可避免地要解决音视频的同步问题。DirectShow是怎么来实现的呢？我们一起来学习一下。 大家知道，DirectShow结构最核心的部分是Filter Graph Manager：向下控制Graph中的所有Filter，向上对τ贸绦蛱峁┍喑探涌凇Ｆ渲校現ilter Graph Manager实现的很重要一个功能，就是同步音视频的处理。简单地说，就是选一个公共的参考时钟，并且要求给每个Sample都打上时间戳，Video Renderer或Audio Renderer根据Sample的时间戳来控制播放。如果到达Renderer的Sample晚了，则加快Sample的播放；如果早了，则Renderer等待，一直到Sample时间戳的开始时间再开始播放。这个控制过程还引入一个叫Quality Control的反馈机制。 下面，我们来看一下参考时钟(Reference Clock)。所有Filter都参照于同一个时钟，才能统一步调。DirectShow引入了两种时钟时间：Reference time和Stream time。前者是从参考时钟返回的绝对时间(IReferenceClock::GetTime)，数值本身的意义取决于参考时钟的内部实现，利用价值不大；后者是两次从参考时钟读取的数值的差值，实际应用于Filter Graph内部的同步。Stream time在Filter Graph不同状态的取值为： 1. Filter Graph运行时，取值为当前参考时钟时间减去Filter Graph启动时的时间(启动时间是通过调用Filter上的IMediaFilter::Run来设置的)； 2. Filter Graph暂停时，保持为暂停那一刻的Stream time; 3. 执行完一次Seek操作后，复位至零； 4. Filter Graph停止时，取值不确定。 那么，参考时钟究竟是什么东西呢？其实，它只是一个实现了IReferenceClock接口的对象。也就是说，任何一个实现了IReferenceClock接口的对象都可以成为参考时钟。在Filter Graph中，这个对象一般就是一个Filter。(在GraphEdit中，实现了参考时钟的Filter上会显示一个时钟的图标；如果同一个Graph中有多个Fiter实现了参考时钟，当前被Filter Graph Manager使用的那个会高亮度显示。)而且大多数情况下，参考时钟是由Audio Renderer这个Filter提供的，因为声卡上本身带有了硬件定时器资源。接下来的问题是，如果Filter Graph中有多个对象实现了IReferenceClock接口，Filter Graph Manager是如何做出选择的呢？默认的算法如下： 1. 如果应用程序设置了一个参考时钟，则直接使用这个参考时钟。(应用程序通过IMediaFilter:: SetSyncSource设置参考时钟，参数即为参考时钟；如果参数值为NULL，表示Filter Graph不使用参考时钟，以最快的速度处理Sample；可以调用IFilterGraph:: SetDefaultSyncSource来恢复Filter Graph Manager默认的参考时钟。值得注意的是，这时候的IMediaFilter接口应该从Filter Graph Manager上获得，而不是枚举Graph中所有的Filter并分别调用Filter上的这个接口方法。) 2. 如果Graph中有支持IReferenceClock接口的Live Source，则选择这个Live Source。 3. 如果Graph中没有Live Source，则从Renderer依次往上选择一个实现IReferenceClock接口的Filter。
实时音频采集与播放技术的研究 荣治国陈松乔(中南大学信息工程学院 湖南 长沙 410083） 【摘 要】介绍了音频采集、播放的三种技术，分别给出实现模型，并对三种技术作出对比分析，以此提出了声音实时传输的依据。 【关键词】声音采集、播放；媒体控制器；DIRECTSOUND；实时传输 在信息化日益加速的今天，数字多媒体的应用越来越广泛，随着宽带网概念深入人心，数字多媒体进入到了一个更广阔的空间，许多应用课题都围绕着两者展开，其中可视电话、电话会议系统和视频会议系统发展迅速，这些都要涉及到多媒体数据通信。在多媒体数据通信中，要求有良好的实时性，能够对多媒体数据进行细节的操作，如压缩、实时流传输等。而在这些应用之中，因为现实的网络状况还难以满足较好的实时视频通讯，音频数据在其中就更显重要，本文对比分析了实时音频采集和播放技术，以期为音频数据通讯提供参考。 1 音频采集、播放的三种模式 Windows通过高级音频函数、媒体控制接Array口MCI[1、2]设备驱动程序；低级音频函数 MIDI Mapper、低级音频设备驱动；以及 DirectSound提供了音频服务，可以从声卡获 取音频流。图1说明了应用程序与提供音频支 持的Windows成员之间的关系。 使用MCI的方法极其简便，灵活性较差； 使用低级音频函数的方法相对来说难一点，但 是能够对音频数据进行灵活的操控；而采用 DirectSound的方法，控制声音数据灵活，效 果比前二者都好，但实现起来是三者中最难的。下面我将分别介绍如何用三者实现音频的实时采集和播放。 2 使用MCI方法实现音频采集与播放 用MCI方法是很方便的，它对媒体设备控制主要通过命令接口函数mciSendCommand （）或者字符串接口函数mciSendString（）来完成的，这两个函数的作用相同。命令接口函数比命令字符串使用起来要复杂，但它为MCI提供了更为强大的控制能力，下面就介绍命令接口函数的使用。 2.1命令接口函数的原型 MCIERROR mciSendCommand(MCIDEVICEID IDDevice,UINT uMsg, DWORD fdwCommand,DWORD dwParam);
H.323视频会议系统音视频同步原理 针对H.323 视频会议系统设计了一种基于RTP 的音视频同步方法，该方法在严格遵守 RTP 协议的前提下，将音视频数据联系起来通过同一个媒体通道传输，从而达到唇音同步的目的。实验表明：该方法在对图像质量影响很小的情况下，很好地实现了音视频的同步播放，并且具有实现简便，不增加系统负担等优点，具有广泛的实用性。 H.323 视频会议系统中，发送端同时采集到的音视频数据能在接收端同时播放，则认 为唇音同步。终端采集到的音视频数据肯定是同步的，要保证同时播放，就要保证音视频在采集和播放处理过程中消耗的时间相同。IP 网络的特点决定了通过不同通道的音视频数据传输所消耗的时间不可能完全相同，唇音同步是视频会议系统中的一大难题。如果同时采样的音视频数据播放时间偏差在[-80ms,+80ms]以内，用户基本上感觉不到不同步，一 旦超出[-160ms,+160ms],用户就可以明显感觉到，中间部分是临界范围。 1 引言 1.1 文章安排 本文第2 节分析了现有的音视频同步方案的缺点。第3 节详细描述了本文所设计方案 的实现过程。第4 节给出实验数据以及分析结果。第5 节给出结论。 1.2 基本介绍 H.323 视频会议系统中，音视频不同步现象产生的原因除了网络环境外，还有一个是 音视频的分开传输。虽然H.323 建议音视频通过不同道道传输，但是实际传输数据的 RTP[2,3]协议和其底层的UDP 协议都没有规定一对连接只能传输音频或者视频中的一 种，通过同一个通道传输音视频完全可能，而且这样可以最大程度的减少网络原因引起的音视频不同步，本文给出了这一设想的实现方案，并做了验证。 2 现有解决方案 目前最常用的唇音同步方法从思路上可以分为以下两类： 思路一，发送端给每个要发送的RTP 包打上时戳，记录它们的采样时间。接收端通过 增加延时等方式，保证同时采样的数据同时播放。这类方法的实现需要一个中立的第三方参考时钟，需要有RTCP 协议的SR[2,3]的参与，如果这两个条件不具备，同步就失去了依据。 思路二，唇音不同步本质上是由H.323 视频会议系统中音视频的分开传输和处理导致 的，如果采用某种方法将音视频信息关联起来，就可以有效的避免不同步现象。一种实现方案是，将音频按一定的对应关系嵌入到视频中传输，接收端从视频中提取音频数据并重建，从而达到唇音同步的目的[4].该方案实现较复杂，而且采用非标准的RTP 实现方式，会给不同厂商H.323 产品间的互通带来困难。 3 一种新的音视频同步方法 本方法基本思路是：在音视频数据的采样、编码、打包、发送、网络传输、接收、网络 异常处理、拆包、解码、播放这十个处理过程中，采集、编码、打包、拆包和解码的时间基本上固定，不会因为网络环境差异造成时延的差异，而发送、网络传输、接收、网络异常处理四个过程则具有较大的随机性，其处理时间会随着网络性能的不同有较大的差异，进而造成播放时音视频的不同步。因此唇音同步处理的重点就在于保证发送、网络传输、接收、网络异常处理这四个过程中音视频的同步，即图1 中发送同步到组帧同步之间的部分。
多媒体处理，不可避免地要解决音视频的同步问题。DirectShow是怎么来实现的呢？我们一起来学习一下。 大家知道，DirectShow结构最核心的部分是Filter Graph Manager：向下控制Graph中的所有Filter，向上对τ贸绦蛱峁┍喑探涌凇Ｆ渲校現ilter Graph Manager实现的很重要一个功能，就是同步音视频的处理。简单地说，就是选一个公共的参考时钟，并且要求给每个Sample都打上时间戳，Video Renderer或Audio Renderer根据Sample的时间戳来控制播放。如果到达Renderer的Sample晚了，则加快Sample的播放；如果早了，则Renderer 等待，一直到Sample时间戳的开始时间再开始播放。这个控制过程还引入一个叫Quality Control的反馈机制。 下面，我们来看一下参考时钟(Reference Clock)。所有Filter都参照于同一个时钟，才能统一步调。DirectShow引入了两种时钟时间：Reference time和Stream time。前者是从参考时钟返回的绝对时间(IReferenceClock::GetTime)，数值本身的意义取决于参考时钟的内部实现，利用价值不大；后者是两次从参考时钟读取的数值的差值，实际应用于Filter Graph内部的同步。Stream time在Filter Graph不同状态的取值为： 1. Filter Graph运行时，取值为当前参考时钟时间减去Filter Graph启动时的时间(启动时间是通过调用Filter上的IMediaFilter::Run来设置的)； 2. Filter Graph暂停时，保持为暂停那一刻的Stream time; 3. 执行完一次Seek操作后，复位至零； 4. Filter Graph停止时，取值不确定。 那么，参考时钟究竟是什么东西呢？其实，它只是一个实现了IReferenceClock接口的对象。也就是说，任何一个实现了IReferenceClock接口的对象都可以成为参考时钟。在Filter Graph中，这个对象一般就是一个Filter。(在GraphEdit中，实现了参考时钟的Filter上会显示一个时钟的图标；如果同一个Graph中有多个Fiter实现了参考时钟，当前被Filter Graph Manager使用的那个会高亮度显示。)而且大多数情况下，参考时钟是由Audio Renderer这个Filter提供的，因为声卡上本身带有了硬件定时器资源。接下来的问题是，如果Filter Graph 中有多个对象实现了IReferenceClock接口，Filter Graph Manager是如何做出选择的呢？默认的算法如下： 1. 如果应用程序设置了一个参考时钟，则直接使用这个参考时钟。(应用程序通过IMediaFilter:: SetSyncSource设置参考时钟，参数即为参考时钟；如果参数值为NULL，表
下一代下一代网络网络网络音视频音视频音视频实时传输实时传输实时传输技术技术 -- Ethernet AVB 作者作者：：何冬（首席工程师, Dong.He@https://www.doczj.com/doc/483537603.html, ） 黄晟（工程师, Sheng.Huang@https://www.doczj.com/doc/483537603.html, ） Charles Wang （技术总监, Charles.Wang@https://www.doczj.com/doc/483537603.html, ） 哈曼哈曼（（上海上海））研发中心集团技术研究部 摘要 以太网音视频桥接技术（Ethernet Audio/Video Bridging ，以下简称Ethernet A VB ）是一项新的IEEE 802标准，其在传统以太网络的基础上，通过保障带宽（Bandwidth ），限制延迟（Latency ）和精确时钟同步(Time synchronization)，提 供完美的服务质量（Quality of Service, 简称QoS ） ，以支持各种基于音频、视频的网络多媒体应用。Ethernet A VB 关注于增强传统以太网的实时音视频性能，同时又保持了100%向后兼容传统以太网，是极具发展潜力的下一代网络音视频实时传输技术。 引言 1982年12月IEEE 802.3标准的发布，标志着以太网技术的起步。经过不到30年的发展时间，以太网的传输速度已经从最初的10Mbps 发展到100Mbps 、1000Mbps 、10Gbps ，甚至即将出现的100Gbps 。以太网低廉的端口价格和优越的性能，使得以太网占据了整个局域网的85%左右，而基于以太网的网桥、集线器、交换机和路由器则构成了互联网体系相当重要的组成部分。 近十几年来，消费者对于以太网上的多媒体应用的需求日益剧增，这对网络的带宽及服务质量都提出了更高的要求。不过，由于以太网原本只设计用于处理纯粹的静态非实时数据和保证其可靠性，至于顺序和包延迟等并非作为重要的考虑因素。尽管传统二层网络已经引入了优先级(Priority)机制，三层网络也已内置了服务质量（QoS ）机制，但由于多媒体实时流量与普通异步TCP 流量存在着资源竞争，导致了过多的时延（Delay ）和抖动（Jitter ），使得传统的以太网无法从根本上满足语音、多媒体及其它动态内容等实时数据的传输需要。 IEEE 802.1 A VB 工作组正致力于制定一系列的新标准， 对现有的以太网进行功能扩展，通过建立高质量、低延迟、时间同步的音视频以太网络，为家庭或企业提供各种普通数据及实时音视频流的局域网配套解决方案。 Ethernet A VB 网络的构成 为了在以太网上提供同步化低延迟的实时流媒体服务，需要建立A VB 网络，称之为A VB “云”（Cloud ）。A VB “云”的建立需要至少速度在100Mbps 以上的全双工（Full-duplex ）以太链路，这就需要能保障传输延迟的A VB 交换机(Switch)和终端设备(End Point)，以及逻辑链路发现协议（IEEE 802.1AB - LLDP ），用于设备之间交换支持A VB 的协议信息。 如图1所示，在A VB “云”内，由于延迟和服务质量得到保障，能够高质
【转】如何同步视频 2010-07-16 10:18 转载自fandy586 最终编辑fandy586 如何同步视频 PTS和DTS 幸运的是，音频和视频流都有一些关于以多快速度和什么时间来播放它们的信息在里面。音频流有采样，视频流果我们只是简单的通过数帧和乘以帧率的方式来同步视频，那么就很有可能会失去同步。于是作为一种补充，在码时间戳）和PTS（显示时间戳）的机制。为了这两个参数，你需要了解电影存放的方式。像MPEG等格式，双向bidrectional）的方式。另外两种帧被叫做I帧和P帧（I表示关键帧，P表示预测帧）。I帧包含了某个特前面的I帧和P帧并且使用比较或者差分的方式来编码。B帧与P帧有点类似，但是它是依赖于前面和后面的帧为什么我们可能在调用avcodec_decode_video以后会得不到一帧图像。 所以对于一个电影，帧是这样来显示的：I B B P。现在我们需要在显示B帧之前知道P帧中的信息。因此，帧储：IPBB。这就是为什么我们会有一个解码时间戳和一个显示时间戳的原因。解码时间戳告诉我们什么时候需们什么时候需要显示。所以，在这种情况下，我们的流可以是这样的： PTS: 1 4 2 3 DTS: 1 2 3 4 Stream: I P B B 通常PTS和DTS只有在流中有B帧的时候会不同。 当我们调用av_read_frame()得到一个包的时候，PTS和DTS的信息也会保存在包中。但是我们真正想要的P 原始帧的PTS，这样我们才能知道什么时候来显示它。然而，我们从avcodec_decode_video()函数中得到的帧并没有包含有用的PTS值（注意：AVFrame并没有包含时间戳信息，但当我们等到帧的时候并不是我们想要的新排序包以便于被avcodec_decode_video()函数处理的包的DTS可以总是与其返回的PTS相同。但是，另外是总能得到这个信息。 不用担心，因为有另外一种办法可以找到帧的PTS，我们可以让程序自己来重新排序包。我们保存一帧的第一个这一帧的PTS。我们可以通过函数avcodec_decode_video()来计算出哪个包是一帧的第一个包。怎样实现呢？帧的时候，avcodec_decode_video()将调用一个函数来为一帧申请一个缓冲。当然，ffmpeg允许我们重新定义我们制作了一个新的函数来保存一个包的时间戳。 当然，尽管那样，我们可能还是得不到一个正确的时间戳。我们将在后面处理这个问题。 同步
－2017－ 0引言 实时音视频数据采集和网络传输系统应用广泛，如视频会议、远程教育、实时视频监控、视频通话等。多媒体技术的发展过程中产生了各种各样的文件格式和数据压缩格式，实时音视频数据采集和传输技术的发展历程和多媒体技术的发展历程类似，也有各种不同的采集技术和传输技术可供选择，根据实际问题的需要，选择合适的技术设计音视频数据实时采集和传输系统，是十分重要的。在Windows 环境下，实时音视频采集可以使用采集设备(如采集卡)自带的SDK 进行，此类方法的优点是使用方便，缺点是硬件相关性强，不够灵活，不能适应复杂应用场合的需要。更常用的是使用微软公司提供的VFW (video for Windows )、DirectShow 和Windows Media 。 1使用VFW 进行音视频数据的实时采集 为解决数字音视频应用领域的问题，微软公司在1992年推 出了VFW [7]，应用程序使用VFW 提供的接口可以方便地实现音视频数据实时采集、编辑、播放等通用功能以及开发各种复杂 的应用。在VC++6.0上使用VFW 要包含文件vfw.h 和vfw32.lib 。 视频捕获功能主要存在于VFW 的AVICAP 模块，应用程序创建一个A VICAP 窗口，并通过向窗口发送消息来控制窗口的行为。AVICAP 对视频捕获提供全面的支持，如将捕获到的数据写入磁盘文件和预览，然而，对于其它非文件型的使用则不够灵活，视频的格式和属性不可以在程序运行过程中通过编程进行改变，只能通过对话框进行设置。在将实时音视频数据采集到文件的场合，VFW 重点支持的是A VI 文件。使用VFW 进行音视频捕获的主要步骤为[6]：创建捕获窗口、注册回调函数、获取捕获窗口的缺省设置、设置捕获窗口参数、与捕获设备连接并获取捕获设备能力、设置捕获窗口显示模式、捕获视频数据到文件或者缓存，工作完毕，断开与捕获设备的连接。VFW 的其它主要功能包括音视频数据的压缩和解压、A VI 文件的编辑处理、以及图像显示(DrawDib 模块)。 从Windows 98开始，微软推出了WDM (Windows driver mode )设备驱动模式，现在的音视频数据采集设备都支持WDM ，经过一层模拟子系统处理后，虽然VFW 可以在Win98、Win200、WinXP 等各种平台上使用，但由于VFW 体系在视频 收稿日期：2007-10-18E-mail ：xudianwu@https://www.doczj.com/doc/483537603.html, 作者简介：徐殿武(1949－)，男，硕士，讲师，研究方向为图像处理和程序设计。 实时音视频数据采集和传输系统设计方法的比较研究 徐殿武 (中国石油大学(北京)机电学院，北京102249) 摘 要：在Windows 环境下设计实时音视频数据采集和传输系统常用的3种方法是VFW 、DirectShow 或Windows Media 。这3种方法代表了Windows 在实时音视频数据采集和传输技术上的主要内容，每种方法各有自己的适用场合和优缺点。在系统仿真、电子游戏、音视频数据非线性编辑等应用中，最好选用DirectShow 。在需要将采集到的数据进行实时网络传输的场合，使用Windows Media 会收到事半功倍的效果。而VFW 在数据采集方面用的已经不多，但在AVI-2文件的非线性编辑处理和图像显示方面仍然具有广泛的应用。 关键词：音频;视频;数据采集;多媒体;实时中图法分类号：TP311.1 文献标识码：A 文章编号：1000-7024(2008)08-2017-03 Comparison and study on methods of real-time capture and transmission of audio and video data system design XU Dian-wu (Faculty of Mechanical and Electronic Engineering,China University of Petroleum,Beijing 102249,China ) Abstract ：Under Windows environment,the main design methods of real-time capture and transmission of audio and video data are VFW,DirectShow,and Windows Media.The advantages and disadvantages of above three methods are discussed,and at the same time,the main programming steps are presented.In the case of system emulation,games,video editing,using DirectShow is a better choice.In the case of network application,using Windows Media is the best.VFW is an old method for audio and video capturing,but in the case of A VI-2file nonlinear editing and image display,VFW is still useful and convenient.Key words ：audio;video;data acquisition;multimedia;real-time 2008年4月计算机工程与设计 Apr.2008 第29卷第8期Vol.29 No.8 Computer Engineering and Design
视频文件音视频不同步的调整 (2008-03-15 11:17:39) ◆视频文件音视频不同步的调整◆ 大家可能经常会遇到辛辛苦苦下载或者制作的视频竟然声音画面不同步，实在是很令人郁闷。造成音视频不同步主要有三种原因：1、机器配置太低，播放高码率的视频文件容易造成不同步；2、片子本身就不同步；3、软件使用不当造成转换后的文件不同步。常见于 avi 文件和 rm/rmvb 文件. 一、AVI 对于 avi 文件，可以在 VirtualDub 中进行调整，方法如下，打开一个 avi 文件，选择“音频”菜单里的“交错”，如下图: 输入好确定以后，在“音频”和“视频”菜单里都选择“直接复制数据流”，然后再“另
存AVI”就可以了。如果不合适，可以反复调整数值，直到同步为止。 二、RM/RMVB 对于这类视频，通常都是由于片源问题而导致压制后音视频不同步。 推荐软件：RealMedia Analyzer，这个软件目前没有 GUI 界面的，是个命令行软件，不过使用也还算简单，方法如下： 解压到一个文件以后，把你要调整的文件重命名为“A.rmvb”或“A.rm”，复制到这个文件夹里，如下图：
用记事本打开“delayaudio.bat”这个文件，按照下图中的说明进行修改： 反复调整直到满意即可! 附：RMVB音频的修改 注：若发现RealMedia Editor无法编辑重新合并之后的RMVB，可用ERP、RPG的[RM编辑器]另存一次即可。 Q：RMVB本身很小聲，要如何調整音量？ A: 用RealMedia Analyzer分离那rmvb为视频和音频 rma -s bad.rm 找出音频的rm，如001.rm，用RMVB压制软件(ERP、RPG)把那音频调大音量再压为audio.rm 用RealMedia Analyzer合并分离的声音和图像
银行视频监控系统解决方案 一、项目概述 随着经济的进步和银行业竞争的加剧，银行服务网点（营业部、ATM机、自助服务点）正以前所未有的速度和数量覆盖着城市的每一个角落。这一进程给客户带来更多便利，而给银行保卫部门带来的却是一个非常棘手的安全问题。同时由于社会上一些不良份子经常恶意毁坏柜员机现象十分普遍，甚至街头的流浪者也进入自助银行“借宿”或是在炎热的夏日进入里面避暑，给银行的保卫工作添加不少麻烦。为了遏制和打击犯罪、减少金融风险，银行需要对重要地点和营业场所进行有效和可靠的监控，实现对重要地点和营业场所的音、视频资料进行录像保存。 传统模拟系统在实际应用中可以满足本地监控的需求，但无法达到远程连网。并且出入银行的人员相对复杂所以这就要求银行能够全方位的对银行进行监控，基于这些客观因素的存在，广州市思正电子科技有限公司从音频监控领域逐渐延伸至IP网络对讲系统与网络视频会议系统。从产品的设计研发到软件系统平台的搭建，思正正有条不紊地发展覆盖着中国大部分区域。 银行位于城市的各个角落，属于国家的重点安全防范单位。它的监控范围主要分为三大部分，柜员监控、安防监控和自助服务区监控，其中柜员监控主要是看营业员的操作状况以及和顾客之间的对话，因此拟订选用思正COTT系列的高保真、高灵敏度拾音器；安防监控不但要监看白天营业大厅的状况，还要防止晚上非法人员入侵，对门口，通道等部位更是要24小时监控，因此根据具体情况，选用类型摄像机；对于自助服务区更是24小时都处于营业状态，无法从物理上防止非法人员入侵，只能对现场进行实时监控和录像，并且对内部人员的取钞和放钞也要进行实时监控和录像，当然，涉及到一些密码会用一些技术手段处理掉，使得不能外泄，根据安装位置不同， 所有的前端视频都要集中到支行的监控中心进行录像，其中安防监控和自助区的监控图像要能通过网络传输到分行保卫处。 二、设计原则和依据 1、设计原则 根据银行的总体结构，并充分考虑现场实际情况，设计前端采用广州市思正的双核数字拾音器，数字硬盘录像主机，可以实现本地显示，循环录像，检索回放以及远程访问控制等。 a、先进性： 在投资费用许可的情况下，系统采用当今先进的技术和设备，一方面能反映系统所具有的先进水平，另一方面又使系统具有强大的发展潜力，以便该系统在尽可能的时间内与社会发展相适应。 b、可靠性： 系统最重要的就是可靠性，系统一旦瘫痪的后果将是难以想象的，因此系统必须可靠地、能连续地运行，系统设计时在成本接受的条件下，从系统结构、设备选择、产品供应商的技术服务及维修响应能力等各方面均应严格要求，使得故障发生的可能性尽可能少。即便是出现故障时，影响面也要尽可能小。 c、安全性： 对于安全防范系统，其本身的安全性能不可忽视，系统设计时，必须采取多种手段防止本系统各种形式与途径的非法破坏。 d、可扩充性： 系统设计时应充分考虑今后的发展需要，系统应具有预备容量的扩充与升级换代的可能。 e、规范性： 由于本系统是一个严格的综合性系统，在系统的设计与施工过程中应参考各方面的标准与规范，严格遵从各项技术规定，做好系统的标准化设计与施工。 三、设计方案 本套视频监控系统主要是由摄像部分、传输部分、显示和记录部分网络视频远程传输等部分组成。 4.1、拾音器部分 拾音器是电视监控系统的前沿部分，是整个系统的“耳朵”。它布置在被监视场所的某一位置上，使其视场角能覆盖整个被监视的各个部位。有时，被监视场所面积较大，为了节省拾音器所用的数量、一般采取阵列的方
信息·技术信息记录材料 2019年2月 第20卷第2期 1 背景 多媒体时代，用户对音视频的展现技术以及便捷性有了更高的需求，在现有技术中，音视频分屏技术通常是通过HDMI、VGA或DVI等方式分屏到多台显示终端，这种有线分屏输出技术，对设备接口有一定的要求，用户的输出显示设备不一定有对应的接口，且在使用过程中，需要将输入输出设备通过数据线连接，如果显示设备距离较远，还会增加布线的成本，因此，我们需要一种方法可以摆脱数据线和接口的束缚，基于无线传输的技术完成音视频传输。 2 通过WiFi实现实时传输音视频的优点 本文提供一种通过WiFi实现实时传输音视频的方法，实现点对点数据传输的同时按自定义协议协商信息进行数据处理，大大降低网络带宽的负载，提高传输效率。 该方法具有如下优点：（1）基于无线WiFi完成的音视频数据传输，通过一键配对连接，减少各种数据线拔插等操作，变相降低了传统分屏显示的时间成本和经济成本；（2）设备自动协商能力，以最佳采集参数、传输参数以及编解码方式处理数据，大大提高音视频数据传输处理效率；（3）通过自定义协议的协商，完成设备点对点的配对连接，采用单播方式进行音视频数据的传输，且数据经过编码压缩等，降低网络带宽的负载；（4）音视频数据采集、传输、处理与配对协商相互独立，可灵活扩展多种使用场景，大大提升用户体验。 3 通过WiFi实现实时传输音视频的具体实施步骤 一种通过WiFi实现实时传输音视频的方法及系统 林 勇 （福建星网锐捷通讯股份有限公司 福建 福州 350002）【摘要 摘要】针对传统音视频系统布线成本高、耗时长的缺点，本文基于目前使用广泛的 】针对传统音视频系统布线成本高、耗时长的缺点，本文基于目前使用广泛的WiFi技术，搭建了一套音视频数据传输系统，通过WPS协议和自定义协议，能够一键配对，快速建立通信链路，实现了对音视频的实时传输，大大简化了用户配置过程，有效降低了传统有线传输时的布线成本，极大的扩展了使用场景。 【关键词 关键词】WiFi；实时传输；音视频 】WiFi；实时传输；音视频 【中图分类号 中图分类号】TP274 【 】TP274 【文献标识码 文献标识码】A 【 】A 【文章编号 文章编号】1009-5624（2019）02-0046-02 】1009-5624（2019）02-0046-02 录制带来了更多的困难，这给节目录制设备和处理机器提出了更高的要求。在这种情况下嵌入式数字音频技术孕育而生，它能够为电视节目的录制和整理过程省去许多步骤。不仅如此，嵌入式数字音频技术还能够完美的应对现场节目录制中现场收集信号所带来的差异性问题。以往在收集现场音频时，需要提前在场地设计音乐场景来达到节目的最佳观赏效果，但是这种方法的弊端在于后期制作时容易遭人诟病，而且为了营造特定的场景所需要的设备过于繁多，不利于运输，嵌入式技术在现代广播电视建设中有着举足轻重的地位。 4 结语 广播电视行业正处于一个发展迅猛的的势头上，加快广播电视现代化建设是广播电视未来发展的趋势所在数字化音频技术不仅可以满足人们的更高要求，还可以为在节目的录制和和后期制作中提供更为便捷的操作，是现代化广播电视的有力推动者。数字音频技术在广播电视中已经大量投入使用，但是其潜力还远远没有被发掘出来，加深对数字音频技术的研究可以有效的推动我国广播行业的发展。 【参考文献】 [1]王远昌.现代广播电视工程建设中的数字音频技术研究初探[J].电子世界，2018(1):178-179. [2]席琼英.广播电视工程建设中数字音频技术的应用[J].西部广播电视，2017(2):197-197. [3]沈雅娜.试论广播电视工程中数字音频技术的应用[J].数码世界，2017(6):245-245. DOI:10.16009/https://www.doczj.com/doc/483537603.html,13-1295/tq.2019.02.027 46