未来5G编码器之海思小于100毫秒低延迟直播方案评测

本文主要是介绍未来5G编码器之海思小于100毫秒低延迟直播方案评测,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

本文摘自:https://blog.csdn.net/weixin_45326556/article/details/95058054
很多人对于直播的带来的延时还是挺在意的,下面我分享的这篇文章能给大家带来个技术上的指引,好了,坐下来慢慢看:

背景

最近接触了许多客户,许多是做安全方面产品的客户,有些还涉及到jun队后勤的等等,他们普遍对采集延迟,编码延迟,传输延迟等都有很大关注。例如有个客户是做反狙击探测的,那可是与生命相关的,容不得试错的(PS:我无法判断海思Hi3531D/Hi3521D系列产品是否适合做这种高实时性的产品,当然做个评估或者算法验证完全是可以的)。

测量方法

精准测试延迟的方法要用专业仪器来测量,或者在程序中记录精准时间来判断,这些方法过于专业,也不方便展示,本文采用的测量方法是目测法,这个方法不大精准,但最容易展示。
在这里插入图片描述
主板参考链接:https://item.taobao.com/item.htm?spm=a2oq0.12575281.0.0.15d11debUtUQr8&ft=t&id=630502728823
    如上图所,通常直播是经过采集,编码,网络输出,网络接收,解码,显示输出,经过这几大环节后,用户才能看到直播的画面,其总延迟是T1-T3;采集延迟为T1-T2。直播延迟还跟网络协议有关,其中UDP,RTMP和RTSP延迟相对较小,HTTP延迟偏大,延迟最大的是HLS,这种技术是切片技术,很适合做对延迟要求不高的网络直播(例如非互动的单向直播,IPTV就是这类),该技术最大的好处就是能在网络带宽波动很大的环境下也能保持流畅(其实就是因为缓冲够大嘛)。

测试结果

为了抓拍到T1,T2,T3,我们使用单反相机快速连拍功能,分别对UDP,RTSP和RTMP协议的测试进行抓拍,然后对抓拍到图片序列进行统计分析。抓拍到的图片序列已经上传到百度网盘,需要的可以从我们百度网盘上下载:
链接:https://pan.baidu.com/s/1ySnVeRHsuvzvtywh8xDz1g
提取码:qx9x
在这里插入图片描述
    如上图所示,做为信号源的笔记本显示的时间码是19:35:55.217,而编码板采集预览显示的时间码也是19:35:55.217,说明采集延迟为T1-T2=217-217=0,忽略不计;解码板通过网络接收来自编码板的网络流,解码后通过HDMI输出,其显示的时间码是19:35:55.174,那说明延迟为T1-T3=217-174=43,也就是延迟为43毫秒。为了方便用户查看和对比,我们把拍下来的照片的时间码做了记录,并用EXCEL表做了计算,参见下表。
在这里插入图片描述
    从上表可以看出,UDP(TS封装)的平均延迟为71.1毫秒,由于我们的TS封装是使用了FFMPEG来进行封装的,所以封装延迟较大,如果采用RAW H264/H265 UDP,估计延迟会大大降低;RTSP OVER UDP平均延迟为83豪秒,还真搞不懂这个延迟什么会这么大;RTMP的延迟仅为52.6毫秒,真是有点意外,而且每个采样的延迟几乎都是在43毫秒左右,很均匀,不像TS-UDP和RTSP OVER UDP每个采样测出的延迟数据波动有点大。

源程序

编码端源程序

完整的工程参见:https://gitee.com/LinkPi/3531D/tree/master/LowLatencyENC

