背景

分秒幀是一個(gè)音視頻生產(chǎn)協(xié)作平臺(tái)，其中用戶可以通過(guò)在視頻的某個(gè)時(shí)間點(diǎn)提出意見(jiàn)或分享來(lái)溝通對(duì)視頻的修改意見(jiàn)。由于客戶有時(shí)需要對(duì)時(shí)間精確到幀進(jìn)行定位，我們需要保證不同轉(zhuǎn)碼視頻在播放時(shí)，時(shí)間定位能夠精確到毫秒級(jí)別。在滿足這一要求的同時(shí)，我們還必須考慮不同網(wǎng)絡(luò)條件、不同端和不同使用場(chǎng)景。我們?cè)诮鉀Q這些問(wèn)題的過(guò)程中發(fā)現(xiàn)了一些問(wèn)題，本文將對(duì)這些問(wèn)題進(jìn)行討論。

為什么需要畫面幀的準(zhǔn)確性？

當(dāng)用戶發(fā)送批注需要審閱者根據(jù)批注意見(jiàn)做出修改時(shí)，如果沒(méi)有畫面校準(zhǔn)，此時(shí)審閱者一臉黑人問(wèn)號(hào), 哪來(lái)的“T” ? 然后再私下溝通嗎？信息存在誤差， 審閱批注就毫無(wú)意義。

問(wèn)題一：保證瀏覽器中 Video 標(biāo)簽時(shí)間定位在 pause 時(shí)的準(zhǔn)確性

當(dāng)用戶在播放視頻時(shí)暫停，并對(duì)視頻進(jìn)行批注，然后繼續(xù)播放時(shí)，有時(shí)會(huì)發(fā)現(xiàn)定位回原始批注時(shí)間點(diǎn)時(shí)畫面會(huì)有一幀的偏差。這是因?yàn)椋覀冊(cè)跁和r(shí)記錄了視頻的當(dāng)前時(shí)間（即 currentTime）并通過(guò) seek() 方法回到該時(shí)間點(diǎn)，但是這個(gè)方法并不能保證回到的畫面完全準(zhǔn)確。

現(xiàn)象

暫停批注時(shí) 沒(méi)有矯正currentTime，當(dāng)批注發(fā)送成功后，自動(dòng)跳回批注點(diǎn)，畫面發(fā)生了變化，以下是用戶所不想看到的畫面：

JS代碼如下：

JavaScript
var videoDom =  document.getElementsByTagName('video')[0]
videoDom.pause()
var currenttime = videoDom.currentTime
videoDom.currentTime = currentTime // 此時(shí)畫面有概率發(fā)生改變

問(wèn)題產(chǎn)生原因

我們?cè)诮鉀Q這個(gè)問(wèn)題時(shí)發(fā)現(xiàn)，這個(gè)問(wèn)題是由 JavaScript 執(zhí)行機(jī)制導(dǎo)致的。在瀏覽器中，JavaScript 是單線程執(zhí)行的。當(dāng)我們調(diào)用 pause 方法時(shí)，實(shí)際上是將該操作添加到了事件隊(duì)列中。當(dāng)事件輪詢到這個(gè)暫停操作時(shí)，才會(huì)真正執(zhí)行 pause 方法。而在這個(gè)過(guò)程中，獲取 currentTime 的操作已經(jīng)完成了。這就導(dǎo)致了兩個(gè)操作之間的時(shí)間差。如果這個(gè)時(shí)間差恰好發(fā)生在視頻幀切換的時(shí)候，就會(huì)導(dǎo)致畫面偏差一幀。

舉個(gè)例子，如果一個(gè)視頻有 25 幀，那么第 0-40ms 是第一幀畫面，第 41-80ms是第二幀畫面，以此類推。

當(dāng)用戶在播放第一幀畫面時(shí)按下暫停按鈕，我們認(rèn)為JavaScript 會(huì)立即執(zhí)行邏輯并通知 Video 標(biāo)簽停止播放，但實(shí)際上暫停操作會(huì)被加入事件隊(duì)列中等待執(zhí)行。如果暫停操作前面還有其他事件正在排隊(duì)，等執(zhí)行到暫停操作時(shí)就會(huì)有一定的時(shí)間差。如果這個(gè)時(shí)間差恰好發(fā)生在第 41 ms，畫面會(huì)跳到下一幀畫面。但是，我們拿到的currentTime還是第一幀畫面的。

解決方案

為了確保在暫停時(shí)和查看批注時(shí) currentTime 的一致性，我們?cè)跁和r(shí)對(duì) currentTime 進(jìn)行了矯正。這樣，當(dāng)用戶暫停時(shí)進(jìn)行批注，然后再設(shè)置 currentTime查看批注時(shí)，就不會(huì)出現(xiàn)畫面偏差問(wèn)題。通過(guò)這種方式，我們就能保證畫面在暫停時(shí)和查看批注時(shí)的準(zhǔn)確性。

問(wèn)題二：HLS流中視頻 duration 值變化異常

在我們的應(yīng)用中，我們需要確保各端的視頻總時(shí)長(zhǎng)和總幀數(shù)一致。為了實(shí)現(xiàn)這個(gè)目的，我們通常會(huì)在瀏覽器 Video 標(biāo)簽的 durationchange 事件觸發(fā)時(shí)獲取視頻總時(shí)長(zhǎng)，并通過(guò)幀率計(jì)算出總幀數(shù)。durationchange 事件是當(dāng)視頻總時(shí)長(zhǎng)發(fā)生改變時(shí)觸發(fā)的。當(dāng)視頻加載前，總時(shí)長(zhǎng)為默認(rèn)值"NaN"，當(dāng)視頻加載完成后，durationchange 事件觸發(fā)，總時(shí)長(zhǎng)會(huì)變成視頻的實(shí)際總時(shí)長(zhǎng)。

在加載和播放視頻時(shí)，瀏覽器會(huì)用Video標(biāo)簽來(lái)追蹤視頻的狀態(tài)。共有五個(gè)狀態(tài)，分別是：[1]。

在視頻加載和播放過(guò)程中，瀏覽器Video標(biāo)簽的 readyState 會(huì)發(fā)生變化。在這個(gè)過(guò)程中，MP4文件和HLS文件的 duration 變更時(shí)機(jī)是不同的。

MP4

在 MP4 文件的加載過(guò)程中，durationchange 事件會(huì)在資源開(kāi)始加載（loadstart）之后，在元數(shù)據(jù)已加載（loadedmetadata）之前觸發(fā)。此時(shí)，瀏覽器會(huì)解析 MP4 文件中的 moov box，并獲取視頻時(shí)長(zhǎng)。因此，在 durationchange 事件觸發(fā)時(shí)，可以獲取到較為準(zhǔn)確的 duration 。

HLS

我們發(fā)現(xiàn)在加載 HLS 流時(shí)，瀏覽器 video 標(biāo)簽的 duration 會(huì)發(fā)生多次變更。

第一次變更在loadstart之后 loadedmetadata 之前 并且 readyState === 0 時(shí)調(diào)用，此時(shí)已拿到相對(duì)準(zhǔn)確的 duration，≈ ffmpeg取到的 durantion。

舉個(gè)例子，ffmpeg截圖如下：

第二次變更在loadstart之后 loadedmetadata 之前 并且 readyState === 1 時(shí)調(diào)用，此時(shí)拿到的時(shí)長(zhǎng)由 m3u8 文件解析得到。

第三次變更在加載到最后一片 ts 時(shí)調(diào)用。我們發(fā)現(xiàn)這三次變更的時(shí)長(zhǎng)并不一致。因此我們需要在這三次變更中取一個(gè)更準(zhǔn)確的時(shí)長(zhǎng)作為視頻時(shí)長(zhǎng)。

舉個(gè)例子，三次時(shí)長(zhǎng)比較：

HLS三次取值時(shí)長(zhǎng)不一致的原因

第一次：在loadstart后loadedmetadata前readyState === 0時(shí)調(diào)用，視頻的實(shí)際時(shí)長(zhǎng)已被解析出來(lái)，時(shí)機(jī)和機(jī)制類似于MP4文件（第一次調(diào)用時(shí)就可以獲取到duration的值）。

第二次：在loadstart后loadedmetadata前readyState === 1時(shí)調(diào)用，hls.js解析完m3u8索引文件并通過(guò)#EXTINF計(jì)算出視頻的實(shí)際時(shí)長(zhǎng)。

舉個(gè)例子，以下是一個(gè)m3u8文件信息：

第三次：當(dāng)加載完最后一片ts 此時(shí)所有音頻和視頻幀信息已經(jīng)可以全部拿到。

舉個(gè)例子，以下是幀信息：

best_effort_timestamp_time ：媒體流中的一個(gè)標(biāo)識(shí)符，用于標(biāo)識(shí)每一幀的時(shí)間戳。

pkt_duration_time ：媒體流中的一個(gè)標(biāo)識(shí)符，用于標(biāo)識(shí)每一幀的持續(xù)時(shí)間。

通常，best_effort_timestamp_time 和 pkt_duration_time 會(huì)用在音視頻同步、流量控制、緩存等方面。

尾音頻/視頻信息中的 best_effort_timestamp_time 和 pkt_duration_time 可用來(lái)計(jì)算音頻/視頻的結(jié)束時(shí)長(zhǎng)。在這個(gè)案例中，音頻結(jié)束時(shí)長(zhǎng)由 best_effort_timestamp_time 和 pkt_duration_time 相加所得（即 96.230300 + 0.023211 = 96.253511），視頻結(jié)束時(shí)長(zhǎng)也是如此（即 96.229778 + 0.016667 = 96.246445）。

我們發(fā)現(xiàn)，音頻結(jié)束時(shí)長(zhǎng) - 音頻首個(gè)best_effort_timestamp_time約等于第三次獲取的duration。具體來(lái)說(shuō)，音頻的結(jié)束時(shí)間比視頻的結(jié)束時(shí)間長(zhǎng)，同時(shí)音頻的第一個(gè)時(shí)間戳早于視頻的第一個(gè)時(shí)間戳。為了包含最完整的時(shí)間長(zhǎng)度，需要將音頻和視頻時(shí)間戳中的最小值和最大值來(lái)進(jìn)行計(jì)算。這種情況可能出現(xiàn)在音頻和視頻的錄制或處理過(guò)程中，需要進(jìn)行相應(yīng)的調(diào)整以確保兩者之間的同步和一致性。

審核編輯：劉清