[MPlayer-dev-eng] dr2 implementation thoughts

[Arpi]

Hi,

> > anyway, there is put_image() to replace old draw_slice/draw_image pair,
> > using mpi struct, but it is not used by vo drivers yet (it's optional, if
> > implemented then it's called instead of draw_*)
> 
> DOCS/tech/libvo.txt still says draw_slice is mandatory even with
> put_image. Is it just outdated, or do some things still depend on
> draw_slice?

hmm.

         VOCTRL_PUT_IMAGE
                replacement for the current draw_slice/draw_frame way of
                passing video frames. by implementing SET_IMAGE, you'll get
                image in mp_image struct instead of by calling draw_*.
                unless you return VO_TRUE for VOCTRL_PUT_IMAGE call, the
                old-style draw_* functils will be called!
                Note: draw_slice is still mandatory, for per-slice rendering!

[note that SET_IMAGE should be VOCTRL_PUT_IMAGE above, it's a typo]

it's not fully yes, but a little bit yes.
now, when a codec starts decoding a frame, it requests a buffer from vf core.
it can set up the DRAW_CALLBACK flag, signalling that it can do per-slice
draw callbacks, ie it could call draw_slice() for slices instead of the
whole frame at the end. So, at first approach, every vo should have
draw_slice() to support this thing. But, as VOCTRL__GET_IMAGE is called when
requesting teh buffer, it can reset the DRAW_CALLBACK flag, if draw_slice()
is not implemented. Or, we can add a VFCAP_ flag to query_format to
enable/disable support of draw_slice.

anyway, the PUT_IMAGE was a proposal, i've added to make replacing the very
limited draw_frame (and draw_slice) possible by something better, but i didn't
implement it in vo drivers nor the others did. :(

in the future, there should be GET_IMAGE and PUT_IMAGE in vo drivers
implemented, and optional draw_slice().
GET_IMAGE should check for DR possible, and PUT_IMAGE should finish drawing
(it will be called after last draw_slice in per-slice mode, after DRing the
frame if GET_IMAGE was successful, or instead of draw_frame() - don't mix it
with flip_page(), it's for display the frame (whiel draw_*/put_image are to
finish blitting to the (back)buffer))

> > > that some filters could be added that do nothing *but* change the mask
> > > to mark some macroblocks unconditionally changed. This might (??) be
> > > faster than -vop crop for reducing wasted memory bandwidth when there
> > hmm
> > 
> > > are silly black borders to remove -- from my experience the crop
> > > filter makes things slower if anything.
> > why?
> 
> I haven't been able to figure that out -- it doesn't make any sense.
> Using libmpeg2 to decode dvds, with mga_vid and -vop crop...
ah, as libmpeg2 uses draw_slice for B frames, making decoding much faster
(about 10% for me). with crop, you lose it, and probabbly don't win so much
by the actual cropping. one way to workaround is implementing draw_slice()
in vf_crop. i'll look at it.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu