2009-04-08 8 views
2

Je travaille sur une application qui affiche plusieurs vidéos à la fois. Les vidéos sont stockées sous forme de répertoires pleins de fichiers image. Pour chaque numéro d'image, il y a jusqu'à 9 images qui doivent être chargées à partir du disque. Je voudrais implémenter la mise en cache et la lecture anticipée pour les images. Ce serait assez simple, mais la complication est que le système de fichiers (parfois un réseau FS) est loin d'être assez rapide pour afficher chaque image. La readahead doit donc choisir les images qu'elle va essayer de charger et émettre uniquement des requêtes read() pour ces images. En outre, il serait préférable de prendre en compte quelles images sont déjà mises en cache, lors du choix des images à charger.Mise en cache et lecture d'images vidéo non fiables

Je suis venu avec un algorithme glouton qui ira bien, mais je me demandais si c'est un problème qui a été étudié, et il existe des algorithmes meilleurs/optimaux là-bas.

Je suppose que le temps est mesuré par rapport à la fréquence d'images, pas aux secondes, pour faciliter le pseudocode.

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 

Quelqu'un a des suggestions? Merci pour votre aide! -Thomas

+0

C'est un petit monde après tout ... –

Répondre

0

Est-ce prévu pour un fonctionnement en temps réel?

Certains des éditeurs vidéo les moins performants que j'ai vus vont "indexer" chaque image en stockant chaque image dans son propre fichier image. Êtes-vous coincé avec l'utilisation de ce mécanisme de stockage? Il serait nettement plus efficace si les vidéos sources étaient déjà stockées dans un format vidéo (une par fichier) et qu'il y avait un index pour chaque vidéo (essentiellement les décalages de fichier pour chaque image). Vous pouvez ensuite utiliser le mécanisme de mise en cache du système d'exploitation pour améliorer vos performances.

Une autre chose que vous voudrez peut-être considérer, bien que cela ne sera probablement pas très utile avec les systèmes de fichiers en réseau, est de stocker les images au format YUV. Votre application qui affiche les vidéos peut fonctionner plus rapidement (en partie parce que la conversion RGB-YUV n'est pas nécessaire, et souvent parce que vous pouvez décharger le travail de dessin de l'image YUV sur la carte vidéo), laissant ainsi plus de temps au système de fichiers travail. Je fais ceci en dessinant sur un affichage de X juste pour éviter la gigue.

En ce qui concerne la mise en cache des images, j'utiliserais probablement un fil séparé pour lire les images à partir du disque aussi vite que possible pendant que le fil principal assemble et présente l'image. Le thread principal peut faire sa boucle une fois par intervalle de présentation de trame, et le thread séparé peut bloquer lorsque la quantité d'images tamponnées/préparées atteint un certain seuil. Les lecteurs vidéo comme mplayer utilisent de telles stratégies.

+0

Oui, je suis coincé avec ce mécanisme de stockage, puisque c'est ainsi que nous analysons les images vidéo dans Matlab. Je pense que le thread de readahead dédié est un bon. Si le fil d'affichage ne voit pas le bon cadre, il ne fera rien. Et le readahead peut élaborer des stratégies sur l'image à charger. – rescdsk

+0

C'est trop mauvais sur le mécanisme de stockage. Faire de la vidéo en temps réel à partir de fichiers image est un problème assez difficile. –