Трансляция видеов интернете

Макс Лапшинmax@maxidoors.ruhttp://erlyvideo.org/

Требования к видео

Требования к видео

•Получше качество

Требования к видео

•Получше качество

•Пониже битрейт

Требования к видео

•Получше качество

•Пониже битрейт

•Поменьше задержка от прямого эфира

Выберите два пункта?

Нет, надо все три

Как уменьшить битрейт, повысив качество?

Улучшение качества и снижение битрейта —

вопрос к кодекам

Обратить внимание на:

•H.264 — MPEG-LA. Платный, с внятной схемой лицензирования.

•VP8 — Google. Обещают свободу от патентов.

Как работает видеокодек?

25 раз в секунду захватывается сырое

изображение с матрицы

1 секунда из жизни эмигранта занимает 9 MB

сырых кадров

В сжатом виде 20 KB

Видео разрезается на GOP-ы

GOP — Group Of Pictures

В начале GOP-а идет I-Frame

I-Frame — по сути JPEG из сырого кадра

За ним идут P-Frame

Основная магия сжатия в Motion Vector

CPU тратится на вычисление движений в

кадре

Нет возможности ускорить аппаратно

Размер кадра снижается с 230KB вплоть до 35 байт

Невозможно перемотать на произвольный кадр

Проблема контейнеров

•Либо потоковая запись: flv

•Либо перемотка в файле: mp4

После записи потока требуется постпроцессинг

Оптимальный вариант: паковать в mp4

Уменьшение каждого кадра: конфиг декодера

В FLV и VP6 дублирование достигает 25% от кадра

В H.264 это исправлено, вынесением наружу

Поток нельзя воспроизвести без конфига декодера

Мультибитрейт

Один файл/поток кодируется несколько раз

Для деградации потока надо:

•Что бы совпадали конфиги декодеров у видео разного качества

•Дождаться I-Frame на видеопотоке нужного качества

•Переключить клиента на щадящий битрейт

•Молиться, что бы видеопотоки были синхронизированы

•А как поднять обратно?

Есть изыскания по однократному сжатию с

мультибитрейтом

Как же уменьшать задержку?

Источники задержки

•Задержка кодирования

•Задержка транспорта

•Буфер у клиента

•Декодирование

libx264 умеет отдавать кодированные

кадры через 30 мс

Можно играть в игры через видеопоток

В ближайшее время будет использоваться на

практике

Пытаются передавать видео по UDP вместо TCP

Голова поворачивается, уши остаются

Проблема не-TCP каналов:чем замещать нехватающую информацию?

Работающая практика:

•Звук замещать тишиной

•Видео предыдущим кадром, если есть время на пережатие

Хочется иметь видеокодек,

проставляющий QoS метки пакетам

Транспорт в видеотелефонах должен

был бы уметь перезапрашивать кадры

по UDP

Мало кто умеет

Плотность информации в видеопотоке

диктует выбор TCP

Каким транспортом доставлять?

Файлы

•Самый надежный и простой транспорт

•Нет отчета о доставке и просмотре

•Большая задержка

•Apple HTTP Live Streaming — очень плохой протокол

•Microsoft Smooth Streaming — годный протокол

MPEG-TS

•Идет со спутника

•Работает без IP сетей

•Может в себе нести что угодно

•Огромные издержки на контейнер: до 25%

•Поддерживает мультикаст

•Используется для IP-TV из-за мультикаста

RTSP

•Близок к SIP-у (тот же транспорт для контента)

•По сути остался для мобильников

•Ютуб раздает этим протоколом видео на мобильники

•Отмирает

RTMP•Дизайн протокола по принципу надстройки курятника

•Закрытый

•Поддерживается флешем

•Основной способ доставить прямую трансляцию в интернете

•Есть наработки по Peer-to-peer: RTMFP

•RTMFP уже взломан, в течении года расползется код

HTML5 <video>

Разброд и шатание

Реалии тега <video>•Опера и Firefox не хотят покупать H.264

•Apple не видит смысла в VP8

•Гугл пропихивает всем VP8, доставляющийся по WEBM (Matroska)

•Microsoft готов согласиться со всеми

•VP8 ощутимо хуже H.264

•Остальной IT мир только в процессе миграции на H.264

•Возможно получится два основных кодека: общий и «для веба»

Что творится на клиенте?

Буферизация видео

•Сглаживает неравномерность скорости сети

•Увеличивает задержку

•Непросто подобрать размер буфера

•Хорошее правило: буфер размером в GOP

Декодирование

•Пожалуй, самая развитая часть видеотракта

•Аппаратная поддержка

•Хорошие результаты даже на маломощных телефонах

Что же использовать сегодня

•Adobe Flash Media Live Encoder или Wirecast для захвата видео в интерактивном режиме

•VLC для транскодирования

•RTMP сервер

•Флеш для доставки пользователю

•HTTP Live Streaming, если есть пользователи с iPad-ами

•RTSP на мобильные телефоны

Проблемы при трансляции

•Очень сложно выбрать нужный пользователю битрейт

•Сильные флукуации качества канала

•На сервере сложно узнать, видно видео или нет

•Корпоративные прокси мешают RTMP/RTSP

•Комфорт от просмотра живой трансляции гарантированно ниже, чем от скачанных с торрентов фильмов

Выводы

•Видеокодеки подошли к порогу оптимизируемости живым человеком

•Впереди основательная проработка инфраструктуры: мультибитрейт, QoS и т.п.

•С транспортами видео вавилонское столпотворение: будут развиваться HTTP способы доставки

•Пока что целиковые файлы или поток по RTMP + HLS

Вопросы?

Макс Лапшин

max@maxidoors.ru

http://erlyvideo.org/