Upload
max-lapshin
View
1.219
Download
3
Embed Size (px)
Citation preview
Трансляция видеов интернете
Макс Лапшин[email protected]://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