2017-09-27 15:20 GMT+02:00 Martin Vignali <martin.vign...@gmail.com>: > 2017-09-27 13:25 GMT+02:00 Tom Butterworth <bangno...@gmail.com>: > >> >> >> > On 27 Sep 2017, at 11:59, Martin Vignali <martin.vign...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
