[MPlayer-dev-eng] mp-g2 pre14

[D Richard Felker III]

Ivan, as much as we appreciate your enthusiasm, designing the new
architecture for the world's fastest movie player is a bit more
complicated than the data flow that's taught in CS... :) If you could
just allocate, pile up, and free buffers as you please, this might all
be ok, but as it stands, filters will often want to render right into
(or "through" for expand, etc.) the next filter's exported buffer,
which may be video memory. The filter layer in MPlayer is already very
complicated because it actually takes into effect all the different
methods that may be used to deliver data from one filter to the next,
and all the different color spaces and alignments that might be
required. Other slow players and encoders (no names here :) just
allocate new buffers and copy and convert to (slow) yuy2 at will,
making implementation easy but performance abysmal.

Anyway, in general you can't buffer up output frames from one filter,
since they might go direct into the next filter's buffer, which might
need to be preserved (consider I/P/B frame codecs, or a filter that
uses STATIC type for its output image, e.g. ivtc).

Your overall idea would perhaps work if filters had to just 'block'
once their 'output buffer' is filled (1 output frame) until the next
filter has 'consumed' the frame, but I'm not sure if it's better than
Arpi's design... Seems like it's basically another way to accomplish
the same thing.

Rich




On Tue, Apr 22, 2003 at 04:10:09AM +0300, Ivan Kalvachev wrote:
> Hello,
> I see very intersting discution about the future filter arhitecture.  I
> sow some "push" and "pull" discusion, then i sow the arpi's combined
> solution. I mast say that it looks very mach on something i've meet in
> "Super Computers" class - Data Flow. (try google, i don't have a link)
> Modifications are that token here is mpi struct, actions are filters.
> Differense is that one action can accumolate tokens, and can output or
> not more than one token/mpi. It is ok, as long as we have simple chain,
> not a complicated graph.
> 
> My idea, looks something like combo between arpi & michels's.
> let all filter be called in endless loop (decoder and output are like
> filters).  filter have input buffers, and output buffers, with counters
> for them. input_counter may start with 1(filter init will set it). and
> after we add mpi to the input_buffers to decrease the input_counter(=0),
> this will prevent us from injecting more frames on next pass. then the
> filter process the input and (optionaly) write to the one or more output
> mpi. If the filter doesn't need the inputframe anymore it frees it and
> increas the inputcounter. The output counter says now many ready frames
> we have, and output_buffers contain theis mpi's. If next filter's
> input_counter!=0 then we move one mpi from 1'st filter output to 2'd
> filter input. and so on.   Same idea could be used for per block/slice
> rendering, when we count blocks as fraction of the whole frame( 8 block
> input, 4 block output), but they are all from one (logical) frame. It is
> importan the blocks to be processed in regular pattern (left to right,
> top to bottom) and all filters to have one size for the blocks.
> 
> Tomorrow i will write some (better) explanetion and maybe sample code.
> 
> Best Regards
>   Ivan Kalvachev
> p.s. this data-flow may be used after the demuxer and mpi to contain
> packets that to be passed to decoders but seeking will be complicated
> then.
> 
> Michael Niedermayer said:
> > Hi
> >
> > On Monday 21 April 2003 23:39, Arpi wrote:
> > [...]
> >> > images out of the end of the chain as they're needed. The vf api is
> >> already confusing enough for people trying to write filters without
> >> all this back-and-forth craziness...
> >>
> >> we have to decide if we want easy-to-understand APIs (see xine) or
> >> fast, powerful, optimized-to-hell but a bit complex and tricky API.
> > no, i think we dont have to :))))
> > we could have a complex & powerfull API and on top of that a
> > simple&slow one  like
> >
> > filter(context *c, mpi *src, mpi *dst){
> > 	...
> > 	if(...)
> > 		...
> > 		return NO_OUTPUT
> > 	else if(...)
> > 		...
> > 		return MORE_OUTPUT
> > 	else
> > 		...
> > 		return OK
> > }
> >
> > or even something like:
> >
> > filter(context *c){
> > 	for(i=0; i<5; i++)
> > 		src[i]=get_mpi(c, SRC|READ_ONLY);
> > 	for(i=0; i<4; i++)
> > 		dst[i]=get_mpi(c, DST|EXPORT,i*time_base + ...);
> >
> > 	decimate(dst, src);
> >
> > 	for(i=0; i<5; i++)
> > 		release_mpi(c, src[i]);
> > 	for(i=0; i<4; i++)
> > 		release_mpi(c, dst[i]);
> > }
> >
> > [...]
> > --
> > 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
> >
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at mplayerhq.hu
> > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
> 
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng