[MPlayer-G2-dev] Yet another video API. :)

[D Richard Felker III]

On Wed, Apr 14, 2004 at 02:22:16PM +0300, Andriy N. Gritsenko wrote:
> Image flags:
> 
> MF_SLICE: Set if image isn't full image but slice instead. Filters who
> don't accept slices will anyway get a full frame because video layer
> will commit all slices to frame for it.
> 
> MF_FINAL: Set if image is last slice of a frame so all slices before it
> may be committed to full frame.

You fail to address what "all slices before it" means. This is the big
question.

> MF_DROP: Set if decoder or filter may find that: a) there is yet one
> frame before pts; b) that frame wants to be dropped. So it marks
> the frame as may be dropped and any filter except those who desires
> all frames may just ignore it.

This is meaningless. Read my drop spec. Dropping works the other way
around. The source of a frame only "drops" it if it's damaged beyond
repair and can't be decoded. If the destination is dropping it, it
doesn't need a signal from the source to do so. It already knows.

> MF_DECODE_ORDER: Set by decoder to indicate that frame was pulled in
> decode order.

This is also nonsense.

> MF_NOT_IN_ORDER: Set by decoder to indicate that frame was pulled in
> decode order and is out of order. For example in standard MPEG sequence
> 1 4 2 3 7 5 6 if frames are pulled in decode order then frames 4 and 7
> will get that flag.

More nonsense. Learn how slices/dr work. Something like this is not
necessary or useful!

> Filters API has number of functions. Each function should be not called
> directly but only via vp_* API calls.
> 
> Most common rule is "if you get an image buffer then you _MUST_ return
> it to owner", i.e. each vp_get_image() or vp_pull_image() must be
> followed by either vp_release_image() either returned from function.

ROTFL! This makes buffer management useless.

> It is also available to call vp_keep_image() to save you a copy of
> image or vp_export_image() to save you an image descriptor but that
> keeped image also must be followed by one of these functions later.
> I hope that rule is simple. If you follow that rule then you'll never
> get your image lost or get memory leak.

This seems to contradict what you said above.

> Called when one of the filter's output links desires a frame. If the
> filter or decoder can provide one, it should return an image. Mode may
> be one of:
> 
> VPP_MODE_FRAME: Get nearest frame before pts
> 
> VPP_MODE_KEYFRAME: Get nearest keyframe before pts

This is all stupid. These are seek commands, not the way you get a
frame. When requesting a frame, you DO NOT KNOW what pts you want. You
just get frames in sequence. If you don't want some of them, throw
them away!!

> VPP_MODE_SLICE: Get next slice for current pts if VPP_SEEK is not set.
> Otherwise reposition stream and get first slice of nearest frame before
> pts (may have weird effects!)

Sounds dumb.

> VPP_DECODE_ORDER: Get frame in decoder order if supported. Slices will
> be pulled always in decode order.
> (Note: If some filter between decoder and caller of vp_pull_image()
> doesn't accept decoder order then that flag will be seized)

Useless. RTFM slices/dr!

> VPP_CANSKIP: Set if decoder may skip frames up to nearest frame before
> pts if there are any. It does the effect of '-hardframedrop' switch and
> may corrupt the image.
> 
> VPP_CANDROP: Set if decoder or filter may set MF_DROP flag in image.
> 
> VPP_SEEK: If that flag is set and pts points to the same frame as on
> previous call then decoder must just give out the same frame again
> (regetting frame). Otherwise if that flag is set then reposition the
> stream to near pts and get the frame.

WTF.

What you have submitted is NOT a new design. It's my design, with lots
of stupid crap added on top of it. It doesn't fix any of the design
flaws in my spec; it just adds a lot more.

If you want to propose a new spec, fine. But don't rehash old stuff,
bloat it with useless "features" that were already addressed if you
had taken the time to read the old spec, and call it something new...

Rich