Re: Re: Re: Designing a webcam video streaming client-server application in Windows

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.

Comment on Re: Re: Re: 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 b10m (Vicar) on Jan 16, 2004 at 18:37 UTC
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]
Re: Re: Re: Re: Designing a webcam video streaming client-server application in Windows by gaggio (Friar) on Jan 16, 2004 at 17:51 UTC
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]