[FFmpeg-devel] [PATCH] Add pad filter
Tue Dec 8 13:42:01 CET 2009
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
> 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.
FFmpeg = Friendly and Furious Mystic Philosophical Encoding/decoding God
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2912 bytes
Desc: not available
More information about the ffmpeg-devel