Недавно закончилось соревнование от американской национальной футбольной лиги (NFL), которая объединилась с AWS, чтобы прокачать системы спортивной видеоаналитики.

Организаторы поставили простую, казалось бы, задачу — точно определить, в каких случаях игроки сталкиваются друг с другом во время матча по американскому футболу. Мы с коллегами приняли участие, но не успели реализовать все свои идеи. Зато изучили подходы других команд и поняли, что были на верном пути. В этой статье я рассмотрю некоторые из решений, которые принесли денежное вознаграждение и золотые медали участникам этого челленджа.

*Пример видеозаписи матча по американскому футболу с baseline-решением*

Задачи участников соревнования

В качестве цели перед участниками Kaggle NFL — была поставлена задача определения наличия/отсутствия столкновения между двумя игроками в американский футбол в определенный момент времени в конкретной игре.

В соревновании использовалась метрика корреляции Мэтьюса (MCC) для оценки качества классификации столкновений между игроками.

$MCC = \frac{TP*TN - FP * FN}{\sqrt{(TP+FP)(TP+FN)(TN+FP)(TN+FN)} }$

MCC позволяет учитывать все четыре возможных исхода классификации:

Верно-положительный (TP)
Верно-отрицательный (TN)
Ложно-положительный (FP)
Ложно-отрицательный (FN)

С какими данными надо было работать

Исходных данных было много, а особенностей у них еще больше, так что я кратко опишу самые важные моменты. Сам датасет и полную информацию о его содержимом можно найти на странице соревнования на сайте Kaggle или по ссылкам ниже.

Видео-данные [train/test], mp4

Для каждого матча в датасете предложено три видеозаписи, сделанных с трех разных ракурсов в формате mp4. Записи игр идут по 15 секунд, сам игровой эпизод начинается спустя 5 секунд от начала.

*Фрейм из видео, где видно все поле (All29)*

All29 демонстрирует картинку всего поля, endzone и sideline — отдельные его зоны — центр и боковую часть. Видео sideline и endzone синхронизированы по времени. Для видео All29 синхронизация не гарантируется. Кажется никто из участников соревнования его не использовал, хотя организаторы специально предоставили запись для того, чтобы можно было отслеживать всех игроков на поле.

*Фрейм из sideline (слева) фрейм из endzone (справа)*

[train/test]_video_metadata.csv

game_play: уникальная комбинация игрового ключа и идентификатора игры для игры (Unique game key and play id combination for the play);
game_key: ID code игры(game);
play_id: ID code для игрового розыгрыша(play);
view: откуда снимали Sideline or Endzone;
start_time: timestamp начала видео;
end_time: timestamp конца видео;
snap_time: timestamp когда сама игра начинается. Во всех видео составляет 5 секунд (300 фреймов).

train_labels.csv

contact_id: комбинация столбцов game_play, player_ids и step;
game_play: уникальный идентификатор для play и игры;
nfl_player_id_1: идентификатор игрока с меньшим номером в контактной паре. Если контакт с землей, то просто player_id;
nfl_player_id_2: идентификатор игрока с наибольшим номером в контактной паре. Если контакт с землей, то буква «G»;
step: число, представляющее каждый временной шаг для каждого воспроизведения, начиная с 0 в момент начала воспроизведения и увеличиваясь на 1 каждые 0,1 секунды;
datetime: временная метка контакта, 10 Гц;
contact: был контакт или нет.

Больше деталей по данным с видео:

все видео содержат частоту кадров 59.94 HZ;
всего около 149 для train игр;
среднее время игры 11 секунд, где 5 секунд игроки ждут свистка, чтобы начать игру;
в test есть видео, которые были в train.

Tracking данные

Каждый игрок на поле носит датчик, который позволяет определять его местонахождение и ориентацию на поле с привязкой ко времени. Эти данные собираются с частотой 10 Гц каждые 0,1 секунды и они очень важны для решения поставленной задачи.

С помощью этой фичи можно отсеять далекие друг от друга пары игроков, ведь между ними физически не может быть столкновения.

Средний рост взрослого мужчины, скажем 2 ярда (180 см), можно использовать, как порог, благодаря которому можно отбросить ненужные данные. Столкновение между игроками на расстоянии в 180 см теоретически еще возможно, но на большей дистанции уже крайне маловероятно, хотя в данных присутствовали метки между игроками с расстоянием 5 метров.

[train/test]_player_tracking.csv

game_play: уникальная комбинация игрового ключа и идентификатора игры для игры;
game_key: ID-code для игры;
play_id: ID-code для игрового розыгрыша;
nfl_player_id: ID-code игрока;
datetime: timestamp 10 Гц;
step: временной интервал внутри игры относительно начала игры;
position: позиция игрока на поле;
team: команда игрока home или away;
jersey_number: номер игрока (игровой);
x_position: положение игрока вдоль длинной оси поля;
y_position: положение игрока вдоль короткой оси поля;
speed: скорость игрока в yards/second.1 ярд (yard) = 0.9144 метра (meter);
distance: расстояние, пройденное от предыдущей временной точки, в ярдах;
orientation: ориентация игрока на поле(deg);
direction: угол движения игрока (deg);
acceleration: (magnitiude) величина общего ускорения в ярдах/с²;
sa: ускорение ярдов/с² в направлении, в котором движется игрок.

Шлемы игроков (BBoxes)

Подобные соревнования уже проводились раньше, и предыдущим заданием NFL было определение местоположения шлемов игроков на видео. Результаты работы алгоритма-победителя были включены в датасет для нового соревнования. Хотя это и предсказания модели, это не было проблемой, почти всегда шлемы были определены достаточно точно.

[train/test]_baseline_helmets.csv

game_play: уникальный идентификатор для play и игры;
game_key: ID code для game;
play_id: ID code для play;
view: откуда снимали Sideline or Endzone;
video: имя видео к которому относятся BBoxes;
frame: фрейм из видео к которому относятся BBoxes;
nfl_player_id: предсказанный id игрока(точность не гарантируется);
player_label: комбинация номера майки игрока и его команды(home или visitor);
[left/width/top/height]: предсказанный BBox.

*Схема игрового поля с указанием зон и трекинг-информации об игроке*

Предоставленные данные не идеальны, но их достаточно для получения хороших результатов. Вот EDA, в нем можно посмотреть некоторые закономерности в данных.

Данных для решения задачи было много: около 60GB, а при разбиении на фреймы около 373K файлов. Поэтому участники часто сталкивались с ошибкой OOM, и для обучения и сабмита приходилось использовать различные хитрости. Чаще всего модель обучали от 1 до 10 эпох.

Решение, занявшее 5 место

Это решение от команды Тамо состоит из двух этапов: применения нейронной сети (NN) и обработки при помощи градиентного бустинга (GBDT). В этой обзорной статье сделаю упор на первый этап.

Чтобы реализовать детекцию столкновений, сперва было необходимо подготовить данные для входа в NN.

Одна картинка состояла из:

двух grey фреймов +-1 по времени первым и вторым каналом;
масок BBox’ов на третьем канале тензора.

В итоге имеем тензор [f-1, f+1, f] (см. скриншот ниже), где интересующая область вокруг целевых игроков получена следующим образом:

для пар игрок-игрок берется наибольшая сторона среднего BBox по кадрам игроков;
затем она умножается на 3 для увеличения области. Идея в том, чтобы в нее попадал не только шлем, но и силуэт игрока;
далее она ресайзится до 128x128.

Выглядит это так: crop size = max(average BBox width, average BBox height) * 3.

Для пар игрок-земля размер после обрезки равен максимальному значению ширины BBox и высоты BBox, умноженному на 3 и также ресайз до 128x128: crop size = max(BBox width, BBox height) * 3.

Во время обучения используются последовательности кадров, содержащие хотя бы один кадр с расстоянием между игроками не менее двух ярдов. Но в последовательности данные могут содержать также кадры с расстоянием более двух ярдов.

В итоге входные данные представляются в виде двух тензоров:

с размерами B x N x 10 для tracking data;
с размерами (B x N) x 3 x 128 x 128 для фреймов, где B — batch size, N — последовательность кадров (например, 16, 32, 48, 64).

Во время обучения и инференса вырезаются последовательные кадры (N) с разным шагом. Для обучения не используются дублирующие кадры (stride == N), то есть без overlap. Для инференса же применяются дублирующие кадры (stride < N). Полученные значения дублирующих кадров усредняются.

Архитектура

Объединенные последовательности фреймов с sideLine и endzone подаются в CNN backbone с TSM (улучшает способность сети моделировать временную информацию в видео фреймах + оригинал статьи).
Конкатенируются фичи с tracking data.
BiLSTM слои + FC cлой.

Слой BiLSTM (за которым следует слой FC) обрабатывает последовательность кадров и создает последовательность скрытых состояний, которые отражают временные зависимости между кадрами. Затем слой FC принимает эти скрытые состояния в качестве входных данных и производит один выходной сигнал, представляющий всю последовательность кадров.

*Архитектура, позволившая занять 5 место*

Эксперименты проводились c ResNet18, ResNet34, ResNet50, ResNeXt50, EfficientNet B0 и EfficientNet B1 с различной длиной последовательностей: 16, 32, 48 и 64.

Этап 2 (XGB, LGBM)

Этап с XGboost опустим, оставив пару коротких заметок. Во-первых, было две модели: XGB и LGBM, обученных на одних и тех же данных. Во-вторых, в модели подавались фичи: самое важное — outputs с предыдущей модели (NN), сырые табличные данные, трекинг шлемов, некоторые комбинации фичей.

Тут можно потыкать в kaggle ноутбук для обучения XGB на данных этого соревнования.

Ансамбли

Частый прием в соревнованиях — использование предсказаний нескольких моделей. Это соревнование не стало исключением. На табличке ниже представлены комбинации моделей различных архитектур, последовательности кадров и результат на кросс-валидации (CV).

*Модели, отобранные с Forward Selection (данные команды, занявшей 5 место)*

Для ансамблирования участники использовали Forward Selection OOF (Out-of-Fold) — метод ансамбля, который включает в себя обучение нескольких моделей на разных подмножествах данных, а затем объединение прогнозов каждой модели Out-of-Fold для создания окончательного прогноза. Познакомиться с Forward Selection OOF Ensemble можно тут.

Советы от команды, занявшей пятое место, для избегания проблем с OOM и timeout:

lru_cache увеличит скорости чтения изображений;
PyTurboJPEG загрузит изображения быстрее, чем OpenCV;
Polars поможет ускорить время сабмита. Polars — аналог Pandas, написанный на rust. Во многих базовых сценариях работает значительно быстрее.

Решение, занявшее 4 место

*Общая схема решения. Camaro 2 — Public 0.780*

Этот подход к детекции столкновений разбит на два этапа обучение CNN (авторы прогнозируют контакт при помощи двух разных подходов) и обучение градиентных бустингов.

Обучение CNN, подход от K_mat

Один из участников команды предложил следующий алгоритм прогнозирования: сначала пред-обрабатывается полное изображение игроков для детекции каждого из них на изображении.

Как и в предыдущем случае BBox шлема расширяется, так, чтобы захватить силуэт игрока. Так получается кроп игрока в полный рост.

Далее предсказываются три маски для каждого игрока по отдельности с использованием модели UNet.

маски 0_a, 1_a, 2_a — контакт игрока с игроком;
маски 0_b, 1_b, 2_b — маска игрока;
маски 0_c, 1_c, 2_c — контакт игрока с землей;

Уточняется место контакта с масками «контакт игрока с игроком» и масками игроков, 0_a, 1_a, 2_a и 0_b, 1_b, 2_b **соответственно. Получается следующий результат:

