On Fri, May 16, 2008 at 08:54:24PM +0100, vmrsss wrote: > Hi everybody > > I attach an improved version of vf_pad.c, thoroughly tested, with a few > questions for you. > > (1) > On 15 May 2008, at 10:30, Víctor Paesa wrote: >> Try sscanf(arg,"%d:%d:%d:%d:%255[^:]:%255[^:]:%d",&a,&b,&c,&d,e,f,&g); > > I am having a problem with inputs like > > pad=::::16/9:16 > > (which should mean "expand to a 16/9 frame mod 16"), because sscanf can't > find the %d in between the ::, and so the conversion stops. Ideally the > form above should be allowed, lest one needs to ask users to type in clumsy > forms with default values as in: > > pad=-1:-1:-1:-1:16/9:16
Dont you think that pad=::::16/9:16 is clumsy as well ... what about: pad=aspect pad=width:height pad=width:height:x:y (here the number of arguments seperates the variants) > > (which is what the code currently requires). Is there to get sscanf do it? > I don't think so. One alternative is to use sscanf to read args one ":" at > a time, as I currently do for two of the parameters which can take > different forms (aspect and color). > > (2) Following up on the above, would a form like > > pad=w=...:h=...:x=...:y=...:a=...:r=...:c=.... > > be desirable? It'd allow to omit parameters and list them in any order, but > for filters with few parameters might be a cumbersome overkill. Eg > > scale=624:368 against scale=w=624:h=368 > > (3) I have added the possibility of specifying a color for the padding. The > structure which lists the colors is taken from vf_drawbox.c. If people like > the idea, that can easily be factored out in some avfilter_common file. > > (4) The aspect parameter doesn't work as it should for files with SAR > different from 1. It's easy to fix, only that the sar information seems > unavailable at the filter configuration stage (see the code); I expect > Vitor wll be able to help on this one. > > (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.) Direct rendering is a key requirement for av filter, filters not spporting it properly are not interresting to me and you will have to find someone else to review the patch That said i dont care if its commited to soc. To ffmpeg-svn it will not be. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you really think that XML is the answer, then you definitly missunderstood the question -- Attila Kinali
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
