Хобрук: Ваш путь к мастерству в программировании

MediaSource против MediaStream в Javascript

Мое приложение Javascript получает видеопоток WebM через соединение Websocket. Между отправкой видеокадров удаленным узлом и их получением приложением нет задержки.

Я создаю в приложении объект MediaSource, к которому добавляю кадры видео, и позволяю элементу видео показывать его:

video.src = window.URL.createObjectURL(mediaSource);

Это работает хорошо, но есть некоторая (менее секунды) задержка, которая, возможно, делает это решение не оптимальным для видеозвонков.

Очевидно, некоторые приложения WebRTC вместо этого используют MediaStream:

video.srcObject = mediaStream;

... и они не показывают задержки.

Я не мог определить из документации, обрабатывают ли браузеры src и srcObject по-разному.

Еще одна вещь, которую я не смог найти, это то, можно ли создать MediaStream и добавить к нему буферы, как с MediaSource. Я хочу попробовать это, просто чтобы проверить, не вызовет ли srcObject вышеупомянутую задержку в моем приложении.

Если я использую:

video.srcObject = mediaSource;

Я получаю сообщение об ошибке:

TypeError: не удалось установить свойство «srcObject» в «HTMLMediaElement»: предоставленное значение не имеет типа «MediaStream».

javascript video mediastream media-source
14.08.2018

  • Если вам нужна низкая задержка, вам следует использовать WebRTC. Это гораздо больше, чем просто перетасовка данных по сети. Кодеки должны быть настроены, перегрузка должна быть приспособлена, джиттер должен быть исправлен, буферизация должна быть настроена на низкую задержку и т. д. 14.08.2018
  • мое родное приложение (Windows) доставляет через веб-сокет поток webm, или я мог бы просто доставить поток vp8. MediaSource избегает использования ICE/DTLS/SRTP, необходимого для WebRTC... Мне пришлось бы реализовать весь этот штат в моем родном приложении. Что меня смущает, так это то, что один и тот же видеопоток (vp8) отображается с небольшой задержкой в ​​MediaSource и без задержки в MediaStream. Я хотел бы узнать, где разница. Я пытаюсь копаться в источниках хрома, но безуспешно... 15.08.2018
  • Я сказал вам, почему, в моем комментарии. 15.08.2018

Ответы:


1

То, что вы задаете, — очень хорошие вопросы, и все мы, разработчики потокового видео, сталкиваемся с одними и теми же проблемами и одинаково разочарованы, когда дело доходит до потокового видео почти в реальном времени без плагинов в браузерах.

Позвольте мне ответить на ваши вопросы, насколько мне известно (в последние годы я реализовал расширения WebRTC и Media Source для программного обеспечения потокового сервера)

  1. "если возможно создать MediaStream и добавить к нему буферы, такие как MediaSource"

Это легко - это НЕ возможно. API MediaStream: https://developer.mozilla.org/en-US/docs/Web/API/MediaStream не предоставляет доступ к буферу кадров объекта MediaStream, он обрабатывает все внутри, используя WebRTC, либо получая кадры с помощью getUserMedia (с локальной веб-камеры), либо с RTCPeerConection (из сети). С объектом MediaStream вы не управляете кадрами или сегментами напрямую.

И, конечно же, video.srcObject = mediaSource работать не будет: video.srcObject должен быть объектом MediaStream, созданным WebRTC API, и ничем другим.

  1. «Я не смог найти в документации, обрабатывают ли браузеры src и srcObject по-разному»

Черт возьми, браузеры по-разному относятся к video.src и video.srcObject; и документации по этому поводу нет, да и смысла в этом особого нет. Политика играет в этом большую роль.

Пресловутые примеры из браузера Chrome:

а. Расширения источника мультимедиа (video.src) поддерживают звук AAC, а WebRTC (video.srcObject) — нет и никогда не будет. Причина в том, что Google купил слишком много компаний по сжатию звука, и одна из них — Opus — достигла спецификаций WebRTC, а Google продвигает Opus как нового «короля звука без лицензионных отчислений», поэтому в video.srcObject нет поддержки AAC, и весь мир аппаратного обеспечения должен внедрить Opus сейчас. Таким образом, Google может и имеет законное право добавлять поддержку AAC в Chrome, потому что он делает это для расширений источника мультимедиа (video.src). Но он не добавит поддержку AAC в WebRTC, никогда.

б. Chrome использует разные стратегии для видеодекодеров H264 в video.src и video.srcObject. Это не имеет смысла, но это факт. Например, на Android только устройства с аппаратной поддержкой декодирования H264 будут поддерживать H264 в WebRTC (video.srcObject). Старые устройства без аппаратной поддержки H264 не будут воспроизводить видео H264 через WebRTC. Но те же устройства будут воспроизводить одно и то же видео H264 через расширения источника мультимедиа (video.src). Таким образом, video.src должен использовать программный декодер, если аппаратное обеспечение недоступно. Почему то же самое нельзя сделать в WebRTC?

Наконец, ваш поток VP8 не будет воспроизводиться на iOS, ни в Media Source Extensions (iOS вообще его не поддерживает, ха-ха-ха), ни в WebRTC (iOS поддерживает только видео H264 для WebRTC, ха-ха-ха-ха). Вы спрашиваете, почему Apple так делает? ха ха ха ха ха

15.08.2018
  • С точки зрения чистого декодирования + задержки рендеринга, какой из них, по вашему мнению, обеспечит меньшую задержку? Предположим, что для MSE включен режим малой задержки. Как вы думаете, какой сценарий является основной причиной использования MSE поверх WebRTC и наоборот? 26.04.2019
  • WebRTC обеспечит меньшую задержку. К сожалению, задержка в MSE может колебаться. 26.04.2019
  • означает ли это, что, используя webRTC, мы будем просто доверять браузеру выполнение всей работы? Я знаю, что для MSE мы можем обмануть его (т. е. установить продолжительность бесконечной или 0), чтобы войти в режим реального времени с низкой задержкой, что позволяет нам иметь нулевую буферизацию. Может ли WebRTC сделать то же самое? 26.04.2019
  • Да, в WebRTC вы должны доверять браузеру выполнение всей работы; на следующей веб-странице вы можете сравнить задержку прямой трансляции с IP-камеры с использованием проигрывателей MSE и WebRTC: umediaserver. сеть/umediaserver/demos.html 26.04.2019
  • Вам следует просто отредактировать свой старый ответ, включив в него новую информацию... это облегчит людям поиск информации. 01.01.2021
  • Этот ответ несколько устарел. Назначение MediaSource свойству src теперь определяется WHATWG; Для тех, кто любит публиковать приложения только для Chrome (позор! позор! позор!), команда Google/Chromium экспериментирует с некоторым API для создания пользовательских медиатреков, но я не могу найти ссылку в истории браузера, хотя я на 100% уверен, что читал ее неделю назад. 11.05.2021

    • 2

    Наконец, ваш поток VP8 не будет воспроизводиться на iOS, ни в Media Source Extensions (iOS вообще его не поддерживает, ха-ха-ха), ни в WebRTC (iOS поддерживает только видео H264 для WebRTC, ха-ха-ха-ха). Вы спрашиваете, почему Apple так делает? ха ха ха ха ха

    Обновление 2020 — теперь iOS-устройства поддерживают VP8 через WebRTC, а также новые iPAD начали поддерживать Media Source Extensions. Так держать, Apple!

    19.04.2020

    3 
    video.srcObject = mediaStream
video.src = URL.createObjectURL(mediaSource)

    проверено в электроне (поэтому должно работать и в хроме)

    03.10.2020
    Новые материалы
    Создание успешной организации по науке о данных
    "Рабочие часы" Создание успешной организации по науке о данных Как создать эффективную группу по анализу данных! Введение Это обзорная статья о том, как создать эффективную группу по..
    Технологии и проблемы будущей работы
    Изучение преимуществ и недостатков технологий в образовании В быстро меняющемся мире технологии являются решающим фактором в формировании будущего работы. Многие отрасли уже были..
    Игорь Минар из Google приедет на #ReactiveConf2017
    Мы рады сообщить еще одну замечательную новость: один из самых востребованных спикеров приезжает в Братиславу на ReactiveConf 2017 ! Возможно, нет двух других кланов разработчиков с более..
    Я собираюсь научить вас Python шаг за шагом
    Привет, уважаемый энтузиаст Python! 👋 Готовы погрузиться в мир Python? Сегодня я приготовил для вас кое-что интересное, что сделает ваше путешествие более приятным, чем шарик мороженого в..
    Альтернатива шаблону исходящих сообщений для архитектуры микросервисов
    Познакомьтесь с двухэтапным сообщением В этой статье предлагается альтернативный шаблон для папки Исходящие : двухэтапное сообщение. Он основан не на очереди сообщений, а на..
    React on Rails
    Основное приложение Reverb - это всеми любимый монолит Rails. Он отлично обслуживает наш API и уровень просмотра трафика. По мере роста мы добавляли больше интерактивных элементов..
    Что такое гибкие методологии разработки программного обеспечения
    Что представляют собой гибкие методологии разработки программного обеспечения в 2023 году Agile-методологии разработки программного обеспечения заключаются в следующем: И. Введение A...