不可靠的緩存和預讀視頻幀

Question

我正在研究一次顯示多個視頻的應用程序。這些視頻以充滿圖像文件的目錄形式存儲。對於每個幀號，最多有9個必須從磁盤加載的圖像。我想實現圖像的緩存和預讀。這很簡單，但複雜的是文件系統（有時是網絡FS）遠不足以顯示每個圖像。所以readahead應該選擇它將要加載的幀，並且只對這些圖像發出read（）請求。此外，如果可以考慮哪些圖像已被緩存，在決定要裝入哪些幀時最好。

我想出了一個貪婪的算法，它會好起來的，但我想知道這是否是一個已經研究過的問題，並且有更好的/最佳的算法。

我假設時間是根據幀速率測量的，而不是秒數，以便更容易僞代碼。

load_time_per_image = how long it takes to load an image 
images_per_frame = the number of images to display simultaneously 
worst_time = images_per_frame * load_time_per_image 

def decide_next_frame_to_load: 
    for each frame from now to now + worst_time: 
     loadable = (frame - now)/load_time_per_image 
     if number_of_images_cached(frame) > images_per_frame - loadable: 
      # this frame is the first one it's possible to load in time. 
      return frame 

有人有建議嗎？ 感謝您的幫助！ -Thomas

Answer 1

這是用於實時操作嗎？

我見過的一些性能最差的視頻編輯器會通過將每個幀存儲到自己的圖像文件中來「索引」每一幀。你是否堅持使用這種存儲機制？如果源視頻已經以視頻格式存儲（每個文件一個），並且每個視頻都有一個索引（基本上是每個幀的文件偏移量），那麼效率會更高。然後，您可以使用操作系統的緩存機制來幫助提高性能。

你可能想要考慮的另一件事，儘管它可能不會對網絡文件系統有很大幫助，但它是以YUV格式存儲圖像的。顯示視頻的應用程序運行速度可能會更快（部分原因是因爲不需要RGB到YUV的轉換，並且經常因爲您可以卸載將YUV圖像繪製到視頻卡上的工作），因此會爲文件系統留出更多時間工作。爲了避免抖動，我在繪製X顯示器時這樣做。

至於緩存圖像，我可能會使用一個單獨的線程以儘可能快的速度從磁盤讀取圖像，而主線程則會組裝並呈現圖像。主線程可以每幀呈現間隔執行一次循環，並且當緩衝/準備圖像的數量達到某個閾值時，單獨的線程可以阻塞。像mplayer這樣的視頻播放器使用這種策略。