摘 要 隨著互聯(lián)網(wǎng)的快速發(fā)展和網(wǎng)絡(luò)帶寬的逐年增加，網(wǎng)絡(luò)上視頻內(nèi)容逐漸增多，更多的內(nèi)容從純文本網(wǎng)頁發(fā)布變?yōu)槲谋炯右曨l發(fā)布。但是，互聯(lián)網(wǎng)存檔很難采集到網(wǎng)絡(luò)視頻，這些視頻通常使用非標(biāo)準(zhǔn)工具和協(xié)議。本文提供了該領(lǐng)域采集技術(shù)的概述。基于幾年采集網(wǎng)絡(luò)視頻內(nèi)容的經(jīng)驗(yàn)，本文提供了HTTP協(xié)議和RTMP協(xié)議視頻采集的示例，闡述了采集網(wǎng)絡(luò)視頻內(nèi)容的問題和解決方案。本文還提出了一種外部下載器作為視頻采集模塊，用于擴(kuò)展網(wǎng)絡(luò)視頻內(nèi)容采集。

關(guān)鍵詞 互聯(lián)網(wǎng)存檔 網(wǎng)絡(luò)視頻 流媒體 視頻采集

分類號 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 引言

視頻已成為當(dāng)今網(wǎng)絡(luò)的重要組成部分。視頻為了免于被盜版，一般都會采取加密傳輸?shù)姆椒?，免于用戶直接訪問視頻源文件。這就使得Web檔案管理員收集視頻內(nèi)容的任務(wù)變得更加困難，需要開發(fā)特定的方法和工具[1-2]。

本文的目的是討論在網(wǎng)絡(luò)上視頻采集的難點(diǎn)。根據(jù)過去幾年在國家圖書館網(wǎng)絡(luò)采集中獲得的經(jīng)驗(yàn)，我們將視頻采集中所遇到的問題分為兩個主要類別，并使用一些典型的例子說明了幾種技術(shù)解決方案。第一類使用標(biāo)準(zhǔn)HTTP協(xié)議傳遞視頻內(nèi)容的網(wǎng)站，其難點(diǎn)在于使用混淆視頻文件鏈接的技術(shù)（例如：2或3跳躍重定向）。第二類問題是使用HTTP以外的傳輸協(xié)議的網(wǎng)站，從互聯(lián)網(wǎng)上當(dāng)前使用的各種流協(xié)議中，我們選擇了最新且困難的RTMP流協(xié)議作為示例。值得注意的是，用于在網(wǎng)絡(luò)上保存視頻的技術(shù)發(fā)展得非常快，這里介紹的案例很可能在細(xì)節(jié)上迅速發(fā)生變化，我們的工具需要不斷改進(jìn)和更新。但是，其蘊(yùn)含的原理，將幫助我們不斷優(yōu)化采集方法。

在本文的第二部分中，我們提出了一種體系結(jié)構(gòu)設(shè)計以解決該問題，即將視頻解耦下載下來，從而實(shí)現(xiàn)快速適應(yīng)性和可伸縮性。這種設(shè)計原理更易于集成和更新，在可擴(kuò)展性和靈活性方面都得到了很大的提升，進(jìn)一步提高了效率。同時，與采集器同步工作為錯誤處理和流程管理提供了更好的支持。

1 視頻采集方法

1.1 HTTP協(xié)議視頻網(wǎng)站采集策略

每個視頻均由散列標(biāo)識符唯一標(biāo)識，并且通常可以在HTML頁面中使用URL進(jìn)行訪問，該URL類似于http：//www.*.com/uniqueID，采集網(wǎng)站視頻時最困難的是訪問視頻的機(jī)制不斷更新[3]，需要不斷努力隱藏視頻文件的直接URL。使用經(jīng)典的采集方法，爬蟲必須遵循5個不同的直接鏈接或重定向步驟，才能實(shí)際訪問視頻內(nèi)容。表1總結(jié)了中間URL的一般模式。

