音视频FAQ(二)视频直播延时高

摘要

延时高是实时互动技术中常见的问题之一,解决延时高问题需要综合考虑网络、设备、编解码算法等多个因素。解决方案包括优化设备端延时、优化网络传输延时和使用UDP进行音视频传输等。在选择音视频传输协议时,需要综合考虑实际需求和网络条件,选择最适合的协议。
本文介绍了延时高的原因和解决方案,希望对音视频开发者能够有所帮助。

前言

对于音视频开发者来说,掌握排查问题的技术技巧方法是非常必要的,排查问题的技术方法也能够帮助开发者更好地了解音视频技术的原理和工作机制,从而更加深入地理解音视频开发中遇到的各种问题。

即构基于多年实时互动领域技术的沉淀和客户服务保障,我们将推出《音视频技术FAQ》系列文章,将音视频技术领域的常见问题和经验分享出来,同时会针对具体问题附上业务通识和常用解决方案以及案例经验,希望本系列能成为你手边的音视频通识册子,帮助到开发者们快速定位问题并找到合适的解决方案。

本系列将不定期更新,目前已整理了以下常见问题:

  1. 视频卡顿
  2. 延时高
  3. 音画不同步
  4. 视频花屏、绿屏
  5. 视频黑屏
  6. 视频放大或黑边
  7. 首开慢
  8. 音视频流控
  9. 视频模糊
  10. 无法打开摄像头
  11. 音频回声
  12. 音量太小
  13. 音频噪声
  14. 无声
  15. 上下麦音量变化

本文是**《音视频技术FAQ》系列的第二篇文章。在这篇文章中,我们将详细探讨如何处理和排查“延时高”**的问题,这是实时互动技术中最常见的问题之一。

我们将首先介绍什么是“延时高”,然后列举可能导致问题的原因,最后提供一些解决方案和建议,同时也会介绍一些第三方音视频SDK例 即构实时音视频RTC,我们相信这些信息对于那些正在寻找解决办法的开发者来说将非常有用。

一、延时高的定义

视频通话和直播是两种不同的应用场景,对于时延的容忍度也存在明显差异,主要原因在于它们的应用场景和用户期望不同。视频通话追求实时交互的流畅性,而直播更注重内容的连续性和广泛分发。

视频通话(实时通信):视频通话追求实时交互的流畅性,最大可容忍时延:通常认为,150毫秒至300毫秒内的延迟是可以接受的,因为在这个范围内,人类通常不会明显感受到通话的延迟。在商务会议、远程医疗或远程教育等场景中,高延迟可能会严重影响效果和用户体验。

直播:最大可容忍时延:直播的延迟要求会根据具体的应用场景和需求而有所不同。观众在观看直播时,更加关注内容的连续性和清晰度,一般来说,延迟在3秒至30秒之间都可以被认为是可接受的。相较于实时通信,直播对时延的容忍度更高。但这并不是固定的,某些对实时性要求更高的场景可能需要更低的延迟。例秀场直播、电子竞技直播等对实时性要求更高的场景,

二、延时高的问题表现

延时高指的是在实时互动中,由于网络传输、设备性能等因素,导致音视频数据在传输过程中的延迟过高,从而影响到用户的观看和体验。在音视频开发中,延时高一般指音频和视频的延时。
具体场景的影响:

  • 通信过程中出现明显的滞后,如音频或视频的播放与实际发生的时间不同步。
  • 在游戏中,玩家的操作与游戏反应之间存在明显的间隔。
  • 在直播中,主播与观众的互动出现明显的时间差。

三、延时高的产生和原因

音视频传输全流程:音视频采集-编码处理-网络传输-服务器处理-解码处理-音视频播放。
音视频传输流程可以被划分为以下三个主要模块,这些模块都有可能产生延时:
1. 设备端上的延时:包括采集延时、处理延时、编码延时、播放延时。

  • 采集延时:音视频源数据从硬件设备(如麦克风、摄像头)被采集并转换为数字信号的过程中产生的延时。
  • 处理延时:音视频数据在进行各种处理(如降噪、增益控制、回声消除等)的过程中产生的延时。
  • 编解码延时:音视频数据在进行编码(转换为可以传输的格式)和解码(转换为可以播放的格式)的过程中产生的延时。
  • 播放延时:音视频数据在最后播放的过程中产生的延时,包括视频渲染延时和音频播放延时。
  1. 网络传输延时:音视频数据从发送端通过网络传输到接收端的过程中产生的延时,包括以下几个部分:
  • 客户端到服务器的延时:音视频数据从客户端发送到服务器的延时,取决于网络状况、带宽、物理距离等。
  • 服务器内部处理延时:服务器接收、处理、转发数据的过程中产生的延时。
  • 服务器到客户端的延时:服务器将数据发送到客户端的延时,同样取决于网络状况、带宽、物理距离等。
  1. 服务器间的延时:在多服务器或者边缘计算的环境下,音视频数据在服务器之间传输的过程中也会产生延时。

五、延时高的解决方案

在音视频传输全流程中,解决延时高问题是一个综合性的任务,需要从各个环节进行优化和改进。下面我将给出一些建议来解决延时高的问题。

解决音视频传输全流程中的延时高问题,需要从设备端、网络传输、技术栈配置等多个方面进行优化。对于实时性要求较高的音视频传输场景,建议使用UDP协议进行传输,并在设计和选择技术栈时,考虑到预期的延时和实际表现之间的匹配。处理步骤如下:

1. 排查是否是网络问题
2. 优化设备端上的延时
3. 优化网络传输延时
4. 核实技术栈预期延时
5. 使用UDP进行音视频传输

下面我们将逐一详细说明每个步骤,并提供相关示例以帮助读者更好地理解和应用这些步骤。我们还将深入探讨这些步骤的实际应用场景,以帮助开发者更好地理解如何将这些步骤应用于实际问题中。

六、排查是否是网络问题

在处理音视频延时问题时,第一步是确定问题是否源于网络。网络质量、物理距离、以及网络拥塞都可以造成显著的延时。可以使用Ping、Traceroute、iPerf、Wireshark等各种网络测试工具来测试网络延时和丢包率,以确定是否存在网络问题。

网络原因是导致延时高的主要原因之一,解决方案包括以下几个方面:

  • 网络质量:在网络条件不好的情况下,可以采用一些技术来改善网络质量,如使用QoS(Quality of Service)、增强网络连接的稳定性等。
  • 物理距离:尽可能选择离用户近的服务器,减少物理距离带来的延时,增强网络连接的稳定性。
  • 网络拥塞:在网络拥塞的情况下,可以采用拥塞控制算法,如TCP中的拥塞控制,或者使用CDN等技术来分散网络流量。
    同时,监控网络带宽使用情况,确保带宽充足,避免网络拥堵导致延时增加。

七、核实技术栈预期延时

如果我们确定网络状况良好,下一步需要验证你在实际使用的音视频传输过程中的延时,与你使用的技术(例如特定的音视频编解码方案、网络传输协议、服务器配置等)在理论上预期的延时是否匹配。

在验证音视频传输延时与技术预期是否匹配时,有几个步骤可以参考:

  1. 获取技术栈预期延时: 通过阅读相关的技术文档、白皮书或者研究报告,获取你正在使用的编解码方案、网络传输协议等技术的预期延时。这通常会有一个范围,而非精确的数值,因为实际延时会受到很多因素(比如网络状况、设备性能等)的影响。
  2. 测量实际延时: 使用专业的音视频分析工具,例如 Wireshark, FFmpeg, OBS等来获取实际音视频传输的延时。这些工具可以提供音视频流的详细信息,如数据包的时间戳、发送和接收时间等,从而可以用于计算音视频传输的实际延时。
  3. 比较和分析: 将实际测量的延时与技术预期的延时进行比较。如果实际延时显著高于预期延时,那么可能存在问题。分析可能的原因,可能是网络状况不佳,导致了数据包的丢失或者延迟;也可能是编解码设置不当,比如编码级别太高,超出了设备的处理能力;又或者是服务器配置问题,比如服务器的网络带宽不足,不能满足音视频数据的传输需求。
  4. 调整和优化: 根据分析的结果,对可能的问题进行调整和优化。如果是网络问题,可以考虑优化网络环境,或者使用更强大的网络设备;如果是编解码问题,可以调整编解码设置,降低编码级别,或者换用更高效的编解码方案;如果是服务器问题,可以增加服务器的网络带宽,或者优化服务器的配置。

