[FFmpeg-devel] [PATCH] seek print NOPTS

[Baptiste Coudurier]

On 10/20/2009 12:56 PM, Michael Niedermayer wrote:
> On Tue, Oct 20, 2009 at 11:17:53AM -0700, Baptiste Coudurier wrote:
>> On 10/20/2009 12:37 PM, Michael Niedermayer wrote:
>>> On Tue, Oct 20, 2009 at 10:56:17AM -0700, Baptiste Coudurier wrote:
>>>> On 10/20/2009 07:16 AM, Michael Niedermayer wrote:
>>>>> On Tue, Oct 20, 2009 at 02:59:16PM +0200, Reimar D?ffinger wrote:
>>>>>> Hello,
>>>>>> this patch should fix the remaining unaligned output of seek test by
>>>>>> printing
>>>>>> "NOPTS" when the time stamp is AV_NOPTS_VALUE.
>>>>>
>>>>> [...]
>>>>>
>>>>> does not work on all supported archs?
>>>>> if not then your patch is ok
>>>>
>>>> I would like to state that reactions are _a lot_ different than when
>>>> Ramiro
>>>> submitted the first patch about this issue.
>>>>
>>>> Is it different treatment because of different patch submitter or time
>>>> passed makes you more gentle and/or comprehensive ? :)
>>>
>>> maybe its the difference between
>>> - libc on windows is broken, can we workaround that?
>>> and
>>> - it would be nice to print something meaningfull instead of a funny
>>>     number when the timestamp is not known. (and from 2 similar solutions
>>>     pick the one that works on more platforms)
>>>
>>> anyway, i dont remember much support for applying ramiros patch back
>>> then, i cant read peoples minds ... in case people did want it applied
>>
>> Let me quote you:
>> "
>> Complicating the code for no apparent reason, the regression tests are
>> just for developers knowing what they do. And someone not knowing what
>> the big meaningless number is wont be able to make any sense of
>> "AV_NOPTS_VALUE" either.
>> "
>>
>> Besides I resurrected the thread myself, I call that support.
>>
>> Quoting Reimar:
>> "Uh.. could you please explain the sense behind that? Because like this,
>> you complicate the code _and_ it is just wrong..."
>>
>> Now changing to NOPTS is ok for cosmetics reason ? And you guys couldn't
>> suggest that in the first place ?
>> Sorry but I cannot feel anything here than pure bias.
>
> do you suggest we should all now re-read the old thread, and guess why
> we wrote there what we did and then discuss if we are biased or reacted
> inconsistently in a similar but not identical situation?

Kinda, that's the reaction I had when I read the thread.

> or could i maybe skip that reading and just agree with you that we are
> humans? It would save me some time and as far as i can see, we dont seem
> to have a disagreeent that is related to code in ffmpeg here, reimars
> patch has been applied and noone disagreed ...

Of course we are humans, and the first mail I sent to drag attention was 
not meant to be an attack but more a hint on how the first patch could 
have been handled in a better way, if we would have worked together 
trying to fix an IMHO important problem.

Overall, I think Ramiro explained it well in his reply.

In the end, yes, Reimar's patch is fine, and it has been applied.
However I think this commit was 1 year and almost 6 months late :)

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org