[FFmpeg-devel] [PATCH] Add pad filter

[Stefano Sabatini]

On date Tuesday 2009-12-08 13:42:01 +0100, Stefano Sabatini encoded:
> 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.

Ping+patch for the pad filter updated.
-- 
FFmpeg = Foolish Faboulous Mean Puristic Elitarian Gem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-pad-filter.patch
Type: text/x-diff
Size: 14189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091212/358c3077/attachment.patch>