Re: new release: pre39

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!
BTW2, this would suggest that the float-based method was also very
imprecise... BTW3, are you sure these inexact methods are ok for
encoding and stuff, rather than just playing movies?

> - etc/codecs.conf included (note: not compatible with G1!)

Hmm, how about do like G1 and compile it into the binary? Somehow I
suspect having the G2 codecs.conf installed will keep G1 from
working...

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

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

Rich