What's the best way of making a video as an output of a Perl program?
+1
A:
Video what? You can always use a simple graphics library like GD and a whole lot of ffmpeg to do what you want.
tadman
2010-07-05 15:38:11
Yes, using gd to print a whole lot of images to the hard drive and then arraying them into ffmpeg would do it.But its very slow for it uses the hard drive a lot.. unnecessarily.
Hermann Ingjaldsson
2010-07-05 15:41:00
I don't know what you mean by "uses the hard drive a lot". If you're creating video you're going to need to manipulate a lot of data. Generating a twenty second clip, which is about 600 frames, should not take very long. The way most video codecs work means you cannot simply add frames to a video one at a time. You need to create a bunch of raw frames, then encode them in a small batch operation.
tadman
2010-07-05 16:31:59
I mean that i need to write a lot of stuff into the hard drive, and then read it again from the hard drive.Doing so takes up enormously much more time than simply doing things in the ram and then sending it straight to the screen.
Hermann Ingjaldsson
2010-07-05 16:37:29
Although you could be paranoid and make a RAM disk to handle your temporary storage needs for this kind of operation, most operating systems do a very good job of buffering your disk activity. If you really need maximum performance, you're going to have to interface with a codec directly using the C API and a good helping of Inline::C. This is an adventure that is not for the faint of heart. The FFMpeg app can blow through frames in greater than real-time, so I don't know what your performance problems are. Do you have some benchmarks to illustrate your issue?
tadman
2010-07-05 19:51:45
Since you haven't mentioned which OS you're on, I'm not sure what tools you have available. For example, on Windows there is the Windows Media library, and on OS X there is QuickTime. One way to keep things in "memory" is to make ffmpeg read in from a temporary UNIX socket created by your Perl process which generates contents on the fly, but that's far from ideal. Most OS disk buffers will make quick write/reads nearly as fast as memory anyway.
tadman
2010-07-05 19:56:08
A:
DOES NOT WORK!!!
UPDATE: Please ignore the below answer - upon reading through FFmpeg's source code, the URL input is not streamed - it's merely downloaded whole into a file and then regular file processing is done :(
I'm still leaving the answer up in case someone looking later find the FFMpeg's existance a useful info for Perl video processing, even though it doesn't help in this specific case.
ORIGINAL ANSWER
FFmpeg does not (based on POD) seem to allow an in-RAM sources, but it does allow URL based ones. So at the very least you can hack around needing to do disk IO by streaming your raw data via Apache or some smaller web server, and using the FFmpeg's URL input to retrieve that data from http://localhost:yourport. The raw data would natually come to the web server from a Perl program running under mod_perl/FCGI
DVK
2010-07-05 19:35:24
+1
A:
If you can figure out how to produce a data stream that ffmpeg's yuvmpeg4pipe input module can handle, then you could send your data into a fifo to avoid hitting the disk with with intermediate data. Being that the yuvmpeg4pipe seems to just be a header-less data stream it should be fairly easy to replicate.
This link might give you some ideas: http://kylecordes.com/2007/pipe-ffmpeg
You could also try setting up either a memory mapped file or ramdisk of sorts to write into. But even a system with 16 gigs of ram is going to fill up very quickly when working with uncompressed video.
In general it is usually better to just write out the uncompressed files (probably an image sequence in your case) and then compress it after its exported. The reason being, if you are doing anything interesting in the video, it will probably take many times longer to render the uncompressed frames than to compress the video. By saving the uncompressed copy, you are free to compress to different targets, or fine tune your compression settings...
In addition, working with image sequences opens the door to parallel processing on multiple cores or even multiple computers. This is how many commercial video rendering systems achieve greater speeds.
Eric Strom
2010-07-06 19:26:23