JWSmythe

Following are some examples of sites I've worked on, created, or projects I've done over the years. Please read the full description to understand what was involved in each.


Free Internet Press

Prima Dogs

CryptMsg

Drain Doctors, Inc

Geographic map of ping or traceroute

TrackCamping.com

BoT - Network Monitoring Tool

Massive Site Replication






     
live_video Data Exists

Live Video Reflector

In 1998, I was instructed to create a mechanism for serving live video that would be available to any web viewer, without requiring plugins or 3rd party applications. The end result was to be fast, reliable, and secure. It also needed to be able to provide fast service to the 20,000+ paying customers and a reduced service for several million other viewers for free through it's parent web site.

There were several pieces that made this work.

Source The source was a variety of hardware. The main source was an Axis Communications 240 Cam Server, with 4 BNC ports for video input, and a network port for output. Off the shelf Sony HandyCams were attached to each port. Frames were collected via FTP from the device.

A no-brand video capture device, with Sony optics mounted in a steel case, with only network and serial interfaces on the back. Frames were collected via HTTP from this device.

Some Linux workstations were used, with BT848 chipset video capture cards, attached to Sony HandyCams were used.

Over time, the Linux workstations were replaced by Windows 98 workstations. This reduced the number of BT848 inputs to one, but USB cameras replaced these. This decision was made so the capture machines could also be used for normal Internet access by barely computer-literate users. Frames were sent to the primary server via FTP.

Video Reflection Frames were taken in by the primary server, and distributed to secondary servers via NFS mounts. To avoid network contention issues, a second network was established only for the video frame sharing. One set of servers provided service to the paying members, and a second set of servers provided service to the free viewers. This was done pragmatically with Perl scripts. The free viewer servers only got one update every 15 seconds, while the members server was updated as frequently as a new frame was available.

Client The expectation of the site was that it would work for anyone with a web browser. While providing service to so many people, it was well known that no matter how well you document something, it won't be read. This had already been provide so many times simply by putting a link like "CLICK HERE TO CONTINUE" on pages which required a click, but users would email asking how to get to the next page. While it sounds stupid, when dealing with a large user base, even a small percentage of people make for a lot of support calls and emails.

The client was initially written as a Java applet. It took several revisions to make it work fluidly on all platforms we encountered. Internally, we tested on everything we could. This included MSIE 3.x, 4.x, 5.x, and Netscape 4.x on Windows 95/98/NT, Mac, Linux, and Irix. The occasional trouble report came in, which were handled very rapidly. Over the first month of operation, the problems were reduced to "Enable Java in your browser".

After about 2 years of operation, some more than enthusiastic users decompiled the java applet, found the frame source, and started distributing their own java applets to pull our video feeds. Countermeasures were put in place in the following days, which started as a set of hourly rotating keys for the frame source. The enthusiastic users scripted their decompiling, to find the key and automatically update their own applets. We expanded the key set to 10 keys, of which only one was really used and 9 were decoys. This slowed the enthusiastic users down dramatically, and gave us quite a bit of breathing room.

In the following weeks, the java applet was abandon, and replaced with javascript, which was able to use better security through the browser. This remained undefeated for the lifetime of the site.

In both cases, frame swapping was utilized. While one frame was shown, a second frame would be downloaded, and then swapped, to give the user the appearance of fluid motion. This is consistent with what we see in movies and television. Movie theaters generally show their video at 24 fps. NTSC (American television) uses 29.97 fps. PAL uses 25 fps.

Our effective frame rate varied based on different factors. On the source side, this became limited by:

  • The available bandwidth from the broadcast site (T1 - 1.544Mb/s)
  • The capability of the capture device (4 to 8 fps)
  • The size of the captured frame (320x240, varying filesize based on compression and content)
  • The number of cameras (up to 40)
  • The utilization of the line for other uses. Frequently, the source side would watch the feed also, and do other tasks, such as web browsing or chat.
We optimized out reflector farm to handle anything that was thrown at it. If we were coming past 80% utilization on any part of it, extra reflectors were added. They were configured in such a way that they could easily be added or removed, and spares were kept on hand idle.

The client side was an extremely limiting factor. International viewers frequently had very slow frame rates, due to line quality. The other major problem was the line quality of the end user. At the time, quite a few users could only use dial up service, and had no accessibility to the new DSL or cable modem services. While it would be thought that this would slow business, users were impressed that they could get real live video, even if it was one frame every few seconds.

Unfortunately, there are no surviving pictures of any of the hardware or software involved in this project. It is long since obsolete.

There was another live video project that I lead the technology portion, but management embezzled all the funds, and everything fell apart just before the site was to go live.