[MPlayer-G2-dev] requirements for vo2 layer

[D Richard Felker III]

Attila asked for some requirements for changes in the vo2 layer to
accommodate the new vp stuff (and just sanitize it in general). So
here they are:

* A way to query whether a buffer is available for writing the next
  frame. Buffers which are currently displayed or pending display on
  next vblank are NOT available. Also, buffers in shm which the X
  server is presently copying are not available. Etc. Ideally, VO's
  which have temporarily-unavailable states (like the Xshm thing or
  displayed-but-new-frame-is-pending-on-vblank) should have a "sync"
  function we can call (implemented with XSync or a wait-for-vblank
  ioctl, etc.) to wait until the buffer is again writable, for
  reget_buffer or REUSABLE buffers.

[ Note: this isn't strictly a requirement, but it can prevent visual
  glitches on very fast machines, so it's probably desired! Otherwise
  we could get in trouble if we start writing to a still-busy frame
  too soon! ]

* The dynamic buffer allocation system makes no sense. There's an
  IN_USE flag for buffers obtained dynamically, but it's meaningless
  since the caller has to manage its own pool. IMO the IN_USE flag
  should be removed and replaced with the above buffer availability
  system, and the caller (vp_vo2.c or whatever) should 

* Provide some way for the caller to know (at least roughly) how many
  buffers will be available. At least vo's that can provide an
  essentially unlimited number (x11, xv, etc.) should indicate so, and
  ones with a small fixed number of buffers should also report this.

* Simplification of query_format to a simple yes/no. VO's should never
  perform colorspace conversion, software scaling, etc. Flipping is
  just negative stride in G2, so it falls in the next point:

* Report or negotiate pixel aspect ratio of the output picture. For
  drivers without overlay which can change video mode, we might
  actually want some way of negotiating a video mode to meet certain
  size/aspect constraints.

* Exporting stride restrictions so the vo2 wrapper can negotiate
  stride with the filter chain in hopes of getting DR to work. There
  are actually 2 sets of stride restrictions: one for direct
  rendering, and the other for all input images. The latter
  restriction should _ONLY_ be in place if the VO driver does not
  export its buffers, and requires some sort of slice or frame drawing
  function to be called (svgalib?).

[ Note: this does not preclude stupid VO's that change stride, like
  DirectX. It's legal to provide a DR buffer whose stride differs from
  the negotiated stride, but _only_ if the STATIC stride restriction
  isn't in place. But some filters/codecs don't allow stride to change
  (especially lavc!) so negotiation is important if you want DR to
  work. Otherwise lavc will get one stride for the first I frame's
  allocated buffer, then another (possibly different!) stride for the
  first B frame's DR buffer!! ]

Can't think of anything else...

Rich