Sunday, February 27, 2011

Re: how to redirect and let the server do some lengthy job in the background?

On Feb 28, 2011, at 01:14, Zaky Katalan-Ezra wrote:

> On a Linux machine create a bash file like this
> -----
> #!/bin/sh
> ffmpeg -i $1 -r $2 $3 &
> -----
> The ampersand at the end tell the bash to run in the background.
> the $n is parameters.

.....yes..... well, you've forgotten to properly quote/escape your arguments, for one thing. Filenames containing special characters or spaces will break that. (You would at least want: ffmpeg -i "$1" -r "$2" "$3" &)


> From php call it like this:
> $command = mybashpath.sh inputfile.mpg 24 outputfile.flv;
> exec ( $command );
>
> As you can see I called the bash file with three parameters.

You forgot to quote/escape the arguments there too. (escape_shell_arg(), etc.)

But there's really no need to introduce a separate bash script here. You can just as easily build up the entire ffmpeg command line in PHP and exec() it directly.


> If you set a log for the ffmpeg command you will be able to check the execution status and show it in the index view

.....yes, you could do that..... That might be useful, but...

What if an error occurs? The video simply ends up not getting encoded.

By what means does some other part of the web site discover when encoding has finished? Presumably it might take minutes to encode a video, and when it's done encoding, users should be able to view it on the site, but not before.

I like the solution I wrote about better, where a separate process takes care of encoding videos when there's time, outside of the confines of the web server which is not designed for such tasks, and it results in a field in the database being updated when encoding has finished. This yes/no field can be shown on a view to show whether encoding is done or not, and can also be used by other parts of the site to decide which videos to show to other users (i.e. only the ones that have been encoded). This could of course be extended to store additional information in the database in the case of an encoding failure, or even to keep a log of the encoding somewhere so that an view could read it and provide more detailed encoding status.


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.


To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

No comments: