Awesome Video, огромная коллекция статей, туториалов, инструментов и других материалов о разработке видео и стриминговых сервисов — https://awesome.video

Время скандалов из твиттера!

Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help,

https://trac.ffmpeg.org/ticket/10341

Jpegli - новая библиотека кодирования JPEG от Google
https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

Google выкатил в open-source новую библиотеку для кодирования jpeg - https://github.com/libjxl/libjxl/tree/main/lib/jpegli
Либа под капотом используют алгоритмы из JPEG-XL, который Google, по сути, сам похоронил пару лет назад.

Jpegli, судя по тестам, жмет картинки до 35% эффективнее существующих реализаций (mozjpeg, libjpeg-turbo), и полностью совместим с существующими декодерами.

Можно переходить!

Чётко о мутных заглушках 

TL;DR: Команда Mux напоминает о базовых вещах — можно и нужно использовать блюр для имитации загрузки видео и изображений.

Мы постоянно боремся за скорость показа первого кадра видео. Пользователь начинает ждать контент сразу после клика по кнопке «Смотреть». Можно технически ускорять загрузку видео, а можно также работать с ощущениями пользователя — создавать иллюзию того, что мы уже что-то загрузили, чтобы он дождался основного контента. Для этого используются скелетоны, гифки и размытые заглушки (Low-Quality Image Placeholders, LQIP). В статье Mux рассматривают различные способы использовать LQIP.

Идея LQIP проста: сжать изображение до состояния «у вас jpg», растянуть до нужных размеров и сгладить фильтром размытия по Гауссу. С распространением формата WebP вес таких заглушек стал достигать 100B. LQIP отлично работают в вебе, так как можно закодировать сжатое изображение в Base64 и отдать сразу с метаданными видео (без лишних походов по сети).

Есть более продвинутые готовые решения:
• Blurhash. Сжимает еще сильнее, вес заглушки достигает 20-30B. BlurHash применяет дискретное косинусное преобразование, сохраняя только ключевые компоненты, а затем кодирует эти компоненты в Base83.
• Thumbhash. Работает аналогично Blurhash, но кодирует больше деталей. Кроме того позволяет передать соотношение сторон и кодировать изображения с альфа-каналом.

Главный минус этих решений — необходимость декодирования на стороне клиента (hash -> Base64), всегда нужен JS. 

Поделитесь, пользуетесь ли вы заблюренными заглушками? Какие решения для них используете?

AV1 в массы?

Появилось подтверждение, что Google переходит на софтварный декодер libdav1d от VideoLAN для воспроизведения AV1 и "по воздуху" раскатит обновление вплоть до Android 12 (Snow Cone).

Сейчас для софтварного декодирвания используется libgav1. Однако, как говорили в феврале, теперь будет использоваться libdav1d от VideoLAN. Последнее подтверждает Arif Dikici, Software Development Manager из команды Android Video and Image Codecs, Google.

Причина перехода, похоже, производительность.. libdav1d значимо эффективнее, чем libgav1. Конечно, было бы эффективнее использовать хардварное декодирование, однако, появление хардварной поддержки - очень длительный процесс.

Кстати, просмотреть доступные декодеры можно в приложении. Нашел кто у себя libdav1d?

Новые инструменты для WebRTC!

Наверное у вас всегда было желание понять что у вас с STUN/TURN. Базовые знания обычно ограничиваются на том что прямое соединение - хорошо, а relay через turn - плохо. Но мы же инженеры! Нам надо цифр! И вот вышел отличный инструмент ICEPerf - позволяет перевести в цифры что ваш TURN/STUN работает хорошо и померяться цифрами с друзьями.
Авторы софта на своем сайте выложили какие-то цифры о том как работают публично доступные TURN сервера, но это все шелуха, так как они показывают цифры, но не показывают откуда их собирали (мне кажется это домик в лесу около ДЦ CloudFlare, но как проверить?)
Так что можете смело скипать сайт и сразу переходить на их github и брать агента в работу.

Microsoft PlayReady скомпрометирован

