[FFmpeg-devel] Maintainership question

Reimar Döffinger Reimar.Doeffinger
Sun Feb 13 12:38:22 CET 2011


On Sat, Feb 12, 2011 at 03:57:18PM -0500, Ronald S. Bultje wrote:
> 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

That would mean implementing the reodering code in lavf, that would involve
a lot of parsing and code duplication.
IMO at best this could be done in a parser, but then it still would be
in lavc.
Also this approach will not help applications which do not use libavformat
one bit and effectively make the timestamp handling code non-reusable for
applications not using lavf.

> - if lavfilter wants to use it and lavfilter doesn't want to depend on
> lavc, then it again does not belong in lavc

Ok, but sorry, I consider that a purely cosmentical objection, not a technical
one.

> - 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)

I'd like to remind that some people complained bitterly about people requiring
"perfect" patches to get things accepted instead of a clear improvement.
I can easily believe that the code is not optimal (though I have no clue,
and honestly I am almost certain that few if any other have), however I
don't consider that a relevant question.
The only relevant question should be "does this improve behaviour in general,
and in the worst case is it optional so that any breakage caused can be avoided?".
I think we are a bit light on knowing what gets fixed an what gets broken in
general though, significant changes to this code without just as significant number
of samples seems unlikely to me to lead to an overall improvement.
And concerning your restated question: I have no clue, at least not in sufficient
detail that the answer can be anything but misleading.



More information about the ffmpeg-devel mailing list