This entire past week I’ve been reading about the MPEG-2 specs. I’ve got some video files that have KLV data stored in the user_data extension of the MPEG stream. So, right off the bat, I tried using ffmpeg’s avcodec library. Unfortunately, there is no documentation. Seriously, they have no explanation on how to use the API. Websearching found me two tutorials, one that uses img_convert (which is now so deprecated as to be completely removed), and a more recent one that actually implements a full video player, rather than a frame grabber. Both of these also comment on the lack of documentation; in fact that was the tutorial authors’ primary reason for writing the tutorial!

Though useful for their purposes, I’m not that interested in actually playing these videos; rather, I want raw access to particular pieces of the stream (user_data section). After much browsing of the ffmpeg source, and trying, through these tutorials, to understand how to use its undocumented API, I finally figured out that I can’t do what I really want to do. The libavcodec/mpeg12.c file, which contains the decoder code for MPEG-2, totally skips over the user_data sections!!

An entire week spent, all to figure out that I have to implement things myself. I’m going to try and see if I can’t work within the ffmpeg code and tweak it to do the tasks that I require, rather that re-implementing the wheel.

Honestly though, ffmpeg is used by so many projects that it really, really deserves to have much better documentation. It shouldn’t take a newbie the better portion of a week to discover what’s possible within the existing framework. And they shouldn’t have to go browsing around the internal portions of the code in order to gain understanding of how to use the API. They’ve been around long enough that there’s simply no excuse for a lack of explanatory documents regarding the API. I guess that I’m just spoiled after having grown accustomed to the excellence that is Trolltech’s documentation.

The phrase “Do it yourself!” can either be a dismissive command that indicates the speaker doesn’t wish to be bothered, or an empowering personal philosophy. All the great geniuses of history were avid proponents of personal independence in thought, word and deed. All the knowledge that we’ve accumulated over the years has been the result of individuals striving to increase their own personal understanding, while most of the technical progress we’ve made has been either the result of individuals to improve on existing designs (for the personal satisfaction of one-up-manship or raw profit).

The great figures of history, inventors such as Benjamin Franklin and Thomas Edison, artisans like Leonardo DaVinci, and even artist like J.S. Bach and scientists like Richard Feynman all share a few things in common.

• They started young.
• They remained focused and persistent in the face of failure.
• They were always willing to improve on existing designs.
• They took no shame in copying (and then improving) existing works.

Like most geeks, I love to do things myself. I’d love to do everything myself, but I just don’t have the time. Convenience is the rot of the modern age. It’s convenient to pull something off the shelf rather than re-invent or even simply re-construct the wheel, but you don’t learn when somebody else does everything for you. Each and every day millions of people the world over do mostly what the did yesterday rather than something new and empowering. I’m not talking about big projects here either, simple craftsmanship is enough. I’m talking about exercising the brain, both creative and analytical skills. Solve a logic problem, sketch a drawing, focus on building the little skills through daily practice, because mastery of the little things makes the bigger things possible. When you do things yourself, you build skills often overlooked in society at large.

Many people see doing things yourself as a waste of time, because of the convenience of prepackaged solutions. Buy furniture instead of making it, buy software instead of programming it, pay for a plumber instead of fixing it. Don’t bother to build handy skills because someone else will always be there to provide it for you (for a fee, of course). I wish I had the time to master all of these skills myself, they’re really fascinating. Being able to do things yourself means that you don’t depend on others. It means you’re able to build custom solutions for your problems; custom furniture for your house, custom software for your computer, having a functional devices on the weekend (when a repairman is not available). It’s your world the way you want it.

Secondly, and often overlooked, is that when you develop these skills you very quickly insure yourself against personal economic frailty. One of the saddest things about our current economic structure is that we actively discourage doing things yourself. This means that, if the economy collapses, we end up with a very large portion of the workforce unemployed, and idle. If everyone had tradesman-like skills, we could all revert to self-employment, selling our services to those who need it. A physicist should be able to get a job as an engineer, an engineer a job as a technician, a technician a job as a serviceman; and the serviceman is always employable, no matter what the economy. If I lost my job today I’d take my skills as a programmer and become a free-lance consultant.

