Устаревание MediaStream

Sam Dutton

Если вы работаете с getUserMedia() или WebRTC, вам может потребоваться скорректировать код для Chrome 45 и более поздних версий.

API MediaStream представляет синхронизированные потоки медиа. Например, поток, полученный с камеры и микрофона, имеет синхронизированные видео- и аудиодорожки. Каждая дорожка представлена ​​MediaStreamTrack . (Не путать с элементом <track> !)

В Chrome 45 есть три устаревших варианта MediaStream :

• MediaStream.ended
• MediaStream.label
• MediaStream.stop()

Параллельно идут два дополнения:

• MediaStream.active
• MediaStreamTrack.stop()

Для этого необходимо внести следующие изменения:

• Для проверки наличия потоковой передачи MediaStream используйте MediaStream.active , а не MediaStream.ended .
• Для остановки потоковой передачи используйте MediaStreamTrack.stop() , а не MediaStream.stop() .
• Если вам нужен уникальный идентификатор для MediaStream , используйте MediaStream.id вместо MediaStream.label . MediaStreamTrack.label предоставляет понятное человеку имя исходного устройства для потока, например , FaceTime HD Camera (Built-in) (05ac:8510) .

Вы можете увидеть это в действии: откройте simpl.info/gum в Chrome (на устройстве с камерой) и просмотрите консоль Chrome DevTools. stream объектов MediaStream, переданный обратному вызову getUserMedia() в этой демонстрации, находится в глобальной области видимости, поэтому вы можете проверить его из консоли. Вызовите stream.getTracks()[0] , чтобы просмотреть MediaStreamTrack для этого потока.

Stop(), завершен и активен

Когда рабочая группа W3C Media Capture and Streams рассмотрела проблему того, что происходит при добавлении новых дорожек в MediaStream , и заканчивается ли пустой MediaStream , они поняли, что не существует разумного способа реализовать ended в MediaStream (как в 'никогда не начнется снова'). В других частях HTML5 'ended' означает 'это закончилось и никогда не возобновится'. 'Active' не несет такого смысла: неактивный поток может снова стать активным, например, если к нему добавляется новая дорожка. Вместо того, чтобы сохранять запутанный атрибут и функцию, рабочая группа решила удалить его.

Вот пример использования «MediaStream.active» для проверки статуса потока:

var gumStream;

navigator.getUserMedia({audio: false, video: true},
    function(stream) {
            gumStream = stream;
        // ...
    },
    function(error) {
        console.log('getUserMedia() error', error);
    });

// …

if (gumStream.active) {
    // do something with the stream
}

Удаление stop() из MediaStream не удалило никакой реальной функциональности: процессы отсоединения исходных устройств и т. д. в любом случае должны выполняться на MediaStreamTrack . Вместо этого используйте stop() на MediaStreamTrack :

navigator.getUserMedia({audio: false, video: true},
    function(stream) {
            // can also use getAudioTracks() or getVideoTracks()
        var track = stream.getTracks()[0];  // if only one media track
        // ...
        track.stop();
    },
    function(error){
        console.log('getUserMedia() error', error);
    });

этикетка

Оказывается, никто не мог придумать, как использовать эту недвижимость!

MediaStream.label был добавлен в первую версию спецификации, но никто толком не знал, для чего нужна label . Также было неясно, что происходит с label , когда поток отправляется через RTCPeerConnection .

Рабочая группа W3C опросила всех , но никому это не понравилось, поэтому они удалили это.

Повторим: MediaStream.id предоставляет уникальный идентификатор для MediaStream , а MediaStreamTrack.label предоставляет имя источника потока, например тип камеры или микрофона.

Более подробную информацию о MediaStream и MediaStreamTrack можно найти на сайте Mozilla Developer Network , а HTML5 Rocks предоставляет превосходное введение в getUserMedia() в разделе «Захват аудио и видео» .

Как всегда, мы ценим ваши отзывы об изменениях в Chrome. Вы можете следить за ошибками для этих устаревших функций ( здесь и здесь ) и найти больше обсуждений и подробностей в Intent to Implement .