Comments 53
До сих пор даже Сафари на Винде не умеет играть HLS
Прошу прощения, но я про Safari для винды слышал последний раз в 2012 году. Не похоже, что с тех пор что-то изменилось…
Прочитал момент о «хаке» касательно mp4 fragmented и вспомнил о связанной проблеме, которую когда-то пришлось решать. Медиаконтейнер MPEG-4 Part 14 («в народе» известный как MP4) позволяет указывать общую продолжительность видео как в начале файла/потока, так и в его конце. И если сервер отдаёт браузеру MP4-видеофайл, где продолжительность записана в конце, то браузер вообще не способен выполнять перемотку. То же самое, если пользоваться всякими flash-плеерами типа Uppod. Как раз столкнулись с этим, когда делали свою выдачу MP4-видеофайлов. Для решения проблемы каждый файл проверяли через MP4Box и переносили метаданные в начало. Эта проблема даже имеет своё название — «mp4 faststart». Интересно, связана ли эта проблема как раз с описанным в статье читом mp4 fragmented?
нет, это другое.
faststart — это когда moov атом переносят вначало файла. Для этого надо собрать moov, потом добавить его длину ко всем смещениям и переписать файл.
Современные браузеры вроде умеют пользоваться Range запросами и проигрывают непатченые файлы быстро.
faststart — это когда moov атом переносят вначало файла. Для этого надо собрать moov, потом добавить его длину ко всем смещениям и переписать файл.
Современные браузеры вроде умеют пользоваться Range запросами и проигрывают непатченые файлы быстро.
UFO just landed and posted this here
И, как обычно ничего не сказано о технической стороне вопроса.
Со стороны клиента интересует что конкретно и где поддерживается. Говорят от гугла кодек сжимает получше(в плане качества И размера), но что где поддерживается? Появились ли варианты 100% поддержки?
Со стороны сервера всё гооораздо интереснее если мы говорим о стриминге — как обеспечивать из одного источника несколько разных по качеству видео-аудио дорожек? Допустим я вещаю в 1080р, а у клиента нет такого канала и максимум он может 480р. Как «на лету» делать сразу несколько источников с разным качеством?
Вообщем, поделитесь пожалуйста технической информацией, её было пару лет назад крайне мало и с тех пор не замечал ничего нового по этой теме.
Со стороны клиента интересует что конкретно и где поддерживается. Говорят от гугла кодек сжимает получше(в плане качества И размера), но что где поддерживается? Появились ли варианты 100% поддержки?
Со стороны сервера всё гооораздо интереснее если мы говорим о стриминге — как обеспечивать из одного источника несколько разных по качеству видео-аудио дорожек? Допустим я вещаю в 1080р, а у клиента нет такого канала и максимум он может 480р. Как «на лету» делать сразу несколько источников с разным качеством?
Вообщем, поделитесь пожалуйста технической информацией, её было пару лет назад крайне мало и с тех пор не замечал ничего нового по этой теме.
100% варианта, который работает везде, без js-библиотек или flash-плеера, пока нету, но, как написано в статье, MSE + DASH близки к этому.
Про серверную сторону напишем.
Про серверную сторону напишем.
Если вас интересуют именно технические подробности, то наиболее универсальное решение выглядит так:
Протокол HLS (так как IOS пока не позволяет ничего более)
Контейнер MPEG-TS (так как HLS до недавнего времени поддерживал только его)
Кодеки H264/AAC (так как пересечение в таблице по поддержке кодеков в большинстве браузеров пока такое)
В плееере
1. Если браузе поддерживает HLS (Safari) то Ок
2. Если браузер не поддерживает HLS из «коробки» (не Safari), то пробудем эмулировать HLS через MSE.
3. Если не поддерживается MSE, то пробуем эмулировать через Flash
4. Если нет Flash, то все…
Протокол HLS (так как IOS пока не позволяет ничего более)
Контейнер MPEG-TS (так как HLS до недавнего времени поддерживал только его)
Кодеки H264/AAC (так как пересечение в таблице по поддержке кодеков в большинстве браузеров пока такое)
В плееере
1. Если браузе поддерживает HLS (Safari) то Ок
2. Если браузер не поддерживает HLS из «коробки» (не Safari), то пробудем эмулировать HLS через MSE.
3. Если не поддерживается MSE, то пробуем эмулировать через Flash
4. Если нет Flash, то все…
Плюсую, недавно участвовал в реализации видеотрансляции в проекте, главным требованием которого был ~100% охват клиентов, остановился на HLS + MPEG-TS + H.264/AAC и Viblast player на клиенте. Долго боролся с интересным глюком — если в потоке, который уходит клиенту, нет аудиодорожки, то Firefox спокойно продолжает работать, а браузеры на основе Chrome ни в какую не хотят отображать что-либо, помимо квадрата Малевича — пришлось в видеопотоки без аудиодорожки дописывать фейковое пустое аудио.
UFO just landed and posted this here
UFO just landed and posted this here
WebRTC — это SIP в браузере
Или вы не понимаете что такое WebRTC, или не знаете зачем нужен SIP. Ваша характеристика лишена смысла.
Ваша характеристика лишена смысла.Ну почему же, вполне корректно так сказать. Почему нет то?
Потому что WebRTC абсолютно равнодушен в отношении протокола сигнализации, а SIP это только протокол сигнализации. Тоже самое что сказать: WebRTC — это Jingle в браузере. WebRTC это и DTLS-SRTP, и ICE, и SCTP подключения, и еще много чего интересного, но это точно не протокол сигнализации.
В данном контексте SIP это как раз протокол установления сеанса. И в WebRTC как раз сеанс устанавливается именно точно так же SIP/SDP. И webrtc на тот же SDP жёстко завязан. Который при согласовании уже летает по внешнему signaling протоколу, любому, к которому уже WebRTC равнодушен. Вот то, что WebRTC это не только «SIP в браузере»- это верное замечание.
Раз SDP используется в SIP, и WebRTC использует SDP — значит WebRTC это SIP в брузере?
В WebRTC сеанс устанавливаеться так же как и в практически любом дргом протоколе установки медиа сесий. SDP не делает установку сесии. Я вот например на самом низком уровне конвертируюю SDP в Jingle, и вообще с SDP не роботаю, и знать не знаю. Не надо создавать заблуждений. WebRTC это и близко не SIP.
И в WebRTC как раз сеанс устанавливается именно точно так же SIP/SDP
В WebRTC сеанс устанавливаеться так же как и в практически любом дргом протоколе установки медиа сесий. SDP не делает установку сесии. Я вот например на самом низком уровне конвертируюю SDP в Jingle, и вообще с SDP не роботаю, и знать не знаю. Не надо создавать заблуждений. WebRTC это и близко не SIP.
Я вот например на самом низком уровне конвертируюю SDP в Jingle, и вообще с SDP не роботаю, и знать не знаю.Не очень понятно джингл тут причём. Вы его используете вместе с webrtc?
Вы пытаетесь терминами играть зачем-то, SDP «делает установку сессии» настолько, насколько это понятие применимо для протокола прикладного уровня.
Это терминоложеская проблема, но формулировка и вправду не очень. Правильной формулировкой, на мой взгляд, является "WebRTC — SIP-телефон без SIP в браузере".
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.Всё это круто звучит. И да, для DASH, как и для HLS есть немало решений для нативного проигрывания в большинстве браузеров, тот же video.js. Ну и референсную реализацию dash.js надо упомянуть. И даже стабильно работает. Одна проблема — чтобы добиться адекватной (низкой) задержки нужно очень много плясать с бубном. И в итоге обломиться. И речь здесь не о секундах, а о десятках(!) секунд в дефолтных случаях. Издержки обеих технологий, от которых избавиться не получается. Так что, к сожалению, лучше rtmp для low latency live streaming на данный момент ничего нет и в ближайшем будущем не видно. И, как следствие, здесь снова речь про флеш, раз мы говорим об «rtmp в браузере». Буду очень признателен, если кто-то переубедит, проблема не праздная.
Для вещание телеканалов, эта задержка не критична. А для low latency live streaming есть WebRTC, он подходит и для общения, и для просмотра камеры наблюдения.
Именно так, для ТВ это прекрасные технологии (огромный плюс что не надо даже медиасерверов теперь для всяких VOD; ну и плюс CDN и вот это всё, круто), а вот для чатиков, онлайн-стримов, «скайпа в браузере» итд — технологии никакие.
Да, про WebRTC ещё забыл к rtmp добавить, конечно. Но здесь 1) пока проблема с поддержкой, хуже чем флеш, но лучше тем, что там где есть это нативно 2) плюс некоторая всё костыльность (но на это можно закрыть глаза). Так что, видимо, за ним всё же пока видится low latency будущее.
Да, про WebRTC ещё забыл к rtmp добавить, конечно. Но здесь 1) пока проблема с поддержкой, хуже чем флеш, но лучше тем, что там где есть это нативно 2) плюс некоторая всё костыльность (но на это можно закрыть глаза). Так что, видимо, за ним всё же пока видится low latency будущее.
HLS с буфером в 1 фрагмент дадут задержку в несколько секунд (3-6) на перекодирование RTMP потока с того же OBS на сервере + длительность одного фрагмента. С DASH думаю то же самое. Low latency реализовано например у http://beam.pro — транспорт через вебсокеты мелких фрагментов в несколько сотен милисекунд. С их пропатченным OBS можно получить реальную задержку в 100-200мс, без него вроде около секунды-двух.
А вы пробовали играть однофрагментный плейлист HLS? Он постоянно будет затыкаться же и дёргаться. Я пробовал, пройденный этап, всякие готовые решения типа videojs-hls итд очень плохо это переваривают — короткие фрагменты, короткий плейлист итд. Сама по себе суть этой технологии и этого метода, а именно — постоянно зачитываем плейлист (а это отдельные xhr запросы не забываем!), вычитываем новые кусочки (запросы, запросы, http, http, http, http, http), демуксим их в буфер, суём MSE, играем — подразумевает, что без некоторого буфера нереально обойтись. И буфер тут помимо секунд в кол-ве кусочков ещё, т.к. http, как вы понимаете, не очень-то low latency live сам по себе. А если ещё вдруг канал не очень…
Вот про вебсокеты итд это уже интереснее. Это кое-что мы смотрели, вроде где-то на хабре даже было подобное. Нет, на самом деле есть решения разного рода велосипедности. И вебсокетами видел что просто тянут тупо сырой mp4 (ну или тоже чанками, не помню) итд итп. Речь тут больше о стандартных технологиях будущего, нативности. beam.pro посмотрим, спасибо, не видел. А есть ещё какие-то такие же готовые решения типа фреймворков в виде серверная часть + спец. плеер?
Вот про вебсокеты итд это уже интереснее. Это кое-что мы смотрели, вроде где-то на хабре даже было подобное. Нет, на самом деле есть решения разного рода велосипедности. И вебсокетами видел что просто тянут тупо сырой mp4 (ну или тоже чанками, не помню) итд итп. Речь тут больше о стандартных технологиях будущего, нативности. beam.pro посмотрим, спасибо, не видел. А есть ещё какие-то такие же готовые решения типа фреймворков в виде серверная часть + спец. плеер?
Тормоза с 1 фрагментом не из-за протокола доставки http/websockets и т.д., а из-за того, что браузер рассматривает фрагмент как минимальная единица для добавление в кеш семплов, синхронно. Т.е., пока не загрузится предыдущий фрагмент целиком, ни один его кадр не попадет в буфер проигрывания (в терминологии MSE) и не придет событие на добавление следующего. Т.е. петля: сигнал-загрузка-добавление в буфер-сигнал просто не успевает выполняться. У нас серверная часть вообще своя на С++ и данные генерируются на лету из памяти и на страничке данные выкачиваются через WebSocket. При этом не один из браузеров не успевает обрабатывать относительно короткие фрагменты.
В общем, примерно понятно, что надо больше в сторону WebSocket смотреть. А есть вообще что-то такое адекватное и готовое, можно платное? Т.к. про то и говорю, что цельных технологий и решений нет и у всех всё «своё»)
При этом не один из браузеров не успевает обрабатывать относительно короткие фрагменты.Э… это непонятно. Имеете в виду в виде hls если?
В общем, примерно понятно, что надо больше в сторону WebSocket смотреть. А есть вообще что-то такое адекватное и готовое, можно платное? Т.к. про то и говорю, что цельных технологий и решений нет и у всех всё «своё»)
Я видел решение на базе HLS, но не помню сейчас точно название. Мы просто не совсем вебом занимаемся. Нам нужно проигрывать собственный видео-контейнер через браузер в интрасети (легкий клиент).
Э… это непонятно. Имеете в виду в виде hls если?
Я имею ввиду что накладные расходы на обработку одного фрагмента, без учета добавления медиа-семплов (не важно hls или dash), довольно высоки. По этому, если фрагменты слишком маленькие, то временная задержка на их добавление становится выше чем длина видео-контента который в них содержится. В такой ситуации начинаются затыки и подрывы.
И еще, я не думаю что это ограничение спецификации, но все браузеры на которых я тестировал плеер (chrome, firefox, opera, edge) добавляют фрагменты синхронно (с точки зрения медиа буфера). Пока не добавился текущий фрагмент, нельзя, в параллель, добавлять следующий. Из-за этого ограничения работа с кусками меньше определенного размера становится затруднительной.
> И речь здесь не о секундах, а о десятках(!) секунд в дефолтных случаях.
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.
А еще здорово взять и на флеше реализовать технологию Adaptive bitrate streaming, о которой ничего не сказал автор статьи, зато которая нативно поддерживается мобильными устройствами.
Как можно говорить о флеше, если но не поддерживается мобильными устройствами. А то что все основные браузеры планируют прекратить проигрывание флеша, вас тоже никак не смущает?
Переубедил?
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.
А еще здорово взять и на флеше реализовать технологию Adaptive bitrate streaming, о которой ничего не сказал автор статьи, зато которая нативно поддерживается мобильными устройствами.
Как можно говорить о флеше, если но не поддерживается мобильными устройствами. А то что все основные браузеры планируют прекратить проигрывание флеша, вас тоже никак не смущает?
Переубедил?
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.Это к чему вообще? Причём тут «подгрузится», если речь о live-стриминге и low latency в нём.
Так что нет, не переубедили, потому что вариантов вы не предложили никаких, не говоря уж о том, что вы как-то крайне превратно поняли моё сообщение. На флеше не надо ничего этого вашего сложного реализовывать, там фактически всё это сделано нативно. Я написал «к сожалению» неспроста, и флеш тут только потому, что других вариантов браузерных rtmp-клиентов тупо не бывает. И даже типа pure-js плееры, которые играют rtmp используют в глубине флешовую прослойку. У вас есть другие подходящие варианты как без гемора и велосипедов?
А в чем, собственно, проблема псевдостриминга mp4, когда вы знаете, что канал клиента справляется с потоком? Псевдостриминг позволяет достигнуть заметно меньшей задержки, чем это возможно с HLS и MPEG-DASH.
Не приносите в веб старые кодекиПодобные заявления ставят под угрозу универсальность Web как платформы.
Раньше моможно вставитьжно было напрямую вставить видео через <embed>/<object> и оно проигрывалось ActiveX/NPAPI-плагином одного из установленных плееров — как минимум у WMP, QuickTime и VLC такие есть. Все форматы, которые могут установленные плееры с плагином, проиграются прямо на странице.
Потом, поскольку эти плагины не кастомизируются со стороны сайта, пошла мода вместо видео напрямую вставлять кастомный плеер на флеше.
Потом предолжили модный <video>, который можно и просто вставить, и кастомизировать как угодно, но вот беда — за поддерживаемые кодеки и контейнеры отвечает браузер. А всеядный фреймворк QuickTime использует только Safari для macOS — у остальных браузеров набор строго ограничен. Закинуть в браузер без переконвертации видео в 3gp, mkv, или там мидяшку — фигушки. Остаётся ждать, когда в ширпотребные ЭВМ завезут графеновые или вовсе квантовые процессоры и можно будет реврапперы и кодеки на WebAssembly портировать.
И подобных мелких, но болезненных проблем у веба масса, взять хоть отсутствие прямого доступа к локальной ФС. Даже в убогой J2ME он возможен с разрешения пользователя, браузерный JS не предоставляет такой возможности в принципе, чтоб пользователь себе ногу не отстрелил. Ну точнее, IE предоставлял через ActiveX, но он откинулся. В итоге получается, что если пользователь доверяет условному дропбоксу, то поставить для синхронизации нативный клиент он может, а сделать то же самое на сайте — фигушки, там доверять не разрешено никому, сиди и грузи по одной папке.
QuickTime еще официально прикрылся с windows платформы.
Остаётся ждать, когда в ширпотребные ЭВМ завезут графеновые или вовсе квантовые процессоры и можно будет реврапперы и кодеки на WebAssembly портировать.
Не WebAssembly, но доставка чанков mpeg1 по вебсокету, декодирование через JS и отрисовка на канвасе вполне работает прямо сейчас. Со всеми вытекающими болячками, конечно.
Это ужасно, когда ты заходишь на сайт, а он говорит «Установите Flash» или «Установите Silverlignt», ставишь все это, а на следующем сайте: «Установите VLC плеер». Ну ок, ставим. На очередном сайте потребуют ACE или QuickTime. Не, спасибо, такой универсальный веб нам не нужен.
"… Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров."
Скорей производители кодеров/стримеров наплевали на стандарты. В итоге разработчикам сеттопбоксов, кроме проблем с постоянно мутирующим и пополняющимся версиями, типа стандартом, HLS, приходится воевать с кривыми операторскими головными станциями, которые были сделаны на коленке, а проданы отнюдь не за копейки.
Скорей производители кодеров/стримеров наплевали на стандарты. В итоге разработчикам сеттопбоксов, кроме проблем с постоянно мутирующим и пополняющимся версиями, типа стандартом, HLS, приходится воевать с кривыми операторскими головными станциями, которые были сделаны на коленке, а проданы отнюдь не за копейки.
А можно где-нибудь инструкцию для чайника как стриминг организовать? Можно на английском.
К примеру, у меня есть дев-борда (в моём частном случае — малина), к ней совместимая веб-камера, устройство находится за NATом с серым IP, проброс портов нет возможности осуществить (очень часто меняются точки доступа). Кроме дев-борды, есть Linux сервер с белым IPv4 адресом. Как можно отправить видеопоток с малины на мой сервер, чтобы его уже оттуда отдавать с Апача?
Проблемы с масштабированием нет — отдавать поток нужно будет 1 или 2 пользователям после успешного входа в систему. Из-за вопросов приватности никак не хочется использовать популярные стриминг-сервисы или IP камеру.
К примеру, у меня есть дев-борда (в моём частном случае — малина), к ней совместимая веб-камера, устройство находится за NATом с серым IP, проброс портов нет возможности осуществить (очень часто меняются точки доступа). Кроме дев-борды, есть Linux сервер с белым IPv4 адресом. Как можно отправить видеопоток с малины на мой сервер, чтобы его уже оттуда отдавать с Апача?
Проблемы с масштабированием нет — отдавать поток нужно будет 1 или 2 пользователям после успешного входа в систему. Из-за вопросов приватности никак не хочется использовать популярные стриминг-сервисы или IP камеру.
MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.
Уже только ради этой фразы стоило прочитать статью :)
Скажите, ваш сарказм направлен только на первую редакцию ISO/IEC 23009-1:2012, или вторая от 2014 года тоже не сахар?
В отличие от первого HLS, который в целом был редким случаем полностью заимплементированного протокола, DASH является тем самым классическим примером описанного и формализованного протокола для которого никогда не будет сервера, полностью его реализующего и клиента, полностью его реализующего.
Так что сарказм направлен вообще на то, как продумывали dash и как его примеряли к реальной жизни.
Так, например, нельзя просто так взять и сконвертировать HLS сегмент в DASH сегмент, не скачав следующий сегмент, потому что без этого нельзя узнать длительности последних кадров.
Так что сарказм направлен вообще на то, как продумывали dash и как его примеряли к реальной жизни.
Так, например, нельзя просто так взять и сконвертировать HLS сегмент в DASH сегмент, не скачав следующий сегмент, потому что без этого нельзя узнать длительности последних кадров.
Полностью поддерживаю. Да там, такое ощущение, что люди которые принимали стандарт вообще никогда с видео дела не имели. Один пример:
В контейнере segmented-moeg4 есть безобидное, на первый взгляд, поле — номер сегмента. Казалось бы, ну есть и есть… А теперь представим, что мы динамически генерируем фрагмент из середины нашего большого клипа. Из-за наличия данного поля, по спецификации, теперь нам придётся явно или виртуально генерировать все сегменты до текущего, только чтобы определить номер фрагмента в последовательности. Хорошо что пока это поле не несёт никакой смысловой нагрузки и всем сегментам можно проставить одно и тоже значения, а все мне известные браузеры его игнорируют.
В контейнере segmented-moeg4 есть безобидное, на первый взгляд, поле — номер сегмента. Казалось бы, ну есть и есть… А теперь представим, что мы динамически генерируем фрагмент из середины нашего большого клипа. Из-за наличия данного поля, по спецификации, теперь нам придётся явно или виртуально генерировать все сегменты до текущего, только чтобы определить номер фрагмента в последовательности. Хорошо что пока это поле не несёт никакой смысловой нагрузки и всем сегментам можно проставить одно и тоже значения, а все мне известные браузеры его игнорируют.
но мы же с вами понимаем, что как только мы поставим туда произвольный номер, сразу же найдется плеер на js, который пользуется этим полем и искренне верит в то, что во всех видеопотоках этот счетчик монотонно возрастает строго на 1.
А лучше даже не на JS, а на С++. Что бы веселее было поддерживать.
А лучше даже не на JS, а на С++. Что бы веселее было поддерживать.
У меня лично всегда было ощущение, что HLS создали веб-программисты на пару с админами.
Особенно на фоне того набора DVB стандартов от ETSI, которые были ранее созданы (и продолжают развиваться) вменяемыми научно-инжинерными группами.
Особенно на фоне того набора DVB стандартов от ETSI, которые были ранее созданы (и продолжают развиваться) вменяемыми научно-инжинерными группами.
Пока такого нет, но вы правы, earlyvideo, обязательно будет, и это самое печальное во всей этой истории с dash. Но все вопросы про детали разработчики стандарта посылают в… mp4box, мол все вопросы туда.
У нас вся реализация записи своя и мне «посчастливилось» поиграться со всеми параметрами segmented-mp4 в процессе отладки под разные браузеры. Сначала я злился, но после очередного финта стандарта начал в офисе смеяться над тем как тот или иной производитель браузера интерпретирует передаваемые параметры. Т.е. даже эти ребята не в курсе!
У нас вся реализация записи своя и мне «посчастливилось» поиграться со всеми параметрами segmented-mp4 в процессе отладки под разные браузеры. Сначала я злился, но после очередного финта стандарта начал в офисе смеяться над тем как тот или иной производитель браузера интерпретирует передаваемые параметры. Т.е. даже эти ребята не в курсе!
HDS тоже забавный формат, хотя, увы, только под flash.
Три года назад работал в компании, предоставляющей набор охранной системы для частников — это набор беспроводных датчиков и базовой станции, которая общается с «центром» через GSM/3G и имеет бекапную батарейку (грабители обычно обесточивают дом, обрезают телефонную линию, разбивают панель ввода пинкода, думая, что он посылает сигнал тревоги). Я разрабатывал для них IP камеру (прошивку на основе hi3518 и Ambarella A5s/S2Lm) и серверную часть. SDK обычно предоставляет высокоуровневый RTSP/RTP стриминг, но я брал с уровня NAL h264 фреймов и запихивал в пропраетный протокол. Общение камеры с клаудом по типу dropcam, основан на TLS соединении (каждая камера имеет свой сертификат с UUID, подписанный единым CA, что авторизует каждую камеру, и сертификат сервера может быть проверен тоже с помощью CA паблика вшитого в камеру), и протокол на основе protobuf. Серверная часть C++ Boost::ASIO позволяет держать десятки тысяч одновременно подключенных камер на один сервер (стриминг происходит по активации со стороны приложения или по срабатыванию датчиков в доме).
Интересная тема с просмотром live и записанном видео в браузере и в мобильных клиентах. На Android и iOS мы можем просто скармливать NAL фреймы фреймворку и сама OS будет проигрывать видео, т.е. транспорт полностью может быть пропраетным. С браузерами не всё так просто, либо flash, либо html video tag. Хотя есть вариант плагинов, типа VLC для браузеров, чтобы проигрывать RTSP/RTP потоки, или какой-нибудь ActiveX — но это уже сильно устарело.
HTML5 video отлично проигрывает HLS и MPEG-DASH во всех современных браузерах, но live video запаздывает на величину 2х-3х сегментов, которые скажем по 2 сек, значит на 4-6 секунд. Мы же хотим видеть live именно live с минимальной задержкой (как в RTSP/RTP). К сожалению, я выбрал вариант Flash и с сервера лил файлы FLV просто потоком, который сразу же проигрывался. FLV формат супер прост, пихаем h264 NAL и AAC фреймы и всё. На мобильных клиентах мы написали простой FLV парсер и скармливали NAL и AAC фреймы системе.
Интересная тема с просмотром live и записанном видео в браузере и в мобильных клиентах. На Android и iOS мы можем просто скармливать NAL фреймы фреймворку и сама OS будет проигрывать видео, т.е. транспорт полностью может быть пропраетным. С браузерами не всё так просто, либо flash, либо html video tag. Хотя есть вариант плагинов, типа VLC для браузеров, чтобы проигрывать RTSP/RTP потоки, или какой-нибудь ActiveX — но это уже сильно устарело.
HTML5 video отлично проигрывает HLS и MPEG-DASH во всех современных браузерах, но live video запаздывает на величину 2х-3х сегментов, которые скажем по 2 сек, значит на 4-6 секунд. Мы же хотим видеть live именно live с минимальной задержкой (как в RTSP/RTP). К сожалению, я выбрал вариант Flash и с сервера лил файлы FLV просто потоком, который сразу же проигрывался. FLV формат супер прост, пихаем h264 NAL и AAC фреймы и всё. На мобильных клиентах мы написали простой FLV парсер и скармливали NAL и AAC фреймы системе.
Sign up to leave a comment.
Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)