1. 引言
B/S架构(Browser/Server架构)是一种基于浏览器和服务器的网络架构模式，有着跨平台、易部署和易维护的特点，得到了广泛应用。在船舶工程的应用场景中，常会使用到基于HTML5开发的B/S架构综合显控系统、数据管理系统、运行管理系统等，其中会涉及对来自于不同位置、不同设备的实时视频流的实时查看和存储管理，例如来自监控摄像头的监控画面、下位机工控机图像、计算机共享画面、无人机实时图传画面等；同时观看视频画面的位置会包括局域网内的固定设备、移动设备，或通过互联网实现远程访问。这要求开发人员需要根据不同的流媒体文件格式在加载速度、兼容性、传输延迟和用户体验等的差异，结合业务实际需求，选取合适的技术与格式进行应用系统开发。
本文旨在梳理和分析适用于船舶工程的应用场景中的、基于HTML5开发的B/S应用的实时流媒体技术，探讨其在技术特点、浏览器兼容性、传输效率、实时性等方面的差异，为开发者在B/S架构下的流媒体应用中选择合适技术进行开发提供科学依据。
2. 关键技术对比分析
2.1. 编码技术
编码技术指的是将原始音视频数据压缩成便于传输和存储的格式，在减小数据量的同时尽量保持原始质量的技术。在本节中，我们从技术特点、浏览器兼容性、带宽效率与视频质量三个方面，分别对H.264、H.265、AV1和VP9共4种主流的流媒体文件编码技术进行了综述。
H.264 (AVC-Advanced Video Coding) [1]是一种高效的视频编码方式，采用帧内压缩和帧间预测的组合，在较小的文件体积下提供高质量视频。其压缩比高且能支持多种分辨率(4K及以下) [2]，成为互联网视频和流媒体的主流选择。H.264被大多数主流浏览器支持，几乎所有现代浏览器都能够播放H.264编码的视频，包括Chrome、Firefox、Safari和Edge。H.264编码在前端库中有广泛支持，如Video.js和hls.js等流媒体库均支持H.264编码的视频文件。这些库的良好支持使得H.264成为大多数开发者的首选。H.264具有较高的带宽效率和优质的视频质量[3]，尤其在高清和全高清视频传输上表现出色。其编码效率使其适合低带宽环境，同时还能提供清晰的画面[4] [5]。
H.265 (HEVC-High Efficiency Video Coding)是H.264的继任者，支持从4K到8K等高分辨率视频，采用了更复杂的压缩算法，能够在相同质量下减少约50%的数据量[4] [6] [7]，进而减少带宽消耗[2]。Safari浏览器支持H.265编码，但Chrome、Firefox和Edge对其原生支持较少，这限制了H.265在跨浏览器视频应用中的普及。前端库对H.265的支持相对有限。Video.js等库可以在Safari中播放H.265编码视频，但在其他浏览器中需要额外插件或硬件支持。对于需要高兼容性的项目，H.265可能不是最佳选择。H.265比H.264拥有更高的带宽效率和更优的视频质量，在低带宽条件下可以呈现清晰度更高的画面，非常适合超高清内容的传输。不过其编码过程更复杂，对解码设备的计算能力要求较高[5]。
AV1 (AOMedia Video 1)是由开放媒体联盟开发的开源编码格式，旨在替代H.265，且不受专利限制。AV1采用高度优化的压缩算法，支持4K及更高分辨率，同时在带宽效率方面进一步提升[8]。AV1得到了Chrome、Firefox和Edge的支持，但Safari的支持有待完善。由于AV1编码在技术上的复杂性编码速度较慢，Video.js等库对其支持有限，且需要浏览器提供硬件加速或解码支持。但AV1比H.264和H.265有更好的带宽效率，在低比特率下仍可提供较高的视频质量[4] [5]，且解码效率在逐渐优化，适合对带宽敏感的应用场景。
VP9是VP8的继任者，是Google开发的开源视频编码格式，主要用于WebM容器中，专为网络优化设计，具有较高的压缩效率和较低的计算复杂度，能在保持相近画质的情况下显著降低码率，相较于H.264，能有效减少带宽消耗[8]。VP9在Chrome、Firefox和Edge浏览器中均有良好的支持，然而在Safari中支持有限，尤其在较旧版本中。Video.js和Plyr.js等前端库对VP9编码的支持较好。VP9的带宽效率极高，与H.264相比，VP9可以在相同的带宽下提供更高的视频质量，或在同等画质下大幅降低带宽消耗[5]。特别是在高分辨率应用(如4K视频)中，VP9的带宽效率优势明显，能保持较高的视觉质量[4]。
本节中提及的实时流媒体文件编码技术主要特点对比如表1所示。在评估带宽效率与视频质量时，根据不同研究资料中对各编码技术的性能对比，我们梳理出了各编码技术之间大致的性能倍数差距。在表格中，我们将带宽效率和视频质量性能最低的编码技术记为一个基准值1，而其他的编码技术性能记为相应的倍数。
Table 1. Comparison of the main features of real-time streaming media file encoding technology
表1. 实时流媒体文件编码技术主要特点对比
编码技术 |
特点 |
浏览器兼容性 |
带宽效率 |
视频质量 |
H.264 |
目前最主流的选择 |
大部分浏览器支持 |
1 |
1 |
H.265 |
支持大于4K分辨率，编解码复杂 |
Safari支持，其他大部分浏览器不支持 |
1.5 |
1.1 |
AV1 |
编解码复杂，开源 |
Safari不支持，其他浏览器大多可以支持 |
1.8 |
1.2 |
VP9 |
VP8的全面升级 |
Safari需要转码播放，其他浏览器大多支持 |
1.4 |
1.05 |
2.2. 文件容器格式
文件容器格式(或封装格式)是用来封装和组织视频、音频、字幕和元数据的文件格式。一个容器可以封装多个流，允许将视频、音频、时间戳、数据索引、字幕轨道等数据同时存储在一个文件中。不同的容器格式支持不同类型的编码技术，使得同一种编码内容在多种平台和设备上都能得到兼容和高效播放。在本节中，我们从编码支持情况、浏览器兼容性、带宽效率与视频质量等三个方面，分别对MP4、WebM、FLV、MKV、AVI和TS，共6种适用于网络流媒体传输存储的文件容器格式进行了综述。
MP4 (MPEG-4 Part 14)是最常用的视频封装格式之一，广泛应用于视频流媒体、存储和播放。它支持多种视频和音频编解码器，因其良好的兼容性和压缩效率而成为流媒体行业的标准[9]。主流浏览器(如Chrome、Firefox、Safari和Edge)均对MP4提供了良好的原生支持，因此用户在播放MP4式时几乎不需要额外的插件[10]。MP4格式的集成和开发相对简单，如Video.js、hls.js等知名前端库，以及HTML5中<video>标签均支持MP4播放。同时开发者社区资源丰富，使得新手开发者也能够快速上手。MP4支持多种音视频编码方式，具有良好的压缩率和高效的带宽利用率，适合在有限带宽环境下传输高清内容，在较小的文件大小下保持清晰度，适合高清视频点播和网络分发。
WebM是由Google开发的开源容器格式，专为网络设计，支持高效的视频流，旨在提供高效、低带宽的视频传输体验。WebM格式的开发相对简单，HTML5中<video>标签原生支持WebM格式，开发者无需额外的解码插件即可实现播放[10]。WebM格式在Chrome和Firefox中得到了广泛支持；在Safari浏览器中支持有限；Edge浏览器在较新版本中支持WebM格式，但对老版本的浏览器支持不佳。WebM使用VP9和AVI格式的编码，在前端库中得到广泛支持，大多数开源播放器(如Video.js、Plyr、Clappr等)都兼容WebM格式。WebM格式在带宽效率上表现良好，能够在较低带宽条件下保持较高的视频质量。
FLV (Flash Video) [1]格式基于Adobe Flash技术[11]，曾经在流媒体视频传输中被广泛使用，主要依赖Flash Player进行播放。然而，随着Flash技术逐渐退出主流Web标准，几乎所有浏览器都已停止对Flash的支持，导致FLV格式难以直接在网页上播放。为应对该情况，开发者可以采用FLV.js等JavaScript库在不依赖Flash插件的情况下解析FLV文件，并将其转换为HTML5兼容的视频流。另一个解决方案是将FLV流转换为更现代的格式，如通过服务器端转码将FLV转为HLS或DASH，以实现跨平台和多浏览器支持。FLV格式通常支持H.264编码，具有良好的带宽效率，文件体积相对较小，适合在网络带宽较低的情况下传输视频。但FLV格式的视频质量一般，在需要高清画质的场景中逐渐被替代。
MKV (Matroska Video)是开源的多媒体容器格式，支持多种音视频编码和字幕、章节等元数据[9]。MKV常用于高清影视存储和流媒体播放。Chrome和Firefox等主流浏览器对MKV的支持良好，但Safari的兼容性较差，大部分现代前端库支持MKV格式。由于支持多种编码方式，使得其开发难度不高，且应用广泛，适合不同场景。MKV格式支持H.264、H.265、VP8、VP9、AV1等多种编码方式，适合不同需求的视频播放，具有较高的带宽效率，适合高清播放和离线存储，画质优良。
AVI (Audio Video Interleave)是微软推出的多媒体容器格式，历史悠久，广泛用于视频存储。虽然AVI格式较老，但仍在某些场合中使用[9]。浏览器对AVI的原生支持较少，通常需要额外的插件才能播放。前端库对AVI的支持较差，多用于本地播放。AVI格式开发难度相对较低，但由于其格式限制，可能影响现代应用的灵活性。AVI格式支持多种编码方式，如MPEG-4和H.264，但由于其设计较早，压缩效率较低，在带宽效率上表现一般，虽然视频质量较高，但文件大小通常较大。
TS (Transport Stream)格式是由MPEG组织开发的一种用于存储和传输音视频的容器格式，常见于数字电视广播、实时流媒体和监控应用。TS格式的原生浏览器支持较少，大多数浏览器并不直接支持TS文件的播放。但通过前端流媒体库(如HLS.js、Video.js等)，可以实现基于HTTP Live Streaming (HLS)协议的播放[1] [11]，使TS格式能够适应浏览器播放环境，同时令开发者可以简化集成过程，相对轻松地播放TS格式文件。TS格式支持H.264和H.265等编码，支持高质量的视频传输，适合高带宽的网络环境，也可以在保证质量的同时减小传输带宽的需求。此外，TS格式的容错性较强，能够在网络传输不稳定的情况下保持较高的视频质量，因此被广泛应用于实时视频和数字电视广播等需要稳定性的场景。
本节中提及的实时流媒体文件容器格式主要特点对比如表2所示。在评估带宽效率与视频质量时，根据不同研究资料中对各容器格式的性能对比，我们梳理出了各容器格式之间大致的性能倍数差距。在表格中，我们将带宽效率和视频质量性能最低的容器格式记为一个基准值1，而其他的容器格式性能记为相应的倍数。
Table 2. Comparison of the main features of real-time streaming media file container format
表2. 实时流媒体文件容器格式主要特点对比
文件格式 |
支持编码 |
浏览器兼容性 |
带宽效率 |
视频质量 |
MP4 |
H.264、H.265 |
大部分浏览器原生支持 |
1.3 |
1.1 |
WebM |
VP8、VP9、AV1 |
Safari不支持，其他大部分浏览器原生支持 |
1.6 |
1.2 |
FLV |
H.264 |
FLASH停用后的新版浏览器均不支持，依赖前端库转码 |
1.2 |
1 |
MKV |
H.264、H.265、VP9、AV1 |
Safari不支持，其他大部分浏览器需要依赖前端库转码 |
1.4 |
1.1 |
AVI |
H.264 |
大部分浏览器不支持，需要依赖前端库转码 |
1 |
1 |
TS |
H.264、H.265 |
大部分浏览器原生不支持，但在HLS协议内使用，可在大部分浏览器内播放 |
1.3 |
1 |
2.3. 传输协议
传输技术是指将音视频数据从源端传送到目标端的技术方案，包含数据流如何被传输、传输时的协议规范、以及在网络不同状态下如何处理传输流的效率和可靠性。传输技术的核心在于实现流媒体数据的实时性、低延迟和高效传输。在本节中，我们从工作原理与特点、浏览器兼容性和实时性与延迟等三个方面，分别对HLS、DASH、RTSP、RTMP、HTTP-FLV和WebRTC，共6种主流的流媒体文件传输协议进行了综述。
HLS (HTTP Live Streaming) [11] [12]是一种基于HTTP的流媒体传输协议，由Apple推出并广泛应用于直播场景。HLS将视频内容切割成小的TS文件片段，并使用m3u8索引文件管理播放列表，播放器可以通过HTTP根据索引文件逐片段下载并播放视频，实现流式传输[13]。HLS在Safari浏览器上得到原生支持，但在其他浏览器中需要借助第三方库(如hls.js)来进行播放。HLS的实现相对复杂，开发者通常依赖现成的HLS播放器库(如hls.js、videojs-http-streaming等)来实现流媒体传输，避免繁琐的流切片和播放控制。由于HLS分片方式传输，每个分片通常为2~6秒，在传输实时流媒体内容时延迟相对较高[1]，通常大于10秒。低延迟HLS (Low-Latency HLS)可将延迟缩短至2~4秒，但还需要浏览器和服务器端的全面支持。HLS支持自适应比特率流，能够根据用户网络情况自动调整视频质量，提升带宽效率，适合大规模直播和高清视频内容分发。
DASH (Dynamic Adaptive Streaming over HTTP) [8]是一种基于HTTP的流媒体协议，与HLS协议类似，DASH将视频文件分成小段，客户端根据MPD文件索引下载片段。DASH格式在Chrome、Firefox、Edge等主流浏览器中获得良好支持，但在Safari浏览器中需要通过插件或转换为HLS实现兼容。DASH的实现较为复杂，开发者通常需要依赖Dash.js、Video.js等开源库来简化流程，且服务器配置和播放器管理也需要较高的技术背景，对开发者要求较高。DASH的实时性与HLS相似，一般延迟大于6秒，适合于直播延迟容忍度较高的应用。通过启用低延迟DASH (LL-DASH)模式，DASH协议的延迟可减少至2~4秒，最小延迟可达到1.5秒，但依赖于稳定的网络环境和优化的服务器设置。DASH也采用自适应比特率传输，支持多分辨率，可以根据网络状况自动调整视频质量，带宽利用率高且集成灵活。
RTSP (Real-Time Streaming Protocol) [6] [11] [13]是一种用于控制流媒体服务器的协议，支持音视频的实时传输，支持TCP、UDP协议的切换[14]。RTSP大多用于摄像头等硬件设备的实时视频流观看和推送，一般不在Web领域直接使用，未得到HTML5原生支持，Chrome、Firefox、Safari等主流浏览器都不直接支持RTSP协议，因此在Web应用中实现RTSP播放通常需要额外插件或转换工具，例如第三方库(如JSMpeg、RTSP to WebRTC)进行协议转换以支持网页播放，需要开发者具备一定的流媒体协议基础。RTSP协议支持双向传输和快速数据包处理，通常延迟在0.5~2秒，最小延迟在500毫秒以内[15]。
RTMP (Real-Time Messaging Protocol) [13]是由Adobe开发的一种流媒体传输协议，最早用于Flash播放器，专门设计用于低延迟的音视频数据传输[11]。RTMP通信是建立在TCP长连接通道上的，在封装音视频数据时会强制切片，限制每个数据包的大小，这在一定程度上保证了实时性，且有一定的弱网抵抗能力。随着Flash的逐渐退役，RTMP在浏览器端失去原生支持。如今，RTMP通常用于服务器端传输，在浏览器播放时，常用HTML5播放器(如Video.js、hls.js等)都不兼容RTMP格式，需借助中间件将RTMP流转换为其他格式，如HLS、DASH等格式来实现兼容。这种转换过程对服务器端处理和流媒体管理技术提出了更高要求，拉高了开发难度。然而RTMP在现代Web环境中仍具有一定应用价值，特别是在需要低延迟的直播或互动场景中，其延迟通常低于3秒[1]，最小可达到1~2秒[14] [15]。
HTTP-FLV [11]是一种低延迟的流媒体协议，基于HTTP长链接传输FLV容器格式的视频流数据[1]，支持跨平台播放，适合在直播中实现低延迟传输。与RTMP协议类似，HTTP-FLV会对视频文件会强制切片并限制每个数据包的大小，以此保证实时性和弱网抵抗能力。由于FLV格式依赖于FLASH播放器，在FLASH不受主流浏览器支持后，基于HTTP-FLV协议的视频播放也不再被直接支持。开发者可以采用FLV.js等前端库将FLV-HTTP协议的视频流转换为HTML5兼容的视频流进行播放[12]，或通过服务器端转为HLS或DASH流，以实现跨平台和多浏览器支持。HTTP-FLV协议的延迟也是比较低的，大概在1~3秒左右。
WebRTC (Web Real-Time Communication) [11]基于UDP进行通信，用于在浏览器和移动应用之间实现实时音视频和数据的点对点传输。WebRTC在现代主流浏览器中均原生支持[3]，无需安装插件，跨浏览器兼容性较好。WebRTC的开发难度相对较高，需要实现多种协议栈来确保流畅、低延迟的数据传输，会话控制和数据加密也需开发者进行精细化配置。然而WebRTC得到多个前端库的支持，如SimpleWebRTC、PeerJS和Socket.io，在一定程度上降低了开发难度。WebRTC以低延迟著称，延迟通常控制在500毫秒以内，最小延迟可达100毫秒左右，在点对点(P2P)通信中尤其高效。WebRTC视频质量在高比特率下表现优秀，当网络不稳定或带宽受限时，也可以降低清晰度以保证流畅的实时传输。
本节中提及的实时流媒体传输协议主要特点对比如表3所示。
Table 3. Comparison of the main features of real-time streaming media transport protocols
表3. 实时流媒体传输协议主要特点对比
编码技术 |
网络协议 |
浏览器兼容性 |
特点 |
播放延时 |
HLS |
TCP短连接 |
Safari浏览器原生支持，其余可通过前端库转码后直接播放 |
浏览器兼容性强 |
>10 s |
DASH |
TCP短连接 |
Safari浏览器需要转码后播放，其余浏览器新版支持较好 |
浏览器兼容性强 |
>6 s |
RTSP |
TCP/UDP可切换 |
需要前端或后台转码后才能播放 |
不适合浏览器播放 |
<2 s |
RTMP |
TCP长连接 |
需要后台转码后才能播放 |
不适合浏览器播放 |
<3 s |
HTTP-FLV |
TCP长连接 |
需要前端或后台转码后才能播放 |
依赖第三方库 |
<3 s |
WebRTC |
UDP |
大部分浏览器原生支持 |
开发难度大 |
<500 ms |
3. 视频源设备特点
不同的实时视频来源设备通常有着不同的流媒体传输方案。在进行信息管理系统的开发建设时，需要根据所需的应用场景，整理出所需兼容的传输方案，同时对可配置的设备选取较优方案进行设置，从而适应整个系统在使用需求中对视频延迟、质量、兼容性等方面的要求。以下是对几种常见实时视频来源设备特点的分析。
监控摄像头通常用于实时视频监控，通常采用高压缩效率、低延迟的H.264或H.265编码[1]。对于容器格式，多采用容错率高的TS，部分设备支持MP4，适合保存视频回放。由于对延迟要求较高，主要采用RTSP协议，且大多数监控设备内置RTSP支持，通过局域网或互联网传输实时视频；某些监控设备也支持HTTP直播流协议(HLS)，尤其在需要在网页或跨平台查看时。虽然HLS延迟稍高(通常8~10秒)，但其兼容性较好，适合存档录像和低实时性要求的监控场景。
网络摄像头主要用于视频通话、直播和会议等应用中，通常使用有较高的压缩效率、能在有限带宽下保证视频质量的H.264编码。对于容器格式，多采用便于网络传输的MP4、FLV格式。WebRTC是网络摄像头的主要传输协议，支持低延迟和点对点连接，适合实时视频交互。RTMP和HTTP-FLV则通常用于直播平台和网页嵌入应用。
移动设备(如手机、平板等)通常使用H.264、H.265和VP9编码保证压缩率和视频质量的平衡。由于对格式的兼容性要求较高，通常使用MP4和WebM作为容器格式，或使用TS格式配合HLS协议使用。针对浏览器兼容性，移动设备多采用HLS传输，也会使用WebRTC用于低延迟的实时通信场景，如视频通话和互动直播。
专业摄像机用于新闻直播、赛事转播等场景中，对画质和低延迟要求高，常采用H.264和H.265编码方式满足高质量的同时也保证了文件的兼容性。在容器格式上，MP4常用于需要高兼容性的直播和点播场景。在直播过程中，通常使用DASH或HLS进行流媒体传输，或通过RTMP协议传输至服务器，通过服务器推流到不同观看端。
无人机摄像头因其应用于户外实时影像传输，对实时性和带宽要求较高，故通常采用H.264或H.265编码来压缩视频流[2]。常用的容器格式有高兼容性的MP4和广泛用于实时推流的FLV。RTMP和HTTP-FLV协议因为具有较好的低延迟特性，常用于无人机平台的实时视频传输。如今也有部分无人机平台开始引入WebRTC以提供更低的延迟和更高的流畅性。
由于一些数据的处理与可视化工作(如气象数据、雷达数据等)需要依靠计算机实现，而计算机输出的可视化信息有被远程观看的需求，所以需要将计算机输出到显示器的画面编码为流媒体视频。H.264是计算机显示屏推流的主流编码方式，因其兼容性好、带宽效率高，适合清晰地呈现屏幕细节。VP9和H.265编码在一些高分辨率、高帧率需求下也被采用。MP4、WebM是最常用的视频容器格式。WebRTC和RTMP是计算机显示屏推流中最广泛使用的传输协议，RTMP适合向直播平台和内容分发网络(CDN)推送，WebRTC则用于互动性强的实时应用。对于非实时点播场景，也会使用DASH和HLS协议进行后续视频回放。
Table 4. Comparison of the main features of real-time streaming media source device
表4. 实时视频来源设备主要特点对比
视频来源设备 |
常用编码方式 |
常用容器格式 |
常用传输协议 |
监控摄像头 |
H.264、H.265 |
MP4、TS |
RTSP、HLS |
网络摄像头 |
H.264 |
MP4、FLV |
WebRTC、RTMP、HTTP-FLV |
移动设备 |
H.264、H.265和VP9 |
MP4、TS、WebM |
HLS、WebRTC |
专业摄像机 |
H.264、H.265 |
MP4、TS |
HLS、DASH、RTMP |
无人机 |
H.264、H.265 |
MP4、FLV |
WebRTC、RTMP、HTTP-FLV |
计算机 |
H.264、H.265、VP8和VP9 |
MP4、WebM |
WebRTC、RTMP、HLS、DASH |
本章中提及的实时视频来源设备主要特点对比如表4所示。
4. 技术路线建议
4.1. 选型原则
在基于HTML5的B/S架构应用中，实时流媒体技术的选型需综合考虑业务需求、设备特性及网络环境。对于开发者来说，首先需要明确核心需求，之后根据场景特性，确定技术组合。根据实际工程中的经验，我们提出了四条技术选型原则建议如下：
原则一：兼容性优先。适用于多终端访问、跨平台分发场景(如视频点播、公共直播等)。在编码上，建议优先选择浏览器支持率高的编码(如H.264等)，避免使用专利受限或兼容性差的编码(如H.265等)。在容器上，建议优先选择多平台原生支持(如MP4格式)或开源且广泛兼容(如WebM格式)的容器格式。在协议上，建议选择HLS或DASH，确保分段加载与容错性。
原则二：实时性驱动。适用于强交互场景(如视频会议、无人机操控、远程协作等)。在编码上，建议优先选择低带宽占用和适配超高清场景的编码方式(如VP9或H.265等)，但需权衡编码复杂度与设备算力。在容器上，建议优先选择低延迟格式(如WebM或FLV等)。在协议上，建议优先选择点对点传输协议(如WebRTC等)。
原则三：带宽效率优化。适用于网络条件受限的场景(如移动端户外直播、物联网设备图传等)。在编码上，建议优先选择压缩率高(如H.265等)或低码率(如AV1等)的编码方式。在容器上，建议优先选择抗丢包能力强(如TS等)或轻量级封装(如FLV等)的格式。在协议上，建议优先选择推流稳定(如RTMP等)或容错性强(如HLS、DASH等)的协议。
原则四：扩展性与未来适配。适用于有长期运维系统、技术迭代需求的场景(如5G/边缘计算等)。在编码上，建议预留多编码兼容方案，以确保能够逐步支持新兴编码方式(如AV1等)。在容器上，建议支持常用行业标准(如MP4等)，同时使用支持多轨道、元数据扩展(如MKV等)的格式使用。在协议上，建议使用支持模块化设计、易于扩展分辨率/码率层级(如DASH等)的协议。
4.2. 典型场景技术栈推荐
针对监控与安防、视频点播、视频会议、实时交互和户外推流五个典型应用场景，我们给出了一份应用场景与设备适配的技术组合推荐，如表5所示。
Table 5. Recommended combinations of technologies for application scenarios and device adaptation
表5. 应用场景与设备适配的技术组合推荐
应用场景 |
典型设备 |
编码 方式 |
容器 格式 |
传输协议 |
核心需求 |
适配逻辑 |
监控安防 |
监控摄像头、无人机 |
H.264 |
TS、FLV |
HTTP-FLV、HLS |
低延迟、
高稳定性 |
H.264兼容性强；TS容错性高，HTTP-FLV替代RTSP以适配HTML5播放。 |
视频点播 |
服务器、专业摄像机 |
H.264、AV1 |
MP4、WebM |
HLS、DASH |
高画质、
高兼容性 |
MP4/WebM广泛支持；HLS/DASH自适应码率，适合网络波动。 |
视频会议 |
网络摄像头、计算机 |
VP9、H.265 |
MP4、WebM |
WebRTC |
超低延迟 |
WebRTC原生支持P2P；VP9/H.265优化带宽占用与画质。 |
实时交互 |
移动设备、AR/VR设备 |
VP9、H.264 |
WebM、TS |
WebRTC、HTTP-FLV |
即时反馈、高可靠性 |
WebRTC确保低延迟；TS抗丢包，HTTP-FLV适配移动端弱网环境。 |
户外推流 |
无人机、移动设备 |
H.264、H.265 |
FLV、TS |
RTMP、WebRTC |
抗弱网、
低带宽消耗 |
H.265压缩率高；RTMP推流稳定，WebRTC适配户外实时传输。 |
5. 结语
本文针对基于HTML5的B/S架构信息管理系统开发场景，从实时流媒体文件编码技术、文件容器格式和传输协议三个方向综述了多种实时流媒体文件技术，分别对比了它们在技术特点、浏览器兼容性、实时性和带宽效率与视频质量等方面的区别，从而找出其各自的优势和局限性，为开发者应根据应用场景选择适合的HTML5流媒体视频技术进行开发提供了参考。
此外，随着5G和AI技术的发展，流媒体文件格式将进一步优化，更低延迟和更高质量的实时传输将成为未来研究的重点方向，我们也将继续重点关注新技术在流媒体传输和格式优化中的应用，探索更智能化、高效化的解决方案。