Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Designing a webcam video streaming client-server application in Windows

by gaggio (Friar)
on Jan 16, 2004 at 09:52 UTC ( #321763=perlquestion: print w/replies, xml ) Need Help??
gaggio has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

I just bought a webcam but I am not satisfied with it because as it was not delivered with streaming software.

I thought that Yahoo! Messenger or MSN Messenger would be fine to transmit live video to my friends, but for a couple days now the Yahoo server dropped 90% of my frames (the rate was greater than 1 frame every 15 seconds) and let's not even talk about MSN Messenger - the "bigbrotheroverbloatedsystemslowdownertrash" chat application - that takes the guts out of my old AMD K6 380 (yes, 380MHz!) laptop...

As a perl monk and as a perl hacker, my conclusion is that I have to develop myself an application that serves video as well as it is possible. Please don't tell me that to get a fast TCP/IP layer I should turn to Linux since I already know this. My requirement is to develop for the Windows platform. And in my mind, Perl is the language of choice when dealing with network transfers.

I thought that I may find in your posts some helpful information to get started on this project.

The three most important software modules that I foresee are the following:

- Video streaming server
- Video streaming client
- Video grabber

By video streaming, don't get me wrong, I am not saying that I want to replace .rm or .asx formats... My "video stream" would simply be a sequential transfer of JPEG files captured one by one from my webcam.

Having queried Perlmonks and the web, I found out that apparently there exists a Win32::Scanner module on CPAN but I am wondering if it really gets the job done because I am not sure my webcam offers a TWAIN interface... Does somebody know if instead there exists a perl interface to the VFW (Video for Windows) API? I used VFW in the past and I am sure my webcam can be accessed through it. That would get me done for the video grabber.

Now, for the streaming client and server, I thought about using UDP transfer because it is faster than TCP and it does not matter if sometimes a frame is lost due to network problems. What do you think about this? Since there are so many modules available, could you tell me which CPAN module you would use to create this part?

After I get those basic components working, I will probably want to create a small client interface (with Win32::GUI probably) and I will think about making the transfer invisible to software and hardware firewalls, that is switch to HTTP transfer and try to transform the application into an Internet Explorer plugin. I would really like to get some comments on that part as well.

Any comments appreciated!

brother Gaggio+
  • Comment on Designing a webcam video streaming client-server application in Windows

Replies are listed 'Best First'.
Re: Designing a webcam video streaming client-server application in Windows
by Corion (Pope) on Jan 16, 2004 at 09:59 UTC

    Please, go the simple way, and use (or embed) NetMeeting. This is the short and easy way, and it is quite similar to MS Messenger. I guess the best investment you can make is in getting a webcam with good drivers that do not place a great burden on your CPU by doing all conversion/calculation on the CPU instead of on the camera hardware.

    If you really think that creating your own streaming format is a good idea (and I think it's not), please skip VfW, as it is old and unsupported, and look into the DirectX/DirectMedia filter setup. This is what NetMeeting uses though, so in the end you won't be better than NetMeeting, but at least have done it "your way".

    If you use the DirectMedia stuff, you will need a language that lets you use COM objects painlessly, which means either VB, C++, Delphi or Inline::CPP (or maybe C#, but I don't know), as Pure Perl dosen't lend itself to painless COM object manipulation unless that particular COM object implements IDispatch (OLE2).

    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
      Hmmmm, thanks but I really would like to avoid using COM objects. I think VFW is the right choice because it works well, it is still supported, and my laptop has a tendency to crash when used with DirectX...

        While there is nothing wrong with reinventing a wheel, writing your own video streaming application is a REALLY big wheel.

        While NetMeeting (or the Linux NetMeeting app -- yes I know, you want Windows) may be an unwieldy monster, a lot of time went into making that unwieldy monster. Even if you only have to do 1/10th of that work, it's still a ton of work.

        Have fun, you may make something really popular...but it will take some effort. I would look a little harder at other video conference apps, possibly, and maybe you can find one that works for you.

        I will say that UDP is probably a bad choice. What you want is a TCP/IP system that has some sort of quality-of-service feature (possibly using UDP for timing? who knows), as UDP has a small packet size and (worst of all) ordering is not guaranteed. For important packets, especially ones that set up states for your program, you can't have them being lost either. Consider the size of what you are biting off, and see if it wouldn't be worth your time to just buy a 1 GHz machine for $200 at Walmart.

        that is switch to HTTP transfer and try to transform the application into an Internet Explorer plugin

        This is a probably a very bad idea for video streaming. Not the plugin part, but the HTTP part.

        Also, with the MSIE plugin...there probably aren't a ton of MSIE plugins written in Perl. How much pain are you looking for? As I've said, consider the size of what you are biting off. Simply upgrading the computer or trying something like CUSeeMee may be a better option!

        I am not trying to discourage you, this would be a fantastic project to work on -- just saying, I don't think it's going to just fall into place and be better than the commercial/open-source apps already in existance. Most of those folks new what they were doing -- the slow down you see *is* because of your processor, not the app. Whatever you get will still be slowed down by the processor, and Perl may be (unfortunately) slower than the stuff they are using.

Re: Designing a webcam video streaming client-server application in Windows
by Arbogast (Monk) on Jan 16, 2004 at 20:31 UTC
    You might ought to look at the Flash Communication Server.

    It is pretty easy to construct a Perl wrapper around the ActionScripting, if you want to control and create the SWF files with Perl.

    A Perl wrapper can compile the SWF files in Flash MX 2004.

    If you use alot of ActionScript #include directives, Perl can rewrite the FLA files as needed.

    Perl can easily write config files in XML and LoadVars that SWF file can read.

    There is also the FLAP (FLAsh remoting in Perl), which I have never used but looks super useful.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://321763]
Approved by Corion
Front-paged by broquaint
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2017-11-23 00:03 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (327 votes). Check out past polls.