[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)
> 
> Oh? What's used for other colorspaces then? I'm so used to mga_vid and
> lavc/libmpeg2 that I almost forget about other ones existing. :)

draw_frame() is used for packed formats, like yuy2 and rgb

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_*)

> > > 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 :(
> 
> Yeah, but a design like this would leave that possibility open for the
> future, in case someone feels ambitious. Also, there's the possibility
yes

> 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?


A'rpi / Astral & ESP-team

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