Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Devpoint2 video in internet

1.699 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Devpoint2 video in internet

  1. 1. Трансляция видео в интернете в интернете <ul><li>Макс Лапшин </li></ul><ul><li>[email_address] </li></ul><ul><li>http://erlyvideo.org / </li></ul>
  2. 2. Требования к видео
  3. 3. Требования к видео <ul><li>Получше качество </li></ul>
  4. 4. Требования к видео <ul><li>Получше качество </li></ul><ul><li>Пониже битрейт </li></ul>
  5. 5. Требования к видео <ul><li>Получше качество </li></ul><ul><li>Пониже битрейт </li></ul><ul><li>Поменьше задержка от прямого эфира </li></ul>
  6. 6. Выберите два пункта?
  7. 7. Нет, надо все три
  8. 8. Как уменьшить битрейт, повысив качество? повысив качество?
  9. 9. Улучшение качества и снижение битрейта — вопрос к кодекам
  10. 10. Обратить внимание на: <ul><li>H.264 — MPEG-LA. Платный, с внятной схемой лицензирования. </li></ul><ul><li>VP8 — Google. Обещают свободу от патентов. </li></ul>
  11. 11. Как работает видеокодек?
  12. 12. 25 раз в секунду захватывается сырое изображение с матрицы
  13. 18. 1 секунда из жизни эмигранта занимает 9 MB сырых кадров
  14. 19. В сжатом виде 20 KB
  15. 20. Видео разрезается на GOP-ы
  16. 21. GOP — Group Of Pictures
  17. 22. В начале GOP-а идет I-Frame
  18. 23. I-Frame — по сути JPEG из сырого кадра
  19. 24. За ним идут P-Frame
  20. 25. Основная магия сжатия в Motion Vector Motion Vector
  21. 27. CPU тратится на вычисление движений в кадре
  22. 28. Нет возможности ускорить аппаратно
  23. 29. Размер кадра снижается с 230KB вплоть до 35 байт
  24. 30. Невозможно перемотать на произвольный кадр
  25. 31. Проблема контейнеров <ul><li>Либо потоковая запись: flv </li></ul><ul><li>Либо перемотка в файле: mp4 </li></ul>
  26. 32. После записи потока требуется постпроцессинг
  27. 33. Оптимальный вариант: паковать в mp4 паковать в mp4
  28. 34. Уменьшение каждого кадра: конфиг декодера
  29. 35. В FLV и VP6 дублирование достигает 25% от кадра
  30. 36. В H.264 это исправлено, вынесением наружу
  31. 37. Поток нельзя воспроизвести без конфига декодера
  32. 38. Мультибитрейт
  33. 39. Один файл/поток кодируется несколько раз
  34. 40. Для деградации потока надо: <ul><li>Что бы совпадали конфиги декодеров у видео разного качества </li></ul><ul><li>Дождаться I-Frame на видеопотоке нужного качества </li></ul><ul><li>Переключить клиента на щадящий битрейт </li></ul><ul><li>Молиться, что бы видеопотоки были синхронизированы </li></ul><ul><li>А как поднять обратно? </li></ul>
  35. 41. Есть изыскания по однократному сжатию с мультибитрейтом
  36. 42. Как же уменьшать задержку?
  37. 43. Источники задержки <ul><li>Задержка кодирования </li></ul><ul><li>Задержка транспорта </li></ul><ul><li>Буфер у клиента </li></ul><ul><li>Декодирование </li></ul>
  38. 44. libx264 умеет отдавать кодированные кадры через 30 мс кадры через 30 мс
  39. 45. Можно играть в игры через видеопоток
  40. 46. В ближайшее время будет использоваться на практике
  41. 47. Пытаются передавать видео по UDP вместо TCP
  42. 48. Голова поворачивается, уши остаются уши остаются
  43. 49. Проблема не-TCP каналов: чем замещать нехватающую информацию? чем замещать нехватающую информацию?
  44. 50. Работающая практика: <ul><li>Звук замещать тишиной </li></ul><ul><li>Видео предыдущим кадром, если есть время на пережатие </li></ul>
  45. 51. Хочется иметь видеокодек, проставляющий QoS метки пакетам
  46. 52. Транспорт в видеотелефонах должен был бы уметь перезапрашивать кадры по UDP
  47. 53. Мало кто умеет
  48. 54. Плотность информации в видеопотоке диктует выбор TCP диктует выбор TCP
  49. 55. Каким транспортом доставлять?
  50. 56. Файлы <ul><li>Самый надежный и простой транспорт </li></ul><ul><li>Нет отчета о доставке и просмотре </li></ul><ul><li>Большая задержка </li></ul><ul><li>Apple HTTP Live Streaming — очень плохой протокол </li></ul><ul><li>Microsoft Smooth Streaming — годный протокол </li></ul>
  51. 57. MPEG-TS <ul><li>Идет со спутника </li></ul><ul><li>Работает без IP сетей </li></ul><ul><li>Может в себе нести что угодно </li></ul><ul><li>Огромные издержки на контейнер: до 25% </li></ul><ul><li>Поддерживает мультикаст </li></ul><ul><li>Используется для IP-TV из-за мультикаста </li></ul>
  52. 58. RTSP <ul><li>Близок к SIP-у (тот же транспорт для контента) </li></ul><ul><li>По сути остался для мобильников </li></ul><ul><li>Ютуб раздает этим протоколом видео на мобильники </li></ul><ul><li>Отмирает </li></ul>
  53. 59. RTMP <ul><li>Дизайн протокола по принципу надстройки курятника </li></ul><ul><li>Закрытый </li></ul><ul><li>Поддерживается флешем </li></ul><ul><li>Основной способ доставить прямую трансляцию в интернете </li></ul><ul><li>Есть наработки по Peer-to-peer: RTMFP </li></ul><ul><li>RTMFP уже взломан, в течении года расползется код </li></ul>
  54. 60. HTML5 <video>
  55. 61. Разброд и шатание
  56. 62. Реалии тега <video> <ul><li>Опера и Firefox не хотят покупать H.264 </li></ul><ul><li>Apple не видит смысла в VP8 </li></ul><ul><li>Гугл пропихивает всем VP8, доставляющийся по WEBM (Matroska) </li></ul><ul><li>Microsoft готов согласиться со всеми </li></ul><ul><li>VP8 ощутимо хуже H.264 </li></ul><ul><li>Остальной IT мир только в процессе миграции на H.264 </li></ul><ul><li>Возможно получится два основных кодека: общий и «для веба» </li></ul>
  57. 63. Что творится на клиенте?
  58. 64. Буферизация видео <ul><li>Сглаживает неравномерность скорости сети </li></ul><ul><li>Увеличивает задержку </li></ul><ul><li>Непросто подобрать размер буфера </li></ul><ul><li>Хорошее правило: буфер размером в GOP </li></ul>
  59. 65. Декодирование <ul><li>Пожалуй, самая развитая часть видеотракта </li></ul><ul><li>Аппаратная поддержка </li></ul><ul><li>Хорошие результаты даже на маломощных телефонах </li></ul>
  60. 66. Что же использовать сегодня <ul><li>Adobe Flash Media Live Encoder или Wirecast для захвата видео в интерактивном режиме </li></ul><ul><li>VLC для транскодирования </li></ul><ul><li>RTMP сервер </li></ul><ul><li>Флеш для доставки пользователю </li></ul><ul><li>HTTP Live Streaming, если есть пользователи с iPad-ами </li></ul><ul><li>RTSP на мобильные телефоны </li></ul>
  61. 67. Проблемы при трансляции <ul><li>Очень сложно выбрать нужный пользователю битрейт </li></ul><ul><li>Сильные флукуации качества канала </li></ul><ul><li>На сервере сложно узнать, видно видео или нет </li></ul><ul><li>Корпоративные прокси мешают RTMP/RTSP </li></ul><ul><li>Комфорт от просмотра живой трансляции гарантированно ниже, чем от скачанных с торрентов фильмов </li></ul>
  62. 68. Выводы <ul><li>Видеокодеки подошли к порогу оптимизируемости живым человеком </li></ul><ul><li>Впереди основательная проработка инфраструктуры: мультибитрейт, QoS и т.п. </li></ul><ul><li>С транспортами видео вавилонское столпотворение: будут развиваться HTTP способы доставки </li></ul><ul><li>Пока что целиковые файлы или поток по RTMP + HLS </li></ul>
  63. 69. Вопросы? <ul><li>Макс Лапшин </li></ul><ul><li>[email_address] </li></ul><ul><li>http://erlyvideo.org / </li></ul>

×