GNOME Bugzilla – Bug 639292
remove pt value from selected rtp pay/depayloaders
Last modified: 2013-07-19 11:56:30 UTC
Created attachment 178115 [details] [review] put payload in sink caps in comment This patch removes the payload requirement in the caps of - rtpmp4vpay - rtpmp4vdepay - rtph264pay - rtph264depay - rtph263pay - rtph263depay - rtph263ppay - rtph263pdepay Rationale: encoding name is required in the caps and is a better fit for autoplugging than the pt value. Hardware manufacturers have a bad habit of skimming through RFCs and in this case; use unassigned numbers for encoders instead of dynamic numbers. However, I could not really find any reference in the RFC that I had a look at that explicitly forbids this (though it is poor practice since the number are unassigned). In essence, this patch will add support for a lot of Bosch hardware encoders without breaking autoplugging (we are running this fix a couple of months)
The can be more general; but I've provide only the ones that we have tested.
Maybe you should leave the static ones in place.. so that if you do "... rtph263pay ! udpsink", it would still provide the right result.
None of the (de)payloaders use static payload types in the submitted patch; so there is no real added value in the caps negociation. The pt value of the example will give you a pt of 96 in any case; not the static 35 for H263 (IIRC). You will need an extra lookup in your code for that (we do that for static ones like MPEG2 etc, ...).
sorry, I read h263p as h263..
Still the same, both use dynamic PT values in their src pad. IIRC most video gstreamer payloaders just set the pt to 96 by default. Don't know about audio ones. Setting the pt to a static one is a manual action; caps filtering it is not really useful.
*** Bug 621296 has been marked as a duplicate of this bug. ***
I only relaxed the restrictions in the depayloaders. I don't see a reason why we should allow wrong output from our payloaders... commit 4397c8ffbfdac3fee7db98cf3cded08f0f07d569 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Jan 28 12:41:04 2013 +0100 rtpdepay: remove payload type restrictions Remove the pt restrictions for all the depayloaders that have an encoding-name. We can use this to autoplug decoders. Remove the encoding-name for all the payloaders with a fixed payload type. We now either have an encoding-name or a pt in the sinkpad caps of a depayloader. See https://bugzilla.gnome.org/show_bug.cgi?id=639292 commit bab2f3c92b32b82eff7112baa7765935d8c4025e Author: Marc Leeman <marc.leeman@gmail.com> Date: Mon Jan 28 12:23:41 2013 +0100 rtp: remove payload requirements from selected depayloaders encoding name is required in the caps and is a better fit for autoplugging than the pt value. Hardware manufacturers have a bad habit of skimming through RFCs and in this case; use unassigned numbers for encoders instead of dynamic numbers. In essence, this patch will add support for a lot of Bosch hardware encoders without breaking autoplugging. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=639292
Cherry-picked into 1.0 branch as well, for 1.0.9, needed to make mulaw depayloader work properly if only payload=0 is given without encoding-name, because of the stricter caps subset handling (see bug #704533).