Tuesday, February 10, 2004

Inch by inch... Final post for the night. I finished slogging through the ACAppleIMA4Codec and ACAppleIMA4Decoder classes. It's neat how C++ classes build upon themselves and use inherited functionality, but tracing execution through the subclasses and parent classes can be difficult. Enough grousing... I think I get it. I'm looking at the decoder first because an obvious Day One target is being able to decode the FLAC stream and output linear PCM. Here's what I don't get. How does QuickTime know how to play an audio format it hasn't seen before? If I drop in a fully functional FLAC decoder into /Library/QuickTime, QT would have the ability to decode the stream data but would QT be aware of this? How? From the old Component Manager I can see how an application can seek to match itself up with a codec (by passing in a componentType, componentSubType, etc., etc.) but what about the MoviePlayer application. How can it open and recognize enough information from the file to match up with the right codec? I don't even know where to look to find these answers. I'll probably ask on quicktime-api, but I'd appreciate any pointers in the comments section or via email to me. 11:00:06 PM    comment []

Coding Style - variable naming Minor but important style note regarding the Apple example source. Any method variable that is named "in" (such as "inPropertyID") indicates that this variable is being passed in to the method for some operation. Any method variable named "out" (such as "outWritable") indicates that this variables value will be returned to the caller and used in some fashion. [edit] Any method variable named "io" (such as "ioPropertyDataSize") indicates that the caller is passing in a value for the method to use and the method may pass back a changed value to the caller. Makes the code easier to read and understand. 10:12:59 PM    comment []