Comments 54
До сих пор даже Сафари на Винде не умеет играть HLS
Прошу прощения, но я про Safari для винды слышал последний раз в 2012 году. Не похоже, что с тех пор что-то изменилось…
faststart — это когда moov атом переносят вначало файла. Для этого надо собрать moov, потом добавить его длину ко всем смещениям и переписать файл.
Современные браузеры вроде умеют пользоваться Range запросами и проигрывают непатченые файлы быстро.
Со стороны клиента интересует что конкретно и где поддерживается. Говорят от гугла кодек сжимает получше(в плане качества И размера), но что где поддерживается? Появились ли варианты 100% поддержки?
Со стороны сервера всё гооораздо интереснее если мы говорим о стриминге — как обеспечивать из одного источника несколько разных по качеству видео-аудио дорожек? Допустим я вещаю в 1080р, а у клиента нет такого канала и максимум он может 480р. Как «на лету» делать сразу несколько источников с разным качеством?
Вообщем, поделитесь пожалуйста технической информацией, её было пару лет назад крайне мало и с тех пор не замечал ничего нового по этой теме.
Про серверную сторону напишем.
Протокол 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 ни в какую не хотят отображать что-либо, помимо квадрата Малевича — пришлось в видеопотоки без аудиодорожки дописывать фейковое пустое аудио.
WebRTC — это SIP в браузере
Или вы не понимаете что такое 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 в браузере». Буду очень признателен, если кто-то переубедит, проблема не праздная.
Да, про WebRTC ещё забыл к rtmp добавить, конечно. Но здесь 1) пока проблема с поддержкой, хуже чем флеш, но лучше тем, что там где есть это нативно 2) плюс некоторая всё костыльность (но на это можно закрыть глаза). Так что, видимо, за ним всё же пока видится low latency будущее.
Вот про вебсокеты итд это уже интереснее. Это кое-что мы смотрели, вроде где-то на хабре даже было подобное. Нет, на самом деле есть решения разного рода велосипедности. И вебсокетами видел что просто тянут тупо сырой mp4 (ну или тоже чанками, не помню) итд итп. Речь тут больше о стандартных технологиях будущего, нативности. beam.pro посмотрим, спасибо, не видел. А есть ещё какие-то такие же готовые решения типа фреймворков в виде серверная часть + спец. плеер?
При этом не один из браузеров не успевает обрабатывать относительно короткие фрагменты.Э… это непонятно. Имеете в виду в виде hls если?
В общем, примерно понятно, что надо больше в сторону WebSocket смотреть. А есть вообще что-то такое адекватное и готовое, можно платное? Т.к. про то и говорю, что цельных технологий и решений нет и у всех всё «своё»)
Я видел решение на базе HLS, но не помню сейчас точно название. Мы просто не совсем вебом занимаемся. Нам нужно проигрывать собственный видео-контейнер через браузер в интрасети (легкий клиент).
Э… это непонятно. Имеете в виду в виде hls если?
Я имею ввиду что накладные расходы на обработку одного фрагмента, без учета добавления медиа-семплов (не важно hls или dash), довольно высоки. По этому, если фрагменты слишком маленькие, то временная задержка на их добавление становится выше чем длина видео-контента который в них содержится. В такой ситуации начинаются затыки и подрывы.
И еще, я не думаю что это ограничение спецификации, но все браузеры на которых я тестировал плеер (chrome, firefox, opera, edge) добавляют фрагменты синхронно (с точки зрения медиа буфера). Пока не добавился текущий фрагмент, нельзя, в параллель, добавлять следующий. Из-за этого ограничения работа с кусками меньше определенного размера становится затруднительной.
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.
А еще здорово взять и на флеше реализовать технологию Adaptive bitrate streaming, о которой ничего не сказал автор статьи, зато которая нативно поддерживается мобильными устройствами.
Как можно говорить о флеше, если но не поддерживается мобильными устройствами. А то что все основные браузеры планируют прекратить проигрывание флеша, вас тоже никак не смущает?
Переубедил?
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.Это к чему вообще? Причём тут «подгрузится», если речь о live-стриминге и low latency в нём.
Так что нет, не переубедили, потому что вариантов вы не предложили никаких, не говоря уж о том, что вы как-то крайне превратно поняли моё сообщение. На флеше не надо ничего этого вашего сложного реализовывать, там фактически всё это сделано нативно. Я написал «к сожалению» неспроста, и флеш тут только потому, что других вариантов браузерных rtmp-клиентов тупо не бывает. И даже типа pure-js плееры, которые играют rtmp используют в глубине флешовую прослойку. У вас есть другие подходящие варианты как без гемора и велосипедов?
Не приносите в веб старые кодекиПодобные заявления ставят под угрозу универсальность 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 и отрисовка на канвасе вполне работает прямо сейчас. Со всеми вытекающими болячками, конечно.
Скорей производители кодеров/стримеров наплевали на стандарты. В итоге разработчикам сеттопбоксов, кроме проблем с постоянно мутирующим и пополняющимся версиями, типа стандартом, HLS, приходится воевать с кривыми операторскими головными станциями, которые были сделаны на коленке, а проданы отнюдь не за копейки.
К примеру, у меня есть дев-борда (в моём частном случае — малина), к ней совместимая веб-камера, устройство находится за NATом с серым IP, проброс портов нет возможности осуществить (очень часто меняются точки доступа). Кроме дев-борды, есть Linux сервер с белым IPv4 адресом. Как можно отправить видеопоток с малины на мой сервер, чтобы его уже оттуда отдавать с Апача?
Проблемы с масштабированием нет — отдавать поток нужно будет 1 или 2 пользователям после успешного входа в систему. Из-за вопросов приватности никак не хочется использовать популярные стриминг-сервисы или IP камеру.
MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.
Уже только ради этой фразы стоило прочитать статью :)
Скажите, ваш сарказм направлен только на первую редакцию ISO/IEC 23009-1:2012, или вторая от 2014 года тоже не сахар?
Так что сарказм направлен вообще на то, как продумывали dash и как его примеряли к реальной жизни.
Так, например, нельзя просто так взять и сконвертировать HLS сегмент в DASH сегмент, не скачав следующий сегмент, потому что без этого нельзя узнать длительности последних кадров.
В контейнере segmented-moeg4 есть безобидное, на первый взгляд, поле — номер сегмента. Казалось бы, ну есть и есть… А теперь представим, что мы динамически генерируем фрагмент из середины нашего большого клипа. Из-за наличия данного поля, по спецификации, теперь нам придётся явно или виртуально генерировать все сегменты до текущего, только чтобы определить номер фрагмента в последовательности. Хорошо что пока это поле не несёт никакой смысловой нагрузки и всем сегментам можно проставить одно и тоже значения, а все мне известные браузеры его игнорируют.
А лучше даже не на JS, а на С++. Что бы веселее было поддерживать.
Особенно на фоне того набора DVB стандартов от ETSI, которые были ранее созданы (и продолжают развиваться) вменяемыми научно-инжинерными группами.
У нас вся реализация записи своя и мне «посчастливилось» поиграться со всеми параметрами segmented-mp4 в процессе отладки под разные браузеры. Сначала я злился, но после очередного финта стандарта начал в офисе смеяться над тем как тот или иной производитель браузера интерпретирует передаваемые параметры. Т.е. даже эти ребята не в курсе!
Интересная тема с просмотром 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 фреймы системе.
А как проиграть в браузере трансляцию с VLC?
Кроме ogg/theo, а то оно чет квадратиками.
Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)