Recherche vidéo inversée : comment ça fonctionne
Découvrez comment SauceMatch retrouve une vidéo à partir de ses images : index FAISS sur PC domestique, empreintes visuelles et vérification géométrique.
Retrouver la source d'une vidéo : les coulisses d'un moteur maison
Un extrait de dix secondes circule sans titre, sans lien et sans contexte. La question revient aussitôt : « Quelle est la source ? » La recherche inversée d'images semble être la réponse évidente. Sauf que, dans beaucoup de cas, elle n'aide qu'à retrouver des images déjà publiées quelque part sur le web. Or une image extraite d'une vidéo n'a pas forcément été mise en ligne séparément : avec les moteurs classiques, il n'y a parfois tout simplement rien à comparer.
Le projet SauceMatch s'attaque justement à ce décalage en indexant des images tirées de vidéos, puis en comparant l'extrait fourni par l'utilisateur à celles de sa base. Son créateur dit avoir construit un index d'environ 32 millions d'images issus de plus de quatre millions de vidéos, alimenté depuis un PC domestique. Le cas d'usage concerne des vidéos pour adultes, mais l'intérêt technique dépasse largement ce cadre : repérer des doublons, détecter des copies, faire une partie du traitement directement dans le navigateur, et gérer un index tellement lourd qu'il ne tient pas forcément en mémoire vive.
Voici comment la chaîne est pensée : où elle gagne en précision, et ce qu'elle ne sait pas encore trancher.
Le principe : indexer des images plutôt que des vidéos
Une vidéo n'est qu'une suite d'images. Ça simplifie le problème, sans le rendre automatique pour autant. Plutôt que de comparer des fichiers vidéo entiers, SauceMatch choisit quelques images « représentatives » pour chaque vidéo, puis les ajoute à un index. Pendant une recherche, le système extrait lui aussi des images du fichier fourni, calcule leurs empreintes, et compare ces empreintes à celles stockées dans l'index.
À partir de là, chaque image interrogée produit des candidats. Ensuite, le moteur regroupe les candidats par vidéo : si plusieurs sites hébergent des copies du même contenu, il peut afficher plusieurs liens liés à une même vidéo au lieu de traiter tout comme des doublons sans intérêt. Pour retrouver une source, ça compte : même si le premier lien ne répond plus, il peut rester d'autres copies.
D'où viennent les images indexées ?
Le système récupère des images d'aperçu publiées par certains sites vidéo (vignettes de présentation ou images affichées au survol). Ces images sont accessibles comme des fichiers ordinaires, ce qui évite d'avoir à analyser systématiquement chaque vidéo source.
Les images sont réduites à 512 pixels sur le plus grand côté, puis stockées en WebP. Un hachage calculé à partir des pixels décodés sert à repérer les doublons exacts : si une même image apparaît dans plusieurs publications, elle est stockée une seule fois, tout en restant rattachée à plusieurs vidéos.
Il faut aussi éviter les images « trompeuses » qui reviennent partout : image d'introduction, logo de studio, vignette générique. Dans le système décrit, une image retrouvée dans plus de cinq vidéos est écartée au moment de la recherche. L'idée est simple : réduire le bruit sans exiger du modèle qu'il devienne arbitre face à une mauvaise qualité de données.
Choisir des images utiles dans un extrait
Un extrait ne contient pas toujours de « bon signal » : il peut y avoir des fondus au noir, des plans flous, des bandes noires, ou plusieurs images presque identiques. Tout garder augmente le coût de traitement, sans forcément améliorer les chances de retrouver la vidéo.
Le navigateur échantillonne des positions réparties dans le clip (jusqu'à 160 points). Il évalue la luminosité, le contraste et la netteté, puis écarte les images trop sombres ou trop floues. Il fusionne aussi les quasi-doublons. Le système tente enfin de retirer les bandes noires et certains arrière-plans floutés ajoutés par des applications mobiles.
Cette étape compte vraiment. Si les images interrogées ne sont pas distinctives, le moteur n'a rien de solide à comparer. C'est la même histoire que pour la recherche de documents : la qualité de l'index et la qualité de ce qu'on interroge ne se remplacent pas entièrement par un « bon algorithme » de classement.
Rechercher sans confondre ressemblance et copie
Une recherche sémantique classique répondrait : « Quelles images ressemblent à cette scène ? » Ici, la question est plus stricte : « Cette image est-elle une copie modifiée de quelque chose déjà indexé ? » Décors identiques, pièces proches, personnes similaires ne suffisent pas. Le but, c'est la preuve de provenance : deux images peuvent sembler liées sans venir de la même vidéo.
C'est pour ça que le projet utilise SSCD, un modèle de détection de copies d'images développé par Meta et basé sur ResNet-50. Il transforme une image en un vecteur de 512 valeurs. Ces vecteurs sont normalisés, puis comparés avec une similarité cosinus. Le modèle est conçu pour rapprocher une image et ses versions transformées : recadrage, changement d'échelle, variation de couleur, texte ajouté, recompression, etc.
CLIP pourrait répondre à une autre question (images qui représentent des objets ou des scènes similaires). C'est utile pour une recherche « par sujet », mais moins adapté quand on cherche une copie après modification. En clair : « ça ressemble » et « ça provient de la même image » ne demandent pas le même modèle, ni le même niveau d'exigence.
La géométrie sert de preuve supplémentaire
Même une empreinte spécialisée peut parfois rapprocher des images différentes, par exemple si deux scènes ont été tournées dans le même décor. Pour éviter de conclure trop vite, le système traite donc le modèle comme un générateur de candidats, puis ajoute une vérification.
Pour confirmer, il utilise des points caractéristiques SIFT extraits de l'image de requête et de l'image candidate. Les points sont mis en correspondance, filtrés avec le test du rapport de Lowe. Ensuite, il estime une homographie avec MAGSAC, une méthode robuste face aux correspondances incorrectes.
Concrètement : si suffisamment de points s'alignent selon une même transformation géométrique, les deux images peuvent correspondre malgré un recadrage, un changement d'échelle ou un texte superposé. Le score final (sur 100) combine le nombre de points cohérents, leur proportion et leur répartition dans l'image. Le système ajoute aussi des vérifications de caractéristiques de pixels sur la zone commune.
Résultat : le moteur distingue deux niveaux. Une correspondance « vérifiée » a passé le contrôle géométrique. Une image seulement « proche » est présentée comme similaire, sans prétendre que c'est la même vidéo. Et si rien ne franchit les seuils, le moteur préfère afficher peu (ou rien) plutôt que d'empiler des « peut-être » traités comme des preuves.
C'est un choix produit aussi : un résultat incertain peut sembler satisfaisant au premier regard, puis ruine la confiance quand l'utilisateur comprend qu'il s'agit d'une identification approximative.
Tester les seuils sur des cas réels
Choisir des seuils ne peut pas reposer sur une intuition, ni sur un seul exemple. Le créateur dit les avoir réglés à partir de tests conservés séparément : des copies réelles d'une même vidéo, mais aussi des vidéos différentes tournées dans un décor similaire. Dans ses essais, les copies conservaient au moins 28 points cohérents, tandis que certains faux rapprochements échouaient aux critères de validation.
Ces chiffres décrivent ses tests pour ce système précis ; ils ne garantissent pas une performance universelle. Les résultats dépendent des contenus indexés, de la qualité des images et de ce que les copies ont subi. Si on veut juger « le score » correctement, il faut mesurer séparément les faux positifs et les correspondances manquées.
Faire tenir l'index sur un PC et accélérer les recherches
L'index décrit atteint environ 32 millions de vecteurs. Le moteur utilise FAISS avec un index IVF-PQ : les vecteurs sont répartis via des listes inversées, puis compressés pour limiter le stockage. Pour chaque image interrogée, le système examine une partie des listes, récupère des candidats, puis reclasse à partir de copies quantifiées sur 8 bits.
Le créateur indique 16 384 listes, dont 1 536 explorées par image, avec jusqu'à 2 000 candidats retenus avant reclassement. Les vecteurs quantifiés occupent environ 512 octets chacun. Il précise aussi qu'un quantificateur grossier HNSW faisait perdre 15 % de rappel avec produit scalaire dans ses essais ; il a donc conservé un quantificateur plus « plat ». Là encore, l'optique est pragmatique : une structure réputée plus rapide n'est pas forcément meilleure si elle dégrade trop les résultats recherchés.
Le fichier peut rester sur disque
Quand l'index a dépassé la mémoire vive disponible, le serveur n'a plus tout chargé en RAM. Les listes inversées FAISS et les données de reclassement sont accessibles via mappage mémoire, et l'OS gère les pages comme un cache. L'application peut ainsi laisser au système le soin de libérer des pages quand d'autres processus en ont besoin.
Dans les mesures rapportées, la mémoire privée du serveur passe de 18,1 Gio à 5,3 Gio. Le « prix » apparaît sur les recherches à froid : si les données ne sont pas encore en cache, la lecture peut provoquer beaucoup de défauts de page. Une requête de 30 images passe alors à 18,3 secondes, contre environ 0,65 seconde quand les données sont déjà en cache.
D'où venait la lenteur ? Du reclassement. Après la première recherche, le système savait quelles lignes lire, mais elles étaient réparties dans un fichier très volumineux. Les accès dispersés déclenchaient de nombreuses lectures. La solution a consisté à demander au système d'exploitation de précharger les pages correspondantes avant de les consulter.
Sous Windows, l'implémentation utilise PrefetchVirtualMemory. Sous Linux, l'article cite madvise avec MADV_WILLNEED comme équivalent. Le gain rapporté va de 18,3 à 1,1 seconde à froid, sans changer les candidats ni la logique de recherche : seule l'organisation des lectures disque a été ajustée.
Quand un traitement ralentit après le passage au mappage mémoire, le premier réflexe ne devrait pas forcément être d'acheter de la RAM. Il faut d'abord regarder le motif d'accès aux données.
Le détail compte, surtout si on construit un système avec un index plus gros que sa mémoire disponible : le mappage mémoire ne rend pas les accès aléatoires gratuits. Il aide à laisser l'OS gérer les pages, mais l'application doit éviter de provoquer des lectures dispersées inutiles. Les gains observés dépendent alors du disque, du système d'exploitation et du profil réel des requêtes.
Limites, précautions et enseignements
Un index ne peut retrouver que ce qu'il contient. Le créateur indique que 12 % des recherches effectuées pendant les dix premiers jours d'octobre aboutissaient à une correspondance vérifiée. Ce taux dépend notamment de la couverture de la base : beaucoup d'échecs viennent simplement de vidéos absentes de l'index. Ce chiffre ne peut donc pas se généraliser à tous les moteurs, ni à toutes les périodes.
Il existe aussi des faux positifs plus « structurels » : deux vidéos tournées dans le même décor, avec un habillage très proche, peuvent parfois passer le contrôle géométrique. Le créateur estime ce cas à 1 ou 2 % des correspondances dans ses tests. Une vérification photométrique après l'homographie est envisagée, mais pas encore intégrée au système décrit.
Enfin, la couverture dépend de la disponibilité d'images d'aperçu accessibles. Si des sites ne publient rien de ce type, ils sont difficiles à indexer. Le projet indique aussi que les contenus peuvent être retirés sur demande, que l'usage est limité aux adultes et aux usages légaux, et qu'il ne cherche pas à identifier des personnes privées. Dans le contexte européen et des contenus sensibles, ces règles ne suffisent pas toutes seules : il faut des mécanismes concrets de signalement, de suppression et de protection des données. La conformité au RGPD ne se résume pas à une intention.
Ce qu'il faut retenir pour un projet similaire
Les décisions techniques les plus transposables tiennent en quelques points :
- Choisir un modèle conçu pour la détection de copies, pas seulement pour la similarité sémantique.
- Traiter les sorties du modèle comme des candidats, puis valider indépendamment.
- Mesurer à la fois les faux positifs et les correspondances manquées sur des jeux de test représentatifs.
- Avant d'ajouter de la capacité matérielle, regarder le profil réel des accès disque.
- Tester la quantification sur des images difficiles, pas uniquement sur les cas « faciles ».
- Si deux environnements doivent produire le même résultat, partager le code ou automatiser la comparaison des sorties.
- Prévoir un repli pour les formats et appareils qui ne suivent pas le parcours optimisé.
La démonstration est intéressante précisément parce qu'elle ne dépend pas d'une machine de centre de données : index compact, calcul dans le navigateur, gestion explicite des limites et contrôles indépendants. Ça ne veut pas dire que toute recherche vidéo peut être faite « à la maison » : couverture, débit et maintenance restent des contraintes. Mais ça montre qu'un système bien ciblé peut produire des résultats utiles sans résoudre le problème uniquement en achetant plus de matériel.
Pour aller plus loin, vous pouvez consulter l'article technique d'origine et découvrir SauceMatch, le service décrit. L'accès est réservé aux adultes, et le périmètre doit être pris en compte avant toute utilisation.
Conclusion
Construire une recherche vidéo inversée ne consiste pas à « brancher » un modèle d'IA sur un fichier et à croire le premier résultat. Tout se joue sur une chaîne complète : choisir de bonnes images, utiliser une empreinte adaptée à la détection de copies, valider les candidats avec la géométrie, puis gérer sérieusement les limites de stockage et de calcul.
Le cas SauceMatch met surtout en avant une leçon d'ingénierie pragmatique : les gros gains viennent souvent de l'architecture et de la mesure, pas d'un modèle plus spectaculaire. Le préchargement disque, le calcul dans le navigateur et les chemins de repli répondent chacun à une contrainte précise. Si vous développez quelque chose de comparable, commencez par définir ce qui constitue une preuve de correspondance, puis testez cette définition sur des cas réels. C'est un meilleur point de départ que d'empiler des résultats approximatifs.