sdp

WebRTC: SDP in Firefox with VP9 encoding

由 核能气质少年 提交于 2021-02-19 04:27:21
问题 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消息格式

由 有些话、适合烂在心里 提交于 2021-02-12 03:19:29
点击上方 蓝字 关注我们 上一篇我们简单介绍了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)

由 |▌冷眼眸甩不掉的悲伤 提交于 2021-02-11 12:50:55
问题 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基本流程

由 送分小仙女□ 提交于 2021-02-11 11:52:14
点击上方 蓝字 关注我们 哈喽，久违的小伙伴们！之前开了一个专辑手撕了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

由 核能气质少年 提交于 2021-02-10 18:47:06
问题 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?

由 柔情痞子 提交于 2021-02-08 01:22:57
问题 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?

由 喜欢而已 提交于 2021-02-08 01:15:28
问题 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

WebRTC 系列之视频辅流

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

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

由 喜你入骨 提交于 2021-01-05 00:26:09
多年以来，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对终端输出的终极形式吗？

由 不问归期 提交于 2020-12-22 07:54:45
最近我们的各个产品都在整合国标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