[FFmpeg-devel] [PATCH] avfilter/vf_chromakey: The chromakey filter preserves non-opaque alpha transparency.

[Gavin Smith]

On 12/06/2020 12:59, Timo Rothenpieler wrote:
> On 12.06.2020 00:31, Gavin Smith wrote:
>>
>> On 11/06/2020 22:03, Timo Rothenpieler wrote:
>>> On 11.06.2020 22:27, Gavin Smith wrote:
>>>> This is to address trac ticket #8724. The filter did not preserve 
>>>> alpha transparency. Items that were transparent in the input would 
>>>> appear black on the output or pixels that were semi-tranparent 
>>>> would appear opaque.
>>>>
>>>
>>> What is the performance impact for inputs without an alpha channel?
>>
>> Firstly, I'm new to this world of filters.  Now my patch only applies 
>> to chromakey and not chromahold. On that note, is it not the case 
>> that the chromakey mandates that all its inputs surfaces contain 
>> alpha (as per query_formats function)? Would any AVPixelFormat that 
>> does not match query_formats get converted to a format containing 
>> alpha transparency?
>
> But it still adds new code, and given it's in the very hot path of the 
> filter, it can easily add a performance penalty.
Sure. I understand. I'll see what numbers I can get.  Having a quick 
cursory look over the code, I wonder if my code actually might be 
slightly more performant because it checks the case if a0 != 0. However, 
this jmp/cmp may negatively impact performance.
>
>>>
>>> Generally looks fine to me, but might need hidden behind an option, 
>>> as to not break existing setups that rely on this filter 
>>> discarding/ignoring the input alpha channel.
>>
>> Yes. No problem. "preserve_transparency" and default to the 
>> equivalent of 'false'?
>
> That seems a bit clunky. Maybe something like "use_alpha"?
Sure.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".