From #24936 CodecOffer (and the NewCodecOffer signal) should offer a way for the streaming implementation to know which codecs changed and which didn't. It's not clear to me if it contains the codecs from everyone or just from those who joined/changed.
Created attachment 37904 [details] [review] Put only one Contact per CodecOffer Giving all the codecs of all the users is a bad idea. It can not happen atomically. The current spec is not implementable as-is. One CodecOffer should contain codecs from only one contact. Either we keep on having one codec offer at a time and the CM decides the order. Or we can can replace the CodecOffer property with "CodecOffers" and have an array of offers.
Another option is to define the API as the following: they will all be applied in order, if one fail, then rest will on be tried (and then we need to say which one was rejected in the Reject() call) But it seems easier to accept/reject them one at a time.
Sjoerd and ÔlÎvÎÊr say ja oui yes to this. Splendid. In reality they will only come one at a time (in muji). Okay, good.
See my branch.
I don't think there is much of a point of having a mapping to multiple codec offers, if we say they come one by one they should just come out of the interface one by one (the CM can just queue them)
(In reply to comment #5) > I don't think there is much of a point of having a mapping to multiple codec > offers, if we say they come one by one they should just come out of the > interface one by one (the CM can just queue them) So are you happy with my branch without the most recent commit, 80a88995ea?
Created attachment 39938 [details] [review] fix your branch here is a patch against your branch that does the right thing I believe.
Combined jonny's top patch and oliviers patch, with some extra goodness of my own and merged it to master, thanks guys!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.