Alpha channel in Prores4444 is not read

[rmk]

I made a transparent PNG using Gimp, imported that into a Final Cut Pro 7 project and put it on a sequence configured to use Prores4444 as codec and exported the file which resulted in a one-frame Prores4444 file. I then verified that the resulting file still had the transparency by using it as an overlay in Final Cut.

I then transcoded the file to Prores4444 again, this time using ffmpeg. Importing that video into Final Cut Pro and used that as an overlay which did not work (i.e. transparency was gone).

Command line used (current ffmpeg with a patch Carl sent me on the ML today):

ffmpeg -i ~/testdata/video/finalcut-output/prores4444_with_transparency.mov -vcodec prores_kostya -pix_fmt yuv444p10le -acodec copy ~/tmp/prores4444_with_transparency_ffmpeg_patched.mov
ffmpeg version N-44391-gf9dd2e5 Copyright (c) 2000-2012 the FFmpeg developers
  built on Sep 12 2012 12:09:31 with gcc 4.2.1 (GCC) (Apple Inc. build 5664)
  configuration: 
  libavutil      51. 72.100 / 51. 72.100
  libavcodec     54. 55.100 / 54. 55.100
  libavformat    54. 26.101 / 54. 26.101
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3. 16.103 /  3. 16.103
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
Guessed Channel Layout for  Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/krueger/testdata/video/finalcut-output/prores4444_with_transparency.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2012-09-12 08:48:56
  Duration: 00:00:00.04, start: 0.000000, bitrate: 43461 kb/s
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le, 1920x1080, 40697 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 2012-09-12 08:48:56
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, s16, 1536 kb/s
    Metadata:
      creation_time   : 2012-09-12 08:48:56
      handler_name    : Apple Alias Data Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74)
    Metadata:
      creation_time   : 2012-09-12 08:48:57
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
Output #0, mov, to '/Users/krueger/tmp/prores4444_with_transparency_ffmpeg_patched.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    encoder         : Lavf54.26.101
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 2012-09-12 08:48:56
      handler_name    : Apple Alias Data Handler
      timecode        : 01:00:00:00
    Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, 1536 kb/s
    Metadata:
      creation_time   : 2012-09-12 08:48:56
      handler_name    : Apple Alias Data Handler
Stream mapping:
  Stream #0:0 -> #0:0 (prores -> prores_kostya)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=     141kB time=00:00:00.04 bitrate=28897.2kbits/s    
video:132kB audio:8kB subtitle:0 global headers:0kB muxing overhead 1.286356%

I'll attach the Prores4444 file generated Final Cut Pro and the PNG used to create the video. If it would be more convenient for debugging this to have a video with a specific setup (e.g. smaller frame size, a specific pattern or color distribution), don't hesitate to tell me and I will produce it.

[rmk]

Prores 4444 file with transparent background exported from Final Cut Pro 7

[rmk]

PNG file used to create the video

[cehoyos]

I see three (not necessarily related) problems:
There currently is no suitable pixel format to store yuva444 with >32 bit per pixel, see ticket #1749
The prores encoder does not support writing an alpha channel, see ticket #1750

Finally, the decoder does not support reading the alpha channel.

[Timothy_Gu]

Ticket #1749 is closed now. This bug is blocked by #1750.

[cehoyos]

Implemented by Kostya.