[FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Sep 27 18:51:33 EEST 2017

2017-09-27 15:20 GMT+02:00 Martin Vignali <martin.vignali at gmail.com>:
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth <bangnoise at gmail.com>:
>> > On 27 Sep 2017, at 11:59, Martin Vignali <martin.vignali at gmail.com>
>> wrote:
>> >
>> >>
>> >>> +        ctx->tex_fun = ctx->dxtc.rgtc1u_block;
>> >>> +        avctx->pix_fmt = AV_PIX_FMT_RGB0;
>> >>
>> >> The rgtc1u_block function places the single channel value in every
>> channel
>> >> except the alpha channel
>> >> The pixel format you have chosen is one which disregards the alpha
>> channel
>> >>
>> >> The output of this alpha-only decoder should be in the alpha channel of
>> a
>> >> pixel format which carries alpha. Probably other channels should have
>> zero
>> >> values.
>> >>
>> >>
>> > Hi Tom,
>> >
>> > After Carl answer, and thinking about that,
>> > The goal of HapAlphaOnly, is to store alpha, but can also store gray only
>> > (much better than HAP)
>> > In fact, it can be call HAP Gray !
>> But it isn’t
>> > For example from my part, i would like to use this codec, for matte, but
>> > also for gray only layer (use with color blending)
>> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
>> non-standard use of it. If you would like this flexibility in Hap, that
>> should be argued for on the Hap project, not within FFmpeg.
>> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
>> implementation in FFmpeg must follow the definition (see
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md>
>> ).
>> The Alpha Only encoder and decoder must ingest and emit a pixel format
>> which carries alpha. It may be that adding a new alpha-only pixel format is
>> not seen as desirable, in which case an existing format with alpha should
>> be selected. This allows users to, eg, transcode from an RGBA format to Hap
>> Alpha Only and have the channel they expect be preserved from the input
>> video. Any other behaviour (eg having RGB converted to grey and then stored
>> as alpha) is not acceptable.
>> > If a user want to compress a gray picture, it can be done using
>> > RGB to Gray conversion

Of course.
But if the input is single-plane, 8bit, it does not make sense to
output rgb (or rgba).

>> > And if user want to compress only alpha or a specific channel, i think
>> > ffmpeg have a filter for that (extractplanes (untested)),
>> Your non-standard usage can still be achieved by channel switching in a
>> filter, the default behaviour must be according to the standard, which is
>> to encode and decode the alpha channel.

Which is not possible because FFmpeg does not support a single
alpha plane.

> Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> alpha from RGBA input)

I am less convinced:
As long as FFmpeg does not have a native alpha-only
pix_fmt (I am not sure this would have any user-visible
advantage), single-layer 8bit formats should be decoded
as gray8.

Carl Eugen

More information about the ffmpeg-devel mailing list