Ok, you've looked at and maybe even answered parts 1 and 2 of this, maybe posted a comment, maybe even collected the points. Now, on to part 3. I'm still interested in parts 1 and 2, and will award the points even if this part is answered first; I only say that because if somebody answers this part well, I won't need parts 1 and 2.
You can see Parts 1 and 2 here :
http://www.experts-exchange.com/Programming/Programming_Languages/Delphi/Q_20604284.htmlhttp://www.experts-exchange.com/Programming/Programming_Languages/Delphi/Q_20604292.htmlI recommend you read at least the first part of part 1, so you're familiar with what I'm doing and what I'm trying to accomplish.
That said, if DSPack and/or TASFWriter aren't up your alley, that's fine by me because I'd like to get away from TASFWriter anyway, and this part can be answered (I imagine) without any real knowledge of TASFWriter or DSPack.
As with the other two parts, this question is worth 1000 points. I'll provide the other 500 points in another question once this one is answered.
Ok, so I've mentioned I have a webcam app in development, that I want to add streaming capabilities to it, and that I've been trying to use TASFWriter to accomplish that. Even if parts 1 and 2 are answered to my satisfaction, I still have a problem. I don't want viewers of the webcam to have to use windows media player to view the webcam.
What I'd like to do is make streaming available, via mpeg, divx, or whatever other codecs I (or the user) may have available. Now, as you should be aware if you checked out my app, it has a built-in HTTP server. What I'd like to do is provide via a java applet, or javascript, a way for them to view the stream inside IE. The following framework outlines this, it's pretty basic, I'm going to describe it just for clarity.
1) user connects to the internal HTTP server, which already maintains a list of available cams and handles viewing them.
2) user clicks on the "stream" URL for a cam, which directs them to another URL on the internal HTTP server.
3) the internal http server serves up the java/javascript applet, which will connect back to the server machine on a different port to get view the stream.
This is what I've no clue about -- how to create this stream. What I have available is the standard filtergraph I've built using DSPack, a buffer that holds the most recently captured bitmap via a samplegrabber in the graph, and a jpeg compressed version of that bitmap. I currently capture at a rate of 1FPS, but I can of course do this faster if your implementation requires it.
What I'm looking for is twofold.
1) Generate the stream to serve to the client. This stream needs to be compressed. By a 3rd party component if that's what you're comfortable with, by an installed windows codec if you know how to do this would be best.
2) The java/javascript code I'll need to serve to the client that connects to the custom port on the webcam app/server to view the stream. I'll post a link to this Q in the java and javascript areas since I realize this isn't the best place for this. I'm asking here because I'm also willing to accept a lightweight delphi client instead of java/javascript, as long as the code works fine as an ActiveX component. I'd like to avoid the ActiveX route if possible because people, like myself, are leery of downloading an unsigned ActiveX control, or even a signed one that still pops up with security warnings; Also, this is fairly hard on the app user. I can serve the component via the internal HTTP server, but the user will still get security warnings in IE.
As an example of what I'd like to see.. delphi code to take a series of bitmaps and convert them into an mpeg (mjpeg, divx, heck even avi or asf) stream. Generate an event every so often, say once a second, to tell me that a buffer of that length is ready to be sent. I'll grab the buffer and send it over the socket to all connected clients.
On the java side, all it needs to do is be able to correctly interpret and display this stream. It shouldn't send anything, it's a one-sided affair. The java client connects and immediately starts to receive the stream it is to display. A minimal protocol will be required just to make sure the client knows the format of the stream, but I leave that detail to those of you who thing you want a shake at the points. :)
I'll provide 1000 points each for these two parts, provided they work together. ;) This means if one of you comes up with the delphi/sending side and somebody else comes up with the java/client side, you'll get 1k points each. If one enterprising and skilled individual comes up with a solution that implements both sides, I'll throw you the full 2k.
Answers that help me get there on my own but don't implement the full thing will get some points at my discretion, but I'd really like to see both sides from one person, just so I don't have to worry about any collaboration between coders; especially with regard to picking somebody to blame if the two parts don't communicate properly with one another. ;) I'm a coder myself, not a manager, and I don't want to be one. If you can work it out between yourselves, by all means, collaborate away.
I hope that covers everything.. if not, feel free to ask away.
