[FFmpeg-devel] [PATCH] Add pad filter

[Michael Niedermayer]

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 ...

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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-devel/attachments/20091208/5e6828c6/attachment.pgp>