[MPlayer-users] libvo2 under way

[Alexander Werth (gmx)]

Just my two cent, well five actually,
Am Die, 2001-11-13 um 00.32 schrieb David Holm:
> formats for the device to be usable. In libvo2 we are going to approach 
> this problem in a whole different way, we are going to tell mplayer 
> which format(s) out device supports.
Maybe You could add a weight stating the speed or general niceness of
the output. This way mplayer codecs could chose the fastest supported
output without specifying exact tables what output to use in which case.
Maybe this niceness could be tweaked by the user if he prefers quality
over speed. 
Or take this further and add two functions to each source/sink. One for
quality and one for speed.
The codecs would have such characteristic values for quality and
performance too but they are a function of the quality settings. 
It would be even possible to add terms describing the cpu usage of the
stream source.
Then it would be possible to take into account the available cpu power
to chose the optimum in terms of quality.
To implement this there could be a function to query the characteristic
values for a certain interface format of a certain sink/source. mplayer
would have to do the math and arange the sinks/source in the most
suitable way. This way the manual configuration would be minimised.
Depending on the cpu power there would be hard limits that must be meet
by the speed value. Otherwise there wouldn't be any quality
optimisations at all (except the ones that doesn't cost any speed. It's
all in the math).
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.
By changing some kind of master weight for quality or speed the user has
still some influence on the quality and can determine the average cpu
power. This could be used to avoid even the last framedrop, improve A-V
syncronisation or to get the perfect image.
If the calculations are fast (they should be fast since there are just a
few variables) it would be possible to change the quality settings on
the fly.
Maybe it would even be possible to change the codec on the fly.
The nice thing about this is, that it doesn't need to be implemented at
once. Giving just some values would do at first. The functions would be
improved over time depending on the likes and psyches of the users.
Maybe one time it's even possible to take into account the type of movie
scene to select the right postprocessing filters on the fly.
For a great mplayer,
Alexander Werth

-- 
The right to read is a battle being fought today...
http://www.gnu.org/philosophy/right-to-read.html