On Wed, Mar 26, 2008 at 02:30:18PM +0100, Peter Ueger wrote: > 2008/3/25, Jacob Meuser <[EMAIL PROTECTED]>: > > multiple processes are not the same as multiple threads. > > They have a similar purpose. If you want multiple process, pipe your > output into another instance of ffmpeg or another commandline encoder > like xvid_encraw, x264, lame, etc.
so? thats not part of ffmpeg's design. it does not do that on it's own. big difference between what you _can_ do with something, and how it operates by default. > > right, but I can't build an outside module. it has to be built into > > ffmpeg. > > What's so bad about this? because then I have to rebuild all of ffmpeg for maybe just a couple hundred lines of code. that's a waste. > > ffmpeg cannot read from DVD devices, which was the main goal of > > transcode when it started. > > Why would you want to do that? DVD drives are slow. Don't you rip your > DVD with vobcopy or mplayer -dumpstream to your hard disc first? maybe, maybe not. do you really think two steps are necessarily faster than one? > > despite ffmpeg being able to read from pipes: > > > > $ tccat -i /dev/dvd | ffmpeg -i - > > > > really doesn't work very well in my experience. > If you are certain your code is correct, send a bug report to > http://roundup.mplayerhq.hu/roundup/ffmpeg/ it's ffmpeg's fault, not tccat's. it's simple. ffmpeg just disregards the container frame rate and uses the stream frame rate. does it also if the stream is ripped to disk first. put simply, ffmpeg is NOT the be-all-end-all of video processing, period. I really don't understand why you are trying to argue, on a transcode list, that transcode developers should just mode to ffmpeg. especially when it's already been pointed out that transcode and ffmpeg have completely different goals. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
