sdp | 易学教程

WebRTC: SDP in Firefox with VP9 encoding

阅读更多关于 WebRTC: SDP in Firefox with VP9 encoding

问题 I am not able to connect a call from Firefox to Firefox using VP9, allthough I have tried modifying the SDP in several different ways. I have a site similar to https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/, where I simply remove the unwanted codec. In Firefox, VP9 is not listed when I initiate the call. I have enabled VP9 on both sender and receiver, by setting media.mediasource.webm.enabled to true in about:config . Does anybody know how to modify it correctly to get

手撕RTSP协议系列（2）——Rtsp消息格式

阅读更多关于手撕RTSP协议系列（2）——Rtsp消息格式

点击上方蓝字关注我们上一篇我们简单介绍了rtsp协议，本篇我们来看一下rtsp的消息结构！ RTSP消息分为两大类，一类是请求消息（request），一类是回应消息（ressponse）！ 1 请求消息（request）请求消息的格式如下：说明：请求消息由方法+URI+RTSP版本开头，之后跟一条或多条消息！ URI ：表示接收方的地址，如rtsp://192.168.1.201:554 CR ：表示回车 LF ：表示换行 RTSP使用消息类型和消息体来表示不同类型的消息。最后一条消息要使用两个CR LF。我们通过wireshark的抓包来实际看一个RTSP的请求消息：如图中所示，该RTSP请求消息的方法为OPTIONS，请求的目标地址为rtsp://192.17.1.63:554，RTSP的版本为1.0；接下来包含两种类型的消息，第一种为CSeq表示序列号，本次请求的序列号为1（服务器端回复此请求的数据包的序列号也是1）；第二种为User-Agent，表示用户代理，值为 “Lavf58.42.100”；由于User-Agent为最后一条消息，其后要跟两组回车和换行！我们接下来看一下回应消息的格式： 2 回应消息(response) 回应消息由RTSP版本+状态码+解释开头，之后跟一条或多条消息！说明：状态码：表示状态，同http的返回状态

SDP for FFMPEG (IP addresses)

阅读更多关于 SDP for FFMPEG (IP addresses)

问题 I'm receiving audio via RTP, so I'm opening input from the SDP I generate. Media is coming from Port_sender , IP_sender . IP and port of the server for listening: IP_server , Port_server . Here is my SDP template. What of {Port_sender, IP_sender, IP_server, Port_server} should I put in {%1%, %2%, %3%} for the SDP that I feed to ffmpeg and for the SDP that I give back to the sender? \n\nv=0\n o=- 0 0 IN IP4 %1%\n s=name\n c=IN IP4 %2%\n t=0 0\n a=tool:libavformat 57.3.100\n m=audio %3% RTP/AVP

手撕RTSP协议系列（1）——Rtsp基本流程

阅读更多关于手撕RTSP协议系列（1）——Rtsp基本流程

点击上方蓝字关注我们哈喽，久违的小伙伴们！之前开了一个专辑手撕了rtmp协议！对于流媒体协议，rtsp协议也是很常见的，接下来我们继续手撕，手撕rtsp协议！本篇我们首先来简单了解一下rtsp协议并对其连接过程做一个概览！ 1 rtsp协议简介 rtsp，英文全称 Real Time Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议！协议主要规定定了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP体系结位于RTP和RTCP之上（RTCP用于控制传输，RTP用于数据传输），使用TCP或UDP完成数据传输！ 2 rtsp基本交互过程假设我们现在要向一个RTSP的sever发送请求获取数据，基本流程如下： OPTIONS C--->S 客户端向服务器端发现OPTIONS，请求可用的方法。 S--->C 服务器端回复客户端，消息中包含当前可用的方法。 DESCRIBE C--->S 客户端向服务器请求媒体描述文件，一般通过rtsp开头的url来发起请求，格式为sdp。 S--->C 服务器回复客户端sdp文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。 SETUP C--->S 客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据

C++ Video Stream detect FPS

阅读更多关于 C++ Video Stream detect FPS

问题 I try to get the correct fps of a video stream from an axis or eneo camera. rtsp://192.168.0.1:554/axis-media/media.amp I use cv::VideoCapture::get(CV_CAP_PROP_FPS); but with some cameras the result is invalid for example the result is 180000 but the correct value is 25. I have check it with wireshark and see the value in the SDP Protocol is correct. Media Attribute (a): framerate:25.000000 Which Information cv::VideoCapture::get read? 回答1: OpenCV Isn't very good at this sort of thing, and

How to use the constant resolution during webrtc video transmission?

阅读更多关于 How to use the constant resolution during webrtc video transmission?

问题 I am using janus to build my webrtc SFU server. I need the chrome browser to send the video resolution from a start to a fixed value and remain unchanged during the transfer. Where should I set it? I tried setting the degradationPreference in the js code, but it didn't work, the resolution will still change, it seems that chrome does not support this parameter. var senderList = config.pc.getSenders(); var sender = config.pc.getSenders().find(function(s) {return s.track.kind == "video"}); if

How to use the constant resolution during webrtc video transmission?

阅读更多关于 How to use the constant resolution during webrtc video transmission?

WebRTC 系列之视频辅流

阅读更多关于 WebRTC 系列之视频辅流

作者：网易云信资深客户端开发工程师陶金亮近几年，实时音视频领域越来越热，业界很多音视频引擎都是基于 WebRTC 进行实现的。本文主要介绍 WebRTC 在视频辅流上的需求背景以及相关技术实现。 WebRTC 中的 SDP 支持两种方案： PlanB 方案和 Unified Plan 方案。早期我们使用多PeerConnection的 Plan B 方案中只支持一条视频流发送，这条视频流，我们称之为”主流”。目前我们使用单 PeerConnection 的 Unified Plan 方案，新增一条视频辅流，何为视频”辅流”？视频辅流是指第二条视频流，一般用于屏幕共享。需求背景随着业务的发展，一路视频流满足不了更多实际业务场景的需求，例如在多人视频聊天、网易会议以及其他在线教育场景下，需要同时发送两路视频流：一路是摄像头流，另一路是屏幕共享流。但是，目前使用 SDK 分享屏幕时，采用的是从摄像头采集通道进行屏幕分享。在该方案下，分享者只有一路上行视频流，该场景中要么上行摄像头画面，要么上行屏幕画面，两者是互斥的。除非实例一个新的 SDK 专门采集并发送屏幕画面，但实例两个 SDK 的方案在业务层处理起来十分麻烦且会存在许多问题，例如如何处理两个流间的关系等。在 WebRTC 场景中，还存在一种可以单独为屏幕分享开启一路上行视频流的方案，并称之为“辅流

Gartner 2016-2020技术趋势预测分析报告

阅读更多关于 Gartner 2016-2020技术趋势预测分析报告

多年以来，Gartner的研究数据与咨询服务被认为是客观技术思想领导的权威来源。作为全球IT市场预测与咨询的龙头，Gartner每年对外输出数十份市场研究报告，成为全球众多企业在市场分析、技术选择、项目论证、投资决策上的重要参考，所以Gartner每年预测的东西到底准不准？实现率有多少？基于多年对IT及前沿技术的关注和积累，腾讯安全联合腾讯TEG安全平台部天幕团队对Gartner 2016年-2020年的年度战略技术趋势报告和安全项目报告进行回顾与应用情况评估。一、报告概述报告回顾了 2016年-2020年Gartner的年度战略技术趋势报告和安全项目报告，这是具有代表性的两份报告。报告将按年份依次回顾每年的技术预测，并根据当前的应用情况评判是否准确，同时列出该技术领域的现有代表厂商。主要回顾报告包括：《Gartner 年度十大战略技术趋势》（2016-2020）《Gartner 年度十大安全项目》（2016-2020）二、主要发现总体来看，除了2016年在十大信息安全技术上的预测有些偏差，其他年份报告的趋势预测准确率均在 90% 的水平，所以Gartner被誉为全球TOP 1的咨询公司当之无愧。而根据近5年来预测和真实情况对比，以下技术和项目值得继续关注：前沿技术： AI与机器学习技术、AR与VR技术、自主物件、智能空间技术、云计算与边缘计算、

【技术教程】WebRTC技术是国标GB28181对终端输出的终极形式吗？

阅读更多关于【技术教程】WebRTC技术是国标GB28181对终端输出的终极形式吗？

最近我们的各个产品都在整合国标GB28181的功能扩展，有EasyNVR的国标GB28181向上级联、有EasyGBS的下级接入与对上级联、有EasyCVR的多协议接入与GB28181输出，大家都在做GB28181，国标的成熟与兴起是政策与执行相互促进推动的结果，以前没有一个这么完善的协议能统一平台相互级联的思路，如今有了，那么各种类型的系统支持GB28181就是必然的； EasyNVR将RTSP/Onvif设备汇聚并向上级平台级联： EasyGBS国标接入与向上级联： EasyCVR能将各种协议汇聚并向上GB28181级联：同时，我们也有在做WebRTC的更底层的开拓，发现WebRTC的实时性效果确实是出奇的好，我们综合分析了一下： WebRTC的视频传输采用的是RTP/RTCP协议，与GB/T28181一样； WebRTC在信令上各有各的自定义交换方式，与SIP协议类似，其主要目的就是做SDP等信息交换；如果能衔接WebRTC的信令交换方式与国标SIP的信令交换方式，那WebRTC的RTP/RTCP是不是就可以与GB/T28181的RTP/RTCP贯通？那么GB/T28181是不是就可以借助到WebRTC的各种底层框架优势？ WebRTC+GB28181，延时、对讲、回音，是不是统统都没问题了？是的，我们正在按照这个思路在开发！来源： oschina 链接：

订阅 sdp