Hi Juha, > 640->720 would require 40 pixels of black on each side which might make it an > undesireable effect. Then again scaling 640->720 might have less of an impact > on the picture quality than scaling 320->352. 640->352 might be okay too but > (640->) 320->352 by just adding black borders was computationally the fastest > way(even with a 900mhz athlon I care about this..). And besides I didn't have > to use bcast to scale anything.. Interesting. A question: there's a guy with a DC10+ who is really *struggling* to use software playback from stuff he captures. Does this work correctly for you? There's something weird going on with the JPEG data he's getting. Any other feedback from DC10+ owner (especially ones saying: "Yes, I record mjpeg and play it back using software decoding daily") very welcome. > Oh.. I also had to spend and hour to hack mjpegtools to take the latest > version of quicktime4linux.. a major pain. I wonder if there's any chance of > the official version going for the latest one since files created with > bcast2000c seem to be incompatible with the earlier quicktime versions.. Sigh... ;-) Patches are ready for mergeing into the latest cvs version are ready. They're waiting pending a rebuild of the automake/autoconf scripts to make compilation more flexible and robust. The issue of quicktime4linux linking its own internal jpeg lib remains though. This is a *major* pain as it makes it very hard to link against a faster MMX lib instead. Part of the problem is that the latest Qtime libs *seem* to demand glic-2.2 which a lot of people don't have installed and is a pain to upgrade because it breaks stuff. Andrew
