In short, rooVid makes it easy to take one video and convert it for multiple purposes. I use rooVid [1] to convert family movies I edit in iMovie and export them in two different formats for the web, one in h.264 the other in MPEG-4. I also export these family videos to iTunes so they’re always available and backed up on my iPod.

Head over to the rooVid’s page for more info.

[1] Just in case it’s not clear, I wrote rooVid so I better have a use for it.

Default Sound options when using ‘MovieExportDoUserDialog’

QuickTime 7 and iMovie’s dialog

The QT7/iMovie dialog has some clear advantages.

1. Shorter
2. MPEG-4 Audio is re-worded as AAC (as far as I can tell that’s the only difference). People that see this dialog know what AAC is (most?) and know when they want it. However, I’m doubtful that all know that MPEG-4 Audio gets you AAC (I wasn’t, hence this post).
3. “None” is not an option.
4. “Linear PCM” takes the place of “None” and the four int and floating point options.

Do we, as QuickTime developers, have access to this friendlier dialog? Do we have to role our own? Those are questions I’m trying to answer on the side. I did minimal research and found nothing. Right now I can’t devote the time required to keep digging.

If my app was shipping, I’d have mud on my face. I guess I’ll have to scrounge up the 500 clams for the select ADC membership so I can get more of a heads up when these things are coming. We’ll see.

For now I need to figure out if I missed something that said QTMovie initialization needs to be done in the main thread and why.

update: Thankfully, I’m not alone. Felix Schwarz writes:

In short: every developer who wants to background Quicktime operations in threads in order to not block the user interface for the duration of Quicktime calls has a tough time.

update 2: Tim Monroe of QT engineering states:

However, we have recently uncovered some issues when working with QTMovie objects on a background thread, even when doing things the “right way”. We are hoping to provide a more thread-safe QTKit soon.

Although I like my current use of NSThread’s, I can’t afford to test, debug and deal with “issues”. So, back to the drawing board. Right now I’m looking at using a helper application (that’s actually how QuickTime Player does it’s export) communicating via distributed objects. Live and learn.

So, remember:

typedef Handle                      QTAtomContainer;
typedef Ptr *                       Handle;
typedef char *                      Ptr;

// QTAtomContainer is really just
// char **

I wrote a QTSettingsParser that stores the following:

@interface QTSettingsParser : NSObject {
    CodecType   codecType;
    Fixed       width;
    Fixed       height;
    Fixed       frameRate;
    long        dataRateBytes;
}

+ (QTSettingsParser *) initWithContainer:(QTAtomContainer) 
                    aContainer;

- (void) parseAtom:(QTAtomContainer) container 
                    withAtom:(QTAtom) atom 
                    ofType:(QTAtomType) type;

The static initializer is easy:

+ (QTSettingsParser *) initWithContainer:(QTAtomContainer) 
                                              aContainer
{
    QTSettingsParser *settings = 
                     [[QTSettingsParser alloc] init];
    [settings parseAtom:aContainer withAtom:nil ofType:nil];
    return settings;
}

- (void) parseAtom:(QTAtomContainer) container 
                   withAtom:(QTAtom) atom 
                   ofType:(QTAtomType) type 
{
    QTAtomType cur = nil;

    // do we have any data?
    Ptr data;
    long dataSize;
    OSErr result = QTGetAtomDataPtr(container,atom,&dataSize,&data);

    // yes, we could conditionally GetAtomDataPtr, 
    // but this keeps things nice and simple.
    if( result == noErr )
    {
        if( type == movieExportWidth )
        {
            [self setWidth:*(Fixed*)data];
        }
        else if( type == movieExportHeight )
        {
            [self setHeight:*(Fixed*)data];
        }
        else if( type == scSpatialSettingsType )
        {
            SCSpatialSettings *settings = 
                      (SCSpatialSettings *)data;
            [self setCodecType:settings->codecType];
        }
        else if( type == scDataRateSettingsType )
        {
            SCDataRateSettings *settings = 
                      (SCDataRateSettings *)data;
            [self setDataRateBytes:settings->dataRate];
        }
        else if( type == scTemporalSettingsType )
        {
            SCTemporalSettings *tempSettings =
                      (SCTemporalSettings *)data;
            [self setFrameRate:tempSettings->frameRate];
        }
    }

    // go through all the children hunting for more.
    while( cur = QTGetNextChildType (  container,  
                                       atom,  cur ) )
    {
        // we have children
        int childCount = QTCountChildrenOfType( 
                                 container, atom, cur );
        int i;
        for(i = 1; i < = childCount; i++)
        {
            QTAtom nested_atom;
            nested_atom = QTFindChildByIndex( 
                               container, atom, cur, i, nil );
            [self parseAtom:container 
                             withAtom:nested_atom ofType:cur];
        }
    }
}

