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?
2. Add a conditional to do_chromakey_slice(...): In the loop iteration,
check "use_alpha" variable and execute and jmp to pertinent code?
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".