以上步骤1和步骤2比较简单,只需相关的技术文档和使用测量工具即可,在此不赘述。步骤3和步骤4是本环节的核心要点,我们将展开陈述。

八、预期延时的对比和分析

让我们以一个具体的例子来解释这个过程。假设你在实现一个实时音视频通信系统,你选择了使用 H.264 视频编码和 Opus 音频编码,以及 RTP/UDP 网络传输协议。

在你阅读这些技术的相关文档和资料时,你可能会发现一些关于它们在不同网络和硬件条件下的预期延时的数据。例如,H.264 编码可能有 50 毫秒的编解码延时,Opus 编码可能有 20毫秒的编解码延时,RTP/UDP 网络传输可能有 50 毫秒的网络延时。那么,你可以预期,在理想的网络和硬件条件下,你的音视频通信系统的总延时应该在 100 毫秒左右。

然后,你可以使用一些测试工具和方法,例如以上提到的 Ping、iPerf、Wireshark 等,来测量你的系统在实际运行中的延时。 如果你的实际延时与预期的 100 毫秒延时相差不大,那么可以认为你的音视频通信系统的性能与使用的技术栈的预期性能一致。反之,如果你的实际延时远大于预期的 100 毫秒,那么你可能需要进一步分析和优化你的系统,例如,检查你的网络环境、优化你的编解码设置、调整你的网络传输参数等,以降低延时。

九、延时的调整和优化

音视频传输的预期延时,一般来说,取决于所选的技术栈,包括编解码器、传输协议、网络架构等。不同的技术栈对延时的影响程度不同,因此在处理延时问题时,了解并核实所使用的技术栈的预期延时是非常重要的。

  1. 编解码器:音视频编解码器的性能会直接影响到编解码延时。例如,一些复杂的编解码器,如AV1,虽然可以提供高质量的视频,但其编解码过程可能会引入更大的延时。相反,一些更为简单的编解码器,如H.264可能会有更低的编解码延时。因此,核实编解码器的预期延时,有助于理解当前的延时状况是否符合预期。
  2. 传输协议:如上文所述,TCP和UDP是两种常用的网络传输协议,它们对延时的影响程度也不同。TCP提供了可靠的数据传输,但可能会引入较大的延时,因为它需要确保所有数据包的按序到达和错误检测。而UDP则不保证数据包的按序到达或可靠传输,因此通常有更低的延时。如果您正在使用的技术栈包括TCP,那么可能需要接受比UDP更高的预期延时。
  3. 网络架构:音视频传输的网络架构,如点对点传输、云服务器中转等,也会对延时有影响。点对点传输一般可以提供较低的延时,但可能受到各种网络条件的影响。而通过云服务器中转的数据,虽然可以提供更稳定的传输,但可能会增加延时。核实这部分的预期延时,可以帮助您理解是否需要调整网络架构来优化延时。

十、优化设备端上的延时

设备端的延时在音视频传输的全流程中,主要发生在音视频传输的开始(采集、编码)和结束阶段(解码、播放)。设备端的延时通常受设备性能、编解码效率、播放器性能等因素影响。
设备原因也是导致延时高的一个重要原因,针对设备上的延时,可以优化硬件和软件性能。包括以下几个方面:

  • 采集设备性能:优化硬件设备或者采用更高性能的设备来减少采集延时。
  • 编解码性能:采用更高效的编解码算法,或者使用硬件加速来减少编解码延时。
  • 处理性能:优化处理算法,如使用更高效的降噪算法,优化增益控制算法等,以减小处理延时。或者使用更好的硬件设备来减少处理延时。
  • 播放设备性能:采用更高性能的设备,或者优化播放算法和软件来减少播放延时。

