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

[Michael Niedermayer]

On Sun, May 11, 2008 at 04:26:00PM +0100, vmrsss wrote:
> On 11 May 2008, at 15:52, Michael Niedermayer wrote:
> > hmm, i think i misunderstood the code, maybe it is useful to keep,
> > have you tested it?
> 
> yes, of course. The best way to use it is: pad=-1:-1:-1:-1:1.78:r,  
> which leaves the code to embed the frame in the smallest suitable 16/9  
> rectangle mod r, no other modifications. I'd like to improve the  
> sscanf to allow forms like pad=::::16/9, which at the moment would fail.
> 
> >>> unconditional copying is unacceptable
> >>
> >> help explain: Why unconditional? I am copying in->data between y  
> >> and y
> >> +h, which I assume is what draw_slice(...,y,h) entitles to do.  
> >> Anyway,
> >> more fittingly: how would you want that copying to be coded?
> >
> > There should be no copy.
> > The source filter should directly draw into the larger buffer of the
> > destination filter.
> 
> Ok, I don't know how to do this, but I'll look into it. Can you point  
> me to something?

override get_video_buffer() and pass the buffer request on to the next
filter but modify the width/height.

Note iam not sure if this is the only/best way and it might need some
slight API changes ...
maybe bobby wants to comment?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20080511/4ba760b3/attachment.pgp>