Obviously we can't test this because the movie files are missing.
It's also unclear to me what defines whether movies files have alpha... nor how did you make such .mov files then?

I tried three times prior to sending the above message to attach and send the .mov files.

Three times the attachments seemed to attach correctly and three times it appeared to send the files, and it looks like three times it failed!

Eventually, I sent the message above in frustration, with only the blender file, and the message got through.

There must be some limit to the amount of data that can be attached to one of these bug report messages.

I'll try to send smaller .mov files and hope they get through!

love and peace,

Sol.

The .mov file with alpha transparency (premultiply) was created in Motion5, and I'm assuming it is correct
because when it is read back into Motion5 it works, ie. another video file can be loaded 'in parallel' in
the timeline such that the other video shows through the transparent background, and the .mov foreground
appears correctly merged.

love and peace, Sol

I'll attempt to send a very small .mov segment of the file (pasteall.org only allows max of 30mb)
The .mov file with premultiplied (transparent) alpha background is called
68keyedplusAfi.05.mov
Hope you get it!

love and peace,

Sol

pasteall.org will not accept a .mov file!

I've changed the .mov file prefix to .py to try to 'fool' pasteall.org

Not sure if it will work.

Otherwise I'll need to put the .mov file for example onto Google Drive and ask you for an email address I can send it to.

Love and peace,
Sol

pasteall.org seems to uploaded the file 68keyedplusAfi.05.py correctly.

Hopefully, if you change the suffix back to .mov it will be an exact
copy of the .mov file I have.

Love and peace,

Sol.

Please provide link to file here. We could not browse pasteall by file name. You could also use http://download.blender.org/ftp/incoming/ to place your file.

Or just make a 1 Mb movie file to attach then.

For the ftp service we have:

ftp to ftp.blender.org
login name Anonymous
cd to directory incoming

I've just uploaded the file

h264premult.mov 2013-Mar-22 18:38:08 7.1M video/quicktime

to

ftp://download.blender.org/ftp/incoming/

The alpha in this file works fine in motion5 but background appears to be black in blender 2.66a vse.

love and peace,

Sol

I have the file, but fail to get a quicktime debug build here still. Need some more advice.

However - there's no program on my mac that reads this with alpha, nor does quicktime or vlc player tell it has 4 channels.

I think Jens has been checking on RGBA for .mov before? Let's ask him.

Sorry, I've screwed up with this particular clip h264premult.mov. It is black.

However, I have all other clips that have alpha and work in motion5 but don't work in blender, ie. background clip doesn't show through.

All these clips are 100's of mb, so please give me some time to get you a small part of the right clip. I have to be very careful this time.

Sorry to waste your time on h264premult.mov.

Love and peace,

Sol

OK, I've transfered file tryForBugReport.mov to download.blender.org/ftp/incoming.

I've tested this file by inputting it into motion5 and checking that the alpha channel is active, ie. a background clip can be put
behind this clip, and it shows through correctly.

This same file ie. tryForBugReport.mov when loaded into blender appears with a 'black' background, ie. a background clip cannot
be seen 'through' this clip.

Hope I'm not being stupid, but it appears to me that blender is not reading/applying/processing the alpha channel correctly

love and peace,

Sol

Just to be sure i tested this with reference files and it works like a charm.
I suspect your video not containing alpha information.

Closing this bug now.

Jens

A very unsatisfactory ending for me.

I'd appreciate if you can place your 'reference files' on download.blender.org/ftp/incoming for me to test in blender.

Your analysis suggests that motion5 (an Apple product) can process alpha information correctly, produce correct output, which
can be read in again correctly and processed again correctly in motion5 to produce completely useable mixed video files...

and is broken at the same time!!

I would really appreciate the chance to see blender handle alpha channel correctly.

love and peace,

Sol

I was testing your file too, and confirm it has alpha. The problem is that we switched to FFMpeg for most of the movie formats, which is much faster to work with.
If I disable FFMpeg, the file reads with alpha in Blender (but much slower, and no real time playback).

So - the issue is not so much Blender, but an external library... adding a switch for users to choose which decoder library to use is an option. We'll study it.

Reopened this report, i'll test a decoder switch option, i'm sure quicktime can handle some cases better than ffmpg.

Thanks so much.

For us users, the key is to be able to use Blender for actual live end projects, so I'd really like to understand how to use Blender, in this case the VSE, particularly with alpha.

I must say I was amazed at what I perceived as the in-efficiency of the standard options Motion5 output, taking over 30mb to produce 2 seconds of video!

H.264 I think produced much more efficient output.

Look forward to your test results and information on how we can use the Blender VSE for alpha.

love and peace, Sol

Developer note:

Checked on the file. Initial guess was far away from reality.

The thing is. In file attached alpha channel is stored in separated stream which is for sure not handled by FFmpeg (which is logical -- how it'll know where to apply this information). It is possible to threat this stream as alpha by writing some code in blender side, but i'm not fan of doing this. And i'm not fan of adding extra options like switch between QuickTime/FFmpeg -- it'll just make interaction more confusing and increase gap between different platforms.

Ton, we used to stick "support commonly used interchange formats/codecs, all the rest shall be preprocessed externally" and personally i would say we shall really stick to this rule.

If you still want to check on that weirdo switch, make it local in anim_movie level (so image and movie clip datablocks will also work with this video). And also make sure proxies and tmecodes does work correct.

For the time being all movie files in Blender get read via FFmpeg, that's for all platforms the same. As a cross platform program I agree with Sergey to be careful with per-OS hacks for special formats. We dropped QT reading for mov files long ago, it is far too slow (wont play realtime) in Blender.

I am also not maintainer for this module (sergey is :), so I will followup his advice.

Once FFmpeg (an external project) decides to support it, we can do that as well.

For as now: if you want to work with videographics with alpha, save out sequences of images, that always works satisfying.
You can also check on more common (cross platforms) for alpha in video...

Thanks very much Ton for your time and your kind and professional consideration.

I will follow your advice and learn more about alternative more efficient ways of handling alpha in Blender via FFmpeg.

Love and peace,

Sol