总的来说,设备端延时问题是影响音视频传输效果的重要因素,需要进行细致的排查和优化。通过优化硬件设备、编解码器、处理算法和播放器,可以有效地降低设备端延时,提高音视频传输的效果。

十一、优化网络传输延时

服务器处理延时:在服务器端,音视频数据的接收、缓冲、处理、转发等过程都可能产生延时。服务器的缓冲策略、转发策略等也会影响服务器处理音视频数据的速度,从而影响延时。
服务器间的延时有以下几个方面:客户端到服务器的延时、服务器内部处理延时、服务器到客户端的延时、服务器间的延时。

优化办法如下:

  • 服务器性能:服务器间的延时问题,可通过提高服务器的硬件性能,或者优化服务器的软件和算法来降低处理延时。
  • 服务器策略:服务器内部处理的延时问题,可通过优化服务器的策略,包括缓冲策略、负载均衡策略、转发策略等,以提高处理和传输效率,降低延时。
  • 优化服务器的物理位置:客户端到服务器或服务器到客户端的的延时问题,使用边缘计算将计算任务分布到离用户更近的边缘服务器上,或者使用内容分发网络(CDN)等技术,将数据尽可能地接近用户分发,以减小服务器之间的物理距离,减少数据在网络中的传输距离,从而减小延时。

在音视频传输中,服务器延时可以通过优化网络路径、服务器性能、使用CDN和UDP协议、应用边缘计算、服务器负载均衡、采用更高效的编解码技术以及提高服务器并发处理能力等多种策略进行有效管理和降低。

在以上策略中,很难指定一个单一的最关键策略,因为每个策略都在特定的场景和问题上发挥着重要的作用。选择最关键的策略取决于实际情况和需求。然而,使用UDP进行音视频传输被认为是在音视频传输中最有效的策略之一。

十二、使用UDP进行音视频传输

UDP(User Datagram Protocol): UDP 是一种无连接的协议,在发送数据时,不需要建立连接,可以直接发送。这种方式在处理实时数据传输,如音视频数据时,往往更加高效。

音视频传输场景通常对实时性和低延迟有严格要求,而UDP(用户数据报协议)在满足这些要求上具有明显优势,特别在低延迟方面表现优异。UDP具备以下优势:

  1. 实时性: 在音视频传输中,实时性是非常重要的,特别是在实时通信场景下,如视频会议、实时直播、在线游戏等。UDP作为无连接的传输协议,可以直接发送数据包,而无需在传输前进行握手和连接建立,这样可以减少传输的时延,保证音视频数据的及时到达,从而实现更好的实时性。
  2. 低延时: 音视频传输对延时的要求非常高,尤其是在交互性强的应用中。TCP作为面向连接的传输协议,在数据传输前需要建立连接、进行数据确认和重传等机制,这些额外的操作会导致传输延时增加。而UDP不需要这些额外操作,能够更快地传输数据,从而降低延时,确保音视频数据的及时传输。
  3. 带宽传输/效率: UDP头部相对较小,没有TCP复杂的连接管理和拥塞控制机制,这使得UDP在传输效率上更高。在音视频传输中,通常需要高效地传输大量的数据,UDP的传输效率可以更好地满足这一需求。
  4. 灵活性: UDP协议相对简单,没有TCP复杂的连接管理机制,使得开发者可以更自由地控制音视频数据的传输过程,根据实际需求进行优化和定制。
  5. 抗丢包性: 在实时通信中,偶尔丢失少数几个数据包对用户体验的影响通常是可以容忍的。UDP是不可靠的传输协议,它没有数据重传机制。一旦数据包丢失,UDP不会重新发送,而是直接丢弃。因为在实时通信中,过度的重传可能导致更大的延时,而且在连续的音视频流中,丢失少数几个数据包不会对整体体验造成太大影响。