知道了視頻標(biāo)識符（foobar）和網(wǎng)站頁面的URL（序號1），采集程序首先發(fā)現(xiàn)頁面中使用的Flash播放器的URL（序號2）。從傳遞給播放器的參數(shù)列表中，采集程序可以標(biāo)識出請求視頻內(nèi)容時要使用的HTMI查詢（序號3）。在真正獲取視頻文件的URL（序號5）之前，采集程序必須提供包含編碼令牌的中間重定向（序號4），例如主機(jī)的IP地址和請求的時間戳。視頻的URL（序號5）集成在Flash參數(shù)中，該Flash參數(shù)在加載頁面（序號1）時動態(tài)生成。采集程序主要問題在于正確識別此URL，因?yàn)樗煌霓D(zhuǎn)義字符，并且與Flash對象解釋的其他參數(shù)混合在一起。例如，在當(dāng)前視頻網(wǎng)站頁面中，“flashvars”參數(shù)的字符串長度為6374個字符，而要匹配的URL包含392個字符。在對頁面（序號1）進(jìn)行分析時，還可以在生成Flash參數(shù)的JavaScript片段中標(biāo)識視頻的URL（序號5）。在網(wǎng)站頁面中，要解析文本行包含的“PLAYER_CONFIG”字符串，其后是隨機(jī)排列的URL列表。在兩個（“|”）字符之間，可以根據(jù)IP地址和時間戳提取視頻的URL，該URL已經(jīng)包括計算出的令牌。

可以看到，獲取視頻文件的路徑是曲折的，視頻資源的URL因?yàn)楸恢囟ㄏ蚝吞砑优R時令牌而混淆。在采集參數(shù)方面，這可以將采集程序修改為5級深度抓取視頻網(wǎng)站。此外，序號2，序號4和序號5中的URL指向不同的子域，因此需要將它們顯式添加到采集的范圍內(nèi)。

重定向生成的URL還存在一個問題，就是存檔重放工具訪問的問題。即使每個視頻文件在網(wǎng)站上都得到了唯一標(biāo)識，但是每次下載時會由于時間戳而動態(tài)生成不同的URL。因此，需要在URL索引中添加顯式引用，以保持原始頁面（在序號1中）和視頻文件的URL（在序號5中）之間的聯(lián)系。

在實(shí)踐中，有兩種方法可以在HTTP協(xié)議的視頻網(wǎng)站上進(jìn)行視頻存檔：在線視頻采集技術(shù)和離線下載視頻技術(shù)。在線采集視頻技術(shù)采集過程中，視頻文件是在爬網(wǎng)時使用Heritrix軟件的附加處理器進(jìn)行下載。例如，由亞當(dāng)·泰勒編寫的beanShell腳本會將所有中間URL（序號2～5）注入邊界，因?yàn)橹虚g躍點(diǎn)通常不在當(dāng)前爬網(wǎng)范圍內(nèi)。視頻文件將直接添加到采集程序的WARC文件中。離線方法首先根據(jù)網(wǎng)站頁面的URL下載視頻文件，然后在后期進(jìn)行加工處理。它使用由里卡多·加西亞·岡薩雷斯開發(fā)的外部下載器，該下載器采集視頻內(nèi)容并將其轉(zhuǎn)儲為flv文件，然后使用WARC Tools工具將flv文件打包到不同的WARC文件中。兩種方法都需要視頻的原始URL（如出現(xiàn)在網(wǎng)頁中）和文件名或指向視頻內(nèi)容的URL新生成鏈接。

在線采集方法的優(yōu)點(diǎn)在于，視頻文件的下載是由采集程序自身完成的，并且不需要其他外部工具監(jiān)視和同步。此外，在與網(wǎng)站服務(wù)器進(jìn)行對話之后，所有HTTP標(biāo)頭都存儲在存檔中。這種方法的缺點(diǎn)是視頻內(nèi)容的最終URI（如序號5）不再包含視頻的原始標(biāo)識符（如序號1），回溯視頻標(biāo)識符變得難以管理，歸檔文件也被所有重定向URL污染（它們不再是有效的URL，因?yàn)橄螺d令牌的有效性受到限制）。離線方法在監(jiān)視和管理外部下載程序（例如錯誤處理）方面提供了更大的靈活性。視頻文件保留其原始標(biāo)識符的名稱，并且重定向URL不存儲在存檔中。由于外部下載程序不保留服務(wù)器響應(yīng)，因此需要在每個存儲flv文件的WARC文件中插入一個“假”HTTP頭。

1.2RTMP協(xié)議視頻網(wǎng)站采集策略

