FLV with Alpha channel

egproductions

egproductions

Veteran
So I've been having a hard time figuring out how to accuratly calculate my FLV file sizes. Normally if I want to determine the file size of a compressed video I multiply bitrate x seconds and divide by 8. This has worked for me but now that I am encoding with the alpha channel, it doesn't matter what I set my bitrate the extra channel increases the file size. This makes sense to me because you can figure that you can't have compression on an alpha channel since the transparency needs to be exact on or off or a value in between.

So my theory was that for any given clip witha certain amount of transparency and a certain resolution you are going to have a consistent amount of the file size that is being used up by transparency. I took an exported clip that I set to 400kbps video and 64kbps audio and worked backward to determine how much data was left over. I worked it out to be that there is roughly 300kbps that the alpha channel was using up. I figured that this is always going to be a constant for this clip so if I wanted to target a video bitrate of 400kbps I would have set the video bitrate to 100kbps and the extra 300 from the alpha channel would be added automatically. well it didn't work out this way. it wound up only being an extra 150kbps extra after for that export.

How can accuratly determine what my resulting file size will be for flvs with alpha channel encoding?

I am using premiere pro --->adobe media encoder
 
... I wasn't even aware that FLVs supported alpha channels.

I'm too lazy to do calculations myself, but you can start with raw bitmap sizes for a given resolution based on RGB bit values. For example, 24-bit RGB (meaning 8 bits per channel), would entail an *additional* 8-bits for the alpha channel, making it 32-bit RGBA, but I'm sure you know this already.

People use these numbers, in a given image resolution, to determine uncompressed file size (and datarates, which is useful for decoding video in a certain bandwidth, since it's usually decoded to RGB). What confuses me is that FLV is lossy anyway, so you can't *possibly* make absolute measurements like that. Is there a lossless mode (that supports RGBA) I'm unaware of?... Unless you're referring to H.264 lossless mode within FLV, but I've never heard of such a use.
 
FLVs are lossy, however, my theory is that when encoding the alpha channel it bypassed any compression since retaining the accurate transparency is crucial and can't be fudged like the compression on the RGB channels. But if this were the case then there should always be the same amount of file size used up for the alpha channel no matter what the chosen bitrate.

The codec used is the on2 VP6 codec. This codec supports transparency. I have the option of using sorenson spark but that one doesn't support the alpha channel.
 
Interesting, I wasn't aware that VP6 supported transparency. Well, in any case, if I could find the exact numbers on bitmap filesizes for a given resolution I'd post them, but start there. It's relatively easy from what I've seen to calculate a given datarate per channel.

It's rough, but even capturing a single SD frame (obviously your frame size is lower) to a bitmap file would give you the estimated size - theoretically you could divide that into the respective channels.
 
Encoders with rate control isses are a huge pain to work with in your situation where you're trying to hit a target bitrate for streaming.

Just keep encoding small test files untill you get a good result.

If you are dropping this FLV into a custom flash animation, sometimes you can get away with encoding a smaller file, and scaling it in the Flash animation to save space.

Be careful about scaling your file in Adobe media encoder. There are some pretty bad scaling issues when you are trying to make a frame size that isn't a division from a whole nubmer. See "Reducing Frame Size" in this thread:

http://www.dvxuser.com/V6/showthread.php?t=137018


See an example of bad scaling here:

http://www.tavproductions.com/Video/gamepreserve.html
 
You must log in or register to reply here.
Back
Top