虽然UDP在实时性和低延时方面具有优势,但也有一些缺点需要注意。UDP是不可靠的传输协议,会导致数据包丢失和顺序错乱。
因此,在使用UDP进行音视频传输时,需要开发者自己实现一些额外的机制,如前向纠错、重传策略、丢包恢复等,来保证传输的可靠性和数据完整性。
另外,UDP传输对网络的稳定性要求较高,如果网络环境较差或者存在严重的丢包问题,可能会影响音视频传输的质量。
因此,在选择UDP作为音视频传输协议时,需要综合考虑实际需求和网络条件,做出合适的决策。

在选择音视频传输协议时,需要综合考虑实际需求和网络条件。如果实时性和低延时是首要考虑因素,而数据传输的可靠性可以通过应用层的手段解决,那么使用UDP是一个较好的选择。
但如果对数据的完整性和可靠性要求较高,而可以容忍稍微增加的延时,那么TCP也是一个可行的选择。最终的决策应该根据具体场景和需求来做出。

音视频传输的延时问题是一个复杂的问题,需要根据具体情况选择合适的优化策略。音视频厂商针对延时高都有一套成熟的解决方案,若使用第三方音视频SDK服务,可直接使用他们的优化服务。以即构为例,他们的延时高解决方案是基于对音视频处理流程的深入优化,以及对网络传输协议和服务器资源的有效管理。

十三、第三方音视频SDK — “延时高”解决方案

使用第三方音视频SDK可以大大简化开发流程,降低开发难度。并且这些SDK通常都经过了大规模的实际环境测试,能够提供更为可靠的性能。即构SDK是音视频行业的知名产品,可以为开发者提供实时音视频、实时消息、互动白板等服务,其内部包含了优化的音视频编解码技术、网络传输协议、QoS质量控制等模块。

