tl;dr programmer vs domain specialists, episode 523467

This was a fun read, partly because I'm one such domain specialist and have answered questions on HN before about the weirdness of video encoding and all the things that can go wrong with it (which I also had to learn the hard way over a long period).

As a general rule, when you're trying to grasp or automate something that's a little out of the mainstream, 90%+ of all the pain points are already well understood and even documented by other people - but you have to really go looking for that information. Reinventing the wheel takes 10 times longer than looking it up, and looking it up takes 10 times longer than asking people.

The trick is to not ask people how the wheel works, which will require a great deal of time on their part in educating you on the fundamentals, so they'll often give you the brush-off or an abridged answer that it unhelpfully above or below your comprehension level. Instead, ask what they consider to be best reference material. You'll get a variety of answers; usually the more accessible material is a bridge to the harder material.

Where video synchronization is concerned, the standards were set by the Society of Motion Picture and Television Engineers; sync problems originate in a tweak to analog video frame rates (from 30 to 29.97) dating back to the introduction of color TV, which require slightly more bandwidth than was already available for monochrome TV transmission.

But the SMPTE documentation was written for people building equipment from scratch, and in a pre-digital era. The best documentation on recording and converting audio at different frame rates (for people who didn't wish to build their own equipment) was in an idiosyncratic spiral-bound manual available from only one store in Hollywood, and a text document from the website for Avid's Pro Tools audio engineering software respectively.

For quite a few years most pro audio/video editing software could not handle such conversions properly because the programmers didn't understand the use cases, and for commercial and legal reasons were reluctant to study their competitor's materials. trying to explain the analog antecedents of the quirky frame rate standards to people whose only experience with video was digital was an absolute nightmare.

(Avid + Pro Tools were the first movers in this space, and developed hardware and software for video editing for the Star Wars movies. But as so often happens, their solution was horrendously expensive and professionals were locked into their platform, which lead to user interface ossification. As other vendors tried to enter the space, they were limited for years to 'semi pro' status because they couldn't handle complex use cases, even if they were better than A/PT in other respects.)

In the 2000s I was a beta tester for Adobe and it took a full year of extended and repeated explanation to communicate the fact that editors were often handed material with the wrong frame rates because there were 10 or more places in the production cycle where an incorrect decision could throw everything off, and that that could happen every day of a many-day production cycle due to unforeseeable changes in personnel or location or equipment or service vendor.

The vagaries of industrial production were very different from the idealized dependencies of software production, and it was hard to convince developers wrestling with already-arbitrary-seeming domain standards that it was not just a matter of 'fixing the inputs' without access to a time machine or unlimited cash.

People who do a lot of reverse engineering seem to grasp this sort of problem much faster, but for obvious reasons there are very few of them on corporate development teams.