[MPlayer-G2-dev] slices

[Ivan Kalvachev]

Michael Niedermayer said:
> 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

Hmm you start thinking like me (if you have seen my vo3 drafts in this
maillist ;)
I also ask arpi: In G1 slices are treated separatly than the frames,
and we see that very few filters honnor them, and even less work right
with them (including vf_crop and vf_expand) . What is the point of
creating another slice mechanism  that nobody will use ?


> 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
I'm not quite sure but an MPEG-1 picture could be encoded
with one slice - from top to bottom. In this case we may
be unable to work with MPEG-1 streams.
j/k

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

Well it looks like slice size is a big issue. As dalias commented vf_scale
filter Will change  slice size.
But I think about shooting 2 problems at once. Slices are made of
macroblocks, so we could count macroblocks. This will allow us to use
mb_skip[] to jump skipped blocks. The problem is that in this case
we loose both slices and mb_skip after vf_scale (or it becomes a real
mess). Of cource we may have different blocks size (16x16, 8x8) but
this won't help with vf_slice or vf_crop/vf_expand that are not multiple of
block size.


>
> 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
It is easy, I believe libmpeg2 and xvid do this. At least in ffmpeg12
decode_slice() is called in infinite loop (that terminate on last slice).
But I wonder if this will give any advantage.


> alternative unless we use threads but the overhead would cancel any
> advantage
> slices provide

I still cannot get used to new thread functionality in libavcodec ;)

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

As I said in my proposiol of vo3 the video system should act like decoder 
and work in decode order when possible. The B frame delay should be
handled by vf_vo or whatever.

> 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
Don't worry the archive is not very big ;)

I also sorry that i cannot work on my video system at the moment, but
I hope that in 2 weeks I will.

I would like to ask, from what comes the advantage of one slice size
buffers, as they are first written and then readed (no blocking,
probably preventing cache polution?).
I know that they are faster becouse I made experiment by disableing them
in ffmpeg12.

And final words to dalias.
I'm not sure how L2 cache works, but the CPU cache is always separated on
instruction and data cache. So you cannot polute code by data and vise
versa. This is so from the first Pentium and probably for 486 too (if they
have cache at all;)

And about OSD and timer. We actually don't need astronomicat time to
display the PTS is enough. I even have HDTV samples that start from  8:30
oclock ;)
The real problem are the user events. And thats why I want a frame rebuild
mechanism in my vo3.

Best Regards
   Ivan Kalvachev
  iive