> 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 _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
