论文部分内容阅读
摘 要 随着互联网的快速发展和网络带宽的逐年增加，网络上视频内容逐渐增多，更多的内容从纯文本网页发布变为文本加视频发布。但是，互联网存档很难采集到网络视频，这些视频通常使用非标准工具和协议。本文提供了该领域采集技术的概述。基于几年采集网络视频内容的经验，本文提供了HTTP协议和RTMP协议视频采集的示例，阐述了采集网络视频内容的问题和解决方案。本文还提出了一种外部下载器作为视频采集模块，用于扩展网络视频内容采集。
关键词 互联网存档 网络视频 流媒体 视频采集
分类号 G250
DOI 10.16810/j.cnki.1672-514X.2021.03.04
Research on Video Collection in Internet Archiving： Taking National Library of China as an Example
Yang Yunpeng
Abstract With the rapid development of the Internet and the increase in network bandwidth year by year， video content on the Internet has gradually increased， and more content has changed from publishing plain text web pages to publishing text plus video. However， it is difficult for Internet archives to capture network videos， which usually use non-standard tools and protocols. This article provides an overview of acquisition techniques in this field. Based on years of experience in collecting network video content， this article provides examples of HTTP protocol and RTMP protocol video capture to illustrate the problems and solutions of collecting network video content. This article also proposes an external downloader for video capture module， which is used to expand network video content capture.
Keywords Internet archive. Web video. Streaming media. Video capture.
0 引言
視频已成为当今网络的重要组成部分。视频为了免于被盗版，一般都会采取加密传输的方法，免于用户直接访问视频源文件。这就使得Web档案管理员收集视频内容的任务变得更加困难，需要开发特定的方法和工具[1-2]。
本文的目的是讨论在网络上视频采集的难点。根据过去几年在国家图书馆网络采集中获得的经验，我们将视频采集中所遇到的问题分为两个主要类别，并使用一些典型的例子说明了几种技术解决方案。第一类使用标准HTTP协议传递视频内容的网站，其难点在于使用混淆视频文件链接的技术（例如：2或3跳跃重定向）。第二类问题是使用HTTP以外的传输协议的网站，从互联网上当前使用的各种流协议中，我们选择了最新且困难的RTMP流协议作为示例。值得注意的是，用于在网络上保存视频的技术发展得非常快，这里介绍的案例很可能在细节上迅速发生变化，我们的工具需要不断改进和更新。但是，其蕴含的原理，将帮助我们不断优化采集方法。
在本文的第二部分中，我们提出了一种体系结构设计以解决该问题，即将视频解耦下载下来，从而实现快速适应性和可伸缩性。这种设计原理更易于集成和更新，在可扩展性和灵活性方面都得到了很大的提升，进一步提高了效率。同时，与采集器同步工作为错误处理和流程管理提供了更好的支持。
1 视频采集方法
1.1 HTTP协议视频网站采集策略
每个视频均由散列标识符唯一标识，并且通常可以在HTML页面中使用URL进行访问，该URL类似于http：//www.*.com/uniqueID，采集网站视频时最困难的是访问视频的机制不断更新[3]，需要不断努力隐藏视频文件的直接URL。使用经典的采集方法，爬虫必须遵循5个不同的直接链接或重定向步骤，才能实际访问视频内容。表1总结了中间URL的一般模式。
知道了视频标识符（foobar）和网站页面的URL（序号1），采集程序首先发现页面中使用的Flash播放器的URL（序号2）。从传递给播放器的参数列表中，采集程序可以标识出请求视频内容时要使用的HTMI查询（序号3）。在真正获取视频文件的URL（序号5）之前，采集程序必须提供包含编码令牌的中间重定向（序号4），例如主机的IP地址和请求的时间戳。视频的URL（序号5）集成在Flash参数中，该Flash参数在加载页面（序号1）时动态生成。采集程序主要问题在于正确识别此URL，因为它包含不同的转义字符，并且与Flash对象解释的其他参数混合在一起。例如，在当前视频网站页面中，“flashvars”参数的字符串长度为6374个字符，而要匹配的URL包含392个字符。在对页面（序号1）进行分析时，还可以在生成Flash参数的JavaScript片段中标识视频的URL（序号5）。在网站页面中，要解析文本行包含的“PLAYER_CONFIG”字符串，其后是随机排列的URL列表。在两个（“|”）字符之间，可以根据IP地址和时间戳提取视频的URL，该URL已经包括计算出的令牌。 可以看到，获取视频文件的路径是曲折的，视频资源的URL因为被重定向和添加临时令牌而混淆。在采集参数方面，这可以将采集程序修改为5级深度抓取视频网站。此外，序号2，序号4和序号5中的URL指向不同的子域，因此需要将它们显式添加到采集的范围内。
重定向生成的URL还存在一个问题，就是存档重放工具访问的问题。即使每个视频文件在网站上都得到了唯一标识，但是每次下载时会由于时间戳而动态生成不同的URL。因此，需要在URL索引中添加显式引用，以保持原始页面（在序号1中）和视频文件的URL（在序号5中）之间的联系。
在实践中，有两种方法可以在HTTP协议的视频网站上进行视频存档：在线视频采集技术和离线下载视频技术。在线采集视频技术采集过程中，视频文件是在爬网时使用Heritrix软件的附加处理器进行下载。例如，由亚当·泰勒编写的beanShell脚本会将所有中间URL（序号2～5）注入边界，因为中间跃点通常不在当前爬网范围内。视频文件将直接添加到采集程序的WARC文件中。离线方法首先根据网站页面的URL下载视频文件，然后在后期进行加工处理。它使用由里卡多·加西亚·冈萨雷斯开发的外部下载器，该下载器采集视频内容并将其转储为flv文件，然后使用WARC Tools工具将flv文件打包到不同的WARC文件中。两种方法都需要视频的原始URL（如出现在网页中）和文件名或指向视频内容的URL新生成链接。
在线采集方法的优点在于，视频文件的下载是由采集程序自身完成的，并且不需要其他外部工具监视和同步。此外，在与网站服务器进行对话之后，所有HTTP标头都存储在存档中。这种方法的缺点是视频内容的最终URI（如序号5）不再包含视频的原始标识符（如序号1），回溯视频标识符变得难以管理，归档文件也被所有重定向URL污染（它们不再是有效的URL，因为下载令牌的有效性受到限制）。离线方法在监视和管理外部下载程序（例如错误处理）方面提供了更大的灵活性。视频文件保留其原始标识符的名称，并且重定向URL不存储在存档中。由于外部下载程序不保留服务器响应，因此需要在每个存储flv文件的WARC文件中插入一个“假”HTTP头。
1.2 RTMP协议视频网站采集策略
1.2.1 网络视频流协议概述
与互联网工程任务组（IETF）标准相对应的流技术允许服务器控制传输，并进行了严格的优化以保持实时运行。客户不必下载潜在的巨大文件，这种方法特别适合现场直播。实际上，流传输通常使用两种类型的实时流协议：实时传输协议（RTP）[rfc3550]发送媒体数据包，以及实时流协议（RTSP）[rfc2326]作为控制信息。RTP使用潜在的有损UDP，该UDP不会尝试重新传输丢失的数据包，因此系统被设计为可以承受传输期间数据包的丢失。这意味着客户端要能够很好地处理只获取到部分视频帧或音频样本数据的情况。这比基于TCP/IP的方法更好，后者可以进行不確定的重试次数（从而花费不确定的时间）来获取丢失的数据包。
实时流协议（RTSP）是一种网络控制协议，用于娱乐和通信系统，以控制流媒体服务器。该协议用于建立和控制两端之间的媒体会话。媒体服务器的客户端发出类似于VCR的命令，例如播放和暂停，以便于实时控制服务端的媒体文件的播放[4-5]。
RTSP协议与HTTP相似，但是RTSP添加了新的请求。HTTP是无状态的，而RTSP是有状态的协议。会话标识符用于在需要时跟踪会话，因此，不需要永久的TCP连接。RTSP消息从客户端发送到服务器，只有少数情况下会从服务器发送到客户端。
多媒体消息服务（MMS）是用于发送带有多媒体对象（图像，音频，视频，富文本）消息的电信标准。MMS是SMS标准的扩展，允许更长的消息长度，并使用WAP显示内容。MMS消息的发送方式几乎与SMS相同，但是首先要将所有多媒体内容进行编码，然后以类似于发送MIME电子邮件的方式将其插入文本消息中。
实时消息协议（RTMP）是Adobe Systems开发的一种专有协议，用于在Flash播放器和服务器之间通过互联网传输音频、视频和数据[6]。为了保证视频和音频流的平稳传递，同时保留传输更大信息块的能力，该协议可以将视频和数据拆分为片段。首先所用片段的大小可以在客户端和服务器之间动态协商，如果需要，甚至可以完全禁用它们。然后，来自不同流的片段可以在单个连接上交错和多路复用。Adobe于2009年6月15日开放了RTMP协议的规范，但该规范似乎省略了协议实现的许多细节。
1.2.2 采集RTMP网络视频
根据国家图书馆采集程序对视频采集的研究，本节将介绍基于RTMP协议进行视频网站采集的一些技术细节。
（1）视频页面布局。显示视频的Web页面的结构与HTTP协议网站的相同。HTML页面包含一个主视频面板，其中包括原始视频播放器。每个HTML页面的内容由服务器动态生成，并存储在特定的HTML元素中[7-8]。将Flash Player嵌入到<object>元素中，并从Web服务器加载。播放器所需的所有参数均由JavaScript函数（创建视频播放器）准备，并传递给Flash对象（使用flashvars参数）。从这一点开始，与流服务器的整个对话将直接由Flash Player处理。
（2）下载流媒体视频。从爬虫的角度来看，视频文件的URL清晰地写在了JavaScript片段内，这代表了一种有利的情况，因为JavaScript提取器能够识别和提取视频文件的URL。但是，此URL并不是采集程序的有效URL，因为它不支持HTTP/HTTPS以外的协议方案。因此，RTMP URL将在采集的错误日志中报告为无效URL。为了有效地下载视频文件（rtmp：//…/foobar-video.flv），将RTMP URL从错误日志中过滤掉，并传递给外部下载器（即FLVStreamer），RTMP下载器需要先将视频内容转储到flv文件中，然后再将其打包存储到WARC文件中。 （3）访问存档中的视频内容。从访问的角度来看，实时网页和已存档网页之间的根本区别在于用于将视频内容交付给播放器的传输协议。在存档的基础架构上部署流服务器需要大量的工作，这是一个开发和维护成本昂贵的解决方案。它还需要针对不同的协议运行不同的服务器。为了实现通用，我们通过HTTP协议对存档视频内容进行访问，并且flv文件与HTML页面及其他资源一起直接从WARC文件提取出来。流媒体的特定功能已丢失（例如快进或增量下载），但是可以确保对视频内容的基本访问，并且可以适应不同的情况而不需要额外的工作。
对于大型视频来说，用纯HTTP代替流媒体的一个重要缺点变得显而易见。如果未进行任何改编，播放器需要在开始播放视频之前加载整个flv文件。我们已调整了访问工具，通过增量地从存档中加载视频文件的块来缓解此问题。块的大小是优化的关键，但是在更快地访问视频和缓冲方法的复杂性之间需要权衡取舍。
在访问时，要进行的主要调整是更换原始Flash Player。由于已存档的视频文件不再流媒体传输，因此页面上的原始播放器无法在存档的版本上使用，HTML容器需要相应地更新。
与实时页面相比，在存档版本中，用包含存档特定播放器的特定<embed>元素替换<script>和<object>元素。注意，此时已存档视频文件的URL已转换为指向存档中flv文件的HTTP URL。
HTML元素的替换是通过在服务器上访问代码实现的特定方法即时完成的。WARC文件始终保留页面的原始版本。寻找正确的模式来正确识别和替换播放器仍然是一项挑战，因为<object>元素的结构和属性可能在不同网站之间有所不同。
在本节中，我们重点介绍采集RTMP流视频的示例，因为下载过程涉及特定的流协议。尽管如此，访问代码中实现的播放器替换技术也可以用于HTTP下载的视频。
2 使用外部下载器进行视频采集
作为LiWA项目中开发的Web归档新技术的一部分，针对不同的多媒体内容类型，设计了一个特定的模块来增强采集系统的采集功能。Heritrix的当前版本主要基于HTTP/HTTPS协议，不能广泛用于处理多媒体内容（例如流媒体）的其他传输协议。LiWA Rich Media Capture模块将多媒体内容检索委托给能够处理更大范围传输协议的外部应用程序（例如MPlayer或FLVStreamert）。该模块被构造为Heritrix的外部插件。使用这种方法，流的标识和检索完全分离，从而允许使用更有效的工具来分析视频和音频内容。同时，使用外部工具有助于减轻爬网过程的负担。
2.1 模块结构介绍
该模块由几个通过消息进行通信的子组件组成。我们使用一种高级消息队列协议（AMQP）的开放标准通信协议。Rich Media Capture模块与采集系统的集成如图1所示，消息的工作流程可以总结如下。连接到Heritrix的插件检测流媒体的URL，并为其中的每一个URL构造一个AMQP消息。此消息将传递到中央Messaging Server。Messaging Server的作用是将Heritrix与流媒体下载器（即外部下载工具）分离。Messaging Server将URL存储在队列中，并且其中一个流媒体下载器可用时，它将发送下一个URL进行处理。在模块的软件架构中，有三个不同的子模块：
（1）控制模块，负责访问Messaging Server，启动新作业，停止新作业并发送警报;
（2）用于流媒体的识别和下载（此处使用外部工具，例如MPlayer）;
（3）将下载的流重新打包为访问工具（WARC编写器）可以识别的格式。
当流媒体下载器空闲时，将连接到Messaging Server，以请求采集新的流媒体URL。在接收到新的URL后，将进行初始分析以检测一些参数，其中包括流媒体的类型和持续时间。当然，如果流是直播的，则可以配置固定的持续时间。成功识别后，便开始实际下载。控制模块生成一个作业，并将其与时间参数一起传递给下载器，以确保下载所花费的时间不会超过初始估计的时间。成功采集后，最后一步是将采集的流媒体视频编写到WARC文件中，然后将其移动到最终存储中。
2.2 优化采集模块
测试中出现的主要问题是采集系统和外部采集模块之间的同步。如果采集网站上有大量视频，那么依次下载每个视频肯定要比文本页面的采集过程花费更多的时间。因此，采集系统必须等待外部模块完成视频的下载。
通过增加下载器的数量，可以提高视频采集的速度。但是另一方面，增加下载器的方法将受到流媒体服务器上可用最大带宽的限制。另一种解决方案是将视频采集模块与采集程序完全分离，然后再进行后期处理。这意味着用日志读取器和视频下载程序的独立管理器替换了采集系统搜寻插件。这种方法的优点是直接显示视频URL总数，可以更好地管理下载资源（所有视频下载器共享带宽）。此方法的主要缺點是网站的采集时间和独立采集的视频之间可能出现不一致，可能导致一些视频内容不存在（视频采集延迟了1到2天），或部分视频下载被阻止。
因此，在管理视频下载时需要权衡取舍，缩短完整下载的时间，处理错误（慢速服务器提供的视频内容）和优化多个下载器使用的总带宽。
3 结论
本文通过介绍国家图书馆HTTP协议和RTMP协议视频存档的工作经验，分析了互联网视频存档的原理和步骤。首先是找到视频的真实URL，然后选择通过下载器进行下载，最后编写到WARC文件当中。视频的存档主要有三种方法：视频和文本同时采集编写到WARC文件;一个采集任务，视频和文件分开采集，采集完成后合并到WARC文件中;两个采集任务，一个采集视频，一个采集网站网页，然后将两个合并到WARC文件中。
不同的采集方法有不同的优缺点，很难只用一种解决方案来处理所有网站的视频内容，具体应根据网站的性质选择合适的方法进行采集。使用外部下载器进行视频采集能够适应多种协议的视频网站，但是由于视频文件和文档文件分开采集，合并的时候有可能出现不一致的情况。因此，根据本文介绍的方法，应针对每种网站情况调整采集策略。选取何种采集方法进行视频存档取决于网站采集的难易程度。
参考文献：
闫晓创.全球网页存档项目发展状况研究：以国际互联网保存联盟（IIPC）成员为例[J].浙江档案，2016（8）：10-14.
王艺美.世界记忆视角下互联网信息存档的必要性分析[J].办公室业务，2018（9）：37.
宋锐星，朱小勇，胡琳琳，等.HTTP媒体传输方式简述[J].网络新媒体技术，2020，9（3）：61-67.
王旭鹏.基于Rtmp和Http双协议流媒体视频点播系统[J].电脑知识与技术，2011，7（1）：226-228.
雷霄骅，姜秀华，王彩虹.基于RTMP协议的流媒体技术的原理与应用[J].中国传媒大学学报（自然科学版），2013，20（6）：59-64.
徐枫，归伟夏.基于Heritrix视频资源抓取的研究与实现[J].集成技术，2014（3）：85-91.
张林.基于Heritrix的视频垂直搜索引擎[J].计算机系统应用，2016，25（9）：52-59.
李远英.基于流媒体相关的视频安全组播协议（MSMP）研究[J].计算机安全，2012（3）：25-30.
杨云鹏 中国国家图书馆数字资源部工程师、馆员。 北京，100083。
（收稿日期：2020-07-25 编校：陈安琪，谢艳秋）
关键词 互联网存档 网络视频 流媒体 视频采集
分类号 G250
DOI 10.16810/j.cnki.1672-514X.2021.03.04
Research on Video Collection in Internet Archiving： Taking National Library of China as an Example
Yang Yunpeng
Abstract With the rapid development of the Internet and the increase in network bandwidth year by year， video content on the Internet has gradually increased， and more content has changed from publishing plain text web pages to publishing text plus video. However， it is difficult for Internet archives to capture network videos， which usually use non-standard tools and protocols. This article provides an overview of acquisition techniques in this field. Based on years of experience in collecting network video content， this article provides examples of HTTP protocol and RTMP protocol video capture to illustrate the problems and solutions of collecting network video content. This article also proposes an external downloader for video capture module， which is used to expand network video content capture.
Keywords Internet archive. Web video. Streaming media. Video capture.
0 引言
視频已成为当今网络的重要组成部分。视频为了免于被盗版，一般都会采取加密传输的方法，免于用户直接访问视频源文件。这就使得Web档案管理员收集视频内容的任务变得更加困难，需要开发特定的方法和工具[1-2]。
本文的目的是讨论在网络上视频采集的难点。根据过去几年在国家图书馆网络采集中获得的经验，我们将视频采集中所遇到的问题分为两个主要类别，并使用一些典型的例子说明了几种技术解决方案。第一类使用标准HTTP协议传递视频内容的网站，其难点在于使用混淆视频文件链接的技术（例如：2或3跳跃重定向）。第二类问题是使用HTTP以外的传输协议的网站，从互联网上当前使用的各种流协议中，我们选择了最新且困难的RTMP流协议作为示例。值得注意的是，用于在网络上保存视频的技术发展得非常快，这里介绍的案例很可能在细节上迅速发生变化，我们的工具需要不断改进和更新。但是，其蕴含的原理，将帮助我们不断优化采集方法。
在本文的第二部分中，我们提出了一种体系结构设计以解决该问题，即将视频解耦下载下来，从而实现快速适应性和可伸缩性。这种设计原理更易于集成和更新，在可扩展性和灵活性方面都得到了很大的提升，进一步提高了效率。同时，与采集器同步工作为错误处理和流程管理提供了更好的支持。
1 视频采集方法
1.1 HTTP协议视频网站采集策略
每个视频均由散列标识符唯一标识，并且通常可以在HTML页面中使用URL进行访问，该URL类似于http：//www.*.com/uniqueID，采集网站视频时最困难的是访问视频的机制不断更新[3]，需要不断努力隐藏视频文件的直接URL。使用经典的采集方法，爬虫必须遵循5个不同的直接链接或重定向步骤，才能实际访问视频内容。表1总结了中间URL的一般模式。
知道了视频标识符（foobar）和网站页面的URL（序号1），采集程序首先发现页面中使用的Flash播放器的URL（序号2）。从传递给播放器的参数列表中，采集程序可以标识出请求视频内容时要使用的HTMI查询（序号3）。在真正获取视频文件的URL（序号5）之前，采集程序必须提供包含编码令牌的中间重定向（序号4），例如主机的IP地址和请求的时间戳。视频的URL（序号5）集成在Flash参数中，该Flash参数在加载页面（序号1）时动态生成。采集程序主要问题在于正确识别此URL，因为它包含不同的转义字符，并且与Flash对象解释的其他参数混合在一起。例如，在当前视频网站页面中，“flashvars”参数的字符串长度为6374个字符，而要匹配的URL包含392个字符。在对页面（序号1）进行分析时，还可以在生成Flash参数的JavaScript片段中标识视频的URL（序号5）。在网站页面中，要解析文本行包含的“PLAYER_CONFIG”字符串，其后是随机排列的URL列表。在两个（“|”）字符之间，可以根据IP地址和时间戳提取视频的URL，该URL已经包括计算出的令牌。 可以看到，获取视频文件的路径是曲折的，视频资源的URL因为被重定向和添加临时令牌而混淆。在采集参数方面，这可以将采集程序修改为5级深度抓取视频网站。此外，序号2，序号4和序号5中的URL指向不同的子域，因此需要将它们显式添加到采集的范围内。
重定向生成的URL还存在一个问题，就是存档重放工具访问的问题。即使每个视频文件在网站上都得到了唯一标识，但是每次下载时会由于时间戳而动态生成不同的URL。因此，需要在URL索引中添加显式引用，以保持原始页面（在序号1中）和视频文件的URL（在序号5中）之间的联系。
在实践中，有两种方法可以在HTTP协议的视频网站上进行视频存档：在线视频采集技术和离线下载视频技术。在线采集视频技术采集过程中，视频文件是在爬网时使用Heritrix软件的附加处理器进行下载。例如，由亚当·泰勒编写的beanShell脚本会将所有中间URL（序号2～5）注入边界，因为中间跃点通常不在当前爬网范围内。视频文件将直接添加到采集程序的WARC文件中。离线方法首先根据网站页面的URL下载视频文件，然后在后期进行加工处理。它使用由里卡多·加西亚·冈萨雷斯开发的外部下载器，该下载器采集视频内容并将其转储为flv文件，然后使用WARC Tools工具将flv文件打包到不同的WARC文件中。两种方法都需要视频的原始URL（如出现在网页中）和文件名或指向视频内容的URL新生成链接。
在线采集方法的优点在于，视频文件的下载是由采集程序自身完成的，并且不需要其他外部工具监视和同步。此外，在与网站服务器进行对话之后，所有HTTP标头都存储在存档中。这种方法的缺点是视频内容的最终URI（如序号5）不再包含视频的原始标识符（如序号1），回溯视频标识符变得难以管理，归档文件也被所有重定向URL污染（它们不再是有效的URL，因为下载令牌的有效性受到限制）。离线方法在监视和管理外部下载程序（例如错误处理）方面提供了更大的灵活性。视频文件保留其原始标识符的名称，并且重定向URL不存储在存档中。由于外部下载程序不保留服务器响应，因此需要在每个存储flv文件的WARC文件中插入一个“假”HTTP头。
1.2 RTMP协议视频网站采集策略
1.2.1 网络视频流协议概述
与互联网工程任务组（IETF）标准相对应的流技术允许服务器控制传输，并进行了严格的优化以保持实时运行。客户不必下载潜在的巨大文件，这种方法特别适合现场直播。实际上，流传输通常使用两种类型的实时流协议：实时传输协议（RTP）[rfc3550]发送媒体数据包，以及实时流协议（RTSP）[rfc2326]作为控制信息。RTP使用潜在的有损UDP，该UDP不会尝试重新传输丢失的数据包，因此系统被设计为可以承受传输期间数据包的丢失。这意味着客户端要能够很好地处理只获取到部分视频帧或音频样本数据的情况。这比基于TCP/IP的方法更好，后者可以进行不確定的重试次数（从而花费不确定的时间）来获取丢失的数据包。
实时流协议（RTSP）是一种网络控制协议，用于娱乐和通信系统，以控制流媒体服务器。该协议用于建立和控制两端之间的媒体会话。媒体服务器的客户端发出类似于VCR的命令，例如播放和暂停，以便于实时控制服务端的媒体文件的播放[4-5]。
RTSP协议与HTTP相似，但是RTSP添加了新的请求。HTTP是无状态的，而RTSP是有状态的协议。会话标识符用于在需要时跟踪会话，因此，不需要永久的TCP连接。RTSP消息从客户端发送到服务器，只有少数情况下会从服务器发送到客户端。
多媒体消息服务（MMS）是用于发送带有多媒体对象（图像，音频，视频，富文本）消息的电信标准。MMS是SMS标准的扩展，允许更长的消息长度，并使用WAP显示内容。MMS消息的发送方式几乎与SMS相同，但是首先要将所有多媒体内容进行编码，然后以类似于发送MIME电子邮件的方式将其插入文本消息中。
实时消息协议（RTMP）是Adobe Systems开发的一种专有协议，用于在Flash播放器和服务器之间通过互联网传输音频、视频和数据[6]。为了保证视频和音频流的平稳传递，同时保留传输更大信息块的能力，该协议可以将视频和数据拆分为片段。首先所用片段的大小可以在客户端和服务器之间动态协商，如果需要，甚至可以完全禁用它们。然后，来自不同流的片段可以在单个连接上交错和多路复用。Adobe于2009年6月15日开放了RTMP协议的规范，但该规范似乎省略了协议实现的许多细节。
1.2.2 采集RTMP网络视频
根据国家图书馆采集程序对视频采集的研究，本节将介绍基于RTMP协议进行视频网站采集的一些技术细节。
（1）视频页面布局。显示视频的Web页面的结构与HTTP协议网站的相同。HTML页面包含一个主视频面板，其中包括原始视频播放器。每个HTML页面的内容由服务器动态生成，并存储在特定的HTML元素中[7-8]。将Flash Player嵌入到<object>元素中，并从Web服务器加载。播放器所需的所有参数均由JavaScript函数（创建视频播放器）准备，并传递给Flash对象（使用flashvars参数）。从这一点开始，与流服务器的整个对话将直接由Flash Player处理。
（2）下载流媒体视频。从爬虫的角度来看，视频文件的URL清晰地写在了JavaScript片段内，这代表了一种有利的情况，因为JavaScript提取器能够识别和提取视频文件的URL。但是，此URL并不是采集程序的有效URL，因为它不支持HTTP/HTTPS以外的协议方案。因此，RTMP URL将在采集的错误日志中报告为无效URL。为了有效地下载视频文件（rtmp：//…/foobar-video.flv），将RTMP URL从错误日志中过滤掉，并传递给外部下载器（即FLVStreamer），RTMP下载器需要先将视频内容转储到flv文件中，然后再将其打包存储到WARC文件中。 （3）访问存档中的视频内容。从访问的角度来看，实时网页和已存档网页之间的根本区别在于用于将视频内容交付给播放器的传输协议。在存档的基础架构上部署流服务器需要大量的工作，这是一个开发和维护成本昂贵的解决方案。它还需要针对不同的协议运行不同的服务器。为了实现通用，我们通过HTTP协议对存档视频内容进行访问，并且flv文件与HTML页面及其他资源一起直接从WARC文件提取出来。流媒体的特定功能已丢失（例如快进或增量下载），但是可以确保对视频内容的基本访问，并且可以适应不同的情况而不需要额外的工作。
对于大型视频来说，用纯HTTP代替流媒体的一个重要缺点变得显而易见。如果未进行任何改编，播放器需要在开始播放视频之前加载整个flv文件。我们已调整了访问工具，通过增量地从存档中加载视频文件的块来缓解此问题。块的大小是优化的关键，但是在更快地访问视频和缓冲方法的复杂性之间需要权衡取舍。
在访问时，要进行的主要调整是更换原始Flash Player。由于已存档的视频文件不再流媒体传输，因此页面上的原始播放器无法在存档的版本上使用，HTML容器需要相应地更新。
与实时页面相比，在存档版本中，用包含存档特定播放器的特定<embed>元素替换<script>和<object>元素。注意，此时已存档视频文件的URL已转换为指向存档中flv文件的HTTP URL。
HTML元素的替换是通过在服务器上访问代码实现的特定方法即时完成的。WARC文件始终保留页面的原始版本。寻找正确的模式来正确识别和替换播放器仍然是一项挑战，因为<object>元素的结构和属性可能在不同网站之间有所不同。
在本节中，我们重点介绍采集RTMP流视频的示例，因为下载过程涉及特定的流协议。尽管如此，访问代码中实现的播放器替换技术也可以用于HTTP下载的视频。
2 使用外部下载器进行视频采集
作为LiWA项目中开发的Web归档新技术的一部分，针对不同的多媒体内容类型，设计了一个特定的模块来增强采集系统的采集功能。Heritrix的当前版本主要基于HTTP/HTTPS协议，不能广泛用于处理多媒体内容（例如流媒体）的其他传输协议。LiWA Rich Media Capture模块将多媒体内容检索委托给能够处理更大范围传输协议的外部应用程序（例如MPlayer或FLVStreamert）。该模块被构造为Heritrix的外部插件。使用这种方法，流的标识和检索完全分离，从而允许使用更有效的工具来分析视频和音频内容。同时，使用外部工具有助于减轻爬网过程的负担。
2.1 模块结构介绍
该模块由几个通过消息进行通信的子组件组成。我们使用一种高级消息队列协议（AMQP）的开放标准通信协议。Rich Media Capture模块与采集系统的集成如图1所示，消息的工作流程可以总结如下。连接到Heritrix的插件检测流媒体的URL，并为其中的每一个URL构造一个AMQP消息。此消息将传递到中央Messaging Server。Messaging Server的作用是将Heritrix与流媒体下载器（即外部下载工具）分离。Messaging Server将URL存储在队列中，并且其中一个流媒体下载器可用时，它将发送下一个URL进行处理。在模块的软件架构中，有三个不同的子模块：
（1）控制模块，负责访问Messaging Server，启动新作业，停止新作业并发送警报;
（2）用于流媒体的识别和下载（此处使用外部工具，例如MPlayer）;
（3）将下载的流重新打包为访问工具（WARC编写器）可以识别的格式。
当流媒体下载器空闲时，将连接到Messaging Server，以请求采集新的流媒体URL。在接收到新的URL后，将进行初始分析以检测一些参数，其中包括流媒体的类型和持续时间。当然，如果流是直播的，则可以配置固定的持续时间。成功识别后，便开始实际下载。控制模块生成一个作业，并将其与时间参数一起传递给下载器，以确保下载所花费的时间不会超过初始估计的时间。成功采集后，最后一步是将采集的流媒体视频编写到WARC文件中，然后将其移动到最终存储中。
2.2 优化采集模块
测试中出现的主要问题是采集系统和外部采集模块之间的同步。如果采集网站上有大量视频，那么依次下载每个视频肯定要比文本页面的采集过程花费更多的时间。因此，采集系统必须等待外部模块完成视频的下载。
通过增加下载器的数量，可以提高视频采集的速度。但是另一方面，增加下载器的方法将受到流媒体服务器上可用最大带宽的限制。另一种解决方案是将视频采集模块与采集程序完全分离，然后再进行后期处理。这意味着用日志读取器和视频下载程序的独立管理器替换了采集系统搜寻插件。这种方法的优点是直接显示视频URL总数，可以更好地管理下载资源（所有视频下载器共享带宽）。此方法的主要缺點是网站的采集时间和独立采集的视频之间可能出现不一致，可能导致一些视频内容不存在（视频采集延迟了1到2天），或部分视频下载被阻止。
因此，在管理视频下载时需要权衡取舍，缩短完整下载的时间，处理错误（慢速服务器提供的视频内容）和优化多个下载器使用的总带宽。
3 结论
本文通过介绍国家图书馆HTTP协议和RTMP协议视频存档的工作经验，分析了互联网视频存档的原理和步骤。首先是找到视频的真实URL，然后选择通过下载器进行下载，最后编写到WARC文件当中。视频的存档主要有三种方法：视频和文本同时采集编写到WARC文件;一个采集任务，视频和文件分开采集，采集完成后合并到WARC文件中;两个采集任务，一个采集视频，一个采集网站网页，然后将两个合并到WARC文件中。
不同的采集方法有不同的优缺点，很难只用一种解决方案来处理所有网站的视频内容，具体应根据网站的性质选择合适的方法进行采集。使用外部下载器进行视频采集能够适应多种协议的视频网站，但是由于视频文件和文档文件分开采集，合并的时候有可能出现不一致的情况。因此，根据本文介绍的方法，应针对每种网站情况调整采集策略。选取何种采集方法进行视频存档取决于网站采集的难易程度。
参考文献：
闫晓创.全球网页存档项目发展状况研究：以国际互联网保存联盟（IIPC）成员为例[J].浙江档案，2016（8）：10-14.
王艺美.世界记忆视角下互联网信息存档的必要性分析[J].办公室业务，2018（9）：37.
宋锐星，朱小勇，胡琳琳，等.HTTP媒体传输方式简述[J].网络新媒体技术，2020，9（3）：61-67.
王旭鹏.基于Rtmp和Http双协议流媒体视频点播系统[J].电脑知识与技术，2011，7（1）：226-228.
雷霄骅，姜秀华，王彩虹.基于RTMP协议的流媒体技术的原理与应用[J].中国传媒大学学报（自然科学版），2013，20（6）：59-64.
徐枫，归伟夏.基于Heritrix视频资源抓取的研究与实现[J].集成技术，2014（3）：85-91.
张林.基于Heritrix的视频垂直搜索引擎[J].计算机系统应用，2016，25（9）：52-59.
李远英.基于流媒体相关的视频安全组播协议（MSMP）研究[J].计算机安全，2012（3）：25-30.
杨云鹏 中国国家图书馆数字资源部工程师、馆员。 北京，100083。
（收稿日期：2020-07-25 编校：陈安琪，谢艳秋）