1.2.1 網(wǎng)絡(luò)視頻流協(xié)議概述

與互聯(lián)網(wǎng)工程任務(wù)組（IETF）標(biāo)準(zhǔn)相對應(yīng)的流技術(shù)允許服務(wù)器控制傳輸，并進(jìn)行了嚴(yán)格的優(yōu)化以保持實(shí)時運(yùn)行?？蛻舨槐叵螺d潛在的巨大文件，這種方法特別適合現(xiàn)場直播。實(shí)際上，流傳輸通常使用兩種類型的實(shí)時流協(xié)議：實(shí)時傳輸協(xié)議（RTP）[rfc3550]發(fā)送媒體數(shù)據(jù)包，以及實(shí)時流協(xié)議（RTSP）[rfc2326]作為控制信息。RTP使用潛在的有損UDP，該UDP不會嘗試重新傳輸丟失的數(shù)據(jù)包，因此系統(tǒng)被設(shè)計為可以承受傳輸期間數(shù)據(jù)包的丟失。這意味著客戶端要能夠很好地處理只獲取到部分視頻幀或音頻樣本數(shù)據(jù)的情況。這比基于TCP/IP的方法更好，后者可以進(jìn)行不確定的重試次數(shù)（從而花費(fèi)不確定的時間）來獲取丟失的數(shù)據(jù)包。

實(shí)時流協(xié)議（RTSP）是一種網(wǎng)絡(luò)控制協(xié)議，用于娛樂和通信系統(tǒng)，以控制流媒體服務(wù)器。該協(xié)議用于建立和控制兩端之間的媒體會話。媒體服務(wù)器的客戶端發(fā)出類似于VCR的命令，例如播放和暫停，以便于實(shí)時控制服務(wù)端的媒體文件的播放[4-5]。

RTSP協(xié)議與HTTP相似，但是RTSP添加了新的請求。HTTP是無狀態(tài)的，而RTSP是有狀態(tài)的協(xié)議。會話標(biāo)識符用于在需要時跟蹤會話，因此，不需要永久的TCP連接。RTSP消息從客戶端發(fā)送到服務(wù)器，只有少數(shù)情況下會從服務(wù)器發(fā)送到客戶端。

多媒體消息服務(wù)（MMS）是用于發(fā)送帶有多媒體對象（圖像，音頻，視頻，富文本）消息的電信標(biāo)準(zhǔn)。MMS是SMS標(biāo)準(zhǔn)的擴(kuò)展，允許更長的消息長度，并使用WAP顯示內(nèi)容。MMS消息的發(fā)送方式幾乎與SMS相同，但是首先要將所有多媒體內(nèi)容進(jìn)行編碼，然后以類似于發(fā)送MIME電子郵件的方式將其插入文本消息中。

實(shí)時消息協(xié)議（RTMP）是Adobe Systems開發(fā)的一種專有協(xié)議，用于在Flash播放器和服務(wù)器之間通過互聯(lián)網(wǎng)傳輸音頻、視頻和數(shù)據(jù)[6]。為了保證視頻和音頻流的平穩(wěn)傳遞，同時保留傳輸更大信息塊的能力，該協(xié)議可以將視頻和數(shù)據(jù)拆分為片段。首先所用片段的大小可以在客戶端和服務(wù)器之間動態(tài)協(xié)商，如果需要，甚至可以完全禁用它們。然后，來自不同流的片段可以在單個連接上交錯和多路復(fù)用。Adobe于2009年6月15日開放了RTMP協(xié)議的規(guī)范，但該規(guī)范似乎省略了協(xié)議實(shí)現(xiàn)的許多細(xì)節(jié)。

1.2.2 采集RTMP網(wǎng)絡(luò)視頻

根據(jù)國家圖書館采集程序?qū)σ曨l采集的研究，本節(jié)將介紹基于RTMP協(xié)議進(jìn)行視頻網(wǎng)站采集的一些技術(shù)細(xì)節(jié)。

（1）視頻頁面布局。顯示視頻的Web頁面的結(jié)構(gòu)與HTTP協(xié)議網(wǎng)站的相同。HTML頁面包含一個主視頻面板，其中包括原始視頻播放器。每個HTML頁面的內(nèi)容由服務(wù)器動態(tài)生成，并存儲在特定的HTML元素中[7-8]。將Flash Player嵌入到