https://seclists.org/fulldisclosure/2024/May/5

PlayReady — одна из трех популярных DRM-систем для защиты видеоконтента от нелегального копирования, разрабатываемая Microsoft. Видео, защищенное DRM, расшифровывается специальным DRM-клиентом (софтварным или хардварным) и воспроизводится через secure path операционной системы — это блокирует запись экрана при воспроизведении такого контента.

В софтварной реализации PlayReady обнаружена дыра, которая позволяет извлечь приватные ключи DRM-клиента. С помощью этих ключей можно «сэмулировать» DRM-клиента вне secure path и сохранить/записать защищенное PlayReady видео без потери качества.

Впрочем, для записи изображения все DRM-системы в любом случае обходятся устройством для захвата HDMI за 20$ с AliExpress 🏴‍☠️.

Детективная история про запуск DRM-контента на Set-Top Box

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

Daniel Silhavy (мейнтейнер dash.js) делится историей отладки такой проблемы на Set-Top Box и подходами, которые он применял для дебага.

https://websites.fraunhofer.de/video-dev/kid-it-out-putting-big-buck-bunny-on-a-diet/

Почему YouTube бесплатный?

На Hacker News обсуждается очень интересный тред: "Видеостриминг дорогой, YouTube делает его бесплатно. Как?". Прочитав его целиком, можно пойти устраиваться архитектором стриминговых платформ. Если читать все комментарии вам лень, но архитектором быть все-таки хочется, мы подготовили для вас его краткое содержание.

YouTube тратит деньги на следующие направления:
- хранение видео
- его обработка (транскодирование)
- раздача видео пользователям
- ну и операционные расходы (команда, сервера, офисы и т.д.)
А зарабатывает — на рекламе.

Так за счет чего же для пользователей это все еще бесплатно (в отличие от всяких нетфликсов с платной подпиской)?

YouTube — огромный: около эксабайта залитого видео (если собрать башенку из жестких дисков в 1ТБ, получится башня высотой 25 км), и около 18% трафика всего интернета. Эти объемы дают возможность Google делать вещи, не доступные другим сервисам (и сильно экономить расходы):
1) Собственное кастомное железо для транскодирования (ASIC). Такие штуки дорого разрабатывать и производить, но на масштабах YouTube это получается выгодно. Менее крупные сервисы используют видеокарты или вообще CPU, а это работает медленнее и стоит дороже в пересчете на одну единицу контента.
2) Дешевые тарифы раздачи трафика (оптом дешевле, да и провайдеры заинтересованы в том, чтобы YouTube хорошо работал у пользователей)
3) Огромная сеть кеширующих серверов (CDN), которая удешевляет стоимость раздачи видео конечному пользователю. Сеть состоит из трех уровней: дата-центры, "точки присутствия" — места подключения сети Google в интернет, и конечные узлы — кеширующие сервера по всему миру (Google Global Cache). У них даже есть публичная карта с расположением узлов этой сети. Кстати, если вы замечали, что после 2022 года ютубчик у вас в РФ стал работать хуже, то это произошло как раз потому, что Google отключил часть серверов Google Global Cache в России.
Другие сервисы же часто либо не имеют такой сети вовсе, либо пользуются более дорогими внешними провайдерами.
4) Экономия на хранилище — база контента YouTube настолько большая, что существенную часть непопулярных видео можно переложить на "холодное" хранение (медленные дешевые жесткие диски с уменьшенной отказоустойчивостью). Если контента у вас мало, выделить непопулярную его часть будет сложнее.

При этом, YouTube зарабатывает огромные деньги на рекламе. Чистую прибыль Google не публикует, но выручка сервиса за 2023 год составила 31,5 миллиарда долларов. Сходится ли дебет с кредитом? Бывшие сотрудники Google в треде пишут, что ~10 лет назад YouTube был сильно убыточен. Некоторые аналитики считают, что это верно и на сегодняшний день — исходя из логики, что Netflix (который только-только недавно стал профитным) раздает примерно такие же объемы трафика, но имеет сильно менее объемную базу контента, что позволяет им больше экономить на транскодировании и кешировании.

