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

[Tom Butterworth]

On Wed, 27 Sep 2017 at 16:52 Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 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.
>

This would result in a transcode to another alpha-carrying codec
incorrectly placing the alpha channel in the colour channels, and setting
the alpha channel to solid. Likewise, API users would not be able to know
the channel intentions of the decoded frame. I'd argue that either a new
pixel format be added, or an existing format which carries alpha should be
used, even if that has the cost of redundant colour channels.

Cheers - Tom