[MPlayer-G2-dev] MID proposal

[Arpi]

Hi,

> > > What is the point of depth? How is it defined?
> > Depth is the number of bits used for describe a pixel, bpp means the
> > bytes which are used to store a pixel. RGB24 has depth=24 but can have
> > both bpp=24 and bpp=32.
> 
> I know that much. But how is depth defined for YUV? Is there even any
> point of knowing the depth..?

for planar formats, it should be component depth, imho
ie. 8 for most YUV formats, even NV12

mayeb we should add 'component' field too
it could help for nv12 (comp=3 planes=2), rgb vs rgba (comp=4) etc

> > > > fields (interlacing)
> > > 
> > > Hm? Does this just tell if the image is interlaced, or does it contain
> > > other flags about the interlacing format?
> > If we leave it in MID it could contain more flags. Dunno if it should be
> > present or not.
> 
> IMO not. Info about interlacing does definitely belong in the video
> pipeline, BUT most of the time it wouldn't even be known yet when
> you're using MIDs, and like Arpi said MIDs should come from a table of
> constants.

yes. MID shouldnt contani variables at all.
every single field in MID struct must be constant for a given imgfmt

> > > The whole width, height, x, y, w, h system is nonsense. x,y are never
> > > used and not even supported. They're much better handled by just
> > > adjusting the actual pointers. Also lots of filters don't understand
> > > the difference between w and width, which is very silly to begin with.
> > Imho it has sense, but lot of filter/vo writers are dumb and can't make
> > difference.
> > 
> > Width/height defines the dimensions of the whole image pointed by MPI.
> > x,y,w,h descibre a rectangle of which part of the image should be drawn.
> 
> But that's not how it is right now. As it stands, width is essentially
> the same thing as stride/bpp, which filters should not even care
> about.

yes

> > Yes, there are two ways: only pass a MPI with the actual image, but that
> > would still need x,y to be defined to place it correctly on the screen.
> > The other way is to leave our current scheme and fix the filters. Imho
> > this is a better approach.
> > 
> > Probably you will ask about the sense of this whole partial mpi stuff:
> > it has not much sense currently, but we could have some filters/decoders
> > which will support partial decoding / filtering.
> 
> This is NOT a clean way to do it. It's very limited (forces you to
> only have one rectangle) and also forces all filters to support this

agree. x,y must go, it's unused in g1 too
in my original plans (for g1's vf) it was for crop/expand stuff, i wanted
to implement crop/expand by just changing those fields... was bad idea

> bloated ugliness of working on partial images explicitly. I have a

sure. we need well working slices, with x and w parameters (not y-only as in
g1)

> much better design for new vp layer:
> 
> Let's say you want to blur a small rectangle of your picture. Here's
> how the filter chain works:
> 
> 
> vd ----> vf_subfilter ----> vo
>             |   ^
>             |   |
>             V   |
>            vf_blur

huh


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu