I'm having difficulties with alpha channel in an exporter. Symptoms - no alpha channel is given to my exporter by Premiere Pro when using source with alpha channel. I created a sample test video that has rows of (red pixel, green pixel, blue pixel, alpha pixel). So, while examining bits in the memory, I always see 0xff for alpha component (i.e, red pixel looks like 0xff 0x00 0x00 0xff, green pixel looks like 0x00 0xff 0x00 0xff, blue pixel looks like 0x00 0x00 0xff 0xff, and alpha pixel looks like 0x00 0x00 0x00 0xff), which looks to me like no alpha channel given in the frame. I request frames in BGRA_4444_8u pixel format. Correct me if I'm mistaken, but shouldn't that color format give me alpha component if source has alpha? I thought "ok, may be sequence or project settings have setting that i'm not enabling to preserve alpha", but as I found out, Premiere Pro preserves alpha unless explicitly told not to preserve by user. SDK Exporter sample project description mentions support for uncompressed 8 bit RGB with or without alpha. Does that mean that Premiere Pro should give frames with alpha channel if source had it? I looked at how sample exporter requests frames from Premiere Pro and only color format-specific info is custom 'sdk' color format, unless I overlooked something.

What does your timeline look like, so that you are sure that the source footage has an alpha channel? Prior to export, you can view the alpha channel of the timeline by going into the menus in the Program Monitor, and switching the Output mode to Alpha.

Yes, if you are requesting BGRA, Premiere Pro should pass along any alpha information, if there is any to pass through the pipeline. Formats like BGRX will assume that there is no alpha channel.

for the purpose of debugging I use two videos - first one is a talking head with alpha channel and second one is 640x480.png file described in first post. When I import talking head video and switch output mode to Alpha, I see white for the person talking and black for alpha, so that means that I do have alpha channel. I also see alpha channel in my second 640x480.png file. But none of the test clips come out with alpha, as described in my first post.

I looked into the SDK samples, and there was a few adjustments I had to make to get the alpha channel to round trip successfully, when exported out using the SDK Exporter, and reimported using the SDK File Importer.

First, I had to make sure info in the file header was set correctly. In WriteSDK_FileHeader(), I set the bit depth according to the codec setting retrieved using:

For "SDK file format", 32 means there's alpha, and 24 means no alpha. For the two video "codecs" supported, I set it like this:

switch(codecSubType.value.intValue)

{

case SDK_8_BIT_RGB:

mySettings->SDKFileRec.depth = 32;

break;

case SDK_10_BIT_YUV:

mySettings->SDKFileRec.depth = 24;

break;

}

The other change I had to make was in RenderAndWriteVideoFrame(). One of the parameters for RenderVideoFrame(), SequenceRender_ParamsRec, includes a member called inCompositeOnBlack. Again, I set this according to the codec:

switch(codecSubType.value.intValue)

{

case SDK_8_BIT_RGB:

renderParms.inCompositeOnBlack = kPrFalse;

break;

case SDK_10_BIT_YUV:

renderParms.inCompositeOnBlack = kPrTrue;

break;

}

This inCompositeOnBlack may be the problem you're running into. You should set it to false if you want the alpha preserved.

yep, inCompositeOnBlack flag did it. Just double check with you: If I always have that flag set to false, that shouldn't mess up non-alpha compressions, right? We are using pixel forma with alpha, as it is mentioned in first post.

Great, glad that worked! If you are exporting to a format without an alpha channel, you should set inCompositeOnBlack to true. For example, if you have a clip that has it's opacity brought down, you'd want that change to be reflected in the non-alpha (RGB, etc) values of your clip. To do that, you'd need to set inCompositeOnBlack to true for that case.