aggregator: Don't try to be too smart while allocating pad names
authorNirbheek Chauhan <nirbheek@centricular.com>
Sun, 27 Mar 2016 13:11:30 +0000 (18:41 +0530)
committerSebastian Dröge <sebastian@centricular.com>
Mon, 28 Mar 2016 10:46:00 +0000 (13:46 +0300)
commitcb53a6284f248edf184b1f32594e0c56c88407d8
tree3646ca0e28aee9aedabce6a0bae5748c12584e3a
parentc32e74fd8aadf7e8e5499a3cc7f01a35ad2f0394
aggregator: Don't try to be too smart while allocating pad names

Previously, while allocating the pad number for a new pad, aggregator was
maintaining an interesting relationship between the pad count and the pad
number.

If you requested a sink pad called "sink_6", padcount (which is badly named and
actually means number-of-pads-minus-one) would be set to 6. Which means that if
you then requested a sink pad called "sink_0", it would be assigned the name
"sink_6" again, which fails the non-uniqueness test inside gstelement.c.

This can be fixed by instead setting padcount to be 7 in that case, but this
breaks manual management of pad names by the application since it then becomes
impossible to request a pad called "sink_2". Instead, we fix this by always
directly using the requested name as the sink pad name. Uniqueness of the pad
name is tested separately inside gstreamer core. If no name is requested, we use
the next available pad number.

Note that this is important since the sinkpad numbering in aggregator is not
meaningless. Videoaggregator uses it to decide the Z-order of video frames.
gst-libs/gst/base/gstaggregator.c