Как обойти отсутствующую реализацию .stop () RTCRtpTransceiver в Chrome / Chromium - PullRequest
1 голос
/ 08 января 2020

В настоящее время я пытаюсь создать приложение webrt c, которое использует RTCRtpTransceiver-Objects стандарта WebRT C. Я добавляю видео и аудио треки к соединению, а затем, через некоторое время, пытаюсь удалить их. Я делаю это со следующими строками:

// part of a method, that searches the transceiver to stop and assigned it to the 'transceiver' variable
peerconnection.removeTrack(transceiver.sender);
if (transceiver.direction === "sendrecv") transceiver.direction = "recvonly";
else transceiver.direction = "inactive";

Я знаю, что это установит удаленную дорожку только в приглушенное состояние и похоже на замену дорожки отправителя приемопередатчика нулевым, но Chrome не реализовано direction="stopped" или transceiver.stop() пока нет, см. выпуск 980879 .
Так что же делать вместо этого?
Удаленный узел просто видит, что текущее направление приемника становится неактивным, а дорожка приемника отключается.
Er go, он не удаляет дорожку для удаленного однорангового узла в моем приложении, и приглушенные дорожки накапливаются со временем и, что еще хуже, для видеодорожек: они отображаются как обычные приглушенные дорожки.
Я также не могу удалить все приглушенные track, так как мое приложение должно разрешать приглушенные и не отключенные треки (- отключается пользователем, не отключается из-за остановки).
Приглушение треков путем их полного удаления приведет к другому обмену предложением-ответом, и это займет некоторое время. Я бы предпочел просто отключить звук, заменив дорожку на ноль (без необходимости отправлять sdp туда-сюда), так как стандарт WebRT C, кажется, позволяет, и Chrome уже реализует.
Следующим вариантом будет корреляция приемопередатчики на обоих концах и отправка сообщения от остановившегося однорангового узла удаленному, чтобы удаленный остановил полученную дорожку. Это может быть возможно (я полагаю, что середина трансивера должна быть такой же, согласно спецификации c), но, на мой взгляд, это также уродливый способ.
Чего я не могу сделать, так это просто отправить идентификатор дорожки мультимедиа , так как этот отличается для узла остановки и удаленного узла, поэтому я не могу просто отправить сообщение типа ', пожалуйста, остановите ваш трек с идентификатором xyz' (это упростит задачу, но хорошо, это просто работает не так) как долго остановка трансиверов не будет работать в каждом браузере? (chrome исправление его для текущих версий, вероятно, займет некоторое время, но, будучи наиболее используемым браузером, мы не можем просто игнорировать его)

Кто-то как-то (злоупотребляя DTFM, используя magi c или что-то еще ..) .) соединить полифилл вместе? (Я полагаю, что Adapter. js не сделал это каким-то образом возможным) Есть ли другой способ, кроме отключения звука = удаления и отправки сообщений удаленного отслеживания остановки через сигнализатор? Если нет, то какой вариант лучше?

1 Ответ

0 голосов
/ 16 января 2020

В итоге я выбрал решение для сигнализации. Я в основном делаю

// part of a method, that searches the transceiver to stop and assigned it to the 'transceiver' variable
peerconnection.removeTrack(transceiver.sender);
if (transceiver.direction === "sendrecv") transceiver.direction = "recvonly";
else transceiver.direction = "inactive";
signaler.send({type: 'transceiver:stop', data: transceiver.mid});

А с другой стороны

// received sent message and called this method with message.data
onTransceiverStopMessage(mid){
   const transceiverToStop = peerconnection.getTransceivers().filter(transceiver => transceiver.mid === mid);
   transceiverToStop.receiver.track.stop()
   transceiverToStop.receiver.track.dispatchEvent(new Event('ended'));
}

Необходим dispatchEvent -Call, так как вызов stop на дорожке не вызывает ended -Событие. Это хорошо работает для моей цели, но я все еще жду решения для накопления неактивных трансиверов (так как они все еще влияют на производительность, как говорится в проблеме chrome)

...