GNOME Bugzilla – Bug 785777
rtpsession: Also cache RTX stream caps and send caps
Last modified: 2018-11-03 15:21:12 UTC
See commit message
Created attachment 356860 [details] [review] rtpsession: Also cache RTX stream caps and send caps The RTX stream can time-out after a while, causing the internal source to be destroyed and then it forgets clock-rate and everything. By caching the RTX stream caps, we make sure that we can always get all the required info again later if RTX is needed again.
I'm not sure if it's a good idea to store send and receive caps in the same pt map, but that's how it implicitly was before already: the signals/callbacks to request clock-rate and other things did not distinguish between send and receive and were emitted for both.
Review of attachment 356860 [details] [review]: Also if we wanted to support H.323, we'd need different send and receive codecs. I'm also not super happy with the RTX specific code in rtpsession, but I can survive. ::: gst/rtpmanager/gstrtpsession.c @@ +1540,1 @@ + if (rtx_payload != -1 && rtx_payload != -1 "rtx_payload != -1 && rtx_payload != -1" .. you seem to have one too many ?
Indeed, will update later :) Thanks For send!=receive codec, this only works coincidentally currently (the PT map was previously already used for both send and receive). If we want to support that, we have to do it properly and untangle some things. For having RTX specific things in there, it should probably be rather some kind of "related streams" than RTX. But you somehow need a way to be able to know these details for each of the two streams (normal and RTX stream).
Created attachment 357085 [details] [review] rtpsession: Also cache RTX stream caps and send caps The RTX stream can time-out after a while, causing the internal source to be destroyed and then it forgets clock-rate and everything. By caching the RTX stream caps, we make sure that we can always get all the required info again later if RTX is needed again.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/393.