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

[Martin Vignali]

2017-09-27 15:33 GMT+02:00 Tom Butterworth <bangnoise at gmail.com>:

>
>
> > On 27 Sep 2017, at 14:20, Martin Vignali <martin.vignali at gmail.com>
> wrote:
> >
> > 2017-09-27 13:25 GMT+02:00 Tom Butterworth <bangnoise at gmail.com <mailto:
> 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 <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
> >>> 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.
> >>
> >> Cheers - Tom
> >> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel <
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
> >>
> >
> >
> > Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> > alpha from RGBA input)
> > I will change the 24 to 32 as requested and send a new patch
> >
> > Before sending a new patch for the decoding :
> > did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
> > for RGTC1 alpha decoding in RGBA ?
>
> Personally I’d think 0 to allow further operations to eg combine the image
> with one with colour channels to work as expected.
>
> Ok, i will do that,
so i can have the same decoding func in texture dsp that the one use for
hapqa_decoding.

Martin