2009-04-08 4 views
2

Ich arbeite an einer Anwendung, die mehrere Videos gleichzeitig anzeigt. Die Videos werden in Form von Verzeichnissen voller Bilddateien gespeichert. Für jede Bildnummer gibt es bis zu 9 Bilder, die von der Festplatte geladen werden müssen. Ich möchte Caching und Read-Ahead für die Bilder implementieren. Das wäre ziemlich einfach, aber die Komplikation ist, dass das Dateisystem (manchmal ein Netzwerk-FS) nicht annähernd schnell genug ist, um jedes Bild anzuzeigen. Der Readahead sollte also auswählen, welche Frames er laden möchte und nur read() Anfragen für diese Bilder ausgeben. Es wäre auch am besten, wenn berücksichtigt werden könnte, welche Bilder bereits zwischengespeichert sind, wenn entschieden wird, welche Bilder geladen werden sollen.Unzuverlässiges Caching und Readahead von Videobildern

Ich kam mit einem Greedy-Algorithmus, der gut geht, aber ich frage mich, ob dies ein Problem ist, das untersucht wurde, und es gibt bessere/optimale Algorithmen da draußen.

Ich gehe davon aus, dass die Zeit in Bezug auf Bildrate, nicht Sekunden, gemessen wird, um das Pseudocode einfacher zu machen.

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 

Wer hat Vorschläge? Danke für Ihre Hilfe! -Thomas

+0

Es ist schließlich eine kleine Welt ... –

Antwort

0

Ist dies für den Echtzeitbetrieb gedacht?

Einige der schlechtesten Videoeditoren, die ich gesehen habe, "indexieren" jeden Frame, indem sie jeden Frame in seiner eigenen Bilddatei speichern. Sind Sie mit diesem Speichermechanismus festgefahren? Es wäre wesentlich effizienter, wenn die Quellvideos bereits in einem Videoformat gespeichert wären (eines pro Datei) und es einen Index für jedes Video gibt (im Grunde die Dateioffsets für jeden Frame). Dann können Sie den Caching-Mechanismus des Betriebssystems verwenden, um die Leistung zu verbessern.

Eine andere Sache, die Sie in Betracht ziehen sollten, obwohl es wahrscheinlich nicht viel mit vernetzten Dateisystemen helfen wird, ist es, die Bilder im YUV-Format zu speichern. Ihre Anwendung, in der die Videos angezeigt werden, läuft möglicherweise schneller (z. B. weil die RGB-zu-YUV-Konvertierung nicht erforderlich ist und oft das Zeichnen des YUV-Bildes auf die Grafikkarte überflüssig ist), wodurch mehr Zeit für das Dateisystem bleibt Arbeit. Ich mache das, wenn ich auf ein X-Display zeichne, um Jitter zu vermeiden.

Bis zum Zwischenspeichern der Bilder würde ich wahrscheinlich einen separaten Thread verwenden, um die Bilder von der Festplatte so schnell wie möglich zu lesen, während der Hauptfaden das Bild zusammenbaut und präsentiert. Der Haupt-Thread kann seine Schleife einmal pro Frame-Darstellungsintervall ausführen, und der separate Thread kann blockieren, wenn die Anzahl der gepufferten/vorbereiteten Bilder einen bestimmten Schwellenwert erreicht. Videospieler wie MPlayer verwenden solche Strategien.

+0

Ja, ich bin mit diesem Speichermechanismus festgefahren, da wir die Videoframes in Matlab analysieren. Ich denke, der dedizierte Readahead-Thread ist ein guter. Wenn der Display-Thread nicht den richtigen Frame anzeigt, wird nichts unternommen. Und der Readahead kann darüber entscheiden, welcher Frame geladen werden soll. – rescdsk

+0

Das ist schade um den Speichermechanismus. Echtzeit-Video von Bilddateien ist ein ziemlich schwieriges Problem. –