6911
правок
Изменения
м
Нет описания правки
'''Евгений Росинский из ivi. Генерация хайлайтов'''. Всем известны трейлеры к фильмам, это законченные произведения на 2-3 минуты. А хайлайт — еще короче, 40 сек, чтобы зацепить человека. Зачем генерить? Есть страничка фильма, там статический постер. Для 20-30 фильмов руками собрали хайлайты — хайлайт в 4 раза повышает просмотры, поэтому если раскатать на все — будет профит около 20М. И возникла идея порождать хайлайты автоматически. Потому что в реальном мире трейлер делают 1.5 месяца — это долго и дорого. Про решение этой задачи Евгений рассказывал. Идея: фильм состоит из сцен, сцены — из шотов — коротких фрагментов, в которых план съемки не меняется, на шоты можно автоматически нарезать. Будем считать, что в существующие трейлеры создатели отобрали хорошие шоты, обучим модель их отбирать. Для оценки используют три кадра: первый, последний и середина. Еще проверяют, что граница шота совпадает с границей звука, и отсеивают шоты по длительности. А чтобы исключить спойлеры берут первую половину фильма. Дальше была куча техники — про нарезку на шоты, про работу с разными разрешениями, потому что резать и выбирать лучше по сжатому видео — оно меньше, а монтировать хайлайт — по исходному качеству, и не переходе есть проблемы с FPS, регулярная смена хайлайтов при показе предложения, и многое другое, путь от идеи до продакшена, как обычно, имеет много нюансов. В целом получилось так, что автоматические хайлайты не уступают созданным вручную, для оценки использовали респондентов, набранных через Яндекс. Толоку. Трейлеры вручную создают лучше — на более длинном ролике качество монтажа имеет значение. Метод не подходит для мультиков — у них сложнее с выделением персонажей, и для спортивных передач, но для спорта есть альтернатива — по комментариям и реакции в трансляциях выделяются ключевые моменты. В целом интересно и познавательно.
'''Алексей Кановкин Коновкин из Nexign. API Gateway'''. Есть много стандартных, и Мегафон выбирал. Пока выбирал — они сделали свой, вроде как прототип для осознанного выбора, а в результате именно его и взяли в продакшн. Рассказ был про функциональные задачи API Gateway, которых довольно много: хранение конфигурации, версионирование, маршрутизация с учетом работоспособности узлов, балансировка, аутентификация, авторизация, логгирование, преобразование запросов, защита и квотирование и так далее. И для каждой функции есть различные подходы, о которых рассказывали с примерами реализации в стандартных продуктах, и о своем выборе реализации, который выступал как пример. Доклад не был рекламой продукта, тем более, что отдельно они его не продают, а именно рассказом о функциях и вариантах реализации, уместных в зависимости от среды использования. Включая такие штуки, как token exchange, необходимый в гетерогенной среде со многими провайдерами токенов, используемыми разными системами, так что на интеграции токены надо подменять.
'''Алексей Станкевючис, Яндекс. Эволюция акторной системы'''. Технический рассказ об организации системы акторов. Первоначально система была на разделяемой памяти, получалось сложно. И они переделывали на нещависимых акторов, которые обмениваются сообщениями. Акторы — однопоточные state-машины — получают сообщения, обрабатывают, отправляют другие. Хорошо переходят в параллельном и распределенном вариантах. Пример — актор надежной записи: запустил сообщения акторам для записи на конкретные диски, посчитал ответы. Система доступна под Apachе 2.0.
