[MPlayer-dev-eng] dr2 implementation thoughts

[Arpi]

Hi,

> counteracting much of the speed gain. Instead, I'm thinking, why not
> pass the changed macroblock mask along with the draw_slice call, for

hmm, good idea. at least it makes things simpler than passing the whole
array & stride. also, it could benefit from draw_slice callback and the
mb_skip at the same time. only disadvantage is that it's limited to yv12
then. (draw_slice is yv12 only)

> 1) The vo driver could use AGP or otherwise specialized memcpy
>    routines to actually do the copying. Even for instance sending
>    accellerator commands to the video device to setup DMA copying of
>    just the changed blocks. Particularly useful would be the
>    capability of the MGA G200 driver to optimize its U/V plane
>    interleaving. With multiple calls to draw_slice, the copy order is
>    Y, UV, Y, UV, Y, UV, ..., which can't be good for the cache.
yes, i proposed it in my mail today, including sample C implementation

> 2) It could work with double buffering -- the vo driver would just
>    keep the changed macroblock masks from the previous frame and
>    bitwise merge them with the new ones, so as to copy every
>    macroblock that's changed in the last 2 frames.
hmm, good point. we really need this to handle more than 1 buffers

> 3) Potential applications for filters. Some video filters, especially
>    postprocessing, may want to modify not just the macroblocks changed
>    by the codec in the present frame, but also all adjacent
>    macroblocks. To do this, the filter could just make its
>    modifications and then add the macroblocks it changed to the list
>    before passing it on to the next filter/vo in the chain.
good idea, anyway too complex to implement :(

> If anyone sees significant problems with this, lemme know and maybe I
> can come up with something better. Good to finally see DR!
yea ;)


A'rpi / Astral & ESP-team

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