Так что, возможно, YouTube бесплатен для пользователей, но не для Google!

caniwatchvideo.online

Порекламируем пет-проект нашего коллеги — сервис https://caniwatchvideo.online/ покажет всю информацию о том, какие фичи, связанные с видео (кодеки, HDR, DRM и многое-многое другое), поддерживаются вашим устройством и браузером.

WWDC: Обновления в HLS

На WWDC были новости и для видеоинженеров:

• AVPlayer теперь поддерживает стандарт CMCD (Common Media Client Data). CMCD позволяет связывать события с клиента и с CDN для мониторинга и оптимизации доставки контента. AVPlayer поддерживает только один вариант передачи данных — через HTTP-заголовки. Можно включить отправку CMCD, установив urlAsset.resourceLoader.sendsCommonMediaClientDataAsHTTPHeaders = true.

• Добавили AVMetrics API — новый AVFoundation API, который позволяет слушать события производительности и воспроизведения. Подробнее.

• Появилась поддержка AV1 для Dolby Vision 10.x и возможность указать в плейлисте, что у вас есть дорожка с HDR10+.

MLow — новый аудио-кодек в сервисах Meta

В Meta разработали новый аудио-кодек для передачи голоса с очень низкими битрейтами — Meta Low Bitrate (MLow). MLow позволяет передавать запись разговора в очень хорошем качестве на экстремально низких битрейтах (~6kbps), и при этом не требует много вычислительных ресурсов (работает на смартфоне 10-ти летней давности). Кодек уже используется в проде в WhatsApp и других запрещенных экстремистских продуктах.

Похоже, что выход MLow в open-source пока не планируется — в Meta, видимо, считают эту разработку важным конкурентным преимуществом.

Новое поле битвы стримингов: спортивные трансляции

Автор: Ольга Попова, видеоразработчик, соавтор @video_engineer_pains, специально для @contentreview

Для победы в стриминговой гонке онлайн-кинотеатрам важен не только контент, но и высокая эффективность его доставки до зрителя. В The Verge вышла довольно большая статья, посвященная «ставке Netflix на продвинутое кодирование видео». Но в ней нет ничего сверх того, что Netflix уже рассказывал в своем техническом блоге, научных статьях или докладах.

В последние годы начинает казаться, что Netflix выигрывает в этой гонке. Они и правда достигли небывалых высот в сжатии видео с сохранением наилучшего качества. Например, они одними из первых стали использовать per-title кодирование, когда настройки кодеков подбирались алгоритмами для каждого фильма отдельно. А в 2018 году начали делать то, что до сих пор трудно повторить остальным: per-shot кодирование, когда настройки алгоритмов сжатия подбираются не под фильм, а под отдельно взятую сцену фильма. Надо признать, что на данный момент в эффективности сжатия VOD-контента Netflix нет равных.

Но стриминговые войны продолжаются. Новым полем битвы были выбраны спортивные трансляции, собирающие миллионы зрителей. Cтриминги пытаются поделить американский рынок, борются главным образом за NFL (Национальная футбольная лига), NBA (Национальная баскетбольная лига) и MLB (Главная лига бейсбола). Трансляции матчей американского футбола всегда были прерогативой телеканалов. Но они постепенно теряют аудиторию, а стриминги ищут новые способы удерживать подписчиков. И вот уже некоторые из них купили права на крупные спортивные трансляции: YouTube (NFL Sunday Ticket), Amazon Prime Video (несколько игр NFL, NBA), Apple TV+ (Friday Night Baseball). А Disney, WBD и Fox, уже обладающие своими спортивными телеканалами и правами на трансляции, объединились и создали отдельный сервис venu.com.

Netflix включился в игру одним из последних, поскольку, как они сами говорили, их не интересовал «одноразовый контент». И технического преимущества у них пока нет. У инфраструктуры Netflix, заточенной под раздачу VOD-контента, есть две проблемы с трансляциями:

