|
DMI News |
Previous Entry.. Next Entry.. Progress
October 12, 2009 08:28 This weekend I got the camrelay updates done that I've been putting off. I haven't put the new version into production yet, but will likely do so in the next couple of days. This version will feature a 15 second timeout on all connections if no data passes hands when it should be transmitting... and that makes sense. The issue I was having was in regards to quite a few threads hanging somewhere and using up both thread resources as well as about 10 megs of virtual memory each (not sure exactly where the allocation is coming from yet). Another plus is the relay now works in both directions. It can connect out to a cam server to pull images in, or have cam software with streaming using post connect to it to send the images. I have it working with both the webcamxp post update routine, as well as a flash applet. My efforts so far to test the flash applet have resulted in 2 bluescreens of death.. so far.. so I need to do some extensive testing before I release it for public use. It's possible that the crashing was from splitcam, which is actually a driver... which is able to fuzz around with the system better than an application can. I'm hoping that's all it is. In any event, I'm going to test it out with a real webcam for a while to make sure there aren't any further crashes. Once I deploy this feature, people who have a functioning cam on their system and flash for their browser will be able to have a cam up and running in a matter of seconds, with no software installation required. HOWEVER, I'm going to encourage this as a means of last resort, since it's going to be slow (at least the applet I have now is), and it's going to use up a lot more of my server's bandwidth. Still, if someone is sitting behind a firewall they have no control over (or simply doesn't know how to configure port forwarding), we now have a way to get these people up and running until they're able to figure things out. That being said, I'm likely going to either eventually code my own flash streamer, modify the code for jpegcam (which is what I'm using), or find something that works slightly better. A fast, smooth, motion jpeg formatted http post command would work nicely as the relay can handle it well. In theory, that should maximise the throughput of any relay connection... in theory. I also discovered yet another tweak I'll have to make to the camrelay. I need to be able to handle chunked transfers. Ugh.. one more tiny little nightmare. I'm going to need a few things in the near future. First, I need indie Xmas music. Absolutely no restrictions on use would be preferable, but I can go with a "non-commercial only" agreement, so long as it's free and there are no restrictions on broadcasting the audio as part of a video stream. Secondly, I need someone to find the file format for Vixen .vix files. They're xml formated files, but I need to know how to read the sequence. That way I can use vixen to develop a light sequence and use one of my own applications to handle the actual lighting effects. Vixen has a networking option to control the playback from some other network application, but I want my programs to have control of the device. The other option is to run Vixen in a virtualbox and have it use one of the serial based hardware devices. On that system, I'll have a loopbacked serial port so I can have my own application read the Vixen sequence output and reinterpret it in my own application. This way, the lighting display can be controlled by Vixen, but when Vixen isn't in use, lampmaster can handle the lights individual as it does with all the other lights.
|