[FFmpeg-soc] expand filter (alternative to pad syntax)

[Vitor Sessak]

Michael Niedermayer wrote:
> On Fri, May 30, 2008 at 06:30:21PM +0200, Vitor Sessak wrote:
> [...]
>>> (5) I have not resolved the issue of removing memcpy. There is only one 
>>> call to memcpy in the code; to get rid of it is likely to require some 
>>> significant change to the avfilter API, that will have to involve Vitor. 
>>> In these circumstances, I wonder whether it would make sense to commit 
>>> the code to SOC anyway, and then remove the one call to memcpy when 
>>> we'll know how. (Observe that this situation is common to several filters.)
>> I've discussed it a little with vmrsss in pvt and I think the solution 
>> to it would be to negotiate the link dimensions during graph creation as 
>> we do for pix_fmt. But after this is done, the changes to make vf_pad.c 
>> memcpy-less would be rather minor, so I think this filter is better 
>> commited to the soc tree (after review) instead of bitrotting as a patch 
>> in the mailing list.
> 
> as i said i dont mind it being commited to soc
> i do mind it being commited to ffmpeg-svn before the issue is solved.

I know. But since I plan getting all the filters from soc into ffmpeg 
svn one day, I do care if there is anything other than the memcpy that 
is not svn-ready. Also, what do you think of the idea of buffer size 
negotiation (in the same way we do pixfmt negotiation)? I'll quote what 
I worte to vmrsss in pvt:

> looking at avfilter.h:
> 
>> struct AVFilterLink
>> /**
>>  * A link between two filters.  This contains pointers to the source and
>>  * destination filters between which this link exists, and the indexes of
>>  * the pads involved.  In addition, this link also contains the parameters
>>  * which have been negotiated and agreed upon between the filter, such as
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>  * image dimensions, format, etc
>      ^^^^^^^^^^^^^^^^
>>  */
> 
> I think the idea of agreed upon image dimensions (that is _not_ implemented by now, even if documented) is what we need. 
> For example, imagine someone call
> 
> ffmpeg -vfilters "negate, pad" ....
> 
> The idea is the negate filter to "negotiate" a output image dimensions with the pad filter in config_props(). Since 
> the negate filter copy the image anyway, it'll copy it to a properly sized buffer. A problem remains with padding 
> top and left (will that need negotiation too?), but for me it seems the only way to do it. What do you think?

-Vitor