On 12/02/2018 22:37, Carl Eugen Hoyos wrote:
2018-02-12 20:47 GMT+01:00 Jerome Martinez <jer...@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)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
