turbojpeg.dll is libjpeg-turbo 3.2.0, 64-bit Windows, taken from the
conda-forge package libjpeg-turbo-3.2.0-hfd05255_1.conda. It is unmodified.

It is here because the JPEG decoder in the JDK is too slow to watch video
with: on a realistic 1920x1038 frame it takes 28 ms against this library's
5.8 ms, and it cannot decode at a reduced size at all, so asking it for a
quarter of the pixels costs the same as asking for all of them.

The library depends on nothing but KERNEL32, so this one file is the whole of
it. Its licence is beside this file and must stay with it.

Replacing it: any 64-bit turbojpeg.dll will do. The code loads it by name and
uses only tjInitDecompress, tjDecompressHeader3, tjDecompress2, tjDestroy and
tjGetErrorStr2, which have been stable for years.

Check it with: gradlew turboCheck

----------------------------------------------------------------------

openh264.dll is Cisco's openh264 2.4.1, 64-bit Windows, downloaded from
Cisco's own binary host (ciscobinary.openh264.org) and unpacked from the
.bz2 it ships as. It is unmodified. Cisco pays the H.264 patent licence for
the binaries it distributes itself, which is why the binary is taken from
there rather than built here.

It is the video codec: the picture used to be sent as a whole JPEG per
frame, which is fine to look at but costs the same bandwidth every frame
whether the page moved or not. H.264 sends the difference instead.

Both halves of the library are used, the encoder on the broadcaster and the
decoder on every viewer, through WelsCreateSVCEncoder, WelsDestroySVCEncoder,
WelsCreateDecoder and WelsDestroyDecoder. Everything else goes through the
vtable of the object those hand back, so the order of the methods in
ISVCEncoderVtbl and ISVCDecoderVtbl matters: see OpenH264.java.

Replacing it: any 64-bit openh264 DLL of the 2.x line will do. Its licence
(BSD, two clause) is beside this file and must stay with it.

Check it with: gradlew h264Check
