[MPlayer-users] libvo2 under way

[David Holm]

Alexander Werth (gmx) wrote:

>[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html &
> http://gcc.gnu.org/gcc-2.96.html if you still have questions or problems]
>
>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
>
I was planning to add some tweak options to my libvo(not 2) dxr3 device, 
actually this should perhaps be a global option (available when 
possible), for the user to actually have a range to specify quality over 
speed or vice versa, thank you for the idea, I will look into it's 
implementation, this will also have to be implemented in other modules 
that I do not work on, for instance selecting a faster codec with less 
quality than a slower one (on divx we have several m$ codecs and one 
linux codec...)

Thanks for the advice....
//David Holm