视频面试集锦-CSDN博客

本文链接：https://blog.csdn.net/weixin_40966119/article/details/139666125

SDK开发复习资料

1、SDK的特点

SDK是一组工具、库、文档和示例代码的集合，旨在简化软件开发过程。它为开发人员提供了一种更全面的解决方案，包括各种工具和资源，以便他们可以更轻松地构建特定类型的应用程序。

以下是SDK的一些主要特点：

完整性：

SDK通常是一套完整的开发包，包括开发所需的所有组件，如库、工具和文档。这种完整性使开发人员能够更容易地入门并迅速构建应用程序。

集成性：

SDK通常集成了一组工具，使得开发人员能够在一个集成的环境中进行开发，而无需寻找和配置各种不同的工具。

功能性示例：

SDK通常包含用于演示其功能的示例代码。这些示例代码有助于开发人员理解如何使用SDK提供的功能，并在实际应用中进行定制。

平台特定性：

某些SDK可能是针对特定平台或操作系统的，以提供最佳的集成和性能。

SDK的应用场景：

当开发人员需要构建一个涉及复杂功能和多个组件的应用程序时，SDK是一个理想的选择。它提供了一个全面的工具包，简化了整个开发过程。

2、SDK开发的难点

跨平台兼容性：

SDK需要能在不同的操作系统和平台上运行，如iOS、Android、Windows等。这需要对各种平台的API有深入的了解，并且需要处理不同平台之间的差异和兼容性问题。
安全性：

SDK可能需要处理敏感的用户数据，因此安全性是一个重要的问题。需要确保SDK在传输和存储数据时的安全性，避免数据泄露或被恶意利用。
性能优化：

SDK的性能对用户体验有很大的影响。需要对SDK进行性能优化，包括内存管理、CPU使用率、网络请求等方面，以确保SDK能够快速、稳定地运行。
文档和支持：

SDK需要提供详细的文档和用户支持。文档需要清晰地说明如何使用SDK，包括API的说明、示例代码等。同时，需要提供用户支持，解决用户在使用SDK过程中遇到的问题。
更新和维护：

随着操作系统的更新和技术的发展，SDK可能需要进行更新和维护。这需要对新技术进行跟踪，并及时更

新SDK以适应新的环境和需求。
集成和测试：

SDK需要与各种应用程序进行集成，并进行大量的测试以确保其稳定性和兼容性。这需要投入大量的时间和精力。

3、视频SDK的传输算法通常涉及多个层面和关键技术

网络传输：

视频SDK通常使用UDP（用户数据报协议）作为底层传输协议，因为它更适合实时数据传输。在此基础上，可能实现诸如TCP友好速率控制（TFRC）等算法，以在不可靠的网络环境中实现更可靠和高效的视频流传输。
编解码器：

视频SDK中通常包含编解码器，用于将原始视频数据压缩成更小的数据包，以便在网络中传输，并在接收端进行解压缩以恢复原始视频。常见的编解码器包括H.264、H.265（HEVC）和VP8/VP9等。
拥塞控制和网络连接控制：

在网络传输中，拥塞控制和网络连接控制是关键技术。这些技术可以确保视频流在网络拥塞时仍能稳定传输，并避免数据包丢失或延迟。常见的拥塞控制算法包括TCP Reno、TCP Vegas和TCP NewReno等。
媒体流处理：

媒体流处理涉及将视频和音频数据打包成RTP（实时传输协议）数据包，以便在网络中传输。在接收端，需要对这些数据包进行解码和同步，以恢复原始的音视频流。
传输协议：

除了底层的UDP协议，视频SDK还可能使用其他传输协议，如RTMP、HLS和WebRTC等。这些协议具有不同的特点和适用场景，需要根据具体需求进行选择。

总之，视频SDK的传输算法涉及多个层面和关键技术，需要综合考虑网络条件、设备性能、编解码技术等因素，以实现高效、稳定、低延迟的视频传输。

4、视频SDK的传输算法显示流程

原始视频数据采集
- 通常通过摄像头或其他视频输入设备获取原始视频帧。
- 这些帧通常以YUV4:2:0等格式表示，这是一种常见的颜色编码格式，用于表示像素的颜色信息。
视频编码
- 编码是将原始视频数据转换为更紧凑的格式的过程，以便在网络中高效传输。
- 编码通常使用如MPEG2、H.264或VP8/VP9等标准。
- 在编码过程中，会使用各种技术如运动估计、变换编码和量化等，以去除视频帧中的冗余信息，从而达到压缩的目的。
网络传输
- 编码后的视频数据通过网络协议（如UDP）进行传输。
- 在网络层，可能会实现拥塞控制和网络连接控制算法，以确保视频流在网络条件不佳时仍能稳定传输。
- 传输过程可能涉及数据包的分片、重组和重传等机制，以应对网络中的丢包和延迟问题。
视频解码
- 在接收端，需要对传输过来的编码视频数据进行解码，以恢复原始的视频帧。
- 解码过程与编码过程相反，需要按照编码时使用的标准和技术进行逆操作。
- 解码后的视频帧通常以YUV4:2:2等格式表示，以适应不同的显示设备。
视频显示
- 解码后的视频帧被传输到显示设备（如电视、电脑屏幕或移动设备）上进行显示。
- 显示过程可能涉及颜色空间转换、图像缩放和帧率调整等操作，以适应不同的显示要求。
任务同步与消息传递
- 在整个流程中，不同的任务（如采集、编码、传输、解码和显示）之间需要进行同步和通信。
- 这通常通过SCOM_message等消息传递机制来实现，确保各个任务能够协同工作，构成一个回环（loopback）的传输流程。