- Жёсткое ограничение по времени на сжатие. Если фильм или сериал можно заранее загрузить в систему и кодировать несколько суток, то в спортивных трансляциях надо успевать за секунды.

- Существующие алгоритмы per-shot кодирования не работают, так как сложно предсказать, какая сцена будет дальше.

Девять месяцев назад Netflix искала для прямых трансляций специалиста по алгоритмам ABR (adaptive bitrate streaming). Это динамический подбор качества видео в процессе воспроизведения, который в реальном времени адаптируется к пропускной способности сети и производительности устройства пользователя. Сейчас они ищут человека, который поможет разработать систему мониторинга состояния трансляций в реальном времени. Это означает, что Netflix, в первую очередь, делает упор на отказоустойчивость прямых трансляций.

У Netflix серьезные соперники с опытом в прямых трансляциях, например, YouTube. Amazon, владеющий Twitch, возможно, переиспользует свой опыт для спорта в Prime Video. Apple как держатели стандарта HLS (HTTP Live Streaming) занимаются трансляциями и низкими задержками в них. В любом случае, сначала все крупные компании научатся выдерживать миллионные аудитории в режиме реального времени, после чего начнется соревнование за минимальные задержки и высокое качество изображения.

Lottie - видео-анимации без видео

В вечной битве GIF-анимаций против видео есть еще один игрок — формат Lottie. Формат назван в честь Лотты Райнигер — всемирно известного немецкого режиссера силуэтной анимации.

Lottie позволяет экспортировать векторные анимации в JSON-формат, и проигрывать их в плеерах для всех популярных платформ. Формат позволяет сильно экономить на размере "видео" — анимация, описанная в JSON-формате весит в среднем в несколько раз меньше, чем эта же анимация, экспортированная в webm/webp, и в 10 раз меньше, чем GIF. JSON, к тому же, отлично жмется gzipом или brotli. Можно предположить, что при отрисовке такого "видео" компьютер превращается в пылесос, но утвержается, что с перформансом все неплохо — реализации lottie-плееров умеют рендериться с использованием аппаратного ускорения. Бенчмарков, правда, нигде нет.

Telegram, кстати, во всю использует этот формат — анимированные стикеры телеги передаются в формате TGS - это просто Lottie JSON, упакованный в gzip.

Используете ли вы Lottie в своих проектах, по-старинке вставляете GIFки, или показываете видео без звука?

Хотим посоветовать вам папку с подборкой каналов, в создании которых участвуют сотрудники Яндекса. Мы тоже попали в эту подборку. Внутри каналы про разработку, дизайн и менеджмент.
Подписаться на папку можно тут.

Вакансии для разработчиков видео-сервисов

Сегодня мы хотим запустить новую рубрику в канале: подборки тематических вакансий!

Начнем со вакансий в Видеоплатформу Яндекса — команду, которая разрабатывает инфраструктуру для показа видео и проведения видеозвонков в сервисах Яндекса.
- Разработчик видеотехнологий для Android
- Разработчик фронтенда в видеоплеер
- Инженер по тестированию
- Бэкенд-разработчик Видеоплатформы

Если вас заинтересовала вакансия, вы хотите откликнуться или рекомендовать знакомого — пишите мне @alexey_gusev

#вакансии
Чтобы поделиться своими вакансиями в нашем канале, напишите о них в нашего бота обратной связи @video_engineer_pains_feedbackbot

Пока пользователи в РФ борются с замедлением YouTube (говорят, что выходят из строя сервера Google Global Cache в России), YouTube продолжает свой неравный бой с AdBlock — на reddit жалуются, что Google "закидывает" AdBlock фейковой рекламой, что сильно замедляет браузер и вынуждает пользователя отключить блокировщик рекламы.

Демистификация аудио-стека в Linux
blog.rtrace.io/posts/the-linux-audio-stack-demystified

Большая статья о том, как работает аудиоподсистема в операционных системах Linux — от азов про восприятие звука человеческим ухом, квантования и теоремы Котельникова (она же Найквиста — Шеннона), до сравнения актуальных имплементаций аудио-стека JACK/PulseAudio/PipeWire.