On Mon, 2011-03-07 at 11:43 -0300, Tiago Katcipis wrote: > Decodebin is not > > > really suitable, because for RTP, you need to discover all the > possible > codecs before starting the call (so before getting any data), > so that > the codecs can be negotiated with the other side. While > decodebin just > decodes as it goes along. > > Dont know if i get the problem correctly, but if you need to now the > available codecs on the client you could do something similar to what > decodebin already does with gst_element_factory_list_get_elements, > listing only GST_ELEMENT_FACTORY_TYPE_DECODABLE, do negotiation, and > then let decodebin do his job when data arrives. Well it is just an > idea...again...i dont know if would cover all the cases that farsight > needs to handle ( and it handles just fine :-) ).
To know if a codec can be used, I need to check if there is a payloader, a depayloader, an encoder and a decoder. And once I found all of those, I don't really need decodebin anymore (since I know all the elements I need). -- Olivier Crête olivier.cr...@collabora.co.uk Collabora Ltd
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________ Farsight-devel mailing list Farsight-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/farsight-devel
