[MPlayer-dev-eng] dr2 implementation thoughts
D Richard Felker III
dalias at aerifal.cx
Wed Jul 17 00:50:55 CEST 2002
Hey. I've been following the ffmpeg dr thread on cvslog a bit, and
thought I'd share a few thoughts on the matter. It seems like Michael
is working on getting 'dr method 2' working with the ffmpeg codecs,
but the current implementation calls draw_slice multiple times with
width!=imgwidth and/or x!=0, which seems to be incompatible with most
plugins, and which probably results in a good bit of overhead,
counteracting much of the speed gain. Instead, I'm thinking, why not
pass the changed macroblock mask along with the draw_slice call, for
the specific implementation to use if possible. This method would have
several benefits:
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.
Copying all the changed Y blocks in the full width slice, then all
the changed U/V ones, should be a good bit faster I would think.
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.
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.
If anyone sees significant problems with this, lemme know and maybe I
can come up with something better. Good to finally see DR!
Rich
More information about the MPlayer-dev-eng
mailing list