2016-09-19 9 views
2

Я пытаюсь решить проблему с помощью встроенного Android-приложения WebRTC. Я успешно адаптировал AppRTCDemo от вызова 1-1 к вызовам 1-N. В настоящее время у меня есть следующий сценарий:Android WebRTC - Mix AudioTracks для конференции

  • А (я) может поговорить с/слушать B
  • А (я) может поговорить с/слушать C
  • B и C не может говорить или слушайте друг друга.

Для достижения этой цели I (A) есть 2 PeerConnections соответственно с B и C. Я понимаю, что нужно смешать некоторые, как мультимедийные потоки или звуковые дорожки, или другими словами:

  • Mix (A, B) -> отправить C

  • Mix (A, C) -> отправить B

Любые указатели о том, как добиться этого? Thank you

+0

Зачем вам нужно смешивать A и B и отправлять на C? Есть ли какая-либо причина для того, чтобы B и C не устанавливали соединение напрямую? – samgak

+0

@samgak Значение, B и C соединяются напрямую друг с другом? Если клиент (A) является Android-приложением и создал 2 одноранговых соединения с B, а другой - с C ... Я не понимаю, как можно было бы напрямую подключить B к C, как вы сказали, от клиента? – EdGs

+0

Являются ли B и C тем же приложением? Если нет, то каковы они? – samgak

ответ

1

Я считаю, что вы отправляете один и тот же локальный поток обеим сторонам (party-B и party-C) в multiconnection, потому что, если вы попытаетесь создать разные локальные потоки для разных подключений, это вызовет ошибку, поскольку она попытается снова получить доступ к микрофону и фотоаппарату, что невозможно (я считаю).

Вы должны создать localstream что-то вроде этого:

stream = sessionFactory.createLocalMediaStream(LOCAL_MEDIA_ID); 

Для отправки потока Party-B Стороне-C вы можете сделать это:

  • step1-- создать соединение между p2p party-A и party-B
  • step2-- создать p2p-соединение между party-A и party-C
  • step3-- при добавлении локального потока, который вы вызываете mething как этот

    peerconnection2.addStream(myStream) 
    

На месте myStream (для взаимного соединения с C), вы можете добавить в remoteStreamB (удаленный поток, который вы получаете от B). Это добавит поток, который вы получаете от B, как localstream во второй PeerConnection, который с С.

Для отправки удаленного потока от Party-C Стороне-B:

  • Предположим, вы peerconnection1 с партией -B. Чтобы добавить удаленный поток из C в локальный поток, вам сначала нужно удалить текущие треки, а затем добавить новые треки.
  • для этого вы можете сделать что-то вроде этого

    AudioTrack t1 = mystream.audioTracks.get(0); 
    VideoTrack v1 = myStream.videoTracks.get(0); 
    if(myStream.removeTrack(t1)){ 
    if(myStream.removeTrack(v1)){ 
        t1 = remoteStreamC.audioTracks.get(0); 
        v1 = remoteStreamC.videoTracks.get(0); 
    
        myStream.addTrack(t1); 
        myStream.addTrack(v1); 
    } 
    } 
    

    Этим способом вы будете изменять содержание localstream, что вы отправляете в B. Теперь, когда поток будет иметь аудио и видео треков, поступающих от remotestreamC ,

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

+0

Я скоро попытаюсь реализовать ваше предложение. Я дам вам знать результаты. Спасибо!! – EdGs

+0

Вы правы. Я только создаю localStream один раз. И, ваш первый пример, B-Party для C-Party работает, при создании C-party peerConnection я передаю поток B-party как localMedia на C-party. Я пробовал 2-й пример C-Party для B-Party без успеха. У B-party уже есть localStream. Как только я заменил треки, как вы предполагали, я теряю аудио на B-Party. Нужен ли мне вызов B-PeerConnection.removeStream (localStream), затем B-PeerConnection.addStream (modifiedStream)? Другими словами, как мне «заменить» поток B-party? Это должно спровоцировать новое предложение, правильно? – EdGs

+0

Хорошо, ты ответишь мне, где мне нужно. Как выясняется onRenegotiationNeeded запускается, но не было отправлено предложений, когда я добавил или удалил MediaStream из PeerConnection. Поэтому я заставляю его «createOffer». Нечетный, поскольку вы думаете, что это сработает с момента комментария «Нет необходимости ничего делать, AppRTC следует предварительно согласованному протоколу сигнализации/согласования» находится в теле метода. Теперь, создав трехсторонний вызов, реализующий то, что вы предложили, качество звука на конце peer значительно ухудшилось. Любые идеи почему? Благодаря – EdGs