prores alpha blending results in opaque rectangle

[projectsymphony]

The attached file is a prores 4444 with a particular decoding problem. The video has a logo fading from from black and then fading to black again. However lavc rather than fading back to black, shows an opaque square rectangle.

ffmpeg version N-73640-gae4c9dd Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=clang --enable-debug --disable-optimizations --disable-yasm --disable-asm --enable-libfdk-aac --enable-version3 --enable-nonfree --enable-gpl --disable-doc --enable-libmp3lame --enable-openssl --enable-libfreetype --enable-avresample --enable-libopenjpeg --enable-libx264
  libavutil      54. 28.100 / 54. 28.100
  libavcodec     56. 47.100 / 56. 47.100
  libavformat    56. 40.100 / 56. 40.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 21.100 /  5. 21.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'proresalphablock.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 2015-07-09 05:29:21
    encoder         : Lavf56.21.0
  Duration: 00:00:09.43, start: 0.031833, bitrate: 13066 kb/s
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuva444p10le, 1920x1080, 13066 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
    Metadata:
      creation_time   : 2015-07-09 05:29:21
      handler_name    : DataHandler
      encoder         : Apple ProRes 4444

[gjdfgh]

The output is an alpha format, so lavc doesn't blend anything. This is probably a libswscale problem, rather than libavcodec. Or possibly prores doesn't use straight alpha, or the alpha is inverted, or whatever else could go wrong.

Please post a sample file.

[projectsymphony]

Not sure, there is a transparent layer which blended correctly, and if I don't modify the pixel format during conversion it still shows the blending problem.

Anyway I uploaded the sample to ftp incoming / proresalphablock . mov
Can you confirm upload went through?

[gjdfgh]

I don't see the file.

[projectsymphony]

When I am uploading I get

250 OK. Current directory is /incoming
TYPE A
200 TYPE is now ASCII
PASV
227 Entering Passive Mode (138,195,131,196,46,34)
LIST
150 Accepted data connection
226-Sorry, we were unable to read [.]
226-Options: -l 
226 0 matches total

and then it says "transfer incomplete" or just hangs until "connection failed".
Are there other uploading facilities available?

[projectsymphony]

uploaded to ​http://www.datafilehost.com/d/427f09be
(md5 720e0c3c1de8c22d0b061d75e8e1c4b3)

[gjdfgh]

Accessing the download initiation link directly is not allowed. The download only starts if you click from the download page. If you are not being redirected automatically click here.

[Michael Niedermayer]

The file plays fine, but the player you use ignores alpha. (many players ignore alpha, isnt really wrong if they do if theres nothing behind)

if you render the file over a black background you get the fading

./ffplay proresalphablock.mov  -vf 'scale[in],color=black:1920x1080[back],[back][in]overlay'

[gjdfgh]

Well, I'd expect libswscale to take care of some blending when converting to a non-alpha format.

[projectsymphony]

yes I agree with gjdfgh, and what about conversion using ffmpeg?
It's a well known behaviour that when alpha is converted to an opaque format it is blended with black by default

btw, using the provided option with ffmpeg results in an infinite conversion

ffmpeg -i proresalphablock.mov  -vf 'scale[in],color=black:1920x1080[back],[back][in]overlay' -pix_fmt yuv420p output.mov
ffmpeg version N-73640-gae4c9dd Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=clang --enable-debug --disable-optimizations --disable-yasm --disable-asm --enable-libfdk-aac --enable-version3 --enable-nonfree --enable-gpl --disable-doc --enable-libmp3lame --enable-openssl --enable-libfreetype --enable-avresample --enable-libopenjpeg --enable-libx264
  libavutil      54. 28.100 / 54. 28.100
  libavcodec     56. 47.100 / 56. 47.100
  libavformat    56. 40.100 / 56. 40.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 21.100 /  5. 21.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'proresalphablock.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 2015-07-09 05:29:21
    encoder         : Lavf56.21.0
  Duration: 00:00:09.43, start: 0.031833, bitrate: 13066 kb/s
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuva444p10le, 1920x1080, 13066 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
    Metadata:
      creation_time   : 2015-07-09 05:29:21
      handler_name    : DataHandler
      encoder         : Apple ProRes 4444