маски 0_ab, 1_ab, 2_ab — пересечение масок столкновений с масками самих игроков;
маски 0_ab, 1_ab, 2_ab — пересечение масок игроков с землей.

Затем области пересечения масок каждой пары умножаются, а ее максимальное значение выводится в качестве прогноза столкновения между двумя игроками (как это показано на рисунке ниже):

В конце вычисляется функция потерь для каждого контакта. Результаты сравниваются с соответствующими истинными значениями. Для этого используется функция потерь LogLoss.

Получается, что в результате своей работы модель — предсказывает столкновения между игроками. Выглядит это так:

Больше деталей — в комментариях к этому решению.

Обучение CNN, подход от Camaro

Альтернативное решение предсказывает столкновения всех комбинированных пар и контакт игрока с землей одновременно.

*Часть решения на общей схеме (Camaro 1)*

Первый этап — получение фичемапов (RoIAlign) с помощью YoloxFPN из полных изображений с маской BBox’ов шлемов + уточнение RoIAlign игроков с помощью координат BBox’а шлемов. Причем это не кроп, а фичемапа полного изображения. После линейного преобразования трекинг-данных конкатенируем их с фичемапой игроков из предыдущего шага.

Для предсказания столкновения игрока с игроком создается попарная матрица игроков и конкатенация фичей игроков. Затем расстояния между игроками умножаются на фичи матрицы и прогоняются через линейный слой. И в результате получаются попарные предсказания столкновений между игроками.
Для предсказания столкновения игроков с землей результат, полученный после объединения фичимапы с трекинг-данными, прогоняется через линейный слой. В итоге мы имеем попарное предсказание столкновения игроков.
Дополнительно предсказывается наличие/отсутствие контакта игрока с другим игроком (из любой команды).

Обучение градиентных бустингов

Градиентный бустинг — метод машинного обучения для построения предсказательных моделей. Чаще всего для его реализации используются библиотеки XGBoost, LGBM, CatBoost. На втором этапе в градиентный бустинг подаются агрегированные предикты CNN, трекинг-данные и BBox’ы шлемов. Затем вычисляется усредненное значение по пяти моделям, оптимизируется порог для контакта игрока с игроком, плюс для контакта игрока с землей.

Часть с LightGBM и XGBoost в этой статье нами подробно затрагивать не будет, но подсветим несколько интересных деталей:

предсказанные значения из CNN — фичи для последующего обучения множества комбинаций LightGBM и XGBoost;
было создано множество фичей (feature extraction), их полный список можно посмотреть по этой ссылке;
а еще у команды не получилось завести CatBoost.

Решение, занявшее 3 место

В отличие от других решений, участвовавших в соревновании это — end-to-end подход. Модель обучается для каждого игрока и интервала шагов (вместо попарного предсказания). Контакт с землей для текущего игрока и контакт с семью ближайшими игроками прогнозируется для всех входных шагов. Модель состоит из видео-энкодера для обработки входных видеокадров и трансформер декодера для объединения трекинг- и видео-фичей.

*Архитектура решения, занявшего третье место*

Видео-энкодеры

Видео-энкодеры использовали несколько входных видеокадров в соответствии с необходимым количеством шагов. Они производили активацию на соответствующих шагах с уменьшенным разрешением (обычно для 16 шагов с соответствующими 96 кадрами), применяя каждый второй кадр для входа.

В качестве видео-энкодеров использовалось несколько разных моделей:

предтренированные модели 2D imagenet + 3D Conv слой (идея команды, занявшей второе место); черно-белая последовательность из +- 3 фреймов от кадра со столкновением, которая используется как вход для 2D-модели (convnext large backbone) и объединяется с помощью 3D Conv;
обученные модели 2D imagenet + TSM с вводом цвета для каждого второго или третьего кадра и обменом активациями (как TSM) между кадрами перед сверткой. TSM улучшает способность сети моделировать временную информацию в видео фреймах (здесь можно почитать оригинал статьи);
3D / видео-модели, такие как Video Swin Transformer или CLIP-X (X-CLIP-B/16 — вторая по производительности модель).

Подготовка данных

Фреймы были кропнуты до разрешения 224x224. При этом шлем текущего игрока помещался в центральную/верхнюю часть кадра и масштабировался таким образом, чтобы средний размер шлемов в окружающих кадрах был масштабирован до 34 пикселей.

Аугментации: random shift, scale, rotate images, shift HUV, добавленные blur и noise.

Transformer player features / video activations decoder

Основная идея заключалась в том, что механизмы внимания используются в модели-трансформере для обработки и объединения различных признаков. Эти фичи содержат информацию о: местоположении, видимости, принадлежности к команде, роли игроков, скорости, ускорении, расстоянии до других игроков, относительной ориентации и активации видео с позиций шлема. Модель учитывает несколько последовательностей соседних фреймов -7…+8 и семи соседних игроков на фреймах с определенного расстояния. За счет этого создается полное представление для каждого игрока на каждом шаге.

Обучение модели

Выбор данных. Все игроки и их шаги с распознанным шлемом включаются в трейн (хотя бы на одном видео). Это гарантирует доступ модели к трекинг-фичам за несколько шагов до и после становления игрока видимым/невидимым.

Оптимизация и шедулер. Оптимизатор AdamW используется с относительно небольшим размером батча от 1 до 4. В процессе обучения применяется шедулер CosineAnnealingWarmRestarts с размером эпохи в 1024-2048 семплов.

Функция потерь. Потери бинарной перекрестной энтропии (BCE) используются с небольшим сглаживанием таргетов (label smoothing) в диапазоне от 0,001 до 0,999. Параметр сглаживания подобран интуитивно.

Было обучено множество моделей. В toggle представлены почти все модели и ансамбли с их качеством на приватном лидерборде.

Video model type, backbone	Notes	Private LB score
Convnext large, 2D + 3D conv	16 steps/96 frames, skip 1 frame.	0.7915
Convnext base, 2D + 3D conv	16 steps/96 frames, skip 1 frame.	0.786
DPN92, 2D + 3D conv	16 steps/96 frames, skip 1 frame.	0.784
X-CLIP-B/16	11 steps/64 frames, skip 1 frame.	0.791
X-CLIP-B/32	11 steps/64 frames, skip 1 frame.	0.784
Convnext pico, TSM	63 steps/384 frames, skip 2 frames.	0.788
2 best models ensemble	Convnext large and X-CLIP-B/16,	0.7925
6 models ensemble	Without DPN92, re-trained on full data with original helmets	0.7932
6 models ensemble	Without DPN92, re-trained on full data with fixed helmets	0.7934
7 models ensemble	Convnext large added with weight 3 and X-CLIP-B/16 with weight 2. Models trained on different folds.	0.7956

Выводы

Как видите, в машинном обучении возможны очень разные подходы к решению одной и той же задачи. Причем, несмотря на это, команды достигли результатов, отличающихся только в четвертом знаке после запятой.

С каждым из этих решений интересно познакомиться, ведь полезным может быть не только участие в соревнованиях, но и анализ достижений призеров. Эти идеи могут пригодиться в новых проектах. Здесь стоит обратить внимание на:

метрику корреляции Мэтьюса и Forward Selection OOF Ensemble;
процедуру подготовки данных для обучения в задаче видеоклассификации;
разнообразные подходы к обнаружению контакта между игроками;
архитектуры и методы для решения задачи с трекинг-данными и последовательностью изображений.

Ссылки

Соревнование: 1st and Future - Player Contact Detection.
Третье место.
Четвертое место.
Пятое место.
Видеоразбор прошлогоднего соревнования: NFL - Helmet Assignment | Understanding Top Kaggle Solutions.

Разбор выполнен для DeepSchool. На Хабре публикуется в новой, отредактированной версии.

Kaggle для футболистов. Разбираем подходы призеров соревнований по детекции столкновений (5 — 3 место)