G200+NV12 (Re: [MPlayer-G2-dev] Darwin port)

[Michael Niedermayer]

Hi

On Saturday 10 May 2003 15:17, Michael Niedermayer wrote:
> Hi
>
> On Friday 09 May 2003 01:57, Arpi wrote:
> > Hi,
> >
> > > On Fri, May 09, 2003 at 01:32:22AM +0200, Arpi wrote:
> > > > Btw Vektor mentioned scanline buffers yesterday, and I think it's a
> > > > very interesting approach. ie. replace plane+stride with array of
> > > > scanline pointers :)
> > > > It would allow very amazing optimizations, like DR scanlines without
> > > > OSD, and copy the rest. But I guess such feature won't go into g2
> > > > soon, maybe into g3, or in g2 v2.0 :))
> > >
> > > Yes, but it's only good for scanline-based filters. For example, if
> > > you want to apply a block-based filter (e.g. deblock, dering, telecine
> > > detection, anything DCT-based, etc.) you have to load a separate base
> > > pointer every 8 pixels or so inside your inner loop, which is horribly
> > > inefficient. With a single base plus stride, you can just use two
> > > registers (current position and stride) with no extra memory reads.
> >
> > Hmm, you're right...
> > Btw afair Michael's postproc code copies macroblocks into some internal
> > aligned in-l1-cache buffer for processing and at the end it copies it
> > back.
>
> this copy is only done for the first / last row of blocks so the filters
> dont need to check y>=0 / y<height (or have 2 versions for each filter ...)
> but the source data is practically copied (+brightness/contrast corrected)
> to the destination buffer before filtering so if just the source is line
> indirect then it should be possible with only a few modifications but i
> dunno by how much it will be slower ...
>
> > Btw 2, what about MB-lines instead of scanlines? :)
>
> IMHO, the per line pointers are a good idea for simple filters (eq, noise,
> ...) but for complexer ones which need to fetch pixels in the vertical
> direction in the inner loops its probably too complex/slow, MB-lines are
> probably faster to access but not simpler
> btw, how many MB based filters do we have which would benefit from that?

another more insane & overcomplicated idea:
why not squares instead of lines? with constant stride within a square ...

[...]

-- 
Michael
screen[y][x] ^= cursor[cy][cx];			(violates patent #4,197,590)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en