Streaming Video from a Camcorder / DV Cam

I recently needed to stream video for presentations held inside a tent located in a parking lot. Webcams, even ones with good low light did not work. The best results I had were with the Logitech QuickCam Pro 9000. Unfortunately, the ambient light reflected off the surface of the tent and made the lightness and darkness variance too extreme. The screen shots below are from the Logitech QuickCam Ultra Vision.

In order to find another solution it had to meet the following conditions:

• Be recognized by Windows Media Encoder to broadcast the stream
• Stream at greater than 320 by 480
• Work good in low light conditions where the amount of light fluctuates
• Not turn off automatically

Potential solutions that I tried included:

• Camcorder / DV Cam from Sony, JVC, and Panasonic
• Surveillance Camcorder that uses USB
• Video Capture equipment such as Pinnacle Studio Moviebox Ultimate
• Software such as WebcamDV and DVDriver

After getting help from Vital Stream, Best Buy(not helpful), Circuit City, Fry’s(not helpful), and numerous sites/blogs, I finally have a solution:

• Dell Laptop running Win XP with Windows Media Encoder 9
• Firewire Card for a Dell Laptop
• Firewire cable
• Panasonic GS320
• VitalStream Project to host the web broadcast

The Panasonic GS320 has good low light (1 Lux) and is documented as Streaming over USB. It is not recognized automatically. I had taken my laptop to Circuit City and Fry’s and plugged in many camcorders. After installing the driver and setting the camcorder to the PC menu option, the USB stream worked nicely. Unfortunately, the camcorder only streams at 320 by 240 over USB (2.0).

Unlike most Sony camcorders, the Panasonic has both Firewire(iLink) and USB. I was going to try to use WebCamDV but first tried to see if Windows Media Encoder would auto detect the GS320 as a device. Fortunately, the GS320 was recognized by Windows Media Encoder and it streamed at 720 by 480. The GS320 does not shut down after a few minutes and has stayed on for over three hours during testing (and a couple of accidental drops).

The real trick to using a Camcorder / DV Cam as a Webcam is to make sure it has software feature that allow it to stream to the computer. I would caution about WebcamDV software because the un-install did not really uninstall and I had to remove keys from my registry.

Once you are streaming there are few things noteworthy in Windows Media Encoder.

• If you are not sure of the output size do a test using Full Screen Video as the Encoding Options setting for Video. It will show you the size in the Preview field in the upper right windows on the Media Encoder.
• If you need to get a custom size for the output stream from the Media Encoder, click on the properties button on the menu bar. Then click the Compression tab and then the Edit button. Click the tab with the correct Kbps and then change the video size. If you have it set to Full Screen you will need to uncheck the “Same as video input” checkbox.
• In order to have a version of the file to play on demand, check the “Archive a copy of the broadcast to file” button on the Archive File screen. If you did not do this, you can click on the Output tab after clicking on Properties. I then took the archive file into Camtasia to remove the unneeded beginning and ending video and to get a better compression ratio. I also saved the video into different formats so people could choose which size video they wished to watch.
• If you need to have a solution for high and low bandwidth, make sure to select multiple rates in the Windows Media Wizard.

Documenting Website Requirements and Design

10,000 Foot View
Over the years I have seen a lot of different ways to document software. For the most part the level of effort spent on documentation has been inefficient. It is easy to spend too much time on documentation. It is even easier to spend too little.

Ultimately there needs to be a measuring stick to determine what level of documentation is appropriate for the software being developed. Documentation can be in the form of code comments, requirements documents, and user manuals.

Code comments should always be used. Undocumented code is inefficient due to the level of analysis required for maintenance updates. Always comment your code! User manuals are not necessary for consumer facing web sites. If your site needs one than your user interface is ineffective.

So where is the line drawn for requirements and design? To answer this question I have a very simple measuring stick. If it is painful to not have something documented then document it, if it can be omitted and not cause pain then omit it. Keep in mind is the project you are working on and the team.

If software is developed in an iterative fashion then there are really two key categories to keep track of. The primary focus should be on the current iteration. Too much noise will only cause extra distraction and slow the team down. However, the future features should not be simply tossed aside. Instead they should be kept in a log or list of some sort. This list can be grouped into later iterations.

Documentation Specifics
Context goes a long ways to giving a framework everyone can operate from. For this reason it is important to understand why you are building software and what the overarching purpose of the solution is going to achieve.

