Повторю — современные энкодеры могут выдавать H.264/AAC через RTMP, RTSP и MPEG-TS поверх UDP и TCP. Что именно вас смутило?
Насколько я знаю, абсолютно любой видеоплеер такое воспроизводить умеет
Веб-плееры не умеют. Для живых потоков работают: RTMP через Флэш, HLS через Флэш и встренную поддержку браузера, чуть реже — MPEG-DASH, если браузер умеет.
Да, это контейнер. Но в данном случае с точки зрения энкодера это фактически один из протоолов передачи.
Вы вполне себе можете гонять видео через HTTP, не используя дополнительный протокол для этого.
Для VOD это правда, можно использовать progressive download. Но как вы собираетесь делать это для живого видео? MPEG-TS поверх HTTP? Боюсь клиентский софт его не поймёт, кроме VLC, разве что.
Жать один поток это не высокая производительность, даже по меркам одного десктопа :)
Не просто пожать, а доставить с минимальной задержкой. Вы путаете нагрузку и производительность, это не всегда одно и то же.
Сам лично гонял UDP с Иркутска в Иркутск через Москву,
Кто ж спорит, можно и на UDP построить, даже у нас во Владе бывают удачные дни, без перебоев и с хорошим пингом. Но в конкретном случае нашего клиента UDP не ехал.
Не извращайтесь, браузер для просмотра текстов и картинок,
Расскажите это Ютюбу и многочисленным онлайн-кинотеатрам, например.
Сразу вопрос — насколько вообще в таком сценарии нужна задержка меньше секунд? Если зритель находится не на охраняемом объекте, то и 1-2 секунды вполне покроют требования. Если же он рядом, там вполне можно добиться всё той же 1 секунды и даже меньше.
В любом случае можно рассмотреть вариант RTMP (т.е. Flash-based плееры).
Если хочется HLS (для iOS/Android), то от него можно добиться 3-4 секунды задержки. Это, опять же, не сильно повлияет на ряд сценариев в вашем случае.
Теоретически возможен, но уже на грани. Всё от постановки задачи зависит. Если работа идёт в рамках одной сети (например, корпоративной), то почему бы и нет.
По измерениям — всё так и есть, между машинами максимальная синхронизация.
Вообще, как и во многих других вещах по этой задаче, всё исходит из разумной необходимости. Например, если даже часы будут расходиться на 1 мс — да и ладно, время реакции человека всё равно на порядки больше. Поэтому после выведения лейтенси за величину 500 мс все дополнительные приседания уже были лишними. Это не операции на мозге через теле-управление, утаскивать показатель вниз на очередные — 100 мс уже излишество, которое не окупится.
2. Тут речь больше о том, что не стоит юзать вещи типа FMLE или облачные энкодеры. Понятно, что можно и ffmpeg затюнить за безобразия, сделать уникальную сборку яра линукса и самого ффпмег под конкретное железо и получить ещё 100 мс выигрыша. Вопрос — сколько это займёт времени и, как следствие, денег. Тут важно вовремя остановиться :)
В данном случае RTMP зарекомендовал себя значительно лучше, чем UDP, — речь всё ж про передачу между разными континентами через сеть с очень неоднородным поведением.
Кроме того, в конце цепочки стоял кастомный плеер, у которого на вход требуется именно RTMP.
Про хайлоуд речи не шло, речь о высокой производительности, а не о высоких нагрузках.
Битрейт потоков был разный, на максимуме — 3.2Мбит/с, HD насколько помню.
Задержку мерял клиент, у него свои методы. А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Насчёт придуманных техник — я не писал, что мы что-то придумали. Мы показываем, как можно существующие техники применить, они совсем не очевидны местами.
По пунктам.
1. ОК, возможно про 1мс погорячился, но разница с пару мс тут не существенна для данной задачи.
2. Насчёт аппаратов не соглашусь — если алгоритм кодирования зашит в железо, это по определению будет быстрее софтового решения на базе десктопной ОСи.
4. Вариантов масса, у меня нет цели рассказать про все. Описан конкретный сценарий, где речи про udp вообще не может идти. Описание разницы в работе протоколов займёт не одну отдельную статью. Да, ты тоже любим MPEG-TS, у нас в сервере он реализован в самых разнообразных кейсах. Но повторюсь — мы описали конкретный сценарий, который неплохо показывает целый класс подобных задач, и там ему места не нашлось.
5. Про кеш плеера также написано, и конкретных цифр нет именно потому, что нужно считать их исходя из конкретной ситуации и настроек энкодера.
6. Не знал, спасибо за инфу.
По итогу всё равно вышло, что бОльшая часть задержки связана с конкретными шагами, которые клиент и «докрутил». Теле-оборудование на их площадках, видимо также заточено под большую скорость работы.
Что до геймеров — у них своя специфика, что-то применимо взаимно, что-то нет. Будет интересно почитать статьи и про их подходы к уменьшению.
Много постов на ресурсах ТМ — это именно новости в разном виде. И если Техкранч читают многие, то о новостях более узконаправленных ниш никогда не узнать, если специально не копать.
По теме также советую посмотреть выступление Роберта Рейнхарда — он сравнивает x265 и x264, и в целом рассказывает про все плюсы и минусы.
В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
Я не вижу смысла в цифрах, достоверность которых стремится к нулю.
Когда некто начинает коммерческое предприятие, он ведь хотя бы приблизительно оценивает рынок? Ведь если этот некто даже 1 тыс. обосновать не может, то как он может обосновать 1 млрд.? «Дайте денег, у меня наверное получится»?
Повторю — современные энкодеры могут выдавать H.264/AAC через RTMP, RTSP и MPEG-TS поверх UDP и TCP. Что именно вас смутило?
Веб-плееры не умеют. Для живых потоков работают: RTMP через Флэш, HLS через Флэш и встренную поддержку браузера, чуть реже — MPEG-DASH, если браузер умеет.
Да, это контейнер. Но в данном случае с точки зрения энкодера это фактически один из протоолов передачи.
Для VOD это правда, можно использовать progressive download. Но как вы собираетесь делать это для живого видео? MPEG-TS поверх HTTP? Боюсь клиентский софт его не поймёт, кроме VLC, разве что.
Не просто пожать, а доставить с минимальной задержкой. Вы путаете нагрузку и производительность, это не всегда одно и то же.
Кто ж спорит, можно и на UDP построить, даже у нас во Владе бывают удачные дни, без перебоев и с хорошим пингом. Но в конкретном случае нашего клиента UDP не ехал.
Расскажите это Ютюбу и многочисленным онлайн-кинотеатрам, например.
В любом случае можно рассмотреть вариант RTMP (т.е. Flash-based плееры).
Если хочется HLS (для iOS/Android), то от него можно добиться 3-4 секунды задержки. Это, опять же, не сильно повлияет на ряд сценариев в вашем случае.
Вообще, как и во многих других вещах по этой задаче, всё исходит из разумной необходимости. Например, если даже часы будут расходиться на 1 мс — да и ладно, время реакции человека всё равно на порядки больше. Поэтому после выведения лейтенси за величину 500 мс все дополнительные приседания уже были лишними. Это не операции на мозге через теле-управление, утаскивать показатель вниз на очередные — 100 мс уже излишество, которое не окупится.
2. Тут речь больше о том, что не стоит юзать вещи типа FMLE или облачные энкодеры. Понятно, что можно и ffmpeg затюнить за безобразия, сделать уникальную сборку яра линукса и самого ффпмег под конкретное железо и получить ещё 100 мс выигрыша. Вопрос — сколько это займёт времени и, как следствие, денег. Тут важно вовремя остановиться :)
6. Идеальных решений не бывает, чего уж там.
Кроме того, в конце цепочки стоял кастомный плеер, у которого на вход требуется именно RTMP.
Какие именно детали интересуют?
Про хайлоуд речи не шло, речь о высокой производительности, а не о высоких нагрузках.
Битрейт потоков был разный, на максимуме — 3.2Мбит/с, HD насколько помню.
Задержку мерял клиент, у него свои методы. А после всех настроек для наглядности демонстрации он пускал изображение часов с миллисекундами, делая срезы в разные моменты времени, довольно занятно получалось
Насчёт придуманных техник — я не писал, что мы что-то придумали. Мы показываем, как можно существующие техники применить, они совсем не очевидны местами.
По пунктам.
1. ОК, возможно про 1мс погорячился, но разница с пару мс тут не существенна для данной задачи.
2. Насчёт аппаратов не соглашусь — если алгоритм кодирования зашит в железо, это по определению будет быстрее софтового решения на базе десктопной ОСи.
4. Вариантов масса, у меня нет цели рассказать про все. Описан конкретный сценарий, где речи про udp вообще не может идти. Описание разницы в работе протоколов займёт не одну отдельную статью. Да, ты тоже любим MPEG-TS, у нас в сервере он реализован в самых разнообразных кейсах. Но повторюсь — мы описали конкретный сценарий, который неплохо показывает целый класс подобных задач, и там ему места не нашлось.
5. Про кеш плеера также написано, и конкретных цифр нет именно потому, что нужно считать их исходя из конкретной ситуации и настроек энкодера.
6. Не знал, спасибо за инфу.
По итогу всё равно вышло, что бОльшая часть задержки связана с конкретными шагами, которые клиент и «докрутил». Теле-оборудование на их площадках, видимо также заточено под большую скорость работы.
Что до геймеров — у них своя специфика, что-то применимо взаимно, что-то нет. Будет интересно почитать статьи и про их подходы к уменьшению.
В целом, судя по отзывам компетентных людей, x265 ещё долго будет получать распространение, сравнимое с x264.
Когда некто начинает коммерческое предприятие, он ведь хотя бы приблизительно оценивает рынок? Ведь если этот некто даже 1 тыс. обосновать не может, то как он может обосновать 1 млрд.? «Дайте денег, у меня наверное получится»?