[FFmpeg-devel] libavcodec/hap : add HapAlphaOnly decoding/encoding
martin.vignali at gmail.com
Tue Oct 10 20:39:52 EEST 2017
2017-10-10 16:08 GMT+02:00 Tom Butterworth <bangnoise at gmail.com>:
> > On 9 Oct 2017, at 22:36, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > 2017-10-09 21:34 GMT+02:00 Martin Vignali <martin.vignali at gmail.com>:
> >>>> IMHO, from a compositing point of view, alpha only and gray is
> >>>> the same thing.
> >>>> It's common (in cgi compositing for example), to use alpha (or
> >>>> matte) as separate gray only file.
> >>> If this is what you believe, I don't think an RGBA representation
> >>> should be committed.
> >> This is not about what i believe ! :-)
> > I think it is.
> > I asked you to explain why it is a good idea to map alpha only
> > to rgba and if this is what users expect. Your answer seems
> > to indicate that you share my feeling that it would be unexpected.
> > Carl Eugen
> Perhaps I am being slow (which is very possible) - I don’t understand how
> by using a gray pixel format, transcoding between an RGBA codec and Hap
> Alpha-Only would work as expected without users having to add
> counterintuitive filtering to swizzle channels?
Before answering, i'm fine with both pix_fmt option ! even if i found one
really more easy to understand (the gray)
I think if a user use a separate file to store alpha, is not so strange to
use gray (lot of software works like that (in compositing, edit, color
If a user is not familiar with channel manipulation, he will probably just
use an rgba picture.
But we can also add a part in the ffmpeg doc, to explain how to encode from
RGBA, and what is expected as default.
> I would not expect there is much of an audience for this codec, but such
> audience there is is likely to be transcoding to Hap Alpha from something
> like ProRes 4444 and to expect the alpha channel to be selected - eg the
> following must work without extra options:
> ffmpeg -i MyProRes4444.mov -vcodec hap -format hap_alpha_only out.mov
Depend of the default way to use this codec.
If it use to replace for example an HAP video for animated alpha for
example if we want to have a still picture with an animated alpha : we
export one still frame, and one HAPAlpha Only video).
If we consider this is a "valid" use of this codec (which i think it is, or
i miss something),
the user will output a gray picture in his media creation software (as rgb
or gray), and encode it
ffmpeg -i myGrayMatte.mov -vcodec hap -format hap_alpha_only.mov
And if the user really want to extract the alpha plane of an rgba input,
it's probably only something like that (untested)
ffmpeg -i myRgbaInput -vf extractplanes=a -vcodec hap -format
> Furthermore, how is an API user to know that the frames they acquire or
> emit are in fact alpha content when they are tagged as gray?
We can maybe consider, that the data format value in the mov is enough ?
> Patches 0001, 0002, 0006 and 0007 LGTM and are uncontentious. As they are
> required for Hap Q Alpha support I will commit these shortly, assuming
> nobody objects.
Ok for that, so we can discuss in parallel about HAPQAlpha support (with
RGBA pix_fmt output this time ! :-)
More information about the ffmpeg-devel