L'analyse de vidéos sportives dans le monde réel : Reconnaissance des actions de tennis en temps réel à l'aide du flux Movinet

Cet été, j'ai effectué un stage de six semaines à ML6 sur la localisation temporelle des actions (TAL) pour les vidéos de tennis. L'objectif principal était d'en apprendre davantage sur la localisation temporelle des actions et d'évaluer son état actuel en ce qui concerne l'applicabilité dans l'industrie. Cette expérience a été très stimulante et c'est avec plaisir que je partagerai certaines de mes connaissances les plus intéressantes. Dans la première partie, j'expliquerai brièvement le domaine d'application. Ensuite, j'aborderai les trois principales stratégies utilisées dans la recherche pour réaliser les benchmarks TAL. Enfin, j'examinerai de plus près la famille de modèles Movinet et je mettrai au point un modèle de flux Movinet.

Reconnaissance des actions de tennis

Il est bien connu que dans les grands tournois de tennis, on utilise un système appelé Hawk-Eye pour suivre la trajectoire de la balle. Ce que la plupart des gens ignorent, c'est que cette technologie est également utilisée pour l'analyse des joueurs. Il s'agit d'un système extrêmement coûteux et il n'est certainement pas possible de l'installer sur tous les terrains de tennis amateurs. Il serait utile de pouvoir effectuer une analyse à partir d'un flux RVB provenant d'une seule caméra. Une première étape consiste à localiser temporellement les actions dans un flux de tennis non clipsé, de préférence en temps réel.

La reconnaissance des actions de tennis est un domaine intéressant car il s'agit d'actions très courtes. En comparaison, les ensembles de données de référence tels que AVA, ActivityNet, etc. contiennent des clips de plusieurs minutes. J'utilise les données de l'article de Hayden Faulkner et al¹. Elles se composent de 11 classes, qui font la distinction entre les frappes et les services et indiquent le joueur qui a effectué l'action. Elles contiennent 5 matchs de tennis complets dans lesquels chaque image est étiquetée.

Le gif suivant montre à quoi devrait ressembler le résultat final. Le gif est à nouveau tiré de l'article de Hayden Faulkner et al¹. Je vais comparer mon modèle à leur implémentation. Ils rapportent un score F1 de 55,7 pour leur modèle CNN-RNN. En outre, le modèle nécessite beaucoup de calculs car il utilise une fenêtre coulissante de mise en commun temporelle. C'est cette base que j'essaie d'améliorer.

Trois stratégies communes de TAL

Mise en commun temporelle

La première technique est le regroupement temporel, souvent utilisé dans les documents de recherche sur les modèles de classification vidéo pour obtenir des scores de référence sur des ensembles de données d'étiquetage spatio-temporel tels qu'AVA. Je distingue deux définitions. La première définition utilise une fenêtre coulissante pour étiqueter une vidéo image par image. Essentiellement, pour chaque image à étiqueter, on prend une fenêtre de taille N autour de cette image et on soumet cette séquence d'images à un modèle de classification vidéo. Le résultat est une étiquette unique qui n'est plus attribuée qu'à l'image centrale. La figure 1 présente une visualisation de ce processus. C'est ce qu'utilise l'article de Hayden Faulkner et al¹ et cela explique pourquoi leur modèle est assez lent et incapable de traiter les images en temps réel, ce qui est hautement préférable pour notre cas d'utilisation.

La seconde définition divise une vidéo non coupée en clips de longueur égale. Chaque clip est ensuite soumis à un modèle de classification vidéo dont le résultat est attribué à chacune des images de ce clip d'entrée. La figure 2 présente une visualisation du processus.

Il est intéressant de noter que cette deuxième définition est utilisée dans l'article sur SlowFast², un modèle de classification vidéo SOTA. Elle est utilisée comme un "hack" pour pouvoir utiliser le modèle sur l'ensemble de données AVA et fonctionne de la manière suivante. Tout d'abord, ils utilisent la mise en commun temporelle et prennent des clips d'une seconde de la vidéo non coupée. Ensuite, pour chaque clip, ils utilisent Detectron2, la bibliothèque FAIR pour les algorithmes de détection et de segmentation des SOTA, afin de trouver des boîtes de délimitation pour toutes les personnes présentes dans l'image. Enfin, les zones situées à l'intérieur de ces boîtes englobantes sont soumises au modèle SlowFast, qui produit un ensemble de probabilités pour chaque boîte englobante. Une visualisation du résultat est présentée dans le graphique suivant. Il est évident que cette stratégie n'est pas adaptée à notre cas d'utilisation. Les actions de tennis n'ont pas une durée standard car les services prennent plus d'images que les coups. De plus, les actions peuvent être très courtes et les dates de début et de fin doivent être extrêmement précises car les actions se succèdent rapidement. Cela n'est pas possible avec le regroupement temporel, car les dates de début et de fin d'une action ne peuvent se situer qu'à l'intérieur des limites de ces clips de même longueur.

