[FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-09-17#
Fri Sep 24 22:35:02 CEST 2010
On Fri, Sep 24, 2010 at 10:11:23PM +0200, James Darnley wrote:
> On 24/09/2010, Loren Merritt <lorenm at u.washington.edu> wrote:
> > <J_Darnley> [various stuff about importing filters into x264cli]
> > <pengvado> Why are you importing yadif and hqdn3d rather than linking to
> > libavfilter?
> > <J_Darnley> It'd never be committed. Bikeshed this, cosmetic that.
> > <pengvado> Do you think it would matter if I did the committing and
> > threatened to fork libavfilter if people complain?
> In addition to this, my feelings (as both a poor coder and a user) on
> why I didn't just use libavfilter in x264 are that:
> - it didn't have hqdn3d or yadif when I started (not even patches)
yadif is close to being commited
hqdn3d should be easy, we need more manpower not more forks
> - when I looked at adding them to libavfilter, I just thought "WTF is this?"
ask here, dont WTF in secret, we like to know about it so we can help
> - pad and crop have different argument orders, x:y:w:h vs. w:h:x:y
patch that fixes it is on ffmpeg-dev since a short time and already
> - pad and crop do not take left, top, right and bottom arguments (I
> thought they were supposed to replace the options in ffmpeg)
crop will soon take arbitrary expressions so you could do
to removed 10 pixels from the right side
but if you think it makes sense iam not opposed to a patch that adds support
to pad and crop to parse a different syntax that is easier for your use case.
I dont know, to me the width and height seem more fundamental than how many
pixels one adds or removes
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I wish the Xiph folks would stop pretending they've got something they
do not. Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel