[MPlayer-G2-dev] new release: pre39

Arpi arpi at thot.banki.hu
Mon Aug 4 09:11:31 CEST 2003


> On Mon, Aug 04, 2003 at 03:37:05AM +0200, Arpi wrote:
> > - Implemented Rich's idea for inverse soft-telecine in vd_libmpeg2.c
> >   (later may can be moved to a filter)
> Yes, that can be the first filter to demonstrate how to use the
> exported tff/rff flags. :))


> > - Implemented Albeu's timer hack in vo_fbdev.c using FBIO_WAITFORVSYNC ioctl
> >   -> libvo2 API changed, pts is unsigned int (and is in microsecs), not float!
> How about units of 1/1001000 sec? :)) OK maybe not. BTW, is this just


> 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.

> 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.
there are 2 time-spave now:
- float/double based, for demuxer, codecs and filters
- 1/1000000 sec based, for timing display and audio

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

> > - etc/codecs.conf included (note: not compatible with G1!)
> Hmm, how about do like G1 and compile it into the binary? Somehow I

i don't remember why but i couldnt get that hack working in g2 at early days

> 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 :)

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

> >   Note: The effective A-V sync is the delay what you can actualy see/hear.
> >   When this number goes up, it means that your CPU/VGA is probably too slow...
> >   If this isn't constant 0, but floating around zero, it means your timer
> >   (be it soundcard or system timer, depending on -autosync) is inaccurate!
> > 
> >   The 'streams A-V sync' (the second number after A-V:) is the actual
> >   difference of the audio and video stream timers. It should be zero,
> >   non-zero value means one of the streams (or both) run at wrong rate.
> >   It may be problem of codec, demuxer or even the file may be broken.
> >   This isn't influenced by slow cpu, inaccurate timers, broken sound drivers!
> Very nice to be able to tell the difference!


A'rpi / Astral & ESP-team

Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

More information about the MPlayer-G2-dev mailing list