On 6/12/20, Gavin Smith <gavin.sm...@playerbites.com> wrote: > > On 12/06/2020 16:58, Gavin Smith wrote: >> 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. > > vf_chromakey wll now have 2 implementations of chromakey depending on > whether "use_alpha" is selected. What are your feelings on the best way > to approach this? > > 1. Add an additional function pointer to ChromakeyContext: In > do_chromakey_slice(..), call the said func ptr in the loop each iteration?
This is best solution. You could also add function pointer for do_chromakey_pixel(), which would pass in 2nd argument current alpha value. In one case that 2nd argument would not be used and in different case it will be used. > > 2. Add a conditional to do_chromakey_slice(...): In the loop iteration, > check "use_alpha" variable and execute and jmp to pertinent code? That would be slow. > > 3. Any other suggestions? > > Thanks. > >>> >>>>> >>>>> 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@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".