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 _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
