Welcome to Pongle.net. The site is undergoing a refit, so until the new version is up and ready to rock, here are all the other places you can find me.
When designing and implementing a product with a set of distributed components, make sure they consider versioning and report any mismatch. Especially at install or setup points. These are the user's first experience with the system, which might work perfectly once setup, but if the user has to go through hell to get there, it might all be for nothing...
If you use ITU standards (if you're processing broadcast video you should be) the first three are free to download. Just register and you'll get a user name and password to use.
The ITU-R BT.601 recommendation is over 25 years old, and still very useful as it defines the RGB to YUV (YCbCr) conversions required for SD TV signals. The HD equivalent is ITU-R BT.709. If Poynton or Keith is getting you confused, then refer back to the authoritative source..the standards.
Next time you're on the train, sitting by the window, press your phone's camera up against the glass and take a few pictures.
Marvel at all the upright signs and buildings, suddenly having a slant. This works especially well when going through a station.
The effect is caused by the time it takes the phone to read each line off of the camera's sensor. Proper cameras get around this by using a shutter to stop the exposure very quickly across the whole sensor, while the data is read off.
Using AVID's AMT SDK to check content into the Interplay server, the error messages transmitted over the wire are much more descriptive than those returned by the library's error string function call. To intercept these messages Apache's TCPMon is invaluable as a SOAP proxy to view the interaction between the Interplay server and the AMT toolkit.
I'm always amazed when I find another C++ Windows developer that has not used the Visual Leak Detector (VLD). Under Linux the joys of valgrind will help you find memory leaks (and performance problems at the same time!) Unfortunately Windows has no (free) equivalent. When chasing memory leaks, you generally have to deal with memory dumps directly. This is all blown away by using VLD.
Include the header file in your main and suddenly your debug output will include all of the un-freed memory at the end of the application. A handy stack trace and memory dump is printed for each leak. There are #defines to control the output, so it doesn't become overwhelming, and it links into Visual Studio nicely, so the stack traces are clickable.
If you have to develop for Windows, keep VLD in your include directories.
A note on the AVID-L2 mailing list suggested adding a drop-frame timecode format to support matching 23.98Hz video to wall-clock time. The benefit to the editor is that the various video and audio files recorded from different devices on set can be synchronised using their start timecode, as all the devices now follow wall-clock time. I personally think that drop-frame timecode for 23.98Hz video is a bad idea. To discover why, lets look back at why DF (drop-frame) timecode was invented. Long in the distant past the Americans decided to use 29.97Hz video (i.e. 30000 / 1001) to allow their black and white TV sets to continue to be used after the introduction of colour TV. This lead to a problem that the frame-counting based timecode would drift behind wall-clock time. To correct this, so human operators would know when to start rolling tapes, a new timecode format was created where the first two frames in every minute are skipped, except for every 10 minutes. This keeps the timecode in sync with the wall-clock time pretty well, only loosing 2.6 frames a day. Since, in theory, the DF and NDF (non-drop-frame) timecodes match at midnight (00:00:00:00), it is simple to convert between DF and NDF timecode. Unfortunately for 23.98, there is no nice way to do DF and keep in-sync with wall-clock time (trying out the maths is left as an exercise to the reader). Since 23.98 is never broadcast (it only exists as a convenience format for people working with 24Hz material destined for broadcast in the USA), there is no need to keep the timecode in sync with wall-clock time. For capturing using multiple devices, LTC is the way to go, locking everything to a common clock (you weren't really going to rely on the devices not drifting apart were you?) For editing, once your start timecodes match, pulling content onto a timeline with the destination frame-rate will show you the right timecodes (be it DF or NDF). One last thing to consider. Many tools use timecode-discontinuities to either cut material into segments (multiple shoots), or to flag errors during ingest and playback. A new DF timecode format would require all of these tools to be updated to understand that there are now two, different, drop-frame formats... Lets wait for SMPTE to finish it's review of 12M and then see what should be done to synchronise content from multiple sources.
For ages my HTC TyTN II Windows Mobile has not been able to send email through Pongle.net's Exim SMTP server. I spent a few hours today getting this to work.