- From: Harald Alvestrand <hta@google.com>
- Date: Wed, 12 Feb 2014 00:07:34 +0100
- To: Iñaki Baz Castillo <ibc@aliax.net>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOqqYVFwJEJe35LN0ajzRgq2NwKxkKYgFR=BUs28uwAxhTPCPg@mail.gmail.com>
On Tue, Feb 11, 2014 at 11:55 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote: > 2014-02-07 14:54 GMT+01:00 Harald Alvestrand <harald@alvestrand.no>: > > 1) It is only needed when talking to devices that use CSRC mapping. This > > is a property set that belongs to the peerconnection abstraction > > (probably on the receiving doohickey), not to the more generic > > MediaStram connection. > > If that "event" (or whatever) belongs to PeerConnection then the > reference to the MediaStream and/or MediaStreamTrack should also be > provided by the callback, so we end in the same case. The problem here > (IMHO) is having all the stuff on a single object (PeerConnection). Of > course I don't want to expose WebRTC related stuff into > MediaStream(Track), but adding everything on top of PC is not the > proper way to go (IMHO). > > Yes, that's why I want it to be on the RTPReceiver object. We already have one of those per MediaStreamTrack. > > > > 2) If this is going to be useful for active speaker switch indication, > > the notification has to happen on a sub-second basis - too fast for a > > reasonable periodic event. > > It could be relaxed/limited by the spec (i.e. just fire every 0.5 > seconds). I don't get how a JS periodic timer can be better, but maybe > I am wrong. > Try it and see.... my instinct is that events in JS have a bit more overhead than a callback. I could be wrong. > > > Best regards. > > > > -- > Iñaki Baz Castillo > <ibc@aliax.net> > >
Received on Tuesday, 11 February 2014 23:08:21 UTC