I spent a lot of time trying to figure out what the data pointed to for each QTAtomType that I found. The doc that finally got me on the right path was the SCGetInfo doc. Unfortunatly, SCGetInfo didn't work for me (otherwise I wouldn't need this recursion).

How to find out more: When I started this I didn't know where the CodecType or the frame rate or anything would be stored. So I had to dump the QTAtomType's I saw as a string (remember, it's just a character code) and try to fumble through docs to figure out what was what. Fortunately most of the character codes make sense and most are defined in QuickTimeComponents.h. At first I saw that the movieExportHeight was a 4 byte value. I assumed it was a unsigned int. That was wrong. Turns out the height and width are a 'Fixed' value (FixedToFloat() is handy). I found this out by finding some sample code in BackgroundExporter or ThreadsExportMovie. I forget which one.

Unfortunately, trial and error and the dumping of hex characters seems to be the only route we have to figure out what's in these pointers. Well, that and looking at sample code. In reality, I hope that statement is wrong. I really hope somewhere there is a nice doc explaining each type and its payload definition and that I just couldn't find it. If that document doesn't exist then I either don't understand something important, or it's just crazy.

Links:
Working with QT Atoms
SCGetInfo - just remember, the actual function didn't work for me, but some payload types are in the doc.

Useful sample code:
BackgroundExporter
ThreadsExportMovie

What's Next?
I can now present the user with the QuickTime export settings and programmatically figure out what items of interest they selected. The next work item for me on this project is to get some settings persisted and touch up the UI a bit. I look forward to spending some quality time back with Cocoa. Seriously, these QuickTime API's make me feel dumb. Cocoa makes me feel smart. Anyway, I don't plan to post about persisting data or fumbling with UI's, that's already all over the place and, you don't have to take my word for it.

MovieExportGetSettingsAsAtomContainer(component, &settings);

That wasn’t so bad. If we wanted to use something other than the defaults, it gets a lot messier quickly, but that’s not me. With this, the user is presented with the default ‘export settings’ dialog. At the end of those five lines, we’re left with a QTAtomContainer that describes what the user selected. What’s a QTAtomContainer? Good question. While researching this I found a very fitting quote on a cocoa mailing list:

“Hang in there, QT Programming can be frustrating in the beginning but soon you go AHA!”

I’m still waiting for my AHA. I’m certainly getting closer daily, but I think I’m still a ways out. Oh, right, QTAtomContainer. Here’s my understanding:

A QTAtomContainer is a chunk(s) of memory[1] that describes some QT settings. A QTAtom points inside that region of memory. The container contains many QTAtoms. You use funky functions to navigate, add, remove, get and set QTAtoms. See http://developer.apple.com/documentation/QuickTime/APIREF/WorkingWithQTAtoms.htm.

[1] it’s unclear to me if the memory is one contiguous chunk or a linked list of chunks

Many hours pass. Heads hit keyboards.

I’ve given up. When I get more experience I plan to post this question to the QuickTime API’s mailing list, but for now I’m going to call it a bug and move on. Of course I only gave up after finding an alternative solution:

+ (void) GetCompressionName:(CodecType) type name:(Str31)aName
{
    aName[0] = 0;

CodecNameSpecListPtr    list;
OSErr err = GetCodecNameList(&list, 1); 

if( err != noErr )
{
    NSLog(@"GetCodecNameList err=%d", err);
    return;
}

int i;
for( i = 0; i < list->count; i++ )
{
    if( list->list[i].cType == type )
    {
        memcpy(aName, list->list[i].typeName, list->list[i].typeName[0]+1);
        return;
    }
}

NSLog("No match found");
return;

} Use this like:

Str31 sname;
[YourOBJ GetCompressionName:kDVCPALCodecType name:sname];

Where kDVCPALCodecType is a Codec Identifier. Also of interest is the fact that the h.264 codec is not listed in that document. It’s identifier is ‘avc1′ and it’s enum name is kH264CodecType. Although not documented, it works fine if passed into the above GetCompressionName, spitting out “h.264″.

Disclaimer: It’s my first day. If someone can explain why GetCompressionName(kH264CodecType, name) is failing I’d love to know. I imagine it’s something I’m missing, but just what, I’m not sure. Like I mentioned earlier, I’ll post this to the QuickTime mailing list later, when I feel more educated. No one wants to get flamed on their first day.

All code mentioned will be Cocoa. That’s what I do (well, am trying to do).