Как да организираме стрийминг услуга с минимално забавяне
Добър вечер на всички! Кажете ми кой път да копая, когато задачата е да направя услуга за поточно видео с минимално забавяне.
от последната точка на кодиране до зрителя, получаващ: Youtube: 12-15 секунди латентност живо предаване: 22-26 секунди (чрез iOS приложения 35-40 секунди) ustream: 11-12 секунди (чрез iOS приложение
15-20 сек) Това са действителните забавяния, които тествахме. Първата цифра през кабела в бука, до разпределителната точка е по-малко от 40ms във всички случаи (ping)
Това е твърде дълго, отнема 2-5 секунди. И като се вземат предвид разходите за платени тарифи (ustream / livestream) - те решиха да инвестират в своите железни части
Схема от камерата до последната точка на кодиране:
Първо, малък въпрос - не е напълно ясно защо имате нужда от тази стъпка? > 5. H.264 HW енкодер По време на възпроизвеждане, декодирането се извършва посредством платформата - операционна система или браузър, в зависимост от местоположението.
За веригата като цяло закъсненията които си мерил - до момента на възпроизвеждане ли е? Изглежда така. Това е така, защото, първо, най-вероятно използва HLS или MPEG-DASH на изхода, плюс самата платформа налага определени забавяния.
Постъпихте правилно, като решихте да създадете своя собствена - платформите с общо предназначение няма да работят за вашата задача.
Разгледайте тази статия в нашия блог, където споделяме някои подробности за решение с ниска латентност с разрешението на един от нашите клиенти. Мисля, че част от това ще ви бъде полезно. Като начало, просто използването на RTMP вместо HLS вече значително ще намали латентността.
Ще има въпроси - пишете.
Между другото, с 1080p изходен поток вероятно ще ви трябва и транскодер.
5 точка е необходима, защото на етапа на възпроизвеждане и редактираненасложен текст / графика / и друга мишура, която по същество минава през софтуера и изисква окончателно кодиране
Да, мерих преди да играя. Снима се и брои приблизително с пръсти
alexsocute: По принцип не забравяйте да използвате RTMP или RTSP като протокол - те дават минимално ниво на забавяне по време на предаване и възпроизвеждане.
Източник >> Сървър за получаване на поток >> Сървъри за разпространение (прокси)В този случай получаващият сървър изпраща само един по един, следователно, към сървърите за разпространение в рамките на същия център за данни. Ясно е, че сървърът за получаване на потока трябва да е по-мощен, защото най-вероятно ще трябва да намали качеството на 720p/480p на него, така че зрителите да могат да избират в точката на разпространение (не мисля, че превръщането на един поток в 3 е наистина трудна задача за сървър със средна цена. Но нека бъде по-мощен)
alexsocute: Закъснението от 10 секунди вероятно вече не е свързано със самия протокол, а с техния двигател - както на приемащите възли, така и на разпределителната мрежа. За да разпределят товара, те са принудени да направят компромис със скоростта.
Що се отнася до HLS, всичко зависи от дължината на парчетата и поведението на играча. Оптималният размер за предаване на живо е 2-3 секунди. Можете да прочетете за избора на тази дължина тук: https://bitmovin.com/mpeg-dash-hls-segment-length/
Във всеки случай желая просперитет на вашата услуга. Може би ще намерите нещо полезно в моя преглед
И още по темата: Ще намерим най-добрия начин (и май е базиран на NODEJS и embed tag) да направим реално забавяне от 1-2 секунди, пак ще пиша тук.
Благодаря отново за мислите и връзките.
1. Пристъпихме към балансиране няколко пъти и се спряхме на подхода, описан тук: blog.wmspanel.com/2015/02/hls-dash-media-streaming.Балансиращият арбитър взема текущото състояние на всички сървъри чрез API и на базата на тази информация взема решение - кой къде да изпрати. Около това можете да изградите произволна бизнес логика, която с цялото си желание не може да бъде внедрена от страна на медийния сървър.
2. Терминът Transcoder в средата на софтуерните решения отдавна е утвърден, не съм го измислил аз :) Хардуерните системи имат свои собствени подходи и термини - имат своя собствена микровселена :)
Пишете, ако намерите интересно решение за вашия случай.