[MPlayer-dev-eng] mp-g2 pre14

[Ivan Kalvachev]

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