This can be a business case document of some sort but it can also be as simple as a paragraph or two. This is really more like the mission of the software. There will likely be a lot of business details that someone will manage but for the sake of development this is less significant.

In order to get a sense of scope it is helpful to have a high level feature list. Features are broad and describe critical elements of the software. Be careful to keep the features simple and do not be too specific. A bulleted list of elements will suffice. The list can be something like: video player, partner video blinx widget, tools widget, featured articles, etc.

Features can be implemented in a given iteration or multiple iterations. It is likely the specifics of the feature will change over time as the actual details are fleshed out. Details of the features are documented as requirements. Of all the design oriented work products requirements are the most important. They act as a contract so business knows what to expect, so developers know what to build, and so QA knows what to test.

Other design assets can also be helpful. Scenarios or Use Cases help to give a user based view of the solution. I do not advocate detailed Use Cases because the level of effort required to complete them has never provided enough value relative to the amount of work. Instead, just give enough information so the team can understand what is happening for the user. They should depend on the requirements to flesh out the details.

Sequence Diagrams and Class Diagrams can also be very helpful. If a particular implementation is complicated a Sequence Diagram can add clarity. A picture is worth a thousand words is a key concept here. Remember the pain measuring stick; if you don’t need it don’t do it.

How to document
Using Word, Excel, Visio, etc can help and they are all good tools. The key challenge with these applications is that they are very manual. They don’t really make a model that can be worked with. In addition, UI Designers build mockups and Information Architects create wireframes and flow diagrams. Each work product is someone’s view into the software; each interpretation ads things that were not added before.

A development team (or system analyst) must assess all work products to make sure all requirements are included and there is one contract for the team to share. I have been using Enterprise Architect for a number of years now. It is a great UML tool although it has a lot of bells and whistles that I don’t use. I like to keep things simple. It is very easy to add requirements into the tool. It is easy to move them around. If is easy to group them by feature or some other structure.

I create a requirements package and one for other types such as actors, use cases, etc. I then group the requirements by common/global and page specific. It is important to use a structure that works for the entire team. I use the global and page specific so that QA and business can understand the structure. It is very important to put a requirement in only one place. If a requirement is used in more than one location is should be a global requirement.

Initially I will re-create the requirements from all of the available work products. I add a TBD for all open issues. Then I re-order the requirements so they are ordered based on where they fall on the page or based on importance.

I then produce a Rich Text Document for the requirements based on the package. This can also be done for the other packages. I then import the RFT documents into a Word file that I’ve created. The Word file will have a cover page, TOC, and high level summary info. I then insert the RTF documents (can be done with a Macro).

Once the documents are inserted I open the Format > Styles and Formatting pane in Word. I’ve created a style for TBD which is several font sizes larger, bold, and underlined. I then search for all TBD text and change the style. This gives me a Word document with all TBD very easy to see.

I use this as a list rather than having to make another list to follow-up on. At the first meeting or two we address only the TBD’s because they are the risks. Once the big holes are plugged we will review the requirements to make sure that everyone understands them and has a chance to provide feedback.

Another valuable feature of Enterprise Architect is that I can create a RFT document that lists the requirements that have been updated since a certain date. This list can then be put into the appendix. Now it is very easy to see what has changed since the last update.

One final point to stress is that the project should be moving as the requirements are being fleshed out. Development environments should be setup, proof of concept or baseline architectures can be made, etc. The project should keep moving. At some point the requirements for a given iteration or phase should be agreed to. Then for that iteration those requirements will be frozen. However, they can be changed for a future iteration and the rest of the requirements can continue to be fleshed out. In the end there should be a contract that determines what is developed, tested, and expected by business.

So it begins.

I’ve received a lot of value from posts that others hade made to the internet over the years.  Recently we moved to a new house and for a couple of weeks we did not have an internet connection. It became painfully clear how much I and my family depend on the internet.

During the same time period my cousin Earl and his family came to California for a visit and we were able to meet their new born son Elias. During the visit Earl commented on how he has gone to the www.ekillions.com web site several times to read posts that I made. I have a page for each of my two kids to describe where they are developmentally at different stages in their life.

I had initially created the pages to keep the current information available so friends and family could follow their progress. I did not imagine that it would be useful as a gage for how others children were doing.

I’ve decided that it is time to create by own blog in an effort to be a better member of the internet community. Time will tell of what I have to say is considered valuable.