Пишем свой протокол поверх UDP или платформа потокового видео с нуля на миллион онлайнов / Александр Тоболь (Одноклассники)
0 likes2,882 views
Документ описывает разработку протокола видеостриминга поверх UDP и архитектуру стримингового сервиса Ok Live, который позволяет проводить трансляции в режиме реального времени с минимальной задержкой. Основные аспекты включают проблемы качества видео, своевременности передачи, а также методы их решения, такие как использование различных потоковых протоколов и подходов к кодированию. Также рассматриваются достижения Ok Live в сфере увеличения числа зрителей и улучшения технологии трансляции.
Пишем свой протокол поверх UDP или платформа потокового видео с нуля на миллион онлайнов / Александр Тоболь (Одноклассники)
- 1. Пишем свой протокол поверх UDP или платформа потокового видео с нуля на миллион онлайнов Александр Тоболь
- 2. 2 Live Timeline 1949 Первая передвижная телевизионная станцая (ПТС) в МСК март 2015 Запустился Periscope январь 2016 Тест Одноклассниками Periscope в высокогорье июнь 2016 OK Live OK Live ноябрь 2016 Insta Live март 2017 Стрим с высокогорья из OK Live
- 3. 3 Арихитектура и ТЗ без них нельзя вести разработку
- 5. Что НЕ хочет пользователь5 ЖДАТЬ Старта трансляции
- 6. Что НЕ хочет пользователь6 Низкое Качество Видео трансляции
- 7. Заголовок Видео: ok.ru/video/402843570592, автор Pladform 7 Что НЕ хочет пользователь ЗАДЕРЖКИ Между стримером и зрителем Итак, с лесной опушки наш специальный корреспондент – Роман!… Роман?!Так! Слушайте, Роман, я не понимаю, о чем вы говорите! Скажите, вы сейчас находитесь в лесу?…Татьяна?!… … …?!… … … ?!
- 8. Протоколы стриминга8 SMOOTH RTMP RTMFM MPEG-DASH HLS WebRTC OKMP MPEG-TS RTSP/RTP ?
- 9. 9 Конкуренты или с чего начать
- 10. Periscope10 RTMP RTMP HLS "Our video streaming engine is powered by Wowza. So all of the broadcasting and all the consuming is going through this service called Wowza.” —Sara Haider, Periscope Engineering Lead
- 11. Старт, качество, задержка11 600 px 12 sec качество задержка <1 старт sec
- 13. 13 Причины задержки и ее лечение профилируем стриминг видео
- 14. Причины задержки14 видеопамять encoder socket buffer камера сеть socket buffer decoder encoder socket buffer buffer 1 Кодирование/ декодирование 2 Сеть/протокол
- 16. Быстрое транскодирование16 1 Убираем b-frame ставим профайл baseline 2 Уменьшаем длину ссылки до предыдущего кадра Тюним кодек 3 Постоянный битрейт Включаем CBR 4 H264 Server ставим zerolatency
- 18. 18 Потоковые протоколы сложный стриминг 1 к N
- 19. RTMP и мобильный Интернет19
- 20. Потоковые протоколы 1 к N20 RTMP Low Q Low Q HD FullHD Low Q HD FullHD RTMP с нарезкойFull HD
- 22. TCP-стриминг: buffer22 1 Отсутствие управления буфером 2 Нет приоритезации A A HD HD HD Buffer A A SD SD SD Codec
- 23. Мобильные сети23 0.1 % 300 ms avg packet loss avg RTT 1.1 avg bandwidth Mbit/s mts.arm >3% packet loss ~600ms RTT
- 24. TCP–стриминг: packet loss24 Отказать 1-3% потерь на беспроводных сетях – это норма!
- 25. WebRTC–стриминг25 1 Cоздан для p2p конференций, потребует доработок для стриминга 1 к N 2 Шифрует весь поток данных, что, для броадкаст стриминга зря и нагружает CPU Отказать
- 26. RTP–стриминг26 I-D.ietf-avtcore-rtp-multi-stream ref-I-D.ietf-avtcore-multi-media-rtp-session I-D.ietf-avtcore-rtp-multi-stream-optimisation draft-ietf-rtcweb-security-arch-11 rfc3711, rfc5124, rfc7007, rfc5506 ,rfc4961 rfc7164, rfc5104, rfc4585, rfc60519, rfc6464 rfc6904 (https://bugs.chromium.org/p/webrtc/issues/ detail?id=3411) I-D.ietf-mmusic-sdp-bundle-negotiation draft-ietf-rtcweb-video-06 rfc4585: NACK и retransmit. I-D.ietf-rtcweb-fec - FEC I-D.ietf-rmcat-cc-requirements I-D.ietf-avtcore-rtp-circuit-breakers - congestion control Отказать
- 28. MPEG-Dash28 bandwidth time http:// example.com/ manifest.mpd data 2 data 2 data 2 data N … … … … … … 144p 720p 2160p data N data N data 1 data 1 data 1 data k data k data k Fragmented MP4
- 29. HLS - Http Live Streaming29 http://example.com/ high000.ts MPEG2 Transport stream http://example.com/ high001.ts http://example.com/ high002.ts http://example.com/ lowest.m3u8 http://example.com/ low.m3u8 http://example.com/ medium.m3u8 http://example.com/ high.m3u8 http://example.com/ video.m3u8
- 30. Проблемы HLS30 … …HLS 1.ts 2.ts k.ts N.ts MPEG2-TS …188 bytes 188 bytes 188 bytes 188 bytes Header 184 bytes4 bytes 40Гбит/сек по 188байт пакет = 26 млн пакетов в сек Fragmented MP4
- 31. Фрагментный стриминг31 1 2 Быстрый старт Задержка на длину сегмента Можно выдавать сегмент на лету, но старт всегда с опорника 3 Отказать
- 32. Сложность vs задержка32 t Complexity Latency WebRTC RTMP HLS Dash
- 33. Подождем решение?33 UDP–протокол для стриминга 1 к N с задержкой, сравнимой с p2p, с опциональным шифрованием на уровне пакетов
- 34. Пилим свой UDP–протокол — OKMP34 Многопоточность Приоритезация потоков Опциональное шифрование на уровне пакетов для потока 1 3 4 Опциональная гарантия доставки 2
- 35. Качество vs задержка vs реальность vs задержка35 Quality Latency Network t Latency WebRTC RTMP HLS DASHOKMP Quality
- 36. 36 Разработка пилим свой UDP-протокол видеостриминга
- 37. 37 2.5 % 1000 ms0.2 Mbit/s EGDE Мобильные сети EDGE/3G/LTE/WIFI 0.5 % 600 ms1.0 Mbit/s 3G 0.7 % 220 ms2.0 Mbit/s LTE 0.5 % 110 ms2.2 Mbit/s WIFI
- 38. Пишем UDP-протокол38 int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); sendto(s, buffer, strlen(buffer) + 1, 0, (struct sockaddr*)&sa, sizeof(struct sockaddr_in)); 1 1 2 sendto(s, buffer, strlen(buffer) + 1, 0, (struct sockaddr*)&sa, sizeof(struct sockaddr_in)); 2 сеть
- 39. UDP. Pacer39 100% 98,40% 85,60% 1 6 11 16 21 PACER NO PACER
- 40. UDP. Packet Loss40 1–3% потерь на беспроводных сетях — это норма!
- 41. Packet Loss: fast retransmit41 Client Server pkt 1 pkt 2 ack 2 ack 3 ack 1 fast retransmit + нет избыточности – retransmit period pkt 3 packet drop pkt 3 retransmit period
- 42. Retransmit period: jitter42 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 50 ms avg jitter 117ms to 132ms = 15ms 132ms to 176ms = 44ms 176ms to 225ms = 79ms (14 + 44 + 79) / 3 = 46ms
- 43. Fast retransmit: retransmit period (rfc6298)43 RTT retransmit period = RTT + Δ 15 % avg jitter/RTT t0
- 44. Packet Loss: fast speculative retransmit44 Client Serverack 2 ack 3 pkt 3 packet drop pkt 3 retransmit period fast retransmit – проблема со сходимостью например, потеря 5% приводит к лишнему RTT каждые 400 пакетов 400 пакетов * 0.05 * 0.05 = 1 1 fast speculative retransmit + избыточность только при потере пакетов – нет лишних RTT 2 speculative retransmit pkt 3 pkt 3 packet drop retransmit period pkt 4 ack 4
- 45. Forward Error Correction45 … + K FEC – избыточность + Zero RTT P XOR …… … K Reed-Solomon codes N PP а если пропадет несколько пакетов? а если пропадут все пакеты?
- 46. Packet Loss: negative acknowledgement — NACK46 Client Server pkt 1 pkt 2 pkt 4 nack 4 pkt 4 packet drop RTT NACK + прост в реализации + совместим с FEC – можно потерять сам NACK pkt3 pkt5
- 47. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Packet gap47 6 пакетов avg packet gap
- 48. 48 2.5 % 105 ms17 gap EGDE GAP size/Packet loss/Gap duration 0.5 % 24 ms8 gap 3G 0.7 % 29 ms7 gap LTE 0.5 % 22 ms5 gap WIFI
- 49. FEC+NACK vs Fast Retransmit49 <10пакетов 90% packet loss 25 ms packet gap duration FEC + NACK Fast retransmit ?
- 50. FEC + NACK50 1Mb/sec 1% packet loss 300ms RTT 1000byte Packet size 1000packet/sec 10 P P… … 10 1010 FEC: 500 пакетов : 500ms FastRetransmit: RTT + data : 310ms NACK: RTT + data : 310ms
- 51. Fast Retransmit51 1Mb/sec 1% packet loss 300ms RTT 1000byte Packet size 1000packet/sec Client Serverpkt 1 pkt 2 ack 2 pkt 3 pkt 14 ack 15 retransmit period 10 packets drop pkt 13 pkt 15 pkt 3 pkt 13 350 ms retransmit period 25 ms packet gap duration
- 52. UDP. Pacer и packet drop52 IPB tt > tdrop BIP
- 53. 1100 4001100 1 2 MTU: IP fragmentation53 сеть 1500 1500 Header 4 bytes DataHeader
- 54. MTU discovery54 int val = IP_PMTUDISC_DO; setsockopt(fd, IPPROTO_IP, IP_MTU_DISCOVER, &val, sizeof(val)); //выставляем пакетам флаг DF 256 bytes MTU of Network Interface set packet size 1500 bytes 1100 4001100 1 2 1100 4001100 1 2 set packet size 1100 bytes 1100 11001100 1100 11001100
- 55. MTU distribution55 ~1100bytes AVG MTU of OKLive users
- 56. Шифрование56 1 Шифрование заголовков или всех данных Diffie-Hellman Адаптирован к потере пакетов2 AES-256
- 57. Приоритезация57 Данные Приоритет Гарантия доставки Шифрование Метадата Высокий Гарантирована Включено Аудио Средний < 500* мс Опционально Видео Низкий < 300* мс Опционально t t > t drop IPBBI AAA M t
- 59. UDP availability59 7 % no UDP available 1 VOIP (webRTC) 2 QUIC 3 Игры
- 60. ДА!60 1 Задержка снизилась до 1 сек 2 Нет накопительного эффекта задержки в плохих сетях 3 Снизилось кол-во stall’ов 4 FullHD
- 62. Задержка < 1сек62 27:28 27:03 26:34 25 ms 690 ms
- 63. Стриминг на ОК и протоколы63 OKMP RTMP WebRTC
- 64. WebRTC 2 RTMP64 OPUS AAC https://github.com/Blooof/FFmpeg/commit/4e3f764
- 67. Отказоустойчивость и балансировка67 Storage RTMP OKMP WebRTC Upload Transform … … Download
- 68. 68 Продукт что получилось и как применилось
- 69. 69 OK Live — мобильное приложение для выхода в прямой эфир
- 70. 70 Прямой эфир Full HD Android Action Camera Live Full HD
- 71. Прямая линия с Президентом РФ и вопросы71
- 72. OKLive цифры72 2 тыс 3 млн 30 млн онлайн стримов установок просмотров
- 73. 73 Просмотры прямых эфиров на ОК просмотров прямых эфиров х3 апрель 2017 октябрь 2017 Просмотры прямых эфиров
- 74. OKLive хранение записей стримов74 50 тыс +17 TB/ сутки +1 PB стримов в сутки записей стримов всего видео в месяц
- 75. Что получили МЫ75 гарантию задержки между стримером и зрителями1 непрерывный стриминг даже при потере части оборудования 2 балансировка нагрузки во время популярных3 стриминг в FullHD на динамично меняющемся мобильном Интернет-канале 4
- 76. Что узнали ВЫ76 что такое видео и как его стримить1 как писать свой UDP-протокол2 архитектура стримингового сервиса3