Générateur de propositions d'actions et classificateur d'actions

La deuxième technique TAL consiste à utiliser un générateur de propositions d'action suivi d'un modèle de classification vidéo. Un générateur de propositions d'action prend une vidéo non clipsée et renvoie les régions temporelles ayant une forte probabilité de contenir une action. Cela nous permet d'utiliser un classificateur vidéo sur ces régions temporelles afin de leur attribuer une étiquette. Une visualisation est présentée à la figure 3. Cette stratégie s'inspire de celle de certains détecteurs d'objets. Ils utilisent une méthode similaire dans laquelle la première étape consiste à proposer des régions spatiales d'intérêt dans une image, puis cette région est classée dans une étape suivante. Malheureusement, les générateurs de propositions d'action pré-entraînés sont extrêmement rares. Il existe de nombreux articles sur ce type de modèles et leurs scores de référence sont prometteurs, mais le code fait généralement défaut.

Modèles de bout en bout

Les autres modèles utilisent la troisième et dernière stratégie commune. Il s'agit des modèles de bout en bout. Ces types de modèles sont relativement nouveaux et même s'il existe des articles intéressants à lire et de bons résultats, le code et la documentation permettant de reproduire ces résultats sont souvent incomplets et comportent de nombreux bogues.

Ces informations me permettent de tirer quelques conclusions. Premièrement, à l'heure où j'écris ces lignes, il sera impossible de trouver un modèle de bout en bout pré-entraîné que je puisse affiner sur nos données. Deuxièmement, la mise en commun temporelle n'est pas envisageable car, selon la définition que j'utilise, elle est trop lente ou nous donne des dates de début et de fin d'action trop imprécises. Cela nous amène à conclure qu'un générateur de propositions d'actions suivi d'un classificateur de vidéos est notre voie la plus viable à vérifier à ce stade. Pour la partie classification vidéo de cette stratégie, j'examinerai de plus près la famille de modèles Movinet dans la section suivante.

Movinet, base ou flux ?

La famille de modèles Movinet³ a été publiée en mars 2021 par Google Research. Elle tente de résoudre le problème récurrent des modèles de classification vidéo, à savoir leur forte consommation de ressources. La figure 4 montre comment Movinet se compare, en termes d'utilisation des ressources, à d'autres modèles de classification vidéo SOTA tels que X3D.

C'est très impressionnant et cela nous permettrait de faire de la reconnaissance d'action en temps réel. Ce qui est encore plus intéressant, c'est qu'ils proposent une variante "stream" des modèles Movinet. Cette variante me permet de traiter un clip image par image, comme le montre la figure 5. Le modèle prend en entrée un état et une image, ou une séquence d'images, et produit en sortie une étiquette et un état mis à jour. Cela nous donne une étiquette pour chaque image, mais toujours dans le but de donner une seule étiquette pour l'ensemble du clip en prenant la dernière prédiction renvoyée. Dans les prochaines parties de cet article, j'examinerai s'il est également possible d'utiliser ce modèle sur des vidéos non clipsées et de renvoyer ainsi plusieurs étiquettes par vidéo.

Je vais peaufiner un modèle de flux Movinet a0 pré-entraîné sur le jeu de données Kinetics600. Comme Tensorflow ne fournit aucune documentation sur le réglage fin de la variante de flux, cet article peut être lu comme un tutoriel. Pour fournir des données pour le réglage fin, j'utilise la classe keras VideoFrameGenerator fournie dans le package keras-video-generators. Mes générateurs de formation et de validation sont appelés respectivement train et valid.

La première chose à faire est de charger l'architecture du modèle à partir du code source de Movinet⁴, comme le montre le bloc de code suivant.

Ensuite, je dois charger les poids du modèle pré-entraîné sur Kinetics600. Vous pouvez trouver ces poids sur TensorFlow hub.

Ensuite, je dois intégrer ces poids pré-entraînés dans un nouveau modèle avec une nouvelle tête de classificateur afin de pouvoir effectuer un réglage fin sur les données de tennis. Pour cela, je crée d'abord un nouveau classificateur Movinet qui prend les poids du modèle précédent et utilise une nouvelle tête de classificateur qui prend le nombre de classes dans mon générateur de données d'entraînement.

Ensuite, je dois créer les couches d'entrée pour le modèle, qui consiste en une couche d'entrée pour l'image ou la séquence d'images et plusieurs couches d'entrée pour les états d'entrée. Ces couches sont ensuite fournies en tant qu'entrée au classificateur Movinet.

Pour pouvoir affiner ce classificateur à l'aide de l'API Keras, je dois l'intégrer dans un modèle TensorFlow. Cependant, nos générateurs de données ne nous fournissent qu'une étiquette comme valeur cible et je dois donc écarter la sortie d'état pendant l'entraînement en utilisant une étape d'entraînement personnalisée. Enfin, j'intègre le classificateur dans cette classe de modèle personnalisée.

En continuant, je ne veux régler que la tête du classificateur et je gèle donc toutes les autres couches.

Ce modèle prend en entrée un dictionnaire qui contient à la fois une image, ou une séquence d'images, et des états d'entrée. Ces états d'entrée peuvent être définis comme des états initiaux à l'aide du code source de Movinet. La valeur cible doit être une seule étiquette qui est la même pour chaque image de cette séquence. Vous pouvez créer ces états initiaux à l'aide du code suivant, dans lequel NBFRAME représente le nombre d'images dans la séquence d'images.

‍

Les données permettant d'affiner ce modèle doivent alors être fournies dans le format suivant.

Après avoir peaufiné ce modèle, je peux montrer quelques résultats en l'utilisant comme classificateur de vidéos. Le tableau suivant représente une matrice de confusion pour les différentes classes.

La précision sur l'ensemble de test est de 82,69 %, ce qui est assez bon, mais peut certainement être amélioré en ajustant davantage les hyperparamètres. Le modèle commet quelques erreurs évidentes. La première est qu'il a des difficultés à faire la distinction entre un coup à droite (HFR) et un coup à gauche (HFL) pour le joueur le plus éloigné. On peut supposer que cela est dû à la faible résolution de ce modèle, car ce n'est pas le cas pour le joueur le plus proche. En utilisant une variante plus raffinée du modèle Movinet, telle que a4 ou a5, ce problème sera probablement résolu. Deuxièmement, il a des difficultés à distinguer les services défectueux des services corrects, probablement parce que les services défectueux sont sous-représentés dans l'ensemble des données. Ce modèle utilise déjà des poids de classe et, apparemment, cela n'améliore pas le résultat de manière significative. La seule solution que je vois ici est de rassembler plus de données étiquetées.

Le modèle Movinet a également été testé sur des vidéos non coupées en faisant passer la vidéo non coupée image par image dans le modèle Movinet tout en mettant à jour l'état. Malheureusement, les résultats ne sont pas excellents. Le modèle est capable de déterminer si un rallye est en train de se dérouler, mais la classification précise de l'action est le plus souvent erronée. Ce n'est qu'en de rares occasions qu'il est capable de produire des étiquettes précises. Il est donc clair que le modèle de flux Movinet, dans sa forme originale, ne peut pas encore être utilisé sur des vidéos non coupées. Il fallait s'y attendre, car l'article ne traite également que des résultats obtenus sur des vidéos coupées.

Si je disposais d'un bon générateur de propositions d'actions, ce modèle Movinet deviendrait utile car il peut classer avec une grande précision les clips d'actions dans un délai très raisonnable. Cela rendrait possible l'étiquetage en temps réel et, dans le pire des cas, je pourrais toujours compter sur une petite mémoire tampon afin que le générateur de propositions d'actions puisse définir plus facilement les points de départ et d'arrivée des actions.

Conclusion

Les résultats de ce projet sont clairs : il existe un fossé entre la recherche et l'industrie dans le domaine de la localisation temporelle des actions. Comme expliqué dans les paragraphes précédents, les rapports de recherche font état d'une précision impressionnante sur les ensembles de données TAL, mais les modèles pré-entraînés et les bases de code bien structurées font défaut. En outre, les modèles qui peuvent être appliqués sont souvent assez lents et gourmands en ressources informatiques, ce qui rend leur utilisation presque impossible dans des cas concrets. Il est donc difficile pour les ingénieurs en apprentissage automatique de transférer à l'industrie les connaissances acquises dans le cadre de la recherche universitaire. Dans cet article, je donne un bref aperçu des différentes stratégies TAL utilisées dans la recherche universitaire. J'en conclus qu'un générateur de propositions d'actions suivi d'un classificateur de vidéos semble être la stratégie la plus réalisable à l'heure actuelle. Dans le but de trouver une implémentation de cette stratégie pour la reconnaissance des actions de tennis, je montre comment affiner un modèle de flux Movinet et comment il se comporte dans des tâches de classification simples. La précision est acceptable et trouver un générateur de proposition d'action approprié est la prochaine étape dans cette quête de localisation temporelle d'action de tennis.


Cet article est supervisé par Jules Talloen, ingénieur ML6, et écrit par Timo Martens, stagiaire ML6.
>> Lire cet article sur la plateforme Medium.


‍

[1] : Hayden Faulkner et al. (2017). TenniSet : A Dataset for Dense Fine-Grained Event Recognition, Localisation and Description. https://github.com/HaydenFaulkner/Tennis

[2] : Christoph Feichtenhofer et al. (2019). SlowFast Networks for Video Recognition.
https://arxiv.org/pdf/1812.03982v3.pdf

[3] : Recherche Google. (2021). MoViNets : Mobile Video Networks for Efficient Video Recognition (Réseaux vidéo mobiles pour une reconnaissance vidéo efficace).
https://arxiv.org/pdf/2103.11511.pdf

[4] : https://github.com/tensorflow/models/tree/master/official/vision/beta/projects/movinet

‍