[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

On Mon, Apr 21, 2003 at 03:17:52AM +0200, Arpi wrote:
> Hi,
> 
> > > > 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?
> 
> it's the old (mplayer) way

Except that now the codec/demuxer gives the timestamp; the filter
chain can't modify it... :(

> > Of course, I don't know how this could handle
> > filters that increase framerate (multiple output frames per input
> > frame).
> 
> yes, _this_ is the problem with old/current way.
> core calls codec/filter to process a frame, and then it got 2 with different
> pts... without things like slices/dr it wouldn't be problem to return a list
> of picture buffers with pts attached, but things are not so simple here...
> and we have to prepare to evil cases, when a vo driver have a single, always
> visible buffer only... the second picture will overwrite the first one.

Well, I wouldn't be opposed to requiring double buffering when
dr/slices are used... IMO it's needed anyway so we can do OSD without
flicker.

Or we could just say that such filters will not display right when you
have such a brain-damaged vo. Users of such vo's should be accustomed
to broken behavior anyway (shearing, flicker, etc.).

> > The callback idea is just extremely ugly, but it may be the
> > only way...
> it seems :(
> or we have to disallow increasing fps in filters.
> 
> or we have to make hacks, i have an idea, but it's also ugly, and limited:
> filters could send "pts requests" to the core, into a queue, and call
> put_image only for the first output frame (and send pts of second one).
> then core, after displaying the frame, it could process requests from the
> queue, and call a special filter control() at the given times. so filters
> could send the inserted frames at the right time.
> (i know, i said it's ugly)
> also these frames could be dropped, like B frames

Actually I sort of like this architecture. It addresses the fact that
handling the situation is complicated.

On the other hand, I'm a bit confused as to how this would work with
multiple filters which might add/remove frames. E.g. consider the
hypothetical (albeit silly) example -vf telecine,ivtc... :))

Maybe a better design would be for get_image to take a special flag
indicating that the caller intends to output more than one image.
Then, it can ensure that the second image buffer returned is not the
vo's DR buffer. And of course if the image type is STATIC or
something (as in the case of vf_ivtc), it can ensure that direct
rendering is not used at all.

> > I'm not sure, but my guess would be that smoothed timestamps are bad.
> 
> ok 'smoothed' is not the right word for that... call that preprocessed.

OK, I didn't understand what you meant by smoothed...

> believe me, you don't want to meet those evil raw timestamps in filters...

Yes, agreed. :))

> > 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.
> 
> tff/bff may be a problem... it's very sepcific to a given container & format

Well basically, it's going to be hard to inverse telecine really
broken DVDs without first doing the telecine process according to the
exact instructions in the mpeg2 headers. Some discs use really weird
almost nonsensical (but technically valid) patterns, e.g. where a
number of consecutive progressive frames are all 'bff'. The easiest
way to fix these streams seems to be to render the pseudo-frames in
standard tff order, then let a heuristic algorithm like vf_ivtc clean
them up...

Rich