[FFmpeg-devel] libavfilter: extending overlay filter

Mark Himsley mark
Sun Mar 13 16:18:04 CET 2011


On 13/03/11 14:26, Stefano Sabatini wrote:
> On date Sunday 2011-03-13 14:18:42 +0000, Mark Himsley encoded:
>> Dear Developers,
>>
>> I have extended the overlay filter so that it can overlay BGRA,
>> RGBA, ABGR and ARGB streams over BGR24, RGB24, ARGB, RGBA, ABGR and
>> BGRA backgrounds (extended from yuva420p over a yuv420p background),
>> including adding the ability to output non-pre-multiplied video and
>> combined alpha when the main input background has alpha.
>>
>> This is working really well for keying BGRA over BGRA, and
>> outputting combined fill+key for use in professional editing
>> software.
>>
>> With the extension I have added, the overlay filter must have either
>> YUV type inputs for BOTH the main and overlay OR have BGR type
>> inputs for BOTH the main and overlay inputs.
>>
>> That means that, with the extension I have added, I have broken the
>> more usual YUV for the main and BGR for the overlay.
>>
>> This has happened because I have allowed the filter to accept the
>> BGR type inputs (adding to the PixelFormat enums), so ffmpeg doesn't
>> automatically insert a BGR to YUV filter any more.
>>
>> It is not an insurmountable problem for users to change their filter from:
>>
>> -vf "movie='text.tif' [movie]; [in][movie] overlay=0:0 [out]"
>>
>> to:
>>
>> -vf "movie='text.tif', format=yuva420p [movie]; [in][movie]
>> overlay=0:0 [out]"
>>
>> But, is it possible for the filter to programmatically insert the
>> format change filter so that my extension does not break users
>> current filter chains?
>>
>> I would like to submit my extension for inclusion into libavfilter
>> but I don't feel that I can submit it while it breaks users current
>> filter chains...
>>
>> Thanks
>
> Current the overlay filter has the RGB path disabled.

Yes, I saw that and used it as the basis of my extension.

 > I believe the
> more senseful approach is to let the main input determine the output
> format, that is we should have:
>
> RGB main, ANY overlay ->  RGB output
> YUV main, ANY overlay ->  YUV output
>
> while it currently forces both input and output to be YUV.

If I understand the filter mechanism correctly, at least for the overlay 
filter, the main input format is the output format.

The problem I have is, how to force the overlay to be in a format close 
enough to the main format that the overlay code can do the job - i.e. if 
the main is a YUV format the overlay must also be a YUV format.


> Note that format conversion setup is automatically performed just
> after the link configuration stage, in query_formats(), and doesn't
> involve explicit configuration from users.
>
> Show us your approach so that we can suggest how to fix the issue.

My patch to current git is attached.

Thanks!

-- 
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-overlay.patch
Type: text/x-patch
Size: 10292 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110313/992aba52/attachment.bin>



More information about the ffmpeg-devel mailing list