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

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080517/32ce9db5/attachment.pgp>