Question

I’m currently working on the server side of an augmented reality project. It’s a lot like http://www.livingsasquatch.com/. I’m using PHP/MySQL and FFmpeg to capture the webcam video and encoding it to .flv.

Basically Flash uploads the video as a long series of .jpg images. PHP then takes those images, generates a few thumbnails and passes them through FFmpeg which converts them to a single .flv file.

Here is the FFmpeg code:

$ffmpeg_images = $image_directory.'/image%d.jpg';

@unlink($video_directory."/$video_id.flv"); 
$ffmpeg_video = $video_directory."/$video_id.flv";
$ffmpeg_string = FFMPEG_PATH." -f image2 -i $ffmpeg_images -f flv $ffmpeg_video";

@exec($ffmpeg_string);

This seems to be working nicely in my tests, but I don’t know how we’ll it will scale. Since this is my first time using FFmpeg, I don’t know if video encoding this way will bring the server to its knees.

Does anyone have experience with FFmpeg on a high traffic site?

Is there a better way of handling this type of Webcam to .flv conversion?

Are there any examples of FFmpeg being used on a high traffic site?

Answer 1

Your fundamental workflow seems sane to me. I’m sure there are other approaches. Just a series of bullet points to answer your question:

• FFmpeg is a video encoding leader; Arguably ‘the’ leader. You should not worry about it itself being a problem, but more about how you are using it, your parameters, etc.
• Your above script’s FFmpeg parameters are pure default. You may get better, more efficient performance if you try out different parameters. There are many. You should to spend some time tuning the FFmpeg parameters.
• Video encoding is inherently very CPU intensive. If you are going to have any sort of volume, then you are going to have plan for it. That means running some tests, recording some metrics, and making projections. It also means paying close attention to your hardware. E.g.: The new Intel Core i7 CPU absolutely rocks at video encoding–multiple times faster than an MHz*core-count equivalent Core 2.
• You should be able to kick off the FFMpeg jobs at as lower priority processes than your web server, etc. This will keep your server snappy even when pegged at 100% utilization.
• If you really are going to handle volume traffic, then I would strongly suggestion moving the FFmpeg work to auxiliary, dedicated encoding servers. Depending on your traffic, you may even need an encoding farm.

In summary, it seems to me your questions are more ‘system architecture’ and ‘encoder parameter tuning’ related.

There is only one other fundamentally different approach I can think of that would dramatically reduce your server side encoding load, and that would be to handle everything on the client side. But somehow I think you’ve already discounted that approach.