[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gallery-devel
Subject:    Re: [Gallery-devel] A final thought on transcoding
From:       Tom <siggma () trbailey ! net>
Date:       2009-01-26 0:44:53
Message-ID: 497D0785.1050209 () trbailey ! net
[Download RAW message or body]

Andy Staudacher wrote:
>
> I read your posts on the topic, but I couldn't see any results of your 
> tests on dreamhost. It would be great if you could summarize the 
> results of your tests.
I'll have to wait a while. I'm nearly over my monthly limit on Dreamhost 
for now. On small files >4 meg or so it's nearly instantaneous. I spent 
hours yesterday fiddling with mencoder. It works but ffmpeg is just as 
fast. If you wanted to support more input formats it's an option though.
> (typical 5 minute video of type X with resolution Y and frame rate Z 
> takes __ seconds to transcode to h.264 .flv)
Got it.
>
> I guess the typical video you'd host in G3 is 30 seconds to 5 minutes 
> long, with up to 720p resolution (which is getting more and more 
> common in compact cameras). From looking at recent CPU benchmarks, 
> doesn't it take in the order of 1 second to transcode 5 seconds at 
> that resolution? Hence my concerns about long running processes.
>
Your benchmark sounds about right from my experience.  5 minutes of 720p 
would be a burden all at once but not if you leverage the slow upload 
speed. I'd be more worried that someone would kill the script and 
restart it, thinking it will run faster next time.
>   
>
>     If you transcode a file as its uploaded
>     you'll minimize overall impact on server resource as well as limit
>     server I/O and prevent any non-video data from even being saved.
>     However, this approach makes many assumptions but it might be
>     something
>     to think about.
>     Andy?
>
>
> A pipeline, streaming the data to the transcoder as it is uploaded?
> a) With PHP's standard file upload API, you don't get access to the 
> uploaded file before it's been uploaded completely.
> I.e. the PHP script gets control once all POST data has arrived on the 
> server.
> There might be options to work around this (PHP 5.2's file upload 
> progress API comes to mind), but I don't think it's very simple and 
> it's thus not worth looking into this for our first iterations of 
> video support.
> b) Probably less of an issue, does MEncoder support input streams 
> (instead of files)?
>
Just pass the URL directly to ffmpeg as the input file and let the host 
figure it out. It works fine provided it's properly escaped and contains 
no single quotes. At least in my tests, even on Dreamhost. FFmpeg output 
then becomes your uploaded video, neat and hopefully squeaky clean. See 
script for how I manage it. The runExternal() spawns ffmpeg as an 
attached process and captures it's output to a string. If the process 
were released from PHP and a sleep loop checked the size of the output 
file, one could provide a progress indicator. As long as you have the 
process id you can kill it if it gets lost or stops progressing.

For compressions I noted aprox 60% reduction using large avi test files, 
I.E. an upload of 35 meg produces a 13 meg output file.
I'll do more testing later when I have some bandwidth to fiddle with, 
like Feb sometime.
-Tom

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]
[prev in list] [next in list] [prev in thread] [next in thread]