[FFmpeg-devel] [PATCH] Print AV_NOPTS_VALUE in seek test

[Ramiro Polla]

Reimar D?ffinger wrote:
> On Mon, May 05, 2008 at 05:35:37PM +0100, Ramiro Polla wrote:
>> Ramiro Polla wrote:
>>> Michael Niedermayer wrote:
>>>> On Thu, May 01, 2008 at 09:28:37PM +0100, Ramiro Polla wrote:
>>>>> Attached patch makes seek_test print AV_NOPTS_VALUE instead of some big 
>>>>> negative and apparently meaningless number.
>>>> 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.
> [...]
>> Could you please reconsider this?
>> Seek tests with latest MinGW CVS only fail because of this printf. The 
>> tests don't really fail, but the way the results are printed do. This can 
>> easily be avoided in FFmpeg's side by writing cleaner output.
>>
>> Attached patch prints out -1 instead of AV_NOPTS_VALUE.
> 
> Uh.. could you please explain the sense behind that?

If the packet returned by av_read_frame() has no pts or dts, any attempt 
to manipulate and print that value whatsoever is wrong. So the code, the 
way it is now, is already wrong.
The current code unconditionally multiplies that value by 
av_q2d(st->time_base). In the case of AV_NOPTS_VALUE, it should not have 
done it, since it is not a valid pts. That results in a big negative 
number. I don't know about you, but I don't see any sense in that big 
number, except if you want to have a clue about the time_base and for 
some reason you base yourself on what AV_NOPTS_VALUE * some_time_base 
should look like (instead of printing the time base itself).

The problem for me appeared when that number was printf'd from MinGW. 
MSVCRT's printf doesn't print such big number with the same precision as 
Linux. This could require a complete rewrite of printf in MinGW and use 
it instead of MSVCRT's, but it is very easily avoidable in FFmpeg. It is 
not necessary to print such a value.

> Because like this,
> you complicate the code _and_ it is just wrong...

Can you explain how it is wrong please?

Ramiro Polla