[FFmpeg-devel] Maintainership question

[Ronald S. Bultje]

Hi,

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
ffmpeg/ffplay.c)

These are pretty major, especially the third one. FFmpeg does a lot of
dubious stuff to timestamps, every second transcoding I try does abort
with "pts <= last_pts" errors or something along those lines. Breaking
or generalizing this further is pointless, the bugs in the code should
be identified and fixed first before we move this into
lavc/lavu/lavf/lavwhatever. I'm not even sure I understand what parts
of ffmpeg.c touch timestamps where and with what goal anymore.

Ronald