Re[2]: P133 too slow?

Brian Godette (
Wed, 23 Jul 1997 23:32:46 -0600 (MDT)

On Wed, 23 Jul 1997 19:50:12 -0500
"Bill Woodland (Squeek)" <> wrote:

> >
> >All it needs is for some enterprising person to pay the $75 to Cornell,
> >get the 0.92b1 source and retrofit colour codec support and I can see
> >thousands of people dumping 3.0 for good.
> <snip>
> As much as I would like to see that happen, it won't, at least not for $75,
> and Cornell will NEVER support color, due to their agreement with White
> Pine. Unfortunately the $75 deal does NOT give you the right to use the
> source code to produce a product that will compete with White Pine's
> product. There are four kinds of licenses. This is from the license page
> at Cornell:

Well... actually there is a third route. All you *need* to know to make
a compatible client is contained in the 3.0b3 reflector source. The
codec for handling B&W video can be found in the NV 3.3 source. Where do
you think CU-OS/2, QSeeMe, and Java-CU came from, certainly not Cornell
source as they all initialy lacked rate adaption and chat recovery support
amoungst other things.

As for color support.... well since WP went the route of doing thier
video codecs as Video For Windows DLL's it's only a little more than
picking the "correct" video codec to handle the data stream (same deal
on the Mac's with Quicktime). Each VfW/QT codec is identified by a four
byte string, which is included in the OC packets by WP clients.

It's a very hairy grey area, the program could be written to utilize any
installed video codec (same way as WP Mac 2.0 is). There's nothing
illegal about it being able to use WP's codecs (and in fact MJPEG is
free for non-commercial anyways), it's just not very nice :), and as a
point of interest just about any video editing software will allow you
to use them as well. The interesting question would be whether or not
such a client built around the information on packet structure/contents
that's found in the 3.0b3 source would fall under the same licensing as
that reflector source. And there's the issue of the rate adaption
packets and aux data packets (other than a standard chat packet) which
aren't covered by the 3.0b3 source, but can be figured out by examining
the packets. Reverse engineering?? hard to say, it's much the same as
Linux's ability to read foreign file systems, just a matter of data
structures in simplistic terms.