[FFmpeg-devel] [PATCH] Add pad filter

Stefano Sabatini stefano.sabatini-lala
Tue Dec 8 01:10:59 CET 2009


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.

> as a note for future work, we could keep track of what last wrote to a
> picture and when and by that skip drawing the border if the pad filter
> was what last drawed into the specific buffer.

Regards.
-- 
FFmpeg = Faboulous and Foolish Mystic Pure Elastic Gymnast



More information about the ffmpeg-devel mailing list