需要注意的是，视频SDK的传输算法设计需要考虑多种因素，如网络带宽、延迟、设备性能、编解码效率等。因此，在实际应用中，可能需要根据具体需求进行定制和优化，以达到最佳的视频传输效果。

拥塞控制和网络连接控制算法是计算机网络中的重要组成部分，用于确保网络在负载较重时仍能保持较高的性能。以下是这些算法的一些具体实现方式：

QoS的度量指标

影响网络质量的因素包括传输链路的带宽、报文传送时延和抖动、以及丢包率等，它们也就成为了QoS的度量指标。

（1）带宽

带宽也称为吞吐量，是指在一个固定的时间内（1秒），从网络一端传输到另一端的最大数据位数，也可以理解为网络的两个节点之间特定数据流的平均速率。带宽的单位是比特/秒（bit/s）。在网络中，有两个常见的与带宽有关的概念：上行速率和下行速率。上行速率是指用户向网络发送信息时的数据传输速率，下行速率是指网络向用户发送信息时的传输速率。例如，用户通过FTP上传文件到网络，影响上传文件速度的就是上行速率；而从网络下载文件，影响下载文件速度的就是下行速率。

（2）时延

时延是指一个报文或分组从网络的发送端到接收端所需要的延迟时间，一般由传输延迟及处理延迟组成。以语音传输为例，时延是指从说话者开始说话到对方听到所说内容的时间。一般人们察觉不到小于100毫秒的延迟。当延迟在100毫秒和300毫秒之间时，说话者可以察觉到对方回复的轻微停顿，这种停顿可能会使通话双方都感觉到不舒服。超过300毫秒，延迟就会很明显，用户开始互相等待对方的回复。当通话的一方不能及时接收到期望的回复时，说话者可能会重复所说的话，这样会与远端延迟的回复碰撞，导致重复。

（3）抖动

如果网络发生拥塞，导致通过同一连接传输的分组延迟各不相同。抖动用来描述延迟变化的程度，也就是最大延迟与最小延迟的时间差。抖动对于实时性的传输是一个重要参数，特别是语音和视频等实时业务是极不容忍抖动的，抖动会造成话音或视频的断续。抖动也会影响一些网络协议的处理。有些协议是按固定的时间间隔发送交互性报文，抖动过大会导致协议震荡。所有传输系统都有抖动，只要抖动在规定容差之内就不会影响服务质量。利用缓存可以克服过量的抖动，但这将增加时延。

（4）丢包率

丢包率是指在网络传输过程中丢失报文的数量占传输报文总数的百分比。少量的丢包对业务的影响并不大，例如，在语音传输中，丢失一个比特或一个分组的信息，通话双方往往注意不到。在视频的传输中，丢失一个比特或一个分组可能造成在屏幕上瞬间的波形干扰，但能很快恢复正常。使用TCP传送数据可以处理少量的丢包，因为TCP允许丢失的信息重发。但大量的丢包会影响传输效率。在QoS中，我们关注的是丢包的统计数据，也就是丢包率。所以正常传输时，网络丢包率应该控制在一定范围内即可。

QoS的应用场景

以企业办公为例，除了基本的网页浏览、工作邮件外，在较集中的工作时间段内还需要保证Telnet登录设备、异地的视频会议、实时语音通话、FTP文件的上传和下载，以及视频播放等业务的网络质量。对于不同网络质量要求的业务，可以配置不同的QoS子功能，或者不部署QoS。

（1）网络协议和管理协议（如OSPF、Telnet）

这类业务要求低时延和低丢包率，但对带宽的要求不高。因此可以通过QoS的优先级映射功能，为此类报文标记较高的服务等级，使网络设备优先转发此类报文。

（2）实时业务（如视频会议、VoIP）

视频会议要求高带宽、低时延和低抖动。因此可以通过QoS的流量监管功能，为视频报文提供高带宽；通过QoS的优先级映射功能，适当调高视频报文的优先级。

VoIP是指通过IP网络进行实时语音通话，它要求网络做到低丢包、低时延和低抖动，否则通话双方可以明显感知质量受损。因此一方面可以调整语音报文的优先级，使其高于视频报文；另一方面通过流量监管功能，为语音报文提供最大带宽，在网络产生拥塞时，可以保证语音报文优先通过。

（3）大数据量业务（如FTP、数据库备份、文件转储）

大数据量业务是指存在长时间大量数据传输行为的网络业务，这类业务需要尽可能低的网络丢包率。因此可以为这类报文配置流量整形功能，通过数据缓冲区缓存从接口发送的报文，减少由于突发流量导致拥塞而产生的丢包现象。

（4）流媒体（如在线音频播放、视频点播）

由于这些音视频节目都是提前制作好的，观看者的终端通常可以先进行缓存再进行播放，因此降低了对网络时延、丢包和抖动的要求。如果需要降低这类业务的丢包和时延，可以通过QoS的优先级映射功能，适当提高对应报文的优先级。

（5）普通业务（如HTML网页浏览、邮件）

这类业务对网络无特殊要求、重要性也不高。管理员可以对其保持默认设置，不需要额外部署QoS功能。

8、WebRTC面试问题的回答：

1、请解释一下WebRTC是什么，以及它的工作原理是什么？

WebRTC（Web Real-Time Communication）是一种允许网页浏览器和移动应用程序进行实时通信（RTC）的开放项目。它支持音频、视频和数据传输，无需中间服务器或插件。WebRTC的工作原理基于P2P（点对点）连接，当两个用户想要通信时，WebRTC会尝试建立直接的数据通道。如果直接连接失败，它会回退到通过中间服务器进行中继。

两个WebRTC客户端会尽可能选择P2P进行连接，那么进行连接前是如何发现对方的？就是通过信令服务器。

首先将你所有网络相关信息传到信令服务器，服务器帮你交换到对端，对端拿到你的信息后，

若在同一局域网内，直接通过P2P传输；若不在，首先进行P2P穿越，看是否能打通，打通则传输，打不通则中转等。

2、WebRTC中两个端间通信的基本流程：

获取媒体流：首先，通信的双方需要分别获取本地的音视频流。这通常通过使用WebRTC的API（如getUserMedia）来实现，该API可以访问用户的摄像头和麦克风，获取音视频数据。
建立信令通道：在WebRTC中，信令通道是用于交换控制信息的通信路径。通信双方需要建立一个信令通道，以便交换媒体协商信息、ICE候选地址等。信令通道可以通过WebSocket、HTTP或其他协议来建立。在实际应用中，信令通道通常由应用服务器来维护，以便在通信双方之间传递信息。
进行媒体协商：一旦信令通道建立成功，通信双方就可以开始进行媒体协商。这包括交换SDP（Session Description Protocol）信息，以确定双方支持的媒体类型、编解码格式、传输协议、码率、分辨率等参数。双方根据对方的SDP信息进行协商，选择合适的媒体参数。
交换ICE候选地址：在媒体协商过程中，通信双方会交换ICE（Interactive Connectivity Establishment）候选地址。ICE是一种NAT穿透协议，用于解决由于网络地址转换（NAT）导致的端到端通信问题。通信双方通过交换ICE候选地址，可以找到一条可以直接通信的路径。
建立P2P连接：在成功交换ICE候选地址后，通信双方会尝试建立P2P（点对点）连接。如果双方都在同一个局域网内，可以直接建立P2P连接；否则，需要通过STUN（Session Traversal Utilities for NAT）或TURN（Traversal Using Relays around NAT）服务器进行中继，以实现端到端的通信。
传输音视频数据：一旦P2P连接建立成功，通信双方就可以开始传输音视频数据。数据通过RTP（Real-time Transport Protocol）协议进行传输，同时RTCP（RTP Control Protocol）协议用于传输控制信息，如流的统计数据、同步信息等。

总的来说，WebRTC的通信过程涉及多个步骤和协议，但通过合理的设计和实现，可以实现高效、稳定的实时音视频通信。

3、webrtc是P2P通信，那为什么还要服务器呢

WebRTC确实支持P2P通信，即两个客户端可以直接建立连接并交换数据，无需通过服务器中转。然而，在实际应用中，WebRTC仍然需要服务器的支持，原因有以下几点：

信令传输：虽然WebRTC支持P2P通信，但在建立连接之前，客户端之间需要通过服务器进行信令传输。信令传输是指客户端之间交换控制信息，如建立连接、协商参数等。这些控制信息需要通过服务器进行转发，以确保两个客户端能够正确地建立连接。
NAT/防火墙穿越：在P2P通信中，由于网络地址转换（NAT）和防火墙的存在，可能导致两个客户端无法直接建立连接。这时，需要服务器协助进行NAT/防火墙穿越，以便客户端之间能够建立直接的P2P连接。WebRTC通过使用STUN、TURN等协议来实现NAT/防火墙穿越。
用户发现与通信协调：服务器还可以用于用户发现和通信协调。例如，当多个客户端想要建立通信时，可以通过服务器来发现其他在线的客户端，并协调建立连接的过程。

因此，虽然WebRTC支持P2P通信，但仍然需要服务器的支持来实现信令传输、NAT/防火墙穿越以及用户发现与通信协调等功能。这样可以确保WebRTC在不同网络环境下的稳定性和可靠性。

两个WebRTC客户端会尽可能选择P2P进行连接，那么进行连接前是如何发现对方的？就是通过信令服务器。

首先将你所有网络相关信息传到信令服务器，服务器帮你交换到对端，对端拿到你的信息后，若在同一局域网内，直接通过P2P传输；若不在，首先进行P2P穿越，看是否能打通，打通则传输，打不通则中转等。