【音视频 | RTSP】RTSP协议详解 及 抓包例子解析（详细而不赘述）

wkd_0072024-07-08 23:30

😁博客主页😁：🚀https://blog.csdn.net/wkd_007🚀
🤑博客内容🤑：🍭嵌入式开发、Linux、C语言、C++、数据结构、音视频🍭
🤣本文内容🤣：🍭介绍RTSP协议 🍭
😎金句分享😎：🍭你不能选择最好的，但最好的会来选择你------泰戈尔🍭
⏰发布时间⏰：2024-07-06 12:22:00

本文未经允许，不得转发！！！

目录

  • 🎄一、概述
  • [🎄二、RTSP 方法](#🎄二、RTSP 方法)
  • [🎄三、RTSP 的 请求报文 与 响应报文](#🎄三、RTSP 的 请求报文 与 响应报文)
    • [✨3.1 、RTSP 的 请求报文](#✨3.1 、RTSP 的 请求报文)
    • [✨3.2 、RTSP 的 响应报文](#✨3.2 、RTSP 的 响应报文)
  • [🎄四、RTSP 报文的常用字段](#🎄四、RTSP 报文的常用字段)
  • [🎄五、RTSP 流程抓包解析](#🎄五、RTSP 流程抓包解析)
    • [✨5.1、OPTION 方法](#✨5.1、OPTION 方法)
    • [✨5.2、DESCRIBE 方法](#✨5.2、DESCRIBE 方法)
    • [✨5.3、SETUP 方法](#✨5.3、SETUP 方法)
    • [✨5.4、PLAY 方法](#✨5.4、PLAY 方法)
    • [✨5.5、TEARDOWN 方法](#✨5.5、TEARDOWN 方法)
  • [🎄六、RTSP 响应错误码](#🎄六、RTSP 响应错误码)

🎄一、概述

RTSP，全称时 Real Time Streaming Protocol，实时流媒体协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的 IETF RFC 标准。

关于 RTSP 协议的官方文档是 RFC2326，文档链接 ：RFC2326-Real Time Streaming Protocol (RTSP)。

RTSP 协议的语法和操作参考了 HTTP/1.1，基于文本的协议，采用ISO10646字符集，使用UTF-8编码；承载RTSP的传输层协议为TCP，默认端口554；如果是RTSP-over-HTTP tunneling，则默认TCP端口为8080；一般与RTP/RTCP协议搭配使用，由RTP协议传输实时流数据，RTCP协议完成数据流和控制命令的传输。

RTP协议：全称Real-time Transport Protocol，实时传输协议，由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它是创建在UDP协议上的。

RTCP协议：全称Real-time Transport Control Protocol，实时传输控制协议，与RTP配合使用。RTP 使用一个偶数的 UDP 端口；而RTCP 则使用 RTP 的下一个端口，也就是一个奇数端口。RTCP与RTP联合工作，RTP实施实际数据的传输，RTCP则负责将控制包送至会话中的每个人。其主要功能是就RTP正在提供的服务质量做出反馈。
RTSP协议 与 HTTP协议 的区别：

RTSP是有状态的，其命令总是按照顺序来发送，其中某个命令可能需要总在另外一个命令之前要发送。而 HTTP 则是无状态，协议在发送一个命令以后，连接就会断开，且命令之间是没有依赖性的。

rtsp协议使用554端口，http使用80端口。

RTSP的请求服务器和客户端都可以发送，而HTTP请求则只能由客户端发送

🎄二、RTSP 方法

RTSP常用的方法包括：OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN、ANNOUNCE、GET_PARAMETER和SET_PARAMETER等。详细使用介绍如下：

  • OPTIONS：客户端向服务器获取服务器支持的方法。它不影响服务器的状态；
  • DESCRIBE：客户端向服务器获取URL指定的媒体对象的描述，其中Accept字段指定了描述格式；
  • SETUP：客户端向服务器请求建立会话并准备传输。请求信息主要包括传输协议和客户端的端口号；
  • PLAY：客户端主动通知服务器以SETUP指定的机制开始发送数据。其中Range字段指定了播放的起止时间(实时流Range一般为Range: npt=0.000-)，当多个PLAY请求到达时，服务器会将PLAY请求排成队列，顺序执行，即必须等待第一个PLAY的时间完成后，才会继续处理第二个PLAY消息。
  • PAUSE：客户端请求服务器的媒体流传输临时暂停。可以通过Range参数在指定时间点暂停，也可以指定某股流暂停，例如，如果指定音频流暂停，则播放将是无音状态
  • RECORD：RECORD通知服务器，客户端将会根据之前的描述开始记录媒体数据。 其中 timestamp 字段反映开始和结束时间 (UTC)。如果该字段不存在，则会使用媒体描述中的开始或结束时间。 如果会话已经开始，则立即开始录制。
    服务器决定是将记录的数据存储在 request-URI 下还是另一个 URI 下。 如果服务器不使用 request-URI，则响应应该是 201（已创建）并包含描述请求状态并引用新资源的实体和 Location 标头。
  • TEARDOWN：客户端请求停止指定URL流发送，释放相关资源。
  • REDIRECT：重定向请求，服务端通知客户端它必须连接到另一个服务器位置。 它包含强制标头 Location，它指示客户端应该发出对该 URL 的请求。 它可能包含参数Range，表示重定向何时生效。 如果客户端想要继续发送或接收此 URI 的媒体，客户端必须为当前会话发出 TEARDOWN 请求，并在指定主机上为新会话发出 SETUP。
  • ANNOUNCE：当客户端向服务器发送时，表示的是将通过请求 URL 识别的表示描述或者媒体对象提交给服务器
    当服务器向客户端发送时，表示的是通知客户端更新会话信息
  • GET_PARAMETER：GET_PARAMETER 请求检索 URI 中指定的表示或流的参数值。 回复和响应的内容留给实现。 没有实体主体的 GET_PARAMETER 可用于测试客户端或服务器的活跃度（"ping"）。
  • SET_PARAMETER：这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。

上面总共介绍了 11 个RTSP方法，其中，SETUP、PLAY、TEARDOWN三个命令是 RTSP 流程中必须的，其他方法非必须。而ANNOUNCE、GET_PARAMETER、SET_PARAMETER三个命令既可以是客户端发给服务端，也可以是服务端发给客户端，其他命令都是客户端发给服务端的。

🎄三、RTSP 的 请求报文 与 响应报文

RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的应答。

✨3.1 、RTSP 的 请求报文

RTSP请求报文由请求行、请求头部和请求体三个部分组成。其中，请求行是必须的，而请求头部和请求体则根据具体情况可选。

  • 请求行：请求行包含一个方法、一个请求URI和一个协议版本，它们之间以空格分隔，并以CRLF（即：\r\n）结束。
    方法：就是上面介绍的RTSP方法。包括OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等。
    请求URI：标识要操作的媒体资源，格式通常为rtsp://example.com/path/to/stream。
    协议版本：表示请求遵循的RTSP协议版本，一般为RTSP/1.0或RTSP/2.0。
    下面是一个完整的请求行的示例：

    OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0

  • 请求头部：请求头部包含一些附加信息，比如：CSeq（用于标识请求的序列号）、Session ID（会话标识符）、Transport（传输协议）等。每个头部字段由字段名、冒号和字段值组成，各头部字段之间以CRLF分隔。
    下面是一个完整的请求头部的示例:

    CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)

  • 请求体：请求体是用于传输额外的数据。请求体的具体内容，取决于请求行中所使用的RTSP方法。注意：在请求头部之后，需要插入一个空行（CRLF），用于区分请求头部与请求体。大部分请求报文是没有请求体的。

✨3.2 、RTSP 的 响应报文

RTSP请求报文由状态行、响应头部和响应体三个部分组成。其中，状态行是必须的，而响应头部和响应体则根据具体情况可选。

  • 状态行：状态行包含一个协议版本、一个状态码和一个状态文本，它们之间由空格分隔，并以CRLF（即："\r\n"）结束。
    协议版本：表示响应遵循的RTSP协议版本，一般为RTSP/1.0或RTSP/2.0。
    状态码：三位数字，比如：200、401、500等，用于指示请求的处理结果。第一位数字代表响应类别：2xx表示成功，4xx表示客户端错误，5xx表示服务器错误。
    状态文本：简短的文字描述，解释对应状态码的具体含义，比如：OK、Unauthorized等。
    下面是响应行例子：

    RTSP/1.0 200 OK

  • 响应头部：响应头部包含与请求头部类似的信息，比如：CSeq（用于标识请求的序列号）、Session ID（会话标识符）、Transport（传输协议）等。每个响应头部字段的格式与请求头部相同，故这里不再赘述。

    CSeq: 2
Date: Wed, Feb 04 1970 03:25:10 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

  • 响应体：某些RTSP响应（比如：DESCRIBE）可能包含响应体，用于传输额外的数据。注意：在响应头部之后，需要插入一个空行（CRLF），用于区分响应头部与响应体 。
    下面是一个完整的响应体的示例。

    v=0
o=- 8913478 1 IN IP4 192.168.3.91
s=LIVE555 Streaming Media v2016.07.19
i=1080
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:1080
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=64002A;sprop-parameter-sets=Z2QAKq2EAQwgCGEAQwgCGEAQwgCEO1A8ARPyoA==,aO48sA==
a=control:track1
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:768
a=rtpmap:97 PCMA/48000/2
a=control:track2

🎄四、RTSP 报文的常用字段

RTSP报文的响应头会包含一些字段，下面是一些常用的字段：

  • Accept: 用于指定客户端通知服务器自己可以接受的实体数据结构类型。例如: Accept: application/sdp，之后服务器通过Content-Type字段返回其实体数据结构类型；
  • Accept-Encoding:用于客户端通知服务器自己可以接受的数据压缩格式，例如:Accept-Encoding: gzip, compress, br，之后服务器将通过Content-Encoding字段通知客户端它的选择。
  • Accept-Language: 用于客户端通知服务器自己可以理解的语言及其接受度，例如:Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 ，之后服务器将通过Content-Language字段通知客户端它的选择
  • Authorization:客户端请求消息头含有服务器用于验证用户代理身份的凭证
  • Bandwidth: 用于描述客户端可用的带宽值。例如: Bandwidth: 4000
  • Blocksize：此字段由客户端发送到媒体服务器，要求服务器提供特定的媒体包大小，服务器可以自由使用小于请求的块大小。 此数据包大小不包括 IP、UDP 或 RTP 等低层标头
  • CSeq： 指定了RTSP请求响应的序列号，每个RTSP请求都必须包含一个唯一的CSeq值，以便服务器能够正确地识别和处理请求。这个序列号随着请求消息递增。服务器响应必须有CSeq值，指明响应哪个请求。
  • Cache-Control：通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中
  • Conference：通知服务器不得更改同一 RTSP 会话的会议 ID
  • Connection：该字段决定当前的事务完成后，是否会关闭网络连接。如果该值是"keep-alive"，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成或者Connection: close。
  • Content-Length：该字段指明在RTSP协议最后一个标头之后的双 CRLF 之后的内容长度。例如在服务器响应DESCRIBE中，指明sdp信息长度
  • Content-Type：告诉客户端实际返回的内容的内容类型
  • Date：提供服务器生成响应的日期和时间，有助于客户端判断响应的新鲜度或进行时间同步。Date字段的格式符合RFC 1123，比如：Sat, 06 Apr 2024 11:15:00 GMT。
  • User-Agent: 该字段用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。
  • Expires：指明过期的时间
  • Rang： 用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。
  • Session : Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.例如：Session: 4581E0AE;timeout=65
  • Transport: Transport头字段包含客户端可以接受的传输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如: Transport: RTP/AVP/TCPunicast;destination=192.168.31.222;source=192.168.31.222;interleaved=0-1

🎄五、RTSP 流程抓包解析

使用wireshark抓取RTSP流媒体的网络包，可以看到其大概流程如下：

1、客户端发送OPTIONS方法，服务端回复；

2、客户端发送DESCRIBE方法，服务端回复；

3、客户端发送SETUP方法，服务端回复；

2、客户端发送PLAY方法，服务端回复；

2、客户端发送TEARDOWN方法，服务端回复；

完整的取流报文如下：

OPTIONS rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)

RTSP/1.0 200 OK
CSeq: 2
Date: Wed, Jul 03 2024 14:42:11 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

DESCRIBE rtsp://192.168.3.225:554/wbc RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 3
Date: Wed, Jul 03 2024 14:42:11 GMT
Content-Base: rtsp://192.168.3.225/wbc/
Content-Type: application/sdp
Content-Length: 472

v=0
o=- 1720014950032000 1 IN IP4 192.168.3.225
s=LIVE555 Streaming Media v2016.07.19
i=wbc
t=0 0
a=tool:LIVE555 Streaming Media v2016.07.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:LIVE555 Streaming Media v2016.07.19
a=x-qt-text-inf:wbc
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKawsaoHgCJ+WbgoCCgQ=,aO4xshs=
a=control:track1
SETUP rtsp://192.168.3.225/wbc/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=55320-55321

RTSP/1.0 200 OK
CSeq: 4
Date: Wed, Jul 03 2024 14:42:11 GMT
Transport: RTP/AVP;unicast;destination=192.168.2.180;source=192.168.3.225;client_port=55320-55321;server_port=6970-6971
Session: 4581E0AE;timeout=65

PLAY rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 5
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 5
Date: Wed, Jul 03 2024 14:42:11 GMT
Range: npt=0.000-
Session: 4581E0AE
RTP-Info: url=rtsp://192.168.3.225/wbc/track1;seq=7880;rtptime=3548171463

TEARDOWN rtsp://192.168.3.225/wbc/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/3.0.19 (LIVE555 Streaming Media v2016.11.28)
Session: 4581E0AE

RTSP/1.0 200 OK
CSeq: 6
Date: Wed, Jul 03 2024 14:42:19 GMT

下面将解析上个这段报文中用到的各个RTSP方法和响应。

✨5.1、OPTION 方法

向服务器获取可用的方法：

客户端发送 OPTIONS 方法，并使用 CSeq 指明请求序列号，使用 User-Agent 指明自己的代理；

服务端会响应请求，使用 CSeq 指明响应的是哪个请求，使用Date指明日期，Public指明提供的方法。

✨5.2、DESCRIBE 方法

向服务器获取rtsp://192.168.3.225:554/wbc的媒体对象的描述，其中Accept字段指定了描述格式：

客户端发送 DESCRIBE 方法，并使用 CSeq 指明请求序列号，使用 User-Agent 指明自己的代理，Accept字段指定了描述格式为SDP；

服务端会响应这个请求，使用 CSeq 指明响应的是哪个请求，使用Date指明日期，Content-Type指明内容类型是SDP，Content-Length指明内容长度。

注意：

1、有些需要用户名、密码的，服务器会在处理 DESCRIBE 方法进行鉴权。如果未携带Authorization鉴权信息，或者认证失败，服务器会返回错误号为401的响应，客户端接收到401响应时，需要根据已知的用户鉴权信息，生成Authorization，再次发送describe，如果认证成功，服务器返回携带有SDP的响应信息。

2、服务器返回的SDP信息，会在之后的文章进行解析。

✨5.3、SETUP 方法

客户端向服务器请求建立会话并准备传输。请求信息主要包括传输协议和客户端的端口号；

客户端发送 SETUP 方法，并使用 CSeq 指明请求序列号，使用 User-Agent 指明自己的代理，Transport字段指定了可以接受的传输协议RTP/AVP、端口(这里指定了RTP端口为55320，RTCP端口为55321)；

服务端会响应这个请求，使用 CSeq 指明响应的是哪个请求，使用Date指明日期，Transport指明传输协议RTP/AVP、目标地址、源地址、客户端端口(RTP为55320，RTCP为55321)、服务端端口(RTP为6970，RTCP为6971)，Session指明会话ID。

注意：

这个例子的RTP是通过UDP协议传输的，有些时候，RTP会通过TCP进行传输，那么Transport字段会有所差异。可能如下：

客户端请求：Transport: RTP/AVP/TCP;unicast;interleaved=0-1
服务器响应：Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"

RTP/AVP/TCP表示RTP流通过TCP传输，当此值出现时，报文没有client_port字段；
interleaved=0-1表示streamid，标识RTP的streamid=0；RTCP的streamid=1；

当码流通过TCP传输时，与RTSP共用一个TCP链路，所以其不需要建立新的连接，为了区分RTP、RTCP及RTSP协议，需要增加包头标识，这里采用TCPHEAD头字段，tcphead为四个字节，格式如下：

| magic number | channel number | embedded data length | data |

magic number： 1个字节，固定为0x24，是字符$，标识传输的是数据不是rtsp协议；
channel number： 1个字节，信道ID，标识流的类型，就是前面说的streamid；
embedded data length ：2个字节，表示流长度
data：表示RTP/RTCP包数据

✨5.4、PLAY 方法

客户端主动通知服务器以SETUP指定的机制开始发送数据。

客户端发送 PLAY 方法，并使用 CSeq 指明请求序列号，使用 User-Agent 指明自己的代理，Session字段指定会话ID，Range字段指定了播放的起止时间。

服务端会响应这个请求，使用 CSeq 指明响应的是哪个请求；使用Date指明日期；Range字段指定了播放的起止时间；Session字段指定会话ID；RTP-Info字段描述将要发送码流的RTP信息，比如第一包RTP的seq和rtptime，客户端可以根据此字段进行解复用。

✨5.5、TEARDOWN 方法

客户端请求停止指定URL流发送，释放相关资源。

客户端发送 TEARDOWN 方法，并使用 CSeq 指明请求序列号，使用 User-Agent 指明自己的代理，Session字段指定会话ID。

服务端会响应这个请求，使用 CSeq 指明响应的是哪个请求；使用Date指明日期。

🎄六、RTSP 响应错误码

RTSP的响应内容通常包含3位整数响应码以及一个原因短语，短语的目的是给出状态代码的简短文本描述，客户端不需要检查或显示原因短语。 按照响应码的首位数字区别，可以分为以下五个类别：

  • 1xx: 提示- 请求已经收到，正在处理中
  • 2xx: 成功- 请求已经被成功处理
  • 3xx: 重定向- 必须采取进一步行动才能完成请求
  • 4xx: 客户端错误 - 请求中包含错误的参数或语法导致请求无法被满足
  • 5xx: 服务器错误 - 服务器无法满足客户端正确的请求

当然，RTSP的错误码和RTSP方法是强相关的，某些错误可能只会在特定方法中才会触发，详细错误码信息如下：

错误码 原因短语 响应的方法
100 Continue All
200 Success All
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices All
301 Moved Permanently All
302 Moved Temporarily All
303 See Other All
305 Use Proxy All
400 Bad Request All
401 Unauthorized All
402 Payment Required All
403 Forbidden All
404 Not Found All
405 Method Not Allowed All
406 Not Acceptable All
407 Proxy Authentication Required All
408 Request Timeout All
410 Gone All
411 Length Required All
412 Precondition Failed DESCRIBE SETUP
413 Request Entity Too Larg All
414 Request-URI Too Long All
415 Unsupported Media Type All
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found All
455 Method Not Valid In This State All
456 Header Field Not Valid All
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed All
460 Only Aggregate Operation Allowed All
461 Unsupported Transport All
462 Destination Unreachable All
500 Internal Server Error All
501 Not Implemented All
502 Bad Gateway All
503 Service Unavailable All
504 Gateway Timeout All
505 RTSP Version Not Supported All
551 Option not support All

如果文章有帮助的话，点赞👍、收藏⭐，支持一波，谢谢 😁😁😁

参考：
实时流协议---RTSP【详解】
从零开始精通RTSP之请求与响应详解1
流媒体协议之RTSP详解

相关推荐
我喜欢就喜欢12 小时前
基于qt vs下的视频播放
开发语言·qt·音视频
安步当歌13 小时前
【WebRTC】视频采集模块中各个类的简单分析
音视频·webrtc·视频编解码·video-codec
EasyGBS14 小时前
国标GB28181公网直播EasyGBS国标GB28181软件管理解决方案
大数据·网络·音视频·媒体·视频监控·gb28181
Johnstons16 小时前
AnaTraf | 网络性能监控系统保障音视频质量的秘籍
网络·音视频·网络流量监控·网络流量分析·npmd
lrlianmengba16 小时前
推荐一款非常好用的视频编辑软件：Movavi Video Editor Plus
音视频
SZ17011023116 小时前
ffplay 实现视频流中音频的延迟
音视频·延迟
LNTON羚通18 小时前
CPU算法分析LiteAIServer视频智能分析平台视频智能分析：抖动、过亮与过暗检测技术
大数据·目标检测·音视频·视频监控
MediaTea19 小时前
Pr 视频过渡：沉浸式视频 - VR 光线
音视频·vr
几何心凉1 天前
视频自动播放被浏览器阻止及其解决方案
音视频
阿龍17871 天前
流媒体传输，降低延时和保证质量的方法（个人总结）
音视频
热门推荐
01【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总02(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04【AIGC】重塑未来的科技巨轮05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06【经验分享】Ubuntu22.04安装微信(linux官方版)07基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测08Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO09RAG 实践- Ollama+RagFlow 部署本地知识库10红米手机使用google play