[MPlayer-dev-eng] direct rendering disabled for lavc h264

[Ivan Kalvachev]

2006/7/21, elupus <elupus at ecce.se>:
> >
> > Have fun making all the vo drivers support it, and vf.c...
> > Really, although this may be reasonably useful for
> > performance, it will make MPlayer's video layer even uglier,
> > having one additional buffering scheme hack in there. I won't
> > directly rule it out right now but I'd be hesitant to see
> > something like this committed to MPlayer just due to the huge
> > complexity bloat it would add. An H.264-specific hack would
> > be much much larger than the current "simple IPB" hack in place.
> >
>
> Would it really be that bad? Generally ffmpeg will do a reget on a buffer it
> needs again, shouldn't be to hard to handle in the buffer broker to make
> sure it get's the same image as before by storing some identifier in the
> ffmpeg buffer structure (or by just examining the data pointer). Then the
> buffer broker in mplayer could set a flag indicating to vo that this is a
> reget of a previous buffer, and thus it needs to return the same buffer as
> before wich it could also do by priv data in the mpi structure.
>
> I'm not sure how well that would work with filters that do their work in
> get_image, but for a vo only situation I think it would work, might be
> missing something fundamental thou.

The main problem is that frames are only get_ and never released. So
we have few patters that makes some assumption on get/release model.

There is no problem for e.g. xv to have 16 buffers, xv could also mark
buffer as released after it had hide it. The problem comes if there is
frame skipping...

One solution is using g2 vf system that is really nearly g1 one
(minimum translation efforts),  creating compleatly new systemq or
making some ugly hack (like i did for xvmc).