有了強大的 API (例如 IndexedDB 和 WebCodecs) 和效能工具,創作者現在可以使用 Kapwing 在網路上編輯高品質影片內容。
自疫情爆發以來,線上影片的觀看次數迅速增加。使用者花更多時間在 TikTok、Instagram 和 YouTube 等平台上觀看無窮無盡的高畫質影片。全球創作者和小型企業主都需要快速又好用的工具,製作影片內容。
像 Kapwing 這樣的公司只要使用最新的強大 API 和效能工具,就能直接在網路上製作所有影片內容。
關於 Kapwing
Kapwing 是一種以網頁為基礎的協作式影片編輯器,主要針對遊戲直播主、音樂人、YouTube 創作者和迷因創作者等休閒創作者設計。對於需要輕鬆製作社群媒體內容 (例如 Facebook 和 Instagram 廣告) 的商家來說,這也是首選資源。
觀眾會在搜尋特定工作時發現 Kapwing,例如「如何剪輯影片」、「為我的影片加入音樂」或「調整影片大小」。使用者只要按一下即可執行所搜尋的內容,不必再前往應用程式商店下載應用程式。網路可讓使用者輕鬆搜尋所需協助的任務,然後執行該項任務。
首次點選後,Kapwing 使用者就能執行更多操作。他們可以探索免費範本、新增免費的免權利金影片圖層、插入字幕、轉錄影片,以及上傳背景音樂。
Kapwing 如何在網路上提供即時編輯和協作功能
雖然網路提供獨特的優勢,但也存在獨特的挑戰。Kapwing 需要在各種裝置和網路狀況下,流暢且精準地播放複雜的多層次專案。為此,我們採用各種網路 API 來達成效能和功能目標。
IndexedDB
高效能編輯功能需要所有使用者內容都必須在用戶端上架,請盡量避免讓網路出現。與串流服務不同,使用者通常只會使用內容一次,但我們的客戶經常重複使用資產,甚至在上傳後數天或數月後重複使用。
IndexedDB 可讓我們為使用者提供類似永久檔案系統的儲存空間。因此,應用程式中超過 90% 的媒體要求會在本機執行。將 IndexedDB 整合至我們的系統非常簡單。
以下是應用程式載入時執行的常用初始化程式碼:
import {DBSchema, openDB, deleteDB, IDBPDatabase} from 'idb';
let openIdb: Promise <IDBPDatabase<Schema>>;
const db =
(await openDB) <
Schema >
(
'kapwing',
version, {
upgrade(db, oldVersion) {
if (oldVersion >= 1) {
// assets store schema changed, need to recreate
db.deleteObjectStore('assets');
}
db.createObjectStore('assets', {
keyPath: 'mediaLibraryID'
});
},
async blocked() {
await deleteDB('kapwing');
},
async blocking() {
await deleteDB('kapwing');
},
}
);
我們會傳遞版本並定義 upgrade
函式。這可用於初始化,或在必要時更新結構定義。我們會傳遞錯誤處理回呼 blocked
和 blocking
,這對系統不穩定的使用者來說相當實用,可避免發生問題。
最後,請注意我們對主鍵 keyPath
的定義。在這個範例中,這是我們呼叫 mediaLibraryID
的專屬 ID。當使用者透過我們的上傳工具或第三方擴充功能,將媒體內容新增至系統時,我們會使用以下程式碼將媒體內容新增至媒體庫:
export async function addAsset(mediaLibraryID: string, file: File) {
return runWithAssetMutex(mediaLibraryID, async () => {
const assetAlreadyInStore = await (await openIdb).get(
'assets',
mediaLibraryID
);
if (assetAlreadyInStore) return;
const idbVideo: IdbVideo = {
file,
mediaLibraryID,
};
await (await openIdb).add('assets', idbVideo);
});
}
runWithAssetMutex
是我們在內部定義的函式,用於將 IndexedDB 存取序列化。對任何讀取-修改-寫入類型作業而言,這是必要的,因為 IndexedDB API 並非非同步。
現在來看看我們如何存取檔案。以下是 getAsset
函式:
export async function getAsset(
mediaLibraryID: string,
source: LayerSource | null | undefined,
location: string
): Promise<IdbAsset | undefined> {
let asset: IdbAsset | undefined;
const { idbCache } = window;
const assetInCache = idbCache[mediaLibraryID];
if (assetInCache && assetInCache.status === 'complete') {
asset = assetInCache.asset;
} else if (assetInCache && assetInCache.status === 'pending') {
asset = await new Promise((res) => {
assetInCache.subscribers.push(res);
});
} else {
idbCache[mediaLibraryID] = { subscribers: [], status: 'pending' };
asset = (await openIdb).get('assets', mediaLibraryID);
idbCache[mediaLibraryID].asset = asset;
idbCache[mediaLibraryID].subscribers.forEach((res: any) => {
res(asset);
});
delete (idbCache[mediaLibraryID] as any).subscribers;
if (asset) {
idbCache[mediaLibraryID].status = 'complete';
} else {
idbCache[mediaLibraryID].status = 'failed';
}
}
return asset;
}
我們有自己的資料結構 idbCache
,用於盡量減少 IndexedDB 存取次數。雖然 IndexedDB 的速度很快,但存取本機記憶體會比較快。只要您管理快取的大小,我們就建議採用這種方法。
subscribers
陣列用於防止同時存取 IndexedDB,否則在載入時仍會常見。
Web Audio API
音訊示意圖對於影片編輯相當重要。如要瞭解原因,請參閱編輯器的螢幕截圖:
這是 YouTube 風格的影片,在我們的應用程式中很常見。使用者在整個短片中移動的幅度不大,因此時間軸的視覺縮圖在切換各個部分時不太實用。另一方面,音訊波形會顯示峰值和谷值,其中谷值通常對應錄音中的無聲時間。如果您將時間軸放大,就能看到更精細的音訊資訊,其中的谷地對應於斷斷續續和暫停的情況。
我們的使用者研究顯示,創作者在剪輯內容時,經常會參考這些波形圖。網路音訊 API 可讓我們以高效的方式呈現這項資訊,並在縮放或平移時間軸時快速更新。
以下程式碼片段示範我們如何執行這個程序:
const getDownsampledBuffer = (idbAsset: IdbAsset) =>
decodeMutex.runExclusive(
async (): Promise<Float32Array> => {
const arrayBuffer = await idbAsset.file.arrayBuffer();
const audioContext = new AudioContext();
const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);
const offline = new OfflineAudioContext(
audioBuffer.numberOfChannels,
audioBuffer.duration * MIN_BROWSER_SUPPORTED_SAMPLE_RATE,
MIN_BROWSER_SUPPORTED_SAMPLE_RATE
);
const downsampleSource = offline.createBufferSource();
downsampleSource.buffer = audioBuffer;
downsampleSource.start(0);
downsampleSource.connect(offline.destination);
const downsampledBuffer22K = await offline.startRendering();
const downsampledBuffer22KData = downsampledBuffer22K.getChannelData(0);
const downsampledBuffer = new Float32Array(
Math.floor(
downsampledBuffer22KData.length / POST_BROWSER_SAMPLE_INTERVAL
)
);
for (
let i = 0, j = 0;
i < downsampledBuffer22KData.length;
i += POST_BROWSER_SAMPLE_INTERVAL, j += 1
) {
let sum = 0;
for (let k = 0; k < POST_BROWSER_SAMPLE_INTERVAL; k += 1) {
sum += Math.abs(downsampledBuffer22KData[i + k]);
}
const avg = sum / POST_BROWSER_SAMPLE_INTERVAL;
downsampledBuffer[j] = avg;
}
return downsampledBuffer;
}
);
我們會將儲存在 IndexedDB 中的素材資源傳遞給這個輔助程式。完成後,我們會更新 IndexedDB 和自己的快取中的資產。
我們會使用 AudioContext
建構函式收集 audioBuffer
相關資料,但由於我們並未將內容算繪至裝置硬體,因此我們會使用 OfflineAudioContext
將內容算繪至 ArrayBuffer
,並在該處儲存幅度資料。
API 本身會以比有效視覺化所需更高的取樣率傳回資料。因此,我們會手動將取樣率降至 200 Hz,這已足以產生有用且視覺效果良好的波形。
WebCodecs
對於某些影片,軌道縮圖比波形圖更適合用於時間軸導覽。不過,產生縮圖比產生波形圖需要更多資源。
我們無法在載入時快取所有可能的縮圖,因此在時間軸上快速解碼平移/縮放功能,對於效能良好且反應靈敏的應用程式至關重要。要順暢繪製影格,關鍵在於解碼影格,而我們最近才使用 HTML5 影片播放器完成這項工作。這種做法的成效不穩定,我們經常發現在影格算繪期間,應用程式反應速度會變慢。
我們最近已改用 WebCodecs,可用於網路 worker。這應該可提升我們為大量圖層繪製縮圖的能力,且不會影響主執行緒效能。雖然網頁工作站實作項目仍在進行中,但我們會在下文中概略說明現有的主執行緒實作項目。
一個影片檔案包含多個串流,例如影片、音訊、字幕等,而會「混合」。如要使用 WebCodecs,我們必須先取得解多工的影片串流。我們使用 mp4box 程式庫來支援 mp4s,如下所示:
async function create(demuxer: any) {
demuxer.file = (await MP4Box).createFile();
demuxer.file.onReady = (info: any) => {
demuxer.info = info;
demuxer._info_resolver(info);
};
demuxer.loadMetadata();
}
const loadMetadata = async () => {
let offset = 0;
const asset = await getAsset(this.mediaLibraryId, null, this.url);
const maxFetchOffset = asset?.file.size || 0;
const end = offset + FETCH_SIZE;
const response = await fetch(this.url, {
headers: { range: `bytes=${offset}-${end}` },
});
const reader = response.body.getReader();
let done, value;
while (!done) {
({ done, value } = await reader.read());
if (done) {
this.file.flush();
break;
}
const buf: ArrayBufferLike & { fileStart?: number } = value.buffer;
buf.fileStart = offset;
offset = this.file.appendBuffer(buf);
}
};
此程式碼片段參照 demuxer
類別,用來將介面封裝至 MP4Box
。我們會再次從 IndexedDB 存取該素材資源。這些區段不一定以位元組順序儲存,且 appendBuffer
方法會傳回下一個區塊的偏移量。
以下是解碼影片影格的方式:
const getFrameFromVideoDecoder = async (demuxer: any): Promise<any> => {
let desiredSampleIndex = demuxer.getFrameIndexForTimestamp(this.frameTime);
let timestampToMatch: number;
let decodedSample: VideoFrame | null = null;
const outputCallback = (frame: VideoFrame) => {
if (frame.timestamp === timestampToMatch) decodedSample = frame;
else frame.close();
};
const decoder = new VideoDecoder({
output: outputCallback,
});
const {
codec,
codecWidth,
codecHeight,
description,
} = demuxer.getDecoderConfigurationInfo();
decoder.configure({ codec, codecWidth, codecHeight, description });
/* begin demuxer interface */
const preceedingKeyFrameIndex = demuxer.getPreceedingKeyFrameIndex(
desiredSampleIndex
);
const trak_id = demuxer.trak_id
const trak = demuxer.moov.traks.find((trak: any) => trak.tkhd.track_id === trak_id);
const data = await demuxer.getFrameDataRange(
preceedingKeyFrameIndex,
desiredSampleIndex
);
/* end demuxer interface */
for (let i = preceedingKeyFrameIndex; i <= desiredSampleIndex; i += 1) {
const sample = trak.samples[i];
const sampleData = data.readNBytes(
sample.offset,
sample.size
);
const sampleType = sample.is_sync ? 'key' : 'delta';
const encodedFrame = new EncodedVideoChunk({
sampleType,
timestamp: sample.cts,
duration: sample.duration,
samapleData,
});
if (i === desiredSampleIndex)
timestampToMatch = encodedFrame.timestamp;
decoder.decodeEncodedFrame(encodedFrame, i);
}
await decoder.flush();
return { type: 'value', value: decodedSample };
};
解多工器的結構相當複雜,不在本文討論範圍內。它會將每個影格儲存在名為 samples
的陣列中。我們會使用解多工器,找出最接近所需時間戳記的前一個關鍵影格,這是我們必須開始解碼影片的位置。
影片是由完整影格 (又稱為主要影格或 i 影格) 和較小的差異影格組成,通常稱為 p 或 b 影格。解碼作業一律必須從關鍵影格開始。
應用程式會透過以下方式解碼影格:
- 使用影格輸出回呼來例項化解碼器。
- 針對特定編解碼器和輸入解析度設定解碼器。
- 使用解多工器的資料建立
encodedVideoChunk
。 - 呼叫
decodeEncodedFrame
方法。
直到找到所需時間戳記的影格為止。
後續步驟
我們在前端定義的規模,是指在專案規模變大且複雜度提高時,維持精確且高效的播放功能。擴大效能的方式之一,就是一次掛載盡可能少的影片,但這樣做可能會導致轉場速度變慢且不流暢。雖然我們已開發內部系統,可快取影片元件以供重複使用,但 HTML5 影片代碼可提供的控制程度仍有限制。
日後,我們可能會嘗試使用 WebCodecs 播放所有媒體。這可讓我們精確地緩衝哪些資料,進而提升效能。
我們也可以更有效地將大型觸控板運算作業卸載至網路工作者,並更聰明地預先擷取檔案和預先產生影格。我們發現許多機會,可用於改善整體應用程式效能,並透過 WebGL 等工具擴充功能。
因此,我們決定繼續投資 TensorFlow.js,這個 TensorFlow.js 目前用於智慧型背景移除作業。我們打算將 TensorFlow.js 用於其他複雜工作,例如物件偵測、特徵擷取、風格轉移等。
最終,我們很高興能在免費開放的網路上,繼續打造具備原生效能和功能的產品。