Re: slices

Hi

On Friday 13 February 2004 00:13, D Richard Felker III wrote:
> Uhg, one more nasty issue about slices too!!
>
> Consider vf_expand with osd rendering. You want to alpha-blend osd
> onto the image during the slice rendering, so you don't have to read
> video memory later to add osd! But here you run into a big problem.
> Slice rendering takes place in decoding order, whereas osd contents
> will be known in display order. It would look really stupid for the
> clock to jump backwards for one frame, etc. How do we solve this??
>
> I hate slices! No, actually slices are good. I hate B-frames!!! :/
maybe i have an idea how to fix the slice mess, but more likely i missed many 
serious problems as iam a bit tired :), anyway, the idea is:
a pure pull system but not of frames but slices, there would be 2 different 
types of pull requests (more if we want, but its probably not worth)
type 1: single slice pull (only 1 slice, nothing above, nothing below)
type 2: all slices upto slice x
a filter needs to support just one of them, if a filter asks for a single 
slice but the previous filter supports just 0-x slice style then thats 
trivial, on the other hand if a filter asks for slice 0-x but the previous 
filter only supports single slice output then a simple buffering filter needs 
to be inserted which would then combine the slices upto that point

slice sizes ...
very easy too, during config each filter just asks the previous one(s) what 
slice size it can provide, slice size can be specified with a single integer 
pair (x,y) which splits a frame into rectangular tiles which will always be 
requested in raster scan (left->right, top->bottom) order
many filters will probably require x=width though, iam not sure if we should 
support x!=width at all, maybe not, if we do then we also must deal with the 
case of converting x!=width slices to x==width

slice draw callback from the codecs
well, arghhh
i probably would have to change libavcodec to support normally returning after 
each slice and resuming, dunno how easy that would be, but i dont see an 
alternative unless we use threads but the overhead would cancel any advantage 
slices provide

b frames
each frame gets a PTS and picture type and the slice pull can ask either for 
the next picture in display order or dont care order, so if the vo and 
filters dont care about the order then frames could be passed in coded order 
and the vo would do the reordering
so we have a special case again, where a filter asks for display-order but the 
previous one provides any-order, in which case a IPB frame reorder filter 
needs to be inserted

btw if anything mentioned here has already been suggested/implemented/rejected 
then sorry, i didnt follow the discussion about the VP lately, tell me to 
RTFwhatever

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
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