On Fri, 15 Sep 2006 13:57:42 -0700 Phil Ehrens <[EMAIL PROTECTED]> wrote:
In order to make things clear, let me explain what I mean with 'ffmpeg' module: while import_mplayer uses an external binary (mplayer!) to do it's work, import_ffmpeg uses ffmpeg libraries (libavcodec/libaformat/libavutil) and not depends from any external program. In other words, import_mplayer uses mplayer program, but import_ffmpeg DOES NOT uses ffmpeg program :) > > - 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. Yes. I never liked so much import_mplayer ;P No technical reasons (benchmark or stuff), it's kust my taste, I don't like too much to spawn fifos or processes around. > > - 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? In transcode? Yes. The import layer is definitively the part of transcode that I like less. Neverthless I don't want to weaken too much import layer, in order to let transcode still to be a complete solution, not just an encoder, i.e. not depending from other *programs* for decoding. Libraries are a different story. > 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. adding a transcode filter that in turn accesses mplayer (some of) filters could be a funny (and pretty hard I guess) task :) > 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, That's an interesting point of view. The advantage in import_mplayer was outlined before, it eats happily an huge amount of formats/codecs and it has the filters bonus. Except for this (!!) it doesn't help transcode too much (!!!), or no more than other modules. Best regards, -- Francesco Romani - Ikitt ['people always complain, no matther what you do'] IM contact : (email first, Antispam default deny!) icq://27-83-87-867 known bugs : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
