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
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...
Author: Wim Taymans <email@example.com>
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
We now either have an encoding-name or a pt in the sinkpad caps of
Author: Marc Leeman <firstname.lastname@example.org>
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
In essence, this patch will add support for a lot of Bosch hardware encoders
without breaking autoplugging.
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).