Building skills through a do-it-yourself mentality in a thriving economy is doubly rewarding. You can very quickly establish yourself as a local expert simply through diligence and practice in a field that nobody else is will to spend time on because they’d rather watch a movie or be entertained. When work is entertainment, skills and knowledge become their own reward. Not to do things yourself is to be at the mercy of those who can. So work to be a Morlock.

You can have no dominion greater or less than that over yourself.

– Leonardo da Vinci

My laptop broke, so I took it apart to see what was wrong (a personality trait developed in early childhood). All signs point to a hardware problem, one that I’m incapable of fixing. This situation is absolutely galling. Like most things in my life this small incident is a trigger that enlightens me to a much larger problem. Thus began my late-night vision.

Printed circuitry. I’m already aware that certain companies (Xerox, Epson, HP) are interested, and have prototyped the ability to print circuits on plastic sheets using a process akin to that of an ink-jet. Such a printer would reshape the entire industry. It could probably be sold for about $100–$300. The open/free hardware movement would take to the newfound ability of every person to print their own low-cost computer like an estrus pig to truffles. I know that circuits made using such a technology would not be ideal for high-power CPUs, but that’s just an interesting challenge. It would require the redesigning of a computer to be very low-power, and low clockrate (current 45nm vs 200um). But what is lost in performance at the chip level, can be mode up for via cheap fabrication of more chips (ala the Connection Machine or INMOS transputer).

There are a number of features that would be very interesting to industry.
• low distribution cost
• low manufacture cost
• simplified assembly
• extremely light weight
• low power consumption
• increased ease of customization
• rapid prototyping
• Hobbiest magazines could publish user submitted circuits in functional form, so that subscribers can tear along the perforation, apply power, and play with their useful new toy.
• I’m sure that you can think of more. (combined with an E-ink display this would make a feather-light laptop)

I would love to live in a world where I can fix a hardware problem myself, by downloading a schematic file and printing it out, and assembling the machine myself. The whole idea rings of a resurrection of the Homebrew Computer Club. It’s not that doing things myself is more efficient or saves money, it’s that by solving my own problems, I get a strong sense of personal fulfillment that simply can’t be purchased at the supermarket. The popularity of the Maker(tm) movement is evidence that I am not alone in this desire. I believe that this is an idea whose time has come. It’s a great place for a start-up to make a rapid killing.

I purchased myself a really nice Christmas present: Concepts, Techniques, and Models of Computer Programming. So far it has been a really nice read. Though I’m not familiar with the Mozart/Oz system that’s used (and conceptually developed) throughout the book, I’m beginning to glimpse some of the vast array of rather difficult choices that are available to the language designer. For example: scoping can be done lexically/statically or dynamically. Van Roy and Haridi had this to say:

Which default is the right one? The correct default is procedure values with static scoping. This is because a procedurethat works when it is defined will continue to work, independent of the environment where it is called. This is an important software engineering property.

Dynamic scoping remains useful in some well-defined areas. For example, consider the case of a procedure whose code is transferred across a network from one computer to another. Some of this procedure’s external references, e.g., calls to common library operations, can use dynamic scoping. This way, the procedure will use local code for these operations instead of remote code. This is much more efficient.⁷

&vdots;

7. However, there is no guarantee that the operation will behave in the same way on the target machine. So even for distributed programs the default should be static scoping.

I particularly like the advice that goes beyond just linguistic concern, branching out into systems design, because it meshes with my personal conviction that a programing language is a conceptual system in its own right. I’ve also had personal experience with having to modify my $LD_LIBRARY_PATH just to get certain programs to run. Still, I think that is an acceptable cost for keeping the memory load to a minimum by avoiding the redundancy inherent in running statically compiled code.

With regard to the scoping of values in a procedure, I must ask: What if you actually wanted the procedure to have different behavior based on the run-time execution environment? I didn’t see this discussed, but I would solve it with the addition of an external <var> in <statement-block> end, thereby making a diversion from the default explicit.

On the whole, the Mozart/Oz system supports more coding paradigms than I would have thought possible. This is accomplished through a rather elegant Kernel language approach, where the graft each of the available language architecture decisions onto a very small kernel language as the book progresses. Thus building the entire language one conceptual piece at a time.