[FFmpeg-devel] [PATCH] seek print NOPTS
Tue Oct 20 22:08:43 CEST 2009
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
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
> it prints
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.
More information about the ffmpeg-devel