in reply to Designing a webcam video streaming client-server application in Windows

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

[download]
  • Comment on Re: Designing a webcam video streaming client-server application in Windows
  • Download Code

Replies are listed 'Best First'.
Re: Re: Designing a webcam video streaming client-server application in Windows
by gaggio (Friar) on Jan 16, 2004 at 10:08 UTC
    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...

    Gaggio
[reply]
      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.

[reply]
        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.

        Netmeeting uses the H232 protocol, AFAIK, which is beyond horrible, for it needs about a million ports opened, which is a problem for firewalls. The app itself may have nice features, the ports needed is just unworkable for a lot of places. Power to the OP to come up with something better.

        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.

        I beg to differ on this point, for I believe UDP is way better suited for transmission of images, than TCP. The initial connection should probably made through TCP, I agree, but afterwards (the sending of image data) is better suited with UDP. With TCP, all packets will arrive sooner or later, resulting in waiting on the receiving end for TCP to put the packets back in order. With UDP you might get a blur/glitch, but at least the "stream" continues. I believe this is preferable over the waiting time, especially since speed was the "itch" that made the OP consider writing his own app.

        But then again, AFAIK, HTTP utilizes TCP only :( Correct me if I'm wrong on this, please :)

        --
        b10m
[reply]
        Thanks flyingmoose,

        There are some interesting points in your comments.

        You are probably right about transferring through HTTP. I guess that passing through firewalls does not mean HTTP transfer... and obviously would make the protocol much less efficient because of the inherent HTTP overheads. I agree I thought a little fast. But transferring data through port 80 as an IE plugin is still my idea, because when you get executed inside IE you are seen as part of IE by the local firewall so you won't have to explain how to configure the firewall to the users. (Just recall that ICF will be enabled by default in XP SP2.)

        I'd also like to mention that I don't think the processor is the bottleneck in this kind of application and that it is much more probably the network (yep, many users are still having modem connections!)

        Well, thanks anyway!

        Gaggio
[reply]

In Section Seekers of Perl Wisdom