//main.cpp
#include <QCoreApplication>
#include "Link.h"#define RTSP
//#define UDP
//#define RTMPint main(int argc, char *argv[])
{QCoreApplication a(argc, argv);Link::init();LinkObject *vi=Link::create("InputVi");QVariantMap dataVi;dataVi["interface"]="HDMI-A";vi->start(dataVi);LinkObject *vo=Link::create("OutputVo");QVariantMap dataVo;dataVo["type"]="hdmi";dataVo["lowLatency"]=true;vo->start(dataVo);vi->linkV(vo);LinkObject *encV=Link::create("EncodeV");QVariantMap dataEncV;dataEncV["codec"]="h264";dataEncV["framerate"]=60;dataEncV["width"]=1920;dataEncV["height"]=1080;dataEncV["bitrate"]=8000;dataEncV["lowLatency"]=true;encV->start(dataEncV);LinkObject *mux=Link::create("Mux");QVariantMap dataRtsp;
#ifdef RTSPdataRtsp["path"]="mem://test";dataRtsp["format"]="rtsp";
#elif UDPdataRtsp["path"]="mem://test";dataRtsp["format"]="mpegts";
#elif RTMPdataRtsp["path"]="rtmp://127.0.0.1/live/test";dataRtsp["format"]="flv";
#endifdataRtsp["mute"]=true;mux->start(dataRtsp);#ifdef RTSPLinkObject *rtspServer=Link::create("Rtsp");rtspServer->start();vi->linkV(encV)->linkV(mux)->linkV(rtspServer);
#elif UDPLinkObject *udp=Link::create("TSUdp");QVariantMap dataUDP;dataUDP["ip"]="192.168.1.77";dataUDP["port"]=1234;udp->start(dataUDP);vi->linkV(encV)->linkV(mux)->linkV(udp);
#elif RTMPvi->linkV(encV)->linkV(mux);
#endifreturn a.exec();

解码端源程序

完整的工程参见:https://gitee.com/LinkPi/3531D/tree/master/LowLatencyDEC

//main.cpp
#include <QCoreApplication>
#include "Link.h"#define RTSP
//#define UDP
//#define RTMPint main(int argc, char *argv[])
{QCoreApplication a(argc, argv);Link::init();LinkObject *vo=Link::create("OutputVo");QVariantMap dataVo;dataVo["type"]="hdmi";vo->start(dataVo);LinkObject *net=Link::create("InputNet");QVariantMap dataNet;
#ifdef RTSPdataNet["path"]="rtsp://192.168.1.76/test";
#elif UDPdataNet["path"]="udp://@:1234";
#elif RTMPdataNet["path"]="rtmp://192.168.1.76/live/test";
#endifdataNet["protocol"]="udp";dataNet["buffer"]=false;dataNet["sync"]=false;net->start(dataNet);LinkObject *dec=Link::create("DecodeV");QVariantMap dataDec;dataDec["lowLatency"]=true;dec->start(dataDec);net->linkV(dec)->linkV(vo);return a.exec();
}

抓拍的图片序列

为了方便阅读,我们这里对每一种网络协议抓拍到的图片展示三幅图,若需要查看全部的图,请到网盘下载。

1.TS over UDP

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2.RTSP over UDP

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3.RTMP

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

总结

从以上评测数据来看,海思芯片不愧称的上是业内领头羊,ENC5完美的发挥了它的优势性能。希望这篇文章能给大家技术上的指引,谢谢大家能看完本文,还请轻台贵手,多多点赞和支持,关注我哦!

这篇关于未来5G编码器之海思小于100毫秒低延迟直播方案评测的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/391816

相关文章

MyBatis Plus实现时间字段自动填充的完整方案

《MyBatisPlus实现时间字段自动填充的完整方案》在日常开发中,我们经常需要记录数据的创建时间和更新时间,传统的做法是在每次插入或更新操作时手动设置这些时间字段,这种方式不仅繁琐,还容易遗漏,... 目录前言解决目标技术栈实现步骤1. 实体类注解配置2. 创建元数据处理器3. 服务层代码优化填充机制详

防止Linux rm命令误操作的多场景防护方案与实践

《防止Linuxrm命令误操作的多场景防护方案与实践》在Linux系统中,rm命令是删除文件和目录的高效工具,但一旦误操作,如执行rm-rf/或rm-rf/*,极易导致系统数据灾难,本文针对不同场景... 目录引言理解 rm 命令及误操作风险rm 命令基础常见误操作案例防护方案使用 rm编程 别名及安全删除

Python实现批量CSV转Excel的高性能处理方案

《Python实现批量CSV转Excel的高性能处理方案》在日常办公中,我们经常需要将CSV格式的数据转换为Excel文件,本文将介绍一个基于Python的高性能解决方案,感兴趣的小伙伴可以跟随小编一... 目录一、场景需求二、技术方案三、核心代码四、批量处理方案五、性能优化六、使用示例完整代码七、小结一、

C#使用Spire.Doc for .NET实现HTML转Word的高效方案

《C#使用Spire.Docfor.NET实现HTML转Word的高效方案》在Web开发中,HTML内容的生成与处理是高频需求,然而,当用户需要将HTML页面或动态生成的HTML字符串转换为Wor... 目录引言一、html转Word的典型场景与挑战二、用 Spire.Doc 实现 HTML 转 Word1

使用Python实现Word文档的自动化对比方案

《使用Python实现Word文档的自动化对比方案》我们经常需要比较两个Word文档的版本差异,无论是合同修订、论文修改还是代码文档更新,人工比对不仅效率低下,还容易遗漏关键改动,下面通过一个实际案例... 目录引言一、使用python-docx库解析文档结构二、使用difflib进行差异比对三、高级对比方

Python多线程应用中的卡死问题优化方案指南

《Python多线程应用中的卡死问题优化方案指南》在利用Python语言开发某查询软件时,遇到了点击搜索按钮后软件卡死的问题,本文将简单分析一下出现的原因以及对应的优化方案,希望对大家有所帮助... 目录问题描述优化方案1. 网络请求优化2. 多线程架构优化3. 全局异常处理4. 配置管理优化优化效果1.

MySQL容灾备份的实现方案

《MySQL容灾备份的实现方案》进行MySQL的容灾备份是确保数据安全和业务连续性的关键步骤,容灾备份可以分为本地备份和远程备份,主要包括逻辑备份和物理备份两种方式,下面就来具体介绍一下... 目录一、逻辑备份1. 使用mysqldump进行逻辑备份1.1 全库备份1.2 单库备份1.3 单表备份2. 恢复

redis中session会话共享的三种方案

《redis中session会话共享的三种方案》本文探讨了分布式系统中Session共享的三种解决方案,包括粘性会话、Session复制以及基于Redis的集中存储,具有一定的参考价值,感兴趣的可以了... 目录三种解决方案粘性会话(Sticky Sessions)Session复制Redis统一存储Spr

SpringBoot实现虚拟线程的方案

《SpringBoot实现虚拟线程的方案》Java19引入虚拟线程,本文就来介绍一下SpringBoot实现虚拟线程的方案,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,... 目录什么是虚拟线程虚拟线程和普通线程的区别SpringBoot使用虚拟线程配置@Async性能对比H

MySQL中读写分离方案对比分析与选型建议

《MySQL中读写分离方案对比分析与选型建议》MySQL读写分离是提升数据库可用性和性能的常见手段,本文将围绕现实生产环境中常见的几种读写分离模式进行系统对比,希望对大家有所帮助... 目录一、问题背景介绍二、多种解决方案对比2.1 原生mysql主从复制2.2 Proxy层中间件:ProxySQL2.3