On Thu, Dec 11, 2008 at 2:27 PM, Rene Veerman <rene7705@xxxxxxxxx> wrote: > German Geek wrote: > >> On Thu, Dec 11, 2008 at 1:53 PM, Rene Veerman <rene7705@xxxxxxxxx<mailto: >> rene7705@xxxxxxxxx>> wrote: >> >> Colin Guthrie wrote: >> >> 'Twas brillig, and Rene Veerman at 10/12/08 23:03 did gyre and >> gimble: >> >> Well, nowhere can i find the frame count being printed, >> but there _is_ a duration: hh:mm:ss:ms field outputted, >> and the updating line displays a time=seconds.ms >> <http://seconds.ms> (the time in the movie where the >> >> encoder is at). >> >> The question remains how to get at that updating output, >> with exec() you get the output after it's done completely. >> And there's no way to do partial conversions with ffmpeg, >> it's all in one or nothing.. >> >> >> IIRC you can use popen and just read the output into PHP. >> >> http://uk.php.net/manual/en/function.popen.php >> >> That said, if I were you I'd do this system slightly >> differently. I'd do the submissions via the web, but then do >> the encoding as a kind of daemon process/cron job that runs on >> the server. This cron job would do the encoding and update a >> db table periodically with progress. That way you can have a >> page the user goes to that sees their "job progress". >> >> This way the user's browser will not time out and you wont use >> up apache connections waiting for encodings and also you wont >> kill your server by performing multiple encodes at the same >> time - with the cron job/daemon approach you can control how >> many jobs are performed at the same time and thus limit the load. >> >> Just some thoughts. >> >> Col >> >> >> Yep, this is already how it works.. Cron calls a php controller >> daemon script (if it aint runnin yet), which reads the various >> open tasks, and executes one task step (convert & import a single >> media file) at a time for each open task. >> It terminates after no more tasks have steps to do. >> The scripts executing the task update a status JSON file in the >> tasks' working directory, which is the only thing being read by >> the browser after it's kicked off the import process by calling >> the daemon server with the list of files to import. >> >> i've taken a look at popen() and think i can indeed get it to work >> with that.. >> i'll let you all know in this thread where to view a demo, when it >> works :) >> >> >> Cool, would like to see it in action. >> In case you haven't thought of this and it's relevant: >> If ffmpeg is writing out a file and you can estimate the final size, you >> could check the file size, if it's growing that is, and compare it to the >> estimated final size to show the progress. Maybe not the best solution but >> if there is nothing else. >> >> i've thought of it, and considered it too random to even try to estimate > ;) OK. So you have tried converting a couple of vids and the resulting file size is always random? Surely there must be some kind of relation to the input file size, the transcode parameters and the output file size. Of course it also depends on the nature of the video but you could also take into account the file size and the time it took to get to that file size (during the process) in relation to the input file size. > > If you don't mind, i would like to know some good parameters for ffmpeg to >> convert video files to flv format. Might use it in the future. >> >> > > $cmd = 'nice -n 19 ffmpeg -i "'.$sourcePath.'" -b 5000000 -acodec mp3 -ab > 192 -ar 22050 -y "'.$destination.'"'; > > that's what i'm using now. it spits out files larger than the divx > originals that i'm using for testing purposes. > -b <number> is used to set the quality and size of the output flv > > usefull too; > http://www.catswhocode.com/blog/19-ffmpeg-commands-for-all-needs Thanks. -- Tim-Hinnerk Heuer http://www.ihostnz.com
