[RFC] autoparse element

[Andrey Utkin]

> On Thu, 2013-12-05 at 22:23 +0100, Sebastian Dröge wrote:
>> The idea for such an element sounds good, but the implementation should
>> not have hardcoded formats but instead do autoplugging like decodebin.
>> You would use the GstElementFactory API to find appropiate parsers for
>> the caps you get.

Thanks for the direction. Seems gst_element_factory_list_filter() is
what you suggested.
Regarding caps parameter, i guess mediatype should be copied from
unparsed stream caps, and a property must be set, like "parsed=TRUE".
The pain is that some parsers (aacparse, ac3parse) have caps property
name "framed", others (h264parse, mpegvideoparse, mpeg4videoparse)
have "parsed". Is that a special design (i see audio parsers have
"framed", and video parsers have "parsed")? How to overcome this
difference without hardcoding?

2013/12/5 Olivier Crête <olivier.crete at collabora.com>:
> Or you can just set the template caps from the muxer and set these as
> the "caps" property on decodebin. then you can do
> udpsrc ! video/mpeg-ts ! decodebin caps="the template caps from mpegtsmux" ! mpegtsmux ! udpsink

I don't like the idea of hiding the demuxer element into decodebin,
because i want to manage elementary streams knowing their PIDs. As i
see decodebin srcpad template is different from tsdemux one, so i
guess PID won't be accessible.

-- 
Andrey Utkin