Now some remarks :
1. Don’t use Glade XML files, prefer GtkBuilder. It does almost the same thing, but the format is a bit different. The bonus being that it’s integrated in GTK and removes a dependency on libglade.
http://pygtk.org/docs/pygtk/class-gtkbuilder.html

2. Don’t use GtkRadioButton for codecs, it doesn’t scale well depending on the codecs available on the machine. Use one GtkTreeView for audio codecs, another one for video codecs so you can just not display the codecs not supported by the container.

3. Remove all the “Choose” from the interface. They clutter it and give no useful information.

4. Remove the “Container” word, which may be a bit confusing for newbies. “Output Format” or “Output File Format”. According to the widgets you choose for the UI, make sure you respect the capitalization for UI elements:
http://library.gnome.org/devel/hig-book/stable/design-text-labels.html.en#layout-capitalization

5. Have the Cancel and Transcode buttons respectively left and right aligned.

Nice work

It will be very interesting to see how this program develops, the introduction of profiles will allow you to make it much simpler more task based even as the list of codecs and other options gets much longer. A longer list of codecs won’t scale well though, putting them in drop down menus allows the interface to scale better but slows down users who would like to scan and select what they want quickly (but I think this would be an acceptable trade off since you would hope to provide profiles and obviate the need for users to choose the codecs themselves most of the time).

In terms of ergonomics bigger buttons are as you know easier to hit. I’d be interested to see if you could put the input and output choosers below their titles so they could use the full width of the dialog and see if that doesn’t make the dialog too chunky.

The interface Rudd-O uses in his program looks rather good.

Since transcoding can be a potentially time consuming and resource intensive task it might be useful to have a Pause button to allow users to interrupt the task without being forced to cancel the transcoding from scratch. The idea might still be impractical to implement or risk making the dialog overcomplicated but I leave the idea for your consideration.

From your plans it seems like you want to keep this as a standalone application but if you can manage to keep it simple (a single dialog) you might also be able to integrate it as a Plugin to Pitivi, which would be very cool. (It might also help limit the scope of the application if you could point to other parts of Pitivi to do more complicated tasks you’d prefer not to include.)

Nice work.

Regards, Benny