[MPlayer-users] libvo2 under way

[Arpi]

Hi,

Yes, this is the most sensitive part of libvo2 and 'nextgen mplayer'.
I also spent hours thinking about this issue.
My idea:
  group color spaces by quality:
    - yuv420p  (YV12,I420,IYUV)
    - yuv422   (YUY2,UYVY etc)
    - other yuv
    - palette  (8bpp)
    - hicolor  (15/16 bpp)
    - truecolor (24/32bpp)
    - hardware  (mpeg, mjpeg etc)
give a bit for each group in a flags register. a given libvo2 driver
should set flags according its supported formats. and it also should
point best (native) colorspace for each group.

what is it good for?
quality difference between the members of a given group is minimal, mostly
nothing (just byteorder or aligning difference).
(i mean you can convert between rgb24<->rgb32 or yuy2<->uyvy without quality
loss).
what is it good for?
most codecs just support one colorspace from each group.
for example, vfw ones supports only 15, 24 bpp and yuy2.
if the hardware supports 16 and 32bpp and uyvy, the libvo2 core could
find the best conversion: 24->32 or yuy2->uyvy.

codecs could point a preferred (native/internal) group, so we could
do our best selecting best mode wiht minimal quality loss:
1. ask codec for preferred group
2. ask libvo2 for supported modes in that group
3. ask codec for modes reported by libvo2.
in most case we could find a match, or at least 2 modes in the same group,
so we can set up a fast lossless converter.

in the bad case, when no group match:
decide what do we want: speed or quality (user option, default: quality)
1. ask libvo2 for better/worse (quality/speed) quality groups than reported
   by codec
2. ask codec for supported mode in that groups (maybe we find a match,
   for example codec's native group is hicolor, but it can produce 32bpp)
3. set up the converter

what is it good for?
to select the best conversion doing the minimal conversion and quality loss.

> A test suit (maybe at install time) could be used to benchmark the
> actuall hardware and write the perfect values to a config file, but some
> tables with roughly accurate data are shipped with mplayer.
hmm. good idea. i also had the idea of a speed-related constant for each
mode, but there is a big problem:
most of them depends on the actual hardware and secondary driver.
for example, matrox g400's best mode is yv12, while s3 savage supports yv12
but with slow conversion inside teh driver. so for s3 yuy2 is better.
but while you acces them via SDL or Xv, you can't make difference. only way
is measuring the speed.

btw it would be interesting, that when a use selects a -vo2 driver never
used before, it run first a benchmark of available modes.

> Alexander Werth
> 
you should subscribe to -dev-eng list
and continue this thread there. 


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu