GNOME Bugzilla – Bug 796801
find_codec_preferences: use received caps
Last modified: 2018-07-18 16:33:14 UTC
When negotiation is triggered by receiving caps in our pad probe, this addresses a race condition where gst_pad_get_current_caps did not necessarily return the caps, as when the probe is triggered the "current caps" have not yet been set. Instead, as we save the caps in the probe callback anyway, it is better and thread safe to use these if they were set.
Created attachment 373009 [details] [review] find_codec_preferences: use received caps
Review of attachment 373009 [details] [review]: Makes sense but I think the commit message doesn't explain so well the issue :-) ::: ext/webrtc/gstwebrtcbin.c @@ +1264,3 @@ + if (pad->received_caps) { + caps = gst_caps_ref (pad->received_caps); + } else if ((caps = gst_pad_get_current_caps (GST_PAD (pad)))) { Is that still needed now that you use the "cache" caps?
Created attachment 373012 [details] [review] find_codec_preferences: use received caps When negotiation is triggered by receiving caps on our sink pad probes, we could encounter a race condition where need-negotiation is emitted and the application requires the creation of an offer before the current caps were actually updated. This led to retrieving incomplete caps when creating the offer, using find_codec_preferences -> pad_get_current_caps. Instead, as we save the caps in the probe callback anyway, it is better and thread safe to use these if they were set.
(In reply to Thibault Saunier from comment #2) > Review of attachment 373009 [details] [review] [review]: > Is that still needed now that you use the "cache" caps? Potentially, if the user calls create-offer before need-negotiation was emitted, I do not know how legitimate that is but I'd rather we break^W address that in a separate patch :)
Review of attachment 373012 [details] [review]: OK
Attachment 373012 [details] pushed as 6fd3e2a - find_codec_preferences: use received caps