[FFmpeg-cvslog] r26315 - trunk/libavfilter/vf_pad.c

Uoti Urpala uoti.urpala
Wed Jan 12 11:37:18 CET 2011


On Tue, 2011-01-11 at 20:34 -0800, Baptiste Coudurier wrote:
> On 1/11/11 8:12 PM, Michael Niedermayer wrote:

> Besides what's the use of get_buffer if you can override it ? It doesn't
> make sense to me.

Performance optimization.


> > libmpcodecs has no such limitation ...
> > I dont think its filters are that messy as a result.
> > Besides its a double sided sword, if we require that buffers passed down
> > must have come from get_buffer() then we have another thing that must be
> > taken care of, namely no filter ever must break that rule. For some decoders
> > that will lead to mandatory memcpy() of the frame
> 
> I think no filter must ever break that rule. If the decoder does not
> support DR1 then DR1 must be added to this decoder.

I don't think that's going to happen in practice. There are also
non-FFmpeg decoders, and possible sources of filter input other than
decoders.


> I think this discussion is leading to a more complicated issue, namely
> how can a filter (like yadif) ensure some mandatory requirements on the
> buffer allocated. Currently get_buffer is used, if you bypass that
> requirement, we need another mechanism.
> 
> I'd like the simple case to be handled in a simple manner.
> Complicated treatments like messing with linesize should be supported if
> wanted, but must not make the simpler treatment a mess.
> 
> I expect people to be able to create filters in an easy way without
> worrying about hundreds of corner cases.

Expecting all input to be provided in buffers returned by get_buffer()
would cause at least as many problems on the upstream side as not being
able to rely on that causes on the downstream side. You could make the
libavfilter framework automatically copy data from the source to the
filter's preferred buffer type to provide a simple interface. However
that would have a performance cost, so it should be optional; a filter
could have a choice between a simple interface or accepting input in
different forms for best performance.




More information about the ffmpeg-cvslog mailing list