[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

On Mon, Apr 21, 2003 at 02:15:18AM +0200, Arpi wrote:
> > I dunno how this should be done, but there MUST be some way for the
> > player to 'hook in' between the filter chain and libvo2, in order to
> > control the rate at which frames are displayed. Otherwise, filters
> > that alter framerate (e.g. showing interlaced video at 60 fields per
> > second, inverse telecine, etc) cannot work properly! This was one of
> > the big deficiencies in the old design, so I hope G2's architecture
> > will fix it.
> 
> I want to fix it, but can't imagine how to fix it yet.
> Maybe i can't avoid moving the video timing/delaying code to vf_vo2, maybe
> with a callback to the player (to be able to use idle time for something
> more useful).

Bleh...

Would it perhaps be possible to just return the delay to the caller,
and then have the caller signal back to libvo2 when it's time to
actually show the frame? Of course, I don't know how this could handle
filters that increase framerate (multiple output frames per input
frame). The callback idea is just extremely ugly, but it may be the
only way...

> Handling PTSs is tricky. Actually there is 2 layer of timestamps.
> The raw ones (coming from demuxers, usually inaccurate, with discontinuities
> (not only DVD is such thing, some other formats is even worse), and the
> 'smoothed' ones, currently in sh_audio->timer & sh_video->delay.
> 
> My current (not final) plan for g2:
> 
> Demuxers will retrieve the raw timestamps. Let decoders to modify
> timestamps, if they want (because of frame reordering, in-codecs timestamps
> (realvideo, mpeg4, h263)). I'll do the pts smoothing in dec_video.c
> (interface between codecs and filters). Maybe i have to add a demuxer hook
> for that purpose, because smoothing algo depends on demuxer/container format.
> 
> Then the smoothed, linear timestamp will be passed to the filters along with
> the video frames. They can alter it, or just pass to the next filter.
> At the end, either the vo driver or vf_vo2 will delay and then show the
> frame, or the ve driver writes it out with timestamp, or drop/duplicate for
> fixed-fps formats.

I'm not sure, but my guess would be that smoothed timestamps are bad.
For proper inverse telecine of mixed hard- and soft-telecine content,
you need the exact timestamp as well as the values of the tff/bff and
repeat field flags.

> > BTW, I think for G200's broken "YV12" mode, it's best to export the
> > real Y buffer, and allocate fake U/V buffers in system mem, then
> > interleave them into real video mem at page-flip time. Or better yet,
> > maybe vf_vo2 could have some way of notifying the vo driver that a
> > slice is finished, so that it could be done along the way to improve
> > cache utilization...
> 
> already doable with libvo2 :)

Very cool. :))

Rich