как получить доступ к функциям декодирования видео HTML5?

В HTML5 есть элемент <video/>, который загружает видео с сервера, декодирует его и отображает. Часто, если не всегда, они используют аппаратное ускорение декодирования (если оно доступно).

Можно ли получить доступ только к функциям декодирования? Причина в том, что я использую собственный протокол потоковой передачи, поэтому на стороне клиента у меня есть закодированный видеопоток, который мне нужно декодировать и отображать.

Реализации декодера видео на чистом JavaScript, к сожалению, неприменимы, поскольку не могут обеспечить достаточную производительность. Меня интересуют только кодеки HVEC или h.264.


person Andriy Tylychko    schedule 12.12.2017    source источник
comment
А как насчет blob uri?   -  person Qwertiy    schedule 25.12.2017
comment
@Qwertiy, пожалуйста, уточните   -  person Andriy Tylychko    schedule 25.12.2017


Ответы (3)


Можно ли получить доступ только к функциям декодирования?

К сожалению нет. У нас есть доступ только к высокоуровневому API, работающему с потоком/исходным файлом независимо с ограниченным влиянием, таким как положение во времени, состояние воспроизведения и различные события. Мы можем рисовать кадры на холсте как необработанный RGB(A) из текущего декодированного кадра, но это все.

Причина в том, что я использую собственный протокол потоковой передачи, поэтому на стороне клиента у меня есть закодированный видеопоток, который мне нужно декодировать и отображать.

Вы не описываете этот протокол, поэтому мы можем только догадываться, но вы можете создать совместимый с браузером поток, который может использоваться элементом видео, используя Расширения источника мультимедиа. Это позволяет создавать адаптивные и настраиваемые потоковые решения прямо в клиенте.

Реализации декодера видео на чистом JavaScript, к сожалению, неприменимы, поскольку не могут обеспечить достаточную производительность.

Это не обязательно правда. Примерами являются, например, чистая реализация JS, которая декодирует потоки MPEG1 в режиме реального времени, как аудио, так и видео, такие как this и это. Конечно, это работает на самом пределе возможностей большинства браузеров в настоящее время. Существует также декодер H-264 на основе emscripten, который, кажется, также использует GPU через WebGL, но я не могу говорить о его производительности - хотя это может быть хорошей отправной точкой для следующего абзаца:

Лучший вариант — изучить WebAssembly, который может запускать предварительно скомпилированный двоичный код, например, из исходного кода C/C++. Это позволяет вам использовать реализации декодеров HVEC/H.264 с открытым исходным кодом, работающие на исходной скорости в браузере (однако будьте осторожны с лицензиями и условиями, особенно для H.264) или использовать части программного обеспечения, такие как (ссылаемый) ffmpeg.

Меня интересует любое даже не портируемое решение

В этом случае вы можете захотеть создать веб-расширение ( расширения браузера), которые могут использовать обмен сообщениями для взаимодействия с собственным приложением. (последним в данном случае может быть ffmpeg или программа, которая может напрямую работать с потоком).

Как именно это будет работать, конечно, будет зависеть от используемого вами протокола и так далее.

Просто мои 2 цента, основанные на ограниченном объеме/описании.

person Community    schedule 19.12.2017
comment
+1. Насколько я понимаю, элемент видео можно использовать только с HLS или MPEG-DASH, которые не поддерживают потоковую передачу с малой задержкой? Я имею в виду миллисекунды ответа, а не секунды: wowza.com/blog/hls-latency-sucks-but-heres-how-to-fix-it. это единственная причина для пользовательского протокола, и это обесценивает элемент видео, пожалуйста, поправьте меня. к сожалению, MPEG-1 неприемлем, веб-расширения устарели. Существующие декодеры JS представляют собой простые порты от emscripten и показывают плохую производительность на тяжелых потоках. - person Andriy Tylychko; 19.12.2017
comment
жаль, что функциональность, поддерживаемая браузерами и необходимая для целого класса приложений, не раскрывается даже в непереносимом виде - person Andriy Tylychko; 19.12.2017

Решение этой проблемы — WebRTC. Можно интегрировать внешний кодировщик или использовать встроенный. В браузере клиент WebRTC использует декодирование H/W. WebRTC также обеспечивает функциональность потоковой передачи в реальном времени. Совместимость не плохая.

person Andriy Tylychko    schedule 27.07.2018
comment
Не могли бы вы немного расширить свой ответ? Меня очень интересуют любые способы декодирования видео на стороне клиента (точнее — извлечение последовательности кадров без дропов и дублей), но я не совсем уверен, как применить WebRTC в данном случае. Нужно ли настраивать специальный сервер, который будет отдавать декодированные кадры клиенту через WebRTC? - person Michael Radionov; 30.07.2018
comment
@MichaelRadionov: WebRTC был разработан для одноранговых видеоконференций, таких как веб-браузер для веб-браузера, и имеет JavaScript API. Для чего-то менее тривиального его исходный код открыт и имеет собственный C++ API (он же Native WebRTC) плюс привязку для других языков. Вам необходимо стримить по WebRTC и получать через встроенный клиент WebRTC для аппаратного декодирования в веб-браузере. Это потоковая передача в реальном времени, поэтому происходит пропадание кадров, но нет дублирования. Я предлагаю вам подробно описать ваш случай в виде отдельного вопроса, и я постараюсь ответить на него. - person Andriy Tylychko; 31.07.2018
comment
Я заинтересован в непосредственном получении необработанных декодированных кадров, что было бы возможно с использованием только функций декодирования. Но из того, что я читал, это невозможно даже с WebRTC. Поправьте меня, если я ошибаюсь, но с webRTC вы обязаны использовать элемент video, чтобы выполнить HW-декодирование, верно? - person N4ppeL; 04.07.2019

После долгих исследований декодирование потока сегментов HLS TS h264 с использованием аппаратного декодера стало возможным в браузерах Android с использованием расширения источника мультимедиа (MSE). Поскольку MSE не поддерживается iOS, его работа в Safari в iOS кажется препятствием, поскольку Apple не разрешает доступ к аппаратному декодеру через буфер FIFO или обратные вызовы. Учитывая, что Apple поддерживает WebRTC, кажется, что единственный способ добраться до аппаратного декодера в iOS будет эквивалентен потоку «приема видеозвонка», за исключением того, что вход должен быть удаленным потоком http, а вывод должен идти на холст.

person Karthik Vaithianathan    schedule 17.02.2019