Dealing with unwanted source pads.

[Stirling Westrup]

What other options did you try? I'm wondering because I'd *really* rather
not have a fake sink as that means I'll be taking the CPU time to process
and then throw away each track, and my program needs all the CPU it can
get...

So far I've thought of trying:

1) Ignore the extra pads (doesn't seem to work)
2) call gst_element_remove_pad on the pad (docs say don't do that...)
3) call gst_pad_set_active(pad,FALSE), but I suspect that is also a bad idea
4) add a probe to each unwanted pad that blocks and flushes all buffers on
that pad.
5) add a fakesink (don't want to take the CPU hit).

Can anyone think of other options?


On Thu, May 16, 2013 at 1:46 PM, Paddy <pat.blanchon at gmail.com> wrote:

> I encountered a similar problem with the rtspsrc element, which starts all
> streams it finds, even though I'm not at all interested in them.
>
> My solution was to create/add/sync/link a fakesink in the pad-added
> callback
> for all pads I don't care about. AFAIK there's no other way.
>
> Cheers,
>
> Paddy
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Dealing-with-unwanted-source-pads-tp4659965p4659966.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>



-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130516/bf9abd8e/attachment.html>