In a (soon to be released version of) App::VideoMixer, I use ffmpeg.exe to capture the video and output as a raw bytestream to stdout. The essential command line is:

    my $pixel_format = 'rgb24';
    my $file = 0; # device number 0, or .avi file, for reproducible te
+sting
    my ($pid,$stream) = $self->spawn(sprintf qq{%s -f vfwcap -r 30 -i 
+%s -f rawvideo -pix_fmt %s - |},
        $self->ffmpeg, $file, $pixel_format
    );
[download]

It works like a charm with ffmpeg v0.5 and saves me the hassle of downloading and compiling a lot of hard to compile libraries and their prerequisites.

In order to get the slider functions working I am planning to use something like:

ffmpeg -f vfwcap -r 25 -i 0  -f image2 temp_photos\foo_-%03d.jpeg

In order to give me a directory of "frames" without any exclusive lock. This works, although I'm not sure what the highest number is, or what it'll do to my disc fragmentation!

Then I can just do a while loop through them, and they'll look like a video. On exit, I'll do the opposite and recombine them into a video.

However, it's not the most elegant, if I could do it nearer to your method I would, however I do need to write something to a file, because wxMediaCtrl needs a filename or URL

Regards

I'm not sure where a slider control can come in helpful, because for me, time is still linear. I'd be very interested if you could show me how to control/adjust the flow of time through a slider, especially if it works in both directions :).

But if you want to farm out start/stop/rewind of a movie to another control (which is sensible), my approach of reading single frames won't work out unless the control has a way for you to feed it single frames. Maybe you can hand the control a filehandle instead of an URL or a filename, but (pipe) filehandles have the disadvantage of not being seekable...

Hi Corion,

I've had a look a VideoMixer, thanks for this. I'm using wxMediaCtrl to output. I've tried streaming FFMPEG to a file (which works) and then opening with wxMediaCtrl, (which doesn't, because the file is opened with an exclusive lock by FFMPEG). I need wxMediaCtrl to be able to work a bit like Youtube with a sliderbar to rewind and play parts of the video, I also want to take snaps and clips and stuff. This is all working if I play an .avi file. However, I've only made it work for a live source with a streaming Server like BraodCam, which degrades the quality as it assumes inet delivery.

Your plan uses standard output and FFMPEG, which seems like a good idea. I think I can make it work with FFMPEG, but what command do you use to stop it?

I've looked through VideoMixer, but I can't see where you stop the streaming process. I'm not familiar with GL, so maybe I just missed it.

Thanks for your help.

regards

I simply kill the process upon exit. That's not the most grateful thing but it works:

package App::VideoMixer::External::FFmpeg;
use strict;

use vars qw($VERSION);
$VERSION = '0.02';

use parent 'Class::Accessor';
__PACKAGE__->mk_accessors(qw(width height depth pid stream texture_id 
+file pixel_format ffmpeg));

sub spawn {
    my ($self,$cmd) = @_;
    my $pid = open my $stream, $cmd
        or die "Couldn't spawn '$cmd': $!/$?";
    binmode $stream;
    return ($pid,$stream)
};

sub DESTROY {
    if (my $pid = $_[0]->pid) {
        kill 9, $pid
    };
};
[download]

This will kill the external process once the object gets destroyed. You can read the data from $stream and you have to set $self->pid to the returned $pid (and looking at this code, I'm not sure why ->spawn does it that way instead of setting $pid instead - I guess it's because I turned a subroutine into an object later).

As a side note, App::VideoMixer v0.02 is in a sad state, as even the distribution is incomplete, so I'll have to release a fixed version soonish.

Hi Corion,

It's very conventional of you you rely on time being linear: how else do you explain coincidence?

However, I'm going to have a look at your code, maybe if I save each frame in a file AFTER it's displayed then I can use my video bar on it.

I'll let you know

Regards

Perl isn't very good at low-level hardware access, even if it is possible. Typically, you need some C clue code packed in an XS. All current desktop operating systems prevent you from messing directly with the hardware, and they have good reasons to do so. Typically, you communicate with a OS specific and hardware specific driver that wraps the hardware access. Most of the times, the driver (or set of drivers) abstracts the differences between different hardware and give you a generic interface.

Think about soundcards. When was the last time that you had to mess with hardware registers? Last century, I would bet. Today, you connect to a generic sound device driver and tell it to play your sound data.

Exactly the same happens with web cams. They typically are USB devices. To access their hardware registers, you have to communicate with the USB controllers and ask them to mess with the cam's hardware registers. USB controllers have different standards and different vendors, and the OS abstract that for you. So you get a stack of hardware and drivers: Web cam - USB controller - PCI bus - PCI driver - USB driver - Web cam low level driver - video API driver.

Unless you really want to get mad fiddling with the hardware, your best bet is the video API (e.g. V4L on Linux, VfW or some DirectX stuff on Windows).

Alexander