[MPlayer-G2-dev] new release: pre39

[D Richard Felker III]

On Mon, Aug 04, 2003 at 09:11:31AM +0200, Arpi wrote:
> > relative pts, or absolute? With 32bit int, you only have room for
> > ~4000 seconds before you wrap....and many movies are longer than that!
> 
> it's absolute time counter truncated to 32 bits. it's far enough.
> no movies encoded at 1/4000 fps...

??

> > BTW2, this would suggest that the float-based method was also very
> 
> it wasnt inprecise (or at least it was hidden by correction codes)
> but since all the system timer code work with microsecs, it was
> easier (and more accurate) this way.

If a movie goes beyond ~4000 seconds, you'd be using 13 bits of the
float for the integral part, leaving 11 bits for the fractional part.
That's still 0.5 ms precision, so not too bad, but it could start
generating bad timestamps encoding to variable-fps output formats.
Also, there's the case where you're working with really long files,
where the error could easily get as large as frame durations, so I'd
be happier using doubles, at least wherever absolute pts is needed.
For relative, float is certainly fine.

> > imprecise... BTW3, are you sure these inexact methods are ok for
> > encoding and stuff, rather than just playing movies?
> 
> thos 'inexact method' is for playback only.

By inexact I mean it's not based on the same time base as the file,
but rather approximation by float or fixed point number.

> there are 2 time-spave now:
> - float/double based, for demuxer, codecs and filters
> - 1/1000000 sec based, for timing display and audio

Ahh, I see.

> note that there is not 1000000:1 but 1000000:playback_speed mapping between them.

:)

> > suspect having the G2 codecs.conf installed will keep G1 from
> > working...
> 
> no, g1 will ignore that codecs.conf, as being unparseable

:)

> > >               video fps --v     v-- A-V sync: effective/streams(corrected by)
> > > A: 165.311 V: 161.118 (29.970) A-V:+4.193/-0.0000(-0.0000)  102%(216%)
> > >       ^---------^--- audio+video PTS        CPU usage--->> avg^ max^
> > 
> > Is framerate really important?
> 
> no, but it's fun to see, esp. at mixed hard/soft telecined material :)

Ah, but I thought the new code didn't change nominal framerate, just
delay rff frames by 1/120 sec...

> you can guess it out, that this is a debug statusline, not a user-frindly one

Yes.


Rich