Документ представляет собой технический обзор трансляции видео в интернете, охватывающий требования к качеству видео, эффективность кодеков, включая h.264 и VP8, и различные протоколы доставки, такие как RTMP и HTTP Live Streaming. В нем обсуждаются проблемы с задержкой видео и буферизацией, а также развития технологий для оптимизации потоковой передачи. Итоговые выводы подразумевают необходимость улучшения инфраструктуры и адаптации к меняющимся стандартам кодирования.

1. Трансляция видео в интернете в интернете Макс Лапшин [email_address] http://erlyvideo.org /

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

3. Требования к видео Получше качество

4. Требования к видео Получше качество Пониже битрейт

5. Требования к видео Получше качество Пониже битрейт Поменьше задержка от прямого эфира

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

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

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

9. Улучшение качества и снижение битрейта — вопрос к кодекам

10. Обратить внимание на: H.264 — MPEG-LA. Платный, с внятной схемой лицензирования. VP8 — Google. Обещают свободу от патентов.

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

12. 25 раз в секунду захватывается сырое изображение с матрицы

18. 1 секунда из жизни эмигранта занимает 9 MB сырых кадров

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

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

21. GOP — Group Of Pictures

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

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

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

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

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

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

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

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

31. Проблема контейнеров Либо потоковая запись: flv Либо перемотка в файле: mp4

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

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

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

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

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

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

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

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

40. Для деградации потока надо: Что бы совпадали конфиги декодеров у видео разного качества Дождаться I-Frame на видеопотоке нужного качества Переключить клиента на щадящий битрейт Молиться, что бы видеопотоки были синхронизированы А как поднять обратно?

41. Есть изыскания по однократному сжатию с мультибитрейтом

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

43. Источники задержки Задержка кодирования Задержка транспорта Буфер у клиента Декодирование

44. libx264 умеет отдавать кодированные кадры через 30 мс кадры через 30 мс

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

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

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

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

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

50. Работающая практика: Звук замещать тишиной Видео предыдущим кадром, если есть время на пережатие

51. Хочется иметь видеокодек, проставляющий QoS метки пакетам

52. Транспорт в видеотелефонах должен был бы уметь перезапрашивать кадры по UDP

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

54. Плотность информации в видеопотоке диктует выбор TCP диктует выбор TCP

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

56. Файлы Самый надежный и простой транспорт Нет отчета о доставке и просмотре Большая задержка Apple HTTP Live Streaming — очень плохой протокол Microsoft Smooth Streaming — годный протокол

57. MPEG-TS Идет со спутника Работает без IP сетей Может в себе нести что угодно Огромные издержки на контейнер: до 25% Поддерживает мультикаст Используется для IP-TV из-за мультикаста

58. RTSP Близок к SIP-у (тот же транспорт для контента) По сути остался для мобильников Ютуб раздает этим протоколом видео на мобильники Отмирает

59. RTMP Дизайн протокола по принципу надстройки курятника Закрытый Поддерживается флешем Основной способ доставить прямую трансляцию в интернете Есть наработки по Peer-to-peer: RTMFP RTMFP уже взломан, в течении года расползется код

60. HTML5 <video>

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

62. Реалии тега <video> Опера и Firefox не хотят покупать H.264 Apple не видит смысла в VP8 Гугл пропихивает всем VP8, доставляющийся по WEBM (Matroska) Microsoft готов согласиться со всеми VP8 ощутимо хуже H.264 Остальной IT мир только в процессе миграции на H.264 Возможно получится два основных кодека: общий и «для веба»

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

64. Буферизация видео Сглаживает неравномерность скорости сети Увеличивает задержку Непросто подобрать размер буфера Хорошее правило: буфер размером в GOP

65. Декодирование Пожалуй, самая развитая часть видеотракта Аппаратная поддержка Хорошие результаты даже на маломощных телефонах

66. Что же использовать сегодня Adobe Flash Media Live Encoder или Wirecast для захвата видео в интерактивном режиме VLC для транскодирования RTMP сервер Флеш для доставки пользователю HTTP Live Streaming, если есть пользователи с iPad-ами RTSP на мобильные телефоны

67. Проблемы при трансляции Очень сложно выбрать нужный пользователю битрейт Сильные флукуации качества канала На сервере сложно узнать, видно видео или нет Корпоративные прокси мешают RTMP/RTSP Комфорт от просмотра живой трансляции гарантированно ниже, чем от скачанных с торрентов фильмов

68. Выводы Видеокодеки подошли к порогу оптимизируемости живым человеком Впереди основательная проработка инфраструктуры: мультибитрейт, QoS и т.п. С транспортами видео вавилонское столпотворение: будут развиваться HTTP способы доставки Пока что целиковые файлы или поток по RTMP + HLS

69. Вопросы? Макс Лапшин [email_address] http://erlyvideo.org /