[FFmpeg-devel] Maintainership question
Sat Feb 12 22:06:00 CET 2011
"Ronald S. Bultje" <rsbultje at gmail.com> writes:
> On Sat, Feb 12, 2011 at 3:52 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>> On Sat, Feb 12, 2011 at 01:39:26PM -0500, Ronald S. Bultje wrote:
>>> On Sat, Feb 12, 2011 at 9:59 AM, Nicolas George
>>> <nicolas.george at normalesup.org> wrote:
>>> > Le quartidi 24 pluvi?se, an CCXIX, Ronald S. Bultje a ?crit?:
>>> >> Generally, yes. We sometimes forget a patch, and yes I have patches of
>>> >> you in my unread-mailbox waiting for me to have time to read them. I
>>> >> hope to get to them this weekend, they are overdue. I apologize for
>>> >> that.
>>> > Of course, I do not think anyone will begrudge the committers to forget a
>>> > patch in an overloaded mailbox.
>>> >> Sort of, technical arguments will have me delay the patch and I don't
>>> >> really do too many other personal dislikes on non-technical grounds.
>>> >> This is not a humanities field. :-).
>>> > I see. But let us assume that a Third person has reproaches against a patch
>>> > that can not convince either the Submitter to withdraw it or the Maintainer
>>> > to reject it. I suppose you will either consider the patch properly approved
>>> > or intervene in the discussion?
>>> > And the itchy part: does this still hold if the Third person is M?ns and
>>> > Maintainer is Michael?
>>> > If so, I think someone should commit
>>> > 76ad67c ?Implement guessed_pts in avcodec_decode_video2
>>> > d6705a2 ?ffplay: stats: do not dereference NULL video
>>> > (possibly sqhashed into one).
>>> Expanding over what Mans said, he had technical objections so this
>>> whole thing is kind of meritless.
>> I admit I lost track, but the only technical objections I paid attention
>> to were refuted.
>> If that's not the case, someone should probably restate it, otherwise
>> I'm sure I'm not the only one only rembering "I don't like it, it's ugly
>> and it's only going in over my dead body no matter how wrong I am".
> Fair enough, Mans can you restate the technical objections?
> IIRC it was something like:
> - lavc has no business touching pts, it's decoding/encoding lib, if
> anywhere this should be in lavf or so
> - if lavfilter wants to use it and lavfilter doesn't want to depend on
> lavc, then it again does not belong in lavc
> - the logic used to "guess" pts values is highly questionable and
> should probably only be used for certain input formats, and possibly
> only some codecs in those input formats, and that logic is completely
> missing right now (and also from the original implementation in
That pretty much sums it up.
mans at mansr.com
More information about the ffmpeg-devel