[FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Jerome Martinez]

On 12/02/2018 22:37, Carl Eugen Hoyos wrote:
> 2018-02-12 20:47 GMT+01:00 Jerome Martinez <jerome at mediaarea.net>:
>
>> https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx
>> is indicated by the person who provided it as with DPX alpha channel used
>> for actually storing infrared
> Thank you!
>
> This sample appears to confirm that GraphicsMagick is right and FFmpeg
> is buggy. To avoid creating more incorrect (ffv1) encodes, I (strongly)
> suggest to first fix this issue and commit your patch to support more
> bit-depths but if you disagree, please feel free to commit!

Sorry but I don't get it: the patch in this thread is totally separated 
from the alpha channel meaning issue. What should I "commit" about which 
"issue"? The only issues I have for the moment are that 12-bit padded 
DPX is supported by FFmpeg but not 12-bit packed DPX (the patch solves 
it), and that FFV1 support is with e.g. 12-bit YUVA but not 12-bit RGBA 
(I'll send a patch tomorrow for that, separated issue).

I am not against continuing the discussion about the alpha channel 
meaning issue in a global manner, but I wish it is not blocking for this 
patch inclusion (I already sent the modified patch in order to fix the 
issues you indicated), as this patch does not create something new 
compared to what already exists (RGBA 8-bit, 16-bit, 10-bit padded, 
12-bit padded, are already parsed by FFmpeg DPX parser) and the patch 
may be useful for people using "correctly" the alpha channel as they do 
for the other flavors of DPX, as well for people using RGB 12-bit packed.

Let me know if I should split the patch in 2 (RGB part, RGBA part), so 
at least the RGB one could be included, as it is not related with any 
"alpha channel" stuff.

> There is also this sample though:
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2392/
>
> The only solution I can think of is to change the semantics of the fourth
> dpx layer by default and to add an option (to the decoder) that allows using
> the current semantics that defaults to "auto" reading the encoder value.

IMO having the default everywhere as currently set is not "buggy", but a 
global (not limited to DPX) option could be interesting for setting the 
semantics of the channel flagged as "alpha", because people may already 
use DPX or FFV1 (FFV1 supports RGBA 8-bit or YUVA 16-bit for a long 
time, nothing new) or any other format with alpha channel not having the 
"right" semantics (and whatever is the format, it is impossible to know 
how it is used)