Comments 32
UFO just landed and posted this here
Спасибо за фидбек.
Какие именно детали интересуют?
Про хайлоуд речи не шло, речь о высокой производительности, а не о высоких нагрузках.
Битрейт потоков был разный, на максимуме — 3.2Мбит/с, HD насколько помню.
Задержку мерял клиент, у него свои методы. А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Насчёт придуманных техник — я не писал, что мы что-то придумали. Мы показываем, как можно существующие техники применить, они совсем не очевидны местами.
По пунктам.
1. ОК, возможно про 1мс погорячился, но разница с пару мс тут не существенна для данной задачи.
2. Насчёт аппаратов не соглашусь — если алгоритм кодирования зашит в железо, это по определению будет быстрее софтового решения на базе десктопной ОСи.
4. Вариантов масса, у меня нет цели рассказать про все. Описан конкретный сценарий, где речи про udp вообще не может идти. Описание разницы в работе протоколов займёт не одну отдельную статью. Да, ты тоже любим MPEG-TS, у нас в сервере он реализован в самых разнообразных кейсах. Но повторюсь — мы описали конкретный сценарий, который неплохо показывает целый класс подобных задач, и там ему места не нашлось.
5. Про кеш плеера также написано, и конкретных цифр нет именно потому, что нужно считать их исходя из конкретной ситуации и настроек энкодера.
6. Не знал, спасибо за инфу.
По итогу всё равно вышло, что бОльшая часть задержки связана с конкретными шагами, которые клиент и «докрутил». Теле-оборудование на их площадках, видимо также заточено под большую скорость работы.
Что до геймеров — у них своя специфика, что-то применимо взаимно, что-то нет. Будет интересно почитать статьи и про их подходы к уменьшению.
Какие именно детали интересуют?
Про хайлоуд речи не шло, речь о высокой производительности, а не о высоких нагрузках.
Битрейт потоков был разный, на максимуме — 3.2Мбит/с, HD насколько помню.
Задержку мерял клиент, у него свои методы. А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Насчёт придуманных техник — я не писал, что мы что-то придумали. Мы показываем, как можно существующие техники применить, они совсем не очевидны местами.
По пунктам.
1. ОК, возможно про 1мс погорячился, но разница с пару мс тут не существенна для данной задачи.
2. Насчёт аппаратов не соглашусь — если алгоритм кодирования зашит в железо, это по определению будет быстрее софтового решения на базе десктопной ОСи.
4. Вариантов масса, у меня нет цели рассказать про все. Описан конкретный сценарий, где речи про udp вообще не может идти. Описание разницы в работе протоколов займёт не одну отдельную статью. Да, ты тоже любим MPEG-TS, у нас в сервере он реализован в самых разнообразных кейсах. Но повторюсь — мы описали конкретный сценарий, который неплохо показывает целый класс подобных задач, и там ему места не нашлось.
5. Про кеш плеера также написано, и конкретных цифр нет именно потому, что нужно считать их исходя из конкретной ситуации и настроек энкодера.
6. Не знал, спасибо за инфу.
По итогу всё равно вышло, что бОльшая часть задержки связана с конкретными шагами, которые клиент и «докрутил». Теле-оборудование на их площадках, видимо также заточено под большую скорость работы.
Что до геймеров — у них своя специфика, что-то применимо взаимно, что-то нет. Будет интересно почитать статьи и про их подходы к уменьшению.
> Какие именно детали интересуют?
Я повторю вопрос в G+: методика измерения задержки :) Или это ноу-хау заказчика и вы не в курсе?
> А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Если это и есть техника, то довольно забавно, что практически у всех сходится к:
— Все машины точно или почти точно синхронизированы по времени
— Часы на источнике (или метка прямо в поток)
— Приёмник просто делает срезы, сохраняя время оного.
По срезу же потом уже вручную смотрится время среза и время на картинке?
2. Смотря что и как считать аппаратом: Intel QSV это аппаратное кодирование (ну там софтовый бакенд тоже есть, но не про него сейчас)? Для него используются аппаратные блоки GPU, значит аппаратное. Но там тоже можно получить задержки (прикручивал для одних людей к ffmpeg, правда пока прикручивал другие люди сами сделали и заинтегрировали оное в FFmpeg: >= 2.7.1). nVidia NVENC техника тоже может дать задержку. Насколько я понимаю, это особенности алгоритмов сжатия в h264 — там нужно тюнить, в т.ч. параметрами для железа. Конкретно я получался задержку с двумя перекодировками при помощи FFmpeg меньше чем 1 сек (мерили грубо, можно сказать на глаз), цепочка была такая: Камера (5шт) — PC+ffmpeg (5шт) — nginx-rtmp — сервер-обработки(5 входящих потоков и 1 исходящий) — nginx-rtmp — клиент. В исходном варианте латенси была около 10 сек, просто подобрали параметры FFmpeg.
6. Мы с этим на HDMI столкнулись, до 100-200 мс как пить дать задержки дать может. Теперь понимаю, почему VGA до сих пор не умер :)
Я повторю вопрос в G+: методика измерения задержки :) Или это ноу-хау заказчика и вы не в курсе?
> А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Если это и есть техника, то довольно забавно, что практически у всех сходится к:
— Все машины точно или почти точно синхронизированы по времени
— Часы на источнике (или метка прямо в поток)
— Приёмник просто делает срезы, сохраняя время оного.
По срезу же потом уже вручную смотрится время среза и время на картинке?
2. Смотря что и как считать аппаратом: Intel QSV это аппаратное кодирование (ну там софтовый бакенд тоже есть, но не про него сейчас)? Для него используются аппаратные блоки GPU, значит аппаратное. Но там тоже можно получить задержки (прикручивал для одних людей к ffmpeg, правда пока прикручивал другие люди сами сделали и заинтегрировали оное в FFmpeg: >= 2.7.1). nVidia NVENC техника тоже может дать задержку. Насколько я понимаю, это особенности алгоритмов сжатия в h264 — там нужно тюнить, в т.ч. параметрами для железа. Конкретно я получался задержку с двумя перекодировками при помощи FFmpeg меньше чем 1 сек (мерили грубо, можно сказать на глаз), цепочка была такая: Камера (5шт) — PC+ffmpeg (5шт) — nginx-rtmp — сервер-обработки(5 входящих потоков и 1 исходящий) — nginx-rtmp — клиент. В исходном варианте латенси была около 10 сек, просто подобрали параметры FFmpeg.
6. Мы с этим на HDMI столкнулись, до 100-200 мс как пить дать задержки дать может. Теперь понимаю, почему VGA до сих пор не умер :)
По измерениям — всё так и есть, между машинами максимальная синхронизация.
Вообще, как и во многих других вещах по этой задаче, всё исходит из разумной необходимости. Например, если даже часы будут расходиться на 1 мс — да и ладно, время реакции человека всё равно на порядки больше. Поэтому после выведения лейтенси за величину 500 мс все дополнительные приседания уже были лишними. Это не операции на мозге через теле-управление, утаскивать показатель вниз на очередные — 100 мс уже излишество, которое не окупится.
2. Тут речь больше о том, что не стоит юзать вещи типа FMLE или облачные энкодеры. Понятно, что можно и ffmpeg затюнить за безобразия, сделать уникальную сборку яра линукса и самого ффпмег под конкретное железо и получить ещё 100 мс выигрыша. Вопрос — сколько это займёт времени и, как следствие, денег. Тут важно вовремя остановиться :)
6. Идеальных решений не бывает, чего уж там.
Вообще, как и во многих других вещах по этой задаче, всё исходит из разумной необходимости. Например, если даже часы будут расходиться на 1 мс — да и ладно, время реакции человека всё равно на порядки больше. Поэтому после выведения лейтенси за величину 500 мс все дополнительные приседания уже были лишними. Это не операции на мозге через теле-управление, утаскивать показатель вниз на очередные — 100 мс уже излишество, которое не окупится.
2. Тут речь больше о том, что не стоит юзать вещи типа FMLE или облачные энкодеры. Понятно, что можно и ffmpeg затюнить за безобразия, сделать уникальную сборку яра линукса и самого ффпмег под конкретное железо и получить ещё 100 мс выигрыша. Вопрос — сколько это займёт времени и, как следствие, денег. Тут важно вовремя остановиться :)
6. Идеальных решений не бывает, чего уж там.
UFO just landed and posted this here
Жать один поток это не высокая производительность, даже по меркам одного десктопа :)
Не просто пожать, а доставить с минимальной задержкой. Вы путаете нагрузку и производительность, это не всегда одно и то же.
Сам лично гонял UDP с Иркутска в Иркутск через Москву,
Кто ж спорит, можно и на UDP построить, даже у нас во Владе бывают удачные дни, без перебоев и с хорошим пингом. Но в конкретном случае нашего клиента UDP не ехал.
Не извращайтесь, браузер для просмотра текстов и картинок,
Расскажите это Ютюбу и многочисленным онлайн-кинотеатрам, например.
Я бы такое на udp протоколах начал бы делать.
т.е. live streaming в браузер с приемлемой задержкой ( < 1 c) для h.264 все еще невозможен.
Теоретически возможен, но уже на грани. Всё от постановки задачи зависит. Если работа идёт в рамках одной сети (например, корпоративной), то почему бы и нет.
Задача стандартная: отображение информации с камер видео-наблюдения в веб-браузере.
Что можно использовать в качестве контейнера для отображения h.264 потока? Для HLS задержка даже еще выше чем для flash проигрывателей.
Что можно использовать в качестве контейнера для отображения h.264 потока? Для HLS задержка даже еще выше чем для flash проигрывателей.
Сразу вопрос — насколько вообще в таком сценарии нужна задержка меньше секунд? Если зритель находится не на охраняемом объекте, то и 1-2 секунды вполне покроют требования. Если же он рядом, там вполне можно добиться всё той же 1 секунды и даже меньше.
В любом случае можно рассмотреть вариант RTMP (т.е. Flash-based плееры).
Если хочется HLS (для iOS/Android), то от него можно добиться 3-4 секунды задержки. Это, опять же, не сильно повлияет на ряд сценариев в вашем случае.
В любом случае можно рассмотреть вариант RTMP (т.е. Flash-based плееры).
Если хочется HLS (для iOS/Android), то от него можно добиться 3-4 секунды задержки. Это, опять же, не сильно повлияет на ряд сценариев в вашем случае.
в webrtc возможно предположительно почти возможен.
Во флеше очень всё плохо, потому что насколько я помню во флеше до сих пор не убрали багу, которая в режиме zero delay начинает накапливать delay до повисания флеш-плагина
Во флеше очень всё плохо, потому что насколько я помню во флеше до сих пор не убрали багу, которая в режиме zero delay начинает накапливать delay до повисания флеш-плагина
В WebRTC более чем возможен, скоро мы в VoxImplant найдем время заняться стриммингом и это постараемся доказать :)
А rtmfp вы пробовали?
Пробовали, тут не только в протоколе вопрос, а еще в самом движке. Во Flash он сильно хуже.
AEC то в webrtc планируется?
Он уже там давно есть, вот вам шпаргалка iswebrtcreadyyet.com
Протокол передачи данных нужно выбирать исходя из возможностей энкодера и медиа-сервера, который будет раздавать данные конечным пользователям. Для передачи видео в реальном времени наиболее подходят RTSP, RTMP или MPEG2-TS.MPEG-TS это контейнер, а не протокол.
Если собираетесь использовать протоколы на базе HTTP, например HLS или MPEG-DASHВы вполне себе можете гонять видео через HTTP, не используя дополнительный протокол для этого.
MPEG-TS это контейнер, а не протокол
Да, это контейнер. Но в данном случае с точки зрения энкодера это фактически один из протоолов передачи.
Вы вполне себе можете гонять видео через HTTP, не используя дополнительный протокол для этого.
Для VOD это правда, можно использовать progressive download. Но как вы собираетесь делать это для живого видео? MPEG-TS поверх HTTP? Боюсь клиентский софт его не поймёт, кроме VLC, разве что.
Но в данном случае с точки зрения энкодера это фактически один из протоолов передачи.Вероятно, вы заблуждаетесь. С чего бы ему быть протоколом? Вы вполне можете вещать в любом другом контейнере.
MPEG-TS поверх HTTP? Боюсь клиентский софт его не поймёт, кроме VLC, разве что.Да. Насколько я знаю, абсолютно любой видеоплеер такое воспроизводить умеет, раньше это был стандарт де-факто. Более того, с использованием хаков VLC-муксера можно вещать разные кодеки видео и аудио без перекодировки и без переподключения к потоку. Я так разные видеофайлы вещаю без перекодировки.
Вероятно, вы заблуждаетесь.
Повторю — современные энкодеры могут выдавать H.264/AAC через RTMP, RTSP и MPEG-TS поверх UDP и TCP. Что именно вас смутило?
Насколько я знаю, абсолютно любой видеоплеер такое воспроизводить умеет
Веб-плееры не умеют. Для живых потоков работают: RTMP через Флэш, HLS через Флэш и встренную поддержку браузера, чуть реже — MPEG-DASH, если браузер умеет.
Sign up to leave a comment.
Трансляция онлайн-видео с минимальной задержкой