Francesco Romani wrote: > > I've no a precise plan so far. I've only some thoughts: > - mplayer can digest/probe even more (or sometimes more reliably) > formats/codecs than ffmpeg, but ffmpeg has a much better integration > (no fifos, no external processes, no external dependencies...) > So, IMHO ffmpeg should be always preferred on mplayer. Mplayer > should be used as very last resort or just ignored unless user > selects it explicitely.
And, of course, mplayer is a wrapper around ffmpeg for most things, so if transcode wraps ffmpeg more completely the need for mplayer is naturally lessened. > - it's probable that ffmpeg always does a better job than our code > in probing and/or demuxing and/or decoding, but I still like to prefer > specific modules (import_mpeg2/mp3 and stuff) > - same as above for probing routines Maybe. But aren't the export modules where the real vaue added comes in, with things like lame? > Last (but related) topic: better to have a specific identifier > for every format/codec handled by ffmpeg or to use just one tag like > for mplayer? Since ffmpeg's interface has a habit of changing, doesn't it make more sense to use the mplayer model, and to support the passing of ffmpeg options transparently in the same way that mplayer options can be passed now? I couldn't live without the ability to add '-vf eq2=...' to the mplayer import module. The filters that are available via mplayer are at least as important as the probing magic. As I have said before, the wonderful thing about transcode is it's miraculous automatic geometry management. The ability to be able to batch process mixed codec/geometry/container into a single target format without having to calculate any geometry is a huge win. The degree to which import modules can help with that task via accurate probing is the measure of their utility to transcode, IMHO. Phil
