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
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
