Re: Presets and profiles

> Almost. The transcodebin would need to be smart to stop decodebin from decoding
> streams if remuxing is enough. 
Sure. It may be a interesting problem to solve by the way.

> And an encodebin does not make too much sense as
> you need to specify encoders and muxers anyway. 
> We coudl have a function in the
> library altough, that given the specs, creates and ordinary bin and adds the
> requested elements there.
Yes. We need a piece of code that builds the tail of the pipeline from a
profile and a given stream.
But, It can be presented as a single bin, black box, using ghost pads
inside).
>  We would need to define the needed info for doing that:
> - Transcoding: you get media-specs from deodebin
> - Encoding: the application provides it
> These media-specs could e.g. be a list of pads.
>   
The pads seems to be a good choice.
> Now we let the user choose a format that can handle the spec. (like if there is
> video, we don't offer wav).
> When you have the target format, create a bin for it and link pads. In case of
> transcoding if would eventualy restart the decodebin to avoid the decoders.
>
>
>   
>> Let's say an encoding library then.
>> With an optional direct from file encoding.
>>
>> It can be a good idea to make a list of all application that may want to
>> use theses libraries and define a set of use cases!
>>
>> * Converters (transcoders)
>> * Extractors (sound-juicer, music players)
>>     
>     Thoggen for DVDs :)
>   

This one seems to be the most difficult case :)
Multiple video streams, subtitles and audio...
+ removable media source
>> * Multimedia editors / authoring tool
>>     
> I think its really two things Encoding (kind of transcoding from raw) and
> Transcoding.
>   
I totally agree, but it seems possible to handle both at the same time I
think.

David