即构科技官网(https://www.zego.im/))

在这里插入图片描述

当你遇到音视频传输延时高的问题时,可以从以下几个角度使用即构SDK来解决:

  1. 利用即构SDK的QoS模块:即构SDK内置了QoS(Quality of Service)模块,可以根据网络状况动态调整传输参数,包括码率、帧率、分辨率等,以保证音视频传输的流畅性和低延时。
  2. 使用即构SDK的网络传输优化功能:即构SDK采用了优化的UDP协议进行音视频传输,包括丢包恢复、网络拥塞控制等功能,可以在保证传输质量的同时,降低音视频传输的延时。
  3. 优化编解码过程:即构SDK内置了优化的音视频编解码算法,可以在保证音视频质量的同时,尽可能地减小编解码过程中的延时。
  4. 使用即构的服务器资源:即构提供了全球多节点的服务器资源,可以保证音视频数据在服务器间的快速传输,从而降低服务器间的延时。

以上的所有优化措施,都可以通过 即构实时音视频RTC(https://www.zego.im/product/realtime-video)
的接口进行控制和配置,你可以根据你的应用场景和需求,灵活地选择使用哪些功能和策略。

通过上述的各种优化措施,即构等音视频SDK能够在大部分情况下实现低延迟的音视频传输。当然,如果在使用过程中遇到了特殊的问题,他们通常也会提供专业的技术支持来帮助解决。总的来说,通过使用 即构SDK(https://www.zego.im),你可以更专注于你的业务逻辑,而将音视频传输的优化交给专业的SDK来完成。

上述提供了音视频厂商和一般性的解决方案,具体实施时可能需要结合具体情况进行调整。针对以上步骤,下面我们来逐一说明。

结语

本文探讨了音视频传输中的高延迟问题,并提供了解决方案。为了优化设备端和网络传输延迟,建议改进硬件设备、编码解码器、处理算法和播放器,并考虑优化服务器处理和物理位置策略。在音视频传输中,使用UDP协议可以有效地降低服务器延迟,但需要注意其不可靠性。因此,在选择音视频传输协议时,需要综合考虑实际需求和网络条件。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/104101.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

MyBatis进阶:告别SQL注入!MyBatis分页与特殊字符的正确使用方式

目录 引言 一、使用正确的方式实现分页 1.1.什么是分页 1.2.MyBatis中的分页实现方式 1.3.避免SQL注入的技巧 二、特殊字符的正确使用方式 2.1.什么是特殊字符 2.2.特殊字符在SQL查询中的作用 2.3.如何避免特殊字符引起的问题 2.3.1.使用CDATA区段 2.3.2.使用实体引…

Docker容器与虚拟化技术:Dockerfile部署LNMP

目录 一、理论 1.LNMP架构 2.背景 3.Dockerfile部署LNMP 3.构建Nginx镜像 4.构建MySQL容器 5.构建PHP镜像 6.启动 wordpress 服务 二、实验 1.环境准备 2.构建Nginx镜像 3.构建MySQL容器 4.构建PHP镜像 5.启动 wordpress 服务 三、问题 1.构建nginx镜像报错 …

“解放 Arweave“优惠:4EVERLAND的无缝上传教程

为了进一步展示 Arweave 的能力,4EVERLAND 骄傲地推出了“解放 Arweave”活动。我们认识到 Arweave 在数据完整性、抗审查性以及长期保存方面的无与伦比的优势,因此我们与这个去中心化的存储巨头建立了强大的集成。 克服了过去与加密货币支付逻辑相关的…

常见的数据库备份方法,常用的数据库备份方法有哪三种

数据库作为存储和管理这些信息的核心,其安全性和稳定性尤为重要。因此,定期进行数据库备份是保护数据完整性的重要途径。下面我们就详细介绍几种常见的数据库备份方法。 1.全量备份 全备份是指备份数据库中的所有数据和元数据。这种方法通常用于开发或测…

如何获取旧版本的谷歌浏览器

1、明确自己要的版本号 2、访问Chromium History Versions Download ↓ 3、选择系统,选择版本号 4、下载安装

防火墙组建双击热备后老是主备自动切换怎么处理?

环境: 2台主备防火墙 8.0.75 AF-2000-FH2130B-SC 核心交换机 H3C S6520-26Q-SI version 7.1.070, Release 6326 问题描述: 防火墙组建双击热备后老是主备自动切换怎么处理? 查看切换日志,本地故障值小于对端,经常自动切换导致eth3接口业务老是自动断开,切换频率,…

Visual Studio中Linux开发头文件intellisense问题的解决办法

文章目录 前言个人环境 SSH到WSL复制文件后记 前言 最近在用我心爱的Visual Studio配合WSL2做一些Linux开发&#xff0c;但是有一个问题&#xff0c;就是当我#include <sys/socket.h>&#xff0c;会提示找不到文件 我尝试了各种姿势&#xff0c;包括修改CMakeSettings.…

1.分布式电源接入对配电网影响分析

分布式电源接入对配电网影响分析 MATLAB代码&#xff1a;分布式电源接入对配电网影响分析 关键词&#xff1a;分布式电源 配电网 评估 参考文档&#xff1a;《自写文档&#xff0c;联系我看》参考选址定容模型部分&#xff1b; 仿真平台&#xff1a;MATLAB 主要内容&a…

【Linux】socket编程(二)

目录 前言 TCP通信流程 TCP通信的代码实现 tcp_server.hpp编写 tcp_server.cc服务端的编写 tcp_client.cc客户端的编写 整体代码 前言 上一章我们主要讲解了UDP之间的通信&#xff0c;本章我们将来讲述如何使用TCP来进行网络间通信&#xff0c;主要是使用socket API进…

计算机竞赛 python的搜索引擎系统设计与实现

0 前言 &#x1f525; 优质竞赛项目系列&#xff0c;今天要分享的是 &#x1f6a9; python的搜索引擎系统设计与实现 &#x1f947;学长这里给一个题目综合评分(每项满分5分) 难度系数&#xff1a;3分工作量&#xff1a;5分创新点&#xff1a;3分 该项目较为新颖&#xff…

大数据课程K3——Spark的常用案例

文章作者邮箱:yugongshiye@sina.cn 地址:广东惠州 ▲ 本章节目的 ⚪ 掌握Spark的常用案例——WordCount; ⚪ 掌握Spark的常用案例——求平均值; ⚪ 掌握Spark的常用案例——求最大值和最小值; ⚪ 掌握Spark的常用案例——TopK; ⚪ 掌握Spark的常用案例…

华为OD-整数对最小和

题目描述 给定两个整数数组array1、array2&#xff0c;数组元素按升序排列。假设从array1、array2中分别取出一个元素可构成一对元素&#xff0c;现在需要取出k对元素&#xff0c;并对取出的所有元素求和&#xff0c;计算和的最小值 代码实现 # coding:utf-8 class Solution:…

I2S/PCM board-level 约束及同步(latencyskewbitsync)

目录 1.I2S/PCM 同步 2.I2S/PCM的板间latency I2S/PCM是典型的低速串口&#xff0c;在两个方向上分别有两组信号&#xff0c;我们已soc为视角分为soc-adif和外设audio-codec。 那么adif输入&#xff1a; sclk_i, ws_i, sdi 当然并不是三个输入信号同时有效&#xff0c;只…

react 11之 router6路由 (两种路由模式、两种路由跳转、两种传参与接收参数、嵌套路由,layout组件、路由懒加载)

目录 react路由1&#xff1a;安装和两种模式react路由2&#xff1a;两种路由跳转 &#xff08; 命令式与编程式&#xff09;2-1 路由跳转-命令式2-2 路由跳转-编程式 - 函数组件2-2-1 app.jsx2-2-2 page / Home.jsx2-2-3 page / About.jsx2-2-4 效果 react路由3&#xff1a;函数…

模板方法模式(十六)

相信自己&#xff0c;请一定要相信自己 上一章简单介绍了代理模式(十五), 如果没有看过, 请观看上一章 一. 模板模式 引用 菜鸟教程里面的 模板模式介绍: https://www.runoob.com/design-pattern/template-pattern.html 在模板模式&#xff08;Template Pattern&#xff09;…

【HTML】HTML面试知识梳理

目录 DOCTYPE&#xff08;文章类型&#xff09;head标签浏览器乱码的原因及解决常用的meta标签与SEOscript标签中defer和async的区别src&href区别HTML5有哪些更新语义化标签媒体标签表单进度条、度量器DOM查询Web存储Canvas和SVG拖放 &#xff08;HTML5 drag API&#xff0…

高阶数据结构跳表

"想象为翼&#xff0c;起飞~" 跳表简介&#xff1f; skiplist本质上是一种查找结构&#xff0c;用于解决算法中的查找问题&#xff0c;跟平衡搜索树和哈希表的价值是 一样的&#xff0c;可以作为key或者key/value的查找模型。 跳表由来 skiplist是由美国计算…

12、Pinia 快速入门

1、什么是Pinia Pinia 是 Vue 的最新 状态管理工具 &#xff0c;是 Vuex 的 替代品 2、手动添加Pinia到Vue项目 在实际开发项目的时候,关于Pinia的配置,可以在项目创建时自动添加 现在我们初次学习&#xff0c;从零开始&#xff1a; 1.使用 Vite 创建一个空的 Vue3 项目 n…

流媒体服务器SRS的搭建及QT下RTMP推流客户端的编写

一、前言 目前市面上有很多开源的流媒体服务器解决方案&#xff0c;常见的有SRS、EasyDarwin、ZLMediaKit和Monibuca。这几种的对比如下&#xff1a; &#xff08;本图来源&#xff1a;https://www.ngui.cc/zz/1781086.html?actiononClick&#xff09; 二、SRS的介绍 SRS&am…

python操作elasticsearch

python操作elasticsearch_一个高效工作的家伙的博客-CSDN博客 待更新