2016-06-09 1 views
1

Работа с родным приложением Android webRTC и попытка удалить видеодорожку из медиапотока, который содержит комбинированный аудио/видео (например, localMS.addTrack (peerConnectionFactory.createVideoTrack («ARDAMSv0», videoSource)) и localMS.addTrack (peerConnectionFactory.createAudioTrack («ARDAMSa0», аудиоисточник));), поток видео по-прежнему отправляется на удаленный конец, и нет генерации «onrenegotiation» ' Перезвони.webRTC remove media track не генерирует повторные переговоры и не останавливает носитель

Существует много дискуссий о removetrack по сравнению с функциональностью до removestream (например, см https://bugs.chromium.org/p/webrtc/issues/detail?id=5265#c4 или https://bugs.chromium.org/p/webrtc/issues/detail?id=2136), кроме того, некоторые работы обходные обсуждаются такие как удаление потока, с последующим удалением дорожки из потока и добавляя прежде чем создавать новое предложение. В стандартах W3C (см. http://w3c.github.io/mediacapture-main/#dfn-settings), похоже, не существует реального указания на то, что должно произойти пересмотр.

Вопросы, которые я пытаюсь решить, следующие: Правильно ли это удалить видеодорожку (т. Е. Вызвать удаленную ссылку на медиа-поток)?

Почему это не происходит? и если это не произойдет, когда следует отправить новое предложение?

Почему вызов удаляемого потока фактически не останавливает поток от передачи? (передача самого нового предложения, похоже, не оказала бы никакого влияния на передачу потока только в том случае, если у получателя есть recv_only в sdp для этого медиа-компонента).

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

благодаря

+0

Помогает ли [этот ответ] (http://stackoverflow.com/a/35515536/918910)? – jib

ответ

0

Не уверен, что Android WebRTC, но в браузере WebRTC (который должен быть похож), вам нужно позвонить stop() на трассе, чтобы фактически остановить его. Или полностью закрыть соединение.

Вы сначала добавляете трек или новый поток, а затем создаете предложение и начинаете процесс пересмотра - он не запускается автоматически.

+0

Спасибо. В исходном webrtc (JNI MediaStreamTrackInterface) для Android мы включаем/отключаем дорожку (но не останавливаемся), что приводит к отправке нормального или черного потока на пульт. Если я отключу дорожку, а затем позвоню удалить, я еще не уверен, что трек удален, поскольку черный экран все еще показывает - но будет проверять и обновлять). Что касается требуемой onnegotiation, по спецификации W3C (раздел 4.8), похоже, что должен срабатывать по треку, добавленному или остановленному. Неясно, почему удаление трека фактически не приводит к удалению трека из потока независимо от того, остановлен или нет. – SBG

+0

Кроме того, обновится до последней версии libjingle (в настоящее время одна с августа 2015 года), в которой это может быть исправлено - потребуется несколько дней, так как несколько изменений по всему webrtc – SBG

Смежные вопросы