[FFmpeg-devel] [PATCH] seek print NOPTS

[Reimar Döffinger]

On Tue, Oct 20, 2009 at 11:55:43AM -0700, Baptiste Coudurier wrote:
> On 10/20/2009 11:24 AM, Reimar D?ffinger wrote:
> >>Now changing to NOPTS is ok for cosmetics reason ? And you guys
> >>couldn't suggest that in the first place ?
> >
> >Michael did suggest something like I ended up doing in one
> 
> The problem is that fixing windows regression tests is IMHO far more
> important than this cosmetic change, however in the past thread,
> IMHO it seems that instead of working together in the best direction
> for the code itself, people ended up rejecting it in a unreasonable
> manner.

I was starting to write something else, but I decided to just try to
summarize the events, because this gives me a completely different view
of the real "issue" here.
Because from a technical point I don't think it could have been handled any
better, I do wonder if you see it differently or if your complaints
are "_only_" about the style/terseness/friendlyness of the responses,
in which case I very much misunderstood what you wrote so far.

The first patch on May 1st said:
> Attached patch makes seek_test print AV_NOPTS_VALUE instead of some big 
> negative and apparently meaningless number.

To which the response was around May 2nd:
> 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.

While I don't 100% agree, it seems not completely unreasonable to me,
and for the amount of code (duplication) I think the original mail
did indeed give insufficient reason. Agreed or not?

Shortly after, a more thorough explanation was given:
> Seek test fail on MinGW because MSVCRT doesn't properly printf() big 
> numbers. Instead of printing
> pts:-102481911520608.625000
> it prints
> pts:-102481911520608.600000

One response to that being
> So fix it.

With "it" referring to printf. Ignoring the tone, I do think it rightfully
points out that we have not been given a reason why this can't be fixed
"at the source", which is what I think we agree should generally be done
(even if at least I am sometimes too lazy for it).

Then there was the -1 and NaN suggestions which did not work out.