W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > August 2018

Re: [webrtc-pc] pc.addTrack/removeTrack can be described in terms of Transceivers. This may be good for understanding them.

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Wed, 22 Aug 2018 21:34:05 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-415188419-1534973644-sysbot+gh@w3.org>
@jan-ivar do you want to redefine addTrack on top of addTransceiver and not change its behavior or do you want to change addTrack to simply invoke addTransceiver even if a sender could be reused?

Here's my attempt at shimming addTrack, do you want something like this but in language instead of code?
```
arguments: track, streams

const transceivers = pc.getTranceivers();
let transceiver = null;
for (let i = 0; i < transceivers.length; ++i) {
  if (transceivers[i].receiver.track.kind != track.kind)
    continue;
  if (transceivers[i].currentDirection has never had the value 'sendrecv' or 'sendonly') {
    transceiver = transceivers[i];
    break;
  }
}
if (transceiver == null) {
  transceiver = pc.addTransceiver(track, {streams:streams});
} else {
  await transceiver.sender.replaceTrack(track);
  transceiver.sender.setStreams(streams);
  if (transceiver.direction == 'recvonly')
    transceiver.direction = 'sendrecv';
  else if (transceiver.direction == 'inactive')
    transceiver.direction = 'sendonly';
}
return transceiver.sender;
```

A problem above is replaceTrack() is not synchronous, and performing "await replaceTrack" is observably different than "Set sender's [[SenderTrack]] to track."

Looking at the steps in the spec, it is only step 9. that can be replaced by "Call addTransceiver", and the fact that no equivalent of step 10. can be found for addTransceiver() is probably a bug.

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1758#issuecomment-415188419 using your GitHub account
Received on Wednesday, 22 August 2018 21:34:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:04 UTC