docfaraday
docfaraday
> > Then again, this is one of those situations that a reasonable implementation should not care about. > > It would seem that Chrome, Chromium, or libWebRTC(not sure which...
Yeah, I think being explicit here is necessary.
When it comes to what a bfcached peerconnection being revived looks like, I think the key thing to be thinking about is whether there is any other endpoint that is...
> Without taking a position on this technical change, it's not appropriate for W3C specs to override JSEP. > > The correct thing to do is to make the change...
I should note that semantic matching of sdpFmtpLine would not be sufficient to fix this problem; max-fr=60 and max-fr=30 are not semantically equivalent, but we probably still want the .codec...
Fundamentally, the problem we have here is that most fmtp values are not a distinguishing feature of a codec, but in rare cases they are (eg; profile-level-id for H264). Right...
It depends I suppose; if JS sets VP8 with 60 fps as its preferred codec, and the other end says it wants to do H264, or VP8 with 30fps, should...
Right now the spec allows (and wpt tests for) populating .codec from the return of getCapabilities. (If we disallow this, that would solve this problem, probably. You could still in...
> I'm currently working in this area (coming in from PT assignment, but "are these equal" comes in a lot there). Codec capabilities are what one wants to receive, and...
> > ... fmtp in the capabilities differs even slightly from what the remote puts in its SDP, we won't try to honor that .codec setting because it doesn't match....