[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8465 - trunk/libavformat/utils.c

Baptiste Coudurier baptiste.coudurier
Wed Mar 21 14:12:18 CET 2007


Hi

Reimar D?ffinger wrote:
> Hello,
> On Wed, Mar 21, 2007 at 12:05:13PM +0100, Guillaume Poirier wrote:
>> diego wrote:
>>> Author: diego
>>> Date: Wed Mar 21 11:48:10 2007
>>> New Revision: 8465
>>>
>>> Modified:
>>>    trunk/libavformat/utils.c
>>>
>>> Log:
>>> av_estimate_timings_from_pts() flushes the packet queue but doesn't
>>> reset the streams' cur_dts values.  This can lead to a fatal "error,
>>> non monotone timestamps ..." message later, because the out-of-date
>>> cur_dts values are used to compute some packet's dts.
>>>
>>> Fix this by calling av_read_frame_flush() and eliminate code
>>> duplication in the process.
>>>
>>> The additional hunk gives more detailed error messages.
>>>
>>> patch by Wolfram Gloger, wmglo dent.med.uni-muenchen de
>> Would anyone have an objection to systematically add a reference to
>> the thread where the committed patch was posted?
>>
>> I always do it under "original thread" and give the mail subject and
>> date. Very few people do it currently, which is too bad IMHO.
>>
>> I find it quite handy to immedialty find the discussions there were
>> about the patch, which can sometimes help understanding the patch.
>>
>> Other than the fact that it slows down a bit patch committing, I'd
>> like to hear any objection about making it a policy rule when applying
>> non-trivial patches.
> 
> It makes the log messages longer and harder to skim through when
> searching for something. In this case the log message is quite long
> anyway though. Another disadvantage is that you can access the
> information only when you either have email archive or web browser at
> hand, whereas the log information for those of use using git or similar
> is even available when there is no internet at all.
> But most importantly I think sometimes log messages and email thread
> references are misused for things that should actually be documented in
> the code.
> So in short: there are cases where adding such a thread reference
> makes sense, but in most cases IMO it is not necessary (no real
> discussion about the patch) or misplaced (documentation should be in the
> code, not in an email thread) or the essence of the discussion can be
> captured in a two-line log message.
> 

Well, two lines is often longer than thread title (not mentioning email
and commit log which are in common).
Many patches are being discussed longer than one reply, thread is very
useful when you need to understand/remember why it was done that way.

By experience, I thought many times "thanks Guillaume for mentioning
thread reference".

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312




More information about the ffmpeg-devel mailing list