[libx264 @ 0x7fe10c03ce00] using SAR=1/1
[libx264 @ 0x7fe10c03ce00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
[libx264 @ 0x7fe10c03ce00] profile High, level 4.0
[libx264 @ 0x7fe10c03ce00] 264 - core 148 r2538+33M bff0ecd - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mov, to 'output.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf56.40.100
    Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 25 fps, 12800 tbn, 25 tbc (default)
    Metadata:
      creation_time   : 2015-07-09 05:29:21
      handler_name    : DataHandler
      encoder         : Lavc56.47.100 libx264
Stream mapping:
  Stream #0:0 -> #0:0 (prores (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[..]
frame=34281 fps= 48 q=28.0 size=    2458kB time=00:22:48.92 bitrate=  14.7kbits/

I had to stop it manually, but this is probably a separate bug.

[Carl Eugen Hoyos]

Replying to projectsymphony:

It's a well known behaviour that when alpha is converted to an opaque format it is blended with black by default

This is not how FFmpeg or avconv behave (or ever have) and such a behaviour would be a significant and unexpected change afaict. (And why should black be the default? See for example laraShadow_dl.flv.)

I am closing this ticket because I neither see a bug nor do I think the bug tracker is the right place to discuss a significant change of behaviour: Imo, send a patch (or PoC) to the development mailing lists.

[gjdfgh]

This is not how FFmpeg or avconv behave (or ever have) and such a behaviour would be a significant and unexpected change afaict.

Bullshit.

[Carl Eugen Hoyos]

Michael has sent a patch.

[Carl Eugen Hoyos]

Fixed by Michael in e755954a84c96d7344e12ce6e798660d8bf261ea (and three additional commits before).

[projectsymphony]

still happens to me

$ ./ffmpeg -i ./proresalphablock.mov -pix_fmt yuv420p output.mp4
ffmpeg version N-74624-gfd2977d Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=clang --enable-debug --disable-optimizations --disable-yasm --disable-asm --enable-libfdk-aac --enable-version3 --enable-nonfree --enable-gpl --disable-doc --enable-libmp3lame --enable-openssl --enable-libfreetype --enable-avresample --enable-libopenjpeg --enable-libx264
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 58.100 / 56. 58.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 37.100 /  5. 37.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './proresalphablock.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 2015-07-09 05:29:21
    encoder         : Lavf56.21.0
  Duration: 00:00:09.43, start: 0.031833, bitrate: 13066 kb/s
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuva444p10le, 1920x1080, 13066 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
    Metadata:
      creation_time   : 2015-07-09 05:29:21
      handler_name    : DataHandler
      encoder         : Apple ProRes 4444
[libx264 @ 0x7fe545003600] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
[libx264 @ 0x7fe545003600] profile High, level 4.0
[libx264 @ 0x7fe545003600] 264 - core 148 r2538+33M bff0ecd - H.264/MPEG-4 AVC codec - Copyleft 2003-2015 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'output.mp4':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf56.40.101
    Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1920x1080, q=-1--1, 23.98 fps, 24k tbn, 23.98 tbc (default)
    Metadata:
      creation_time   : 2015-07-09 05:29:21
      handler_name    : DataHandler
      encoder         : Lavc56.58.100 libx264
Stream mapping:
  Stream #0:0 -> #0:0 (prores (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame=   61 fps=8.7 q=28.0 size=      15kB time=00:00:00.12 bitrate=1006.3kbits/frame=   66 fps=8.6 q=28.0 size=      16kB time=00:00:00.33 bitrate= 385.8kbits/frame=   71 fps=8.6 q=28.0 size=      16kB time=00:00:00.54 bitrate= 242.7kbits/frame=   76 fps=8.6 q=28.0 size=      16kB time=00:00:00.75 bitrate= 179.1kbits/frame=   81 fps=8.6 q=28.0 size=      17kB time=00:00:00.95 bitrate= 143.1kbits/frame=   86 fps=8.6 q=28.0 size=      17kB time=00:00:01.16 bitrate= 119.9kbits/frame=   91 fps=8.6 q=28.0 size=      17kB time=00:00:01.37 bitrate= 103.8kbits/frame=   96 fps=8.6 q=28.0 size=      18kB time=00:00:01.58 bitrate=  92.0kbits/frame=  101 fps=8.6 q=28.0 size=      18kB time=00:00:01.79 bitrate=  82.8kbits/frame=  106 fps=8.6 q=28.0 size=      29kB time=00:00:02.00 bitrate= 119.4kbits/frame=  111 fps=8.6 q=28.0 size=      33kB time=00:00:02.21 bitrate= 121.1kbits/frame=  116 fps=8.6 q=28.0 size=      37kB time=00:00:02.41 bitrate= 124.7kbits/frame=  121 fps=8.6 q=28.0 size=      46kB time=00:00:02.62 bitrate= 141.9kbits/frame=  126 fps=8.6 q=28.0 size=      55kB time=00:00:02.83 bitrate= 158.7kbits/frame=  131 fps=8.6 q=28.0 size=      56kB time=00:00:03.04 bitrate= 149.6kbits/frame=  136 fps=8.6 q=28.0 size=      56kB time=00:00:03.25 bitrate= 141.5kbits/frame=  141 fps=8.6 q=28.0 size=      57kB time=00:00:03.46 bitrate= 134.2kbits/frame=  146 fps=8.6 q=28.0 size=      57kB time=00:00:03.67 bitrate= 127.8kbits/frame=  151 fps=8.6 q=28.0 size=      58kB time=00:00:03.87 bitrate= 122.0kbits/frame=  156 fps=8.6 q=28.0 size=      59kB time=00:00:04.08 bitrate= 117.3kbits/frame=  161 fps=8.6 q=28.0 size=      59kB time=00:00:04.29 bitrate= 112.3kbits/frame=  166 fps=8.6 q=28.0 size=      59kB time=00:00:04.50 bitrate= 107.8kbits/frame=  171 fps=8.6 q=28.0 size=      60kB time=00:00:04.71 bitrate= 103.7kbits/frame=  176 fps=8.6 q=28.0 size=      60kB time=00:00:04.92 bitrate= 100.0kbits/frame=  181 fps=8.6 q=28.0 size=      60kB time=00:00:05.13 bitrate=  96.5kbits/frame=  186 fps=8.6 q=28.0 size=      61kB time=00:00:05.33 bitrate=  93.3kbits/frame=  191 fps=8.6 q=28.0 size=      61kB time=00:00:05.54 bitrate=  90.3kbits/frame=  196 fps=8.6 q=28.0 size=      62kB time=00:00:05.75 bitrate=  87.6kbits/frame=  201 fps=8.6 q=28.0 size=      62kB time=00:00:05.96 bitrate=  85.1kbits/frame=  206 fps=8.6 q=28.0 size=      62kB time=00:00:06.17 bitrate=  82.7kbits/frame=  211 fps=8.6 q=28.0 size=      63kB time=00:00:06.38 bitrate=  80.5kbits/frame=  216 fps=8.6 q=28.0 size=      63kB time=00:00:06.58 bitrate=  78.4kbits/frame=  221 fps=8.6 q=28.0 size=      63kB time=00:00:06.79 bitrate=  76.5kbits/frame=  227 fps=8.6 q=28.0 size=      64kB time=00:00:07.04 bitrate=  74.3kbits/frame=  227 fps=8.5 q=-1.0 Lsize=      71kB time=00:00:09.38 bitrate=  62.2kbits/s dup=1 drop=0    
video:68kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 5.050767%
[libx264 @ 0x7fe545003600] frame I:2     Avg QP:13.24  size:  7718
[libx264 @ 0x7fe545003600] frame P:64    Avg QP:10.83  size:   549
[libx264 @ 0x7fe545003600] frame B:161   Avg QP:12.87  size:   113
[libx264 @ 0x7fe545003600] consecutive B-frames:  4.8%  1.8%  0.0% 93.4%
[libx264 @ 0x7fe545003600] mb I  I16..4: 42.0% 55.8%  2.3%
[libx264 @ 0x7fe545003600] mb P  I16..4:  0.4%  0.3%  0.0%  P16..4:  0.6%  0.1%  0.0%  0.0%  0.0%    skip:98.6%
[libx264 @ 0x7fe545003600] mb B  I16..4:  0.1%  0.1%  0.0%  B16..8:  0.3%  0.0%  0.0%  direct: 0.0%  skip:99.5%  L0:63.4% L1:36.2% BI: 0.4%
[libx264 @ 0x7fe545003600] 8x8 transform intra:53.1% inter:46.6%
[libx264 @ 0x7fe545003600] coded y,uvDC,uvAC intra: 6.9% 10.4% 0.0% inter: 0.1% 0.1% 0.0%
[libx264 @ 0x7fe545003600] i16 v,h,dc,p: 82% 14%  3%  1%
[libx264 @ 0x7fe545003600] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 62% 11% 27%  0%  0%  0%  0%  0%  0%
[libx264 @ 0x7fe545003600] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 20% 19%  5%  3%  3%  3%  2%  2%
[libx264 @ 0x7fe545003600] i8c dc,h,v,p: 96%  2%  2%  0%
[libx264 @ 0x7fe545003600] Weighted P-Frames: Y:20.3% UV:1.6%
[libx264 @ 0x7fe545003600] ref P L0: 95.8%  3.5%  0.4%  0.2%  0.1%
[libx264 @ 0x7fe545003600] ref B L0: 27.6% 71.4%  1.0%
[libx264 @ 0x7fe545003600] kb/s:58.08

I get the white opaque rectangle where the transition should happen.

[Carl Eugen Hoyos]

-sws_flags +alphablend

[projectsymphony]

I guess you mean -alphablend 1

it still looks like a bug to me, ffmpeg/ffplay should behave like the reference software and quicktime is able to correctly blend this frame.

[Carl Eugen Hoyos]

No, I don't think a default massive performance regression is acceptable.

Sorry about the typo.

[projectsymphony]

I agree, that's why I would assume ffmpeg command line would be smart enough to apply that flag only when needed, for example, when needing to replicate the behaviour of the reference software rather than showing an opaque rectangle...

[Carl Eugen Hoyos]

How would ffmpeg know that you want a black background? How would it know that the encoder decided to use a white rectangle as background for the roi as in your sample?

[projectsymphony]

because black when alpha is not visible is the default behaviour for any sane player
try it with quicktime if you don't believe me

[gjdfgh]

How would ffmpeg know that you want a black background?

Because that's standard behavior with prores, apparently.

[projectsymphony]

this is still happening in ffmpeg version N-74726-gfb42e77
(so is the infinite conversion using the suggested overlay filter)

[gjdfgh]

For the record, I agree with reopening it.

I suspect libswscale does it wrong here, and it should be fixed.

[Carl Eugen Hoyos]

It works fine here, so closing as fixed.

[projectsymphony]

can you paste the full uncut ffmpeg output and upload the converted video somewhere please?

[gjdfgh]

I tried this command line:

./ffmpeg -i ./proresalphablock.mov -pix_fmt yuv420p output.mp4

And it still produces a broken file with a broken fade.

@carl: please don't close this again until it's really fixed. Unless you really want FFmpeg to produce broken files, but even then consider yourself overruled by other ffmpeg devs.

[Carl Eugen Hoyos]

I am sorry but I tested the issue and it was fixed by Michael.

[gjdfgh]

You're a disgrace to this bug tracker.

[Carl Eugen Hoyos]

Replying to gjdfgh:

You're a disgrace to this bug tracker.

Thank you for your kind words!

[Elon Musk]

It is slow.

[projectsymphony]

Can you paste the full uncut ffmpeg output and upload the converted video somewhere please?
In this way we will be able to confirm what you are claiming.

Also not sure what is fixed, as the commit mentioned looks unrelated.

[Carl Eugen Hoyos]

Replying to projectsymphony:

Can you paste the full uncut ffmpeg output and upload the converted video somewhere please?
In this way we will be able to confirm what you are claiming.

I thought you had already tested it?

Also not sure what is fixed, as the commit mentioned looks unrelated.

Then please look at the three commit before as stated above.

[Timothy Gu]

@cehoyos, please do not close this issue again. This is becoming a severe case of ​edit warring and is not constructive. I have reopened this ticket because at least three different people have reopened it, and a patch is available on the mailing list. Please take the time to review the patch and/or voice your opinion clearly so that everybody here understands what you mean, but DO NOT close this ticket again until a consensus is reached.

[Carl Eugen Hoyos]

I did review and comment on the patch.

This issue was fixed, if you want to report another issue, please open a new ticket.

[Michael Niedermayer]

Please find a solution and consensus and dont just close and reopen the ticket, this will lead to no good if it continues

[gjdfgh]

The question is: how many ffmpeg developers have to disagree with Carl, until he is overruled?

Or does Carl alone have the right to decide what is a bug and what not?

[Michael Niedermayer]

Ive created #4814 for the alpha blend default. There should be no dispute on leaving #4814 open until there is some agreement amogth all parties

[projectsymphony]

Replying to cehoyos:

This issue was fixed, if you want to report another issue, please open a new ticket.

The issue is *not* fixed, converting this sample with ffmpeg -i proresalphablock.mov -pix_fmt yuv420p output.mov produces a file which differs from the one played with the reference decoder (quicktime).

[Carl Eugen Hoyos]

There is another ticket now where the default behaviour is discussed.

[iive]

@projectsymphony, FFmpeg provides you with the options to get your desired behavior, please use them.

1. Using the alpha channel means that you allow the player and/or editing software to put any kind of background there.

This is the only reasonable assumption.
If you wanted that background to be black, you should have blended it before encoding and not using alpha channel.

2. There is no any solid proof that blend to black is standard behavior. Your player does that, but it is not the only reference player for FFmpeg. If there is no written standard, quicktime behavior could be changed in next version.

3. If you can find or demonstrate that the default desired color is explicitly stored in the file, then you could request feature that allow it to be passed as metadata.

You should understand that blend-to-black might work for you, but setting it as default is as wrong as any of the other possible behaviors.

• There are encodes that signal existence of alpha channel, but it contains random garbage. These files would suddenly break in spectacular way.

• There are samples (laraShadow_dl.flv) that assume blend-to-white as correct and standard behavior.

• There are samples (your prores encode) that assume blend-to-black as correct and standard behavior.

All these behaviors are wrong. None of them could be enabled without breaking the other two (in quite obscure way).

---

Now, it might be possible to implement format specific defaults, by passing metadata from the demuxer to the filter chain. I have no idea how hard that task is. ​This might be relevant.

If @gjdfgh (I guess that is @kierank) wants to implement it, then I would ask Carl to assign this bug to him and to leave it open.
Until then I guess the status of the bug is "closed - won't fix".

[gjdfgh]

You forgot PNG, that essentially requires the same behavior as prores.

laraShadow_dl.flv unfortunately just shows black when blending against black, but have you considered that the result is not better AT ALL when just discarding the alpha channel?

From what I see, blending against black (or maybe blending against a checkerboard) is still the sanest default behavior.

And the ONLY reason our bug tracker terrorist rejects this new default behavior is because it's "slower". A typical example of "fast and wrong is better than correct and not-turbo-fast". Which is incidentally also the reason why ffmpeg fucks up so often (preferring speed over correctness).

@gjdfgh (I guess that is @kierank)

No, wm4.

[projectsymphony]

Replying to cehoyos:

There is another ticket now where the default behaviour is discussed.

yes, but until that behaviour is implemented, the sample is buggy with ffmpeg, and so this bug should remain open.

Additionally I am not saying that alphablend should be always active, but that it should be enabled for prores, because that is the expected behaviour for this decoder.

[Carl Eugen Hoyos]

Funny that I can reproduce the "bug" you see with QT on OSX...

[projectsymphony]

Replying to cehoyos:

Funny that I can reproduce the "bug" you see with QT on OSX...

Quicktime X disagrees...
Can you please keep this bug open? What benefit is there to close it every time?

[gjdfgh]

Turns out QT's "export" function gets it wrong (like ffmpeg), while playback works.

So if you compare ffplay and QT output, this bug report is still justified, but not if you compare ffmpeg and QT export.

[Carl Eugen Hoyos]

Replying to gjdfgh:

Turns out QT's "export" function gets it wrong (like ffmpeg), while playback works.

Or to say it differently: It is the player's job to decide what to do with alpha content, not the libraries'...

[projectsymphony]

Replying to gjdfgh:

Turns out QT's "export" function gets it wrong (like ffmpeg), while playback works.

So if you compare ffplay and QT output, this bug report is still justified, but not if you compare ffmpeg and QT export.

Oh interesting, thanks for explaining what cehoyos meant, one would expect steps to reproduce to be provided when making claims...

Anyway, I have filed a bug with Apple about this, rdar://22499505, at least something productive can come out of this.

[projectsymphony]

any update on this bug?