[FFmpeg-devel] [PATCH] Add pad filter

[Stefano Sabatini]

On date Tuesday 2009-12-08 03:01:04 +0100, Michael Niedermayer encoded:
> On Tue, Dec 08, 2009 at 01:10:59AM +0100, Stefano Sabatini wrote:
> > On date Monday 2009-12-07 13:49:32 +0100, Michael Niedermayer encoded:
> > > On Sun, Dec 06, 2009 at 05:49:37PM +0100, Stefano Sabatini wrote:
> > [...]
> > > > Regards.
> > > > -- 
> > > > FFmpeg = Fundamental and Frightening Meaningful Powerful Enigmatic Guru
> > > 
> > > >  doc/libavfilter.texi     |   34 +++++
> > > >  libavfilter/Makefile     |    1 
> > > >  libavfilter/allfilters.c |    1 
> > > >  libavfilter/vf_pad.c     |  315 +++++++++++++++++++++++++++++++++++++++++++++++
> > > >  4 files changed, 351 insertions(+)
> > > > bb922d6806e2dfef168f297389ead0ec50e243b7  add-pad-filter.patch
> > > 
> > > ok (if tested & works)
> > 
> > Unfortunately it doesn't for certain inputs.
> > 
> > I was almost committing when I tried this:
> > 
> > ffplay -loglevel debug in.avi -vfilters "scale=300:239, format=yuv410p, pad=410:410:50:50:random"
> > which issues chroma artifacts, while
> > 
> > ffplay -loglevel debug in.avi -vfilters "scale=300:239, format=yuva420p, pad=410:410:50:50:random"
> > just crashes.
> > 
> > This is due to the input image size not being aligned to the chroma_h
> > value, I still cannot see how the scaler deals in such cases, that is
> > when the output size requested to the scaler is not a multiple of
> > 2^log2_chroma_w/h.
> > 
> > Apparently this works fine with yuv420p, while it crashes with
> > yuva420p.
> > 
> > Can someone suggest a sane way to deal with these cases in the pad
> > filter? The simplest solution I can see would be to simply make the
> > scaler always output size values aligned to the chroma values.
> 
> odd sizes must be fixed wherever the problem is (especially they
> must not crash). Its well possible that a video has odd size and its a
> valid use case to pad this ...

I tried to fix them in the pad filter, my fix consists into
"normalizing" the input values and make them chroma-aligned.

I'm attaching the patch as a diff to the pad filter for your
convenience.

> but i think there might be another problem that will need fixing,
> are data[x] aligned to 16 bytes? because some optimized filters will
> need them aligned and id guess pad & crop can produce non aligned cases.
> so possibly we need a AV_PERM_ALIGNED that ensures maximum alignment the
> cpu might need initiating a copy of the frame if its insfficiently aligned.

Regards.
-- 
FFmpeg = Friendly and Furious Mystic Philosophical Encoding/decoding God
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make-pad-manage-odd-sizes.patch
Type: text/x-diff
Size: 2912 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091208/cae4092d/attachment.patch>