[Mplayer-cvslog] CVS: main mplayer.c,1.527,1.528

pl p_l at gmx.fr
Wed Jul 24 10:59:09 CEST 2002


On Sun, Jul 21, 2002 at 04:35:32PM +0200, Arpi wrote:

> > > > Anyway I also don't like this commit, it changes -1000..+1000 raneg to
> > > > -100..+100 dunno why.
> > > 
> > > Ezt nem tom angolul:
> > > 
> > > MP_CMD_* mindig -100...100 - at hasznalt. A -bright... meg a tobbi meg
> > > -1000...1000 - ret, es a driver szorozgatta, osztogatta el. Csak most
> > > egyseges lett az is, konstans -100...100.
> > 
> > That is ? (english plz)
> 
> "Valid range in MP_CMD_* was -100..100 since teh beginning. Options
> -brightness etc used -1000..1000 and the driver did the mul/div by 10.
> Now it's common -100..+100 everywhere."
> 
> At least it should be, but it seems that libvo still uses -1000..+1000.
> I also noticed that the mapping between -1000..+1000 <=> Xv min/max is
> bogus, can result by rounding errors to min-1 or max+1 sometimes.
> Ah, and the codecs (divx4, dshow) use 0..100 range.
> 
> We should agree on some range, and then convert the whole code to use that
> range. I vote for 0..255, but maybe it's too much work and we should use the
> current -100..+100 and fix the vo drivers (mga, vidix, xv).
> Anyway the 0..255 (or -128..127) would better fit the drivers and makes
> conversion cleaner: ((value-min)<<8)/(max-min)

I've checked vo_xv/vidix/mga_common to use a 0..255 range and that's not
a real big diff I'd say. I had a patch working but not submittable with
sunday night cvs but patches were committed since then.

If there's still some interest and somebody else (Pontscho ?) is not
working on the same code I'll try and update the patch tonight.

Besides, if we chose to map [port_low..port_hi] to [0..255] then we need
to divide/multiply by 255 if we want to be able to reach both extremal
values (well.. between last-1 and last the visual effects are not really
visible).
Or we might want to map to [0..256] as it seems to be done for OSD.


> > Your patch suffer from initialization problems as "impossible" values
> > (-101) arrive in vo_xv::__set*eq, which causes problems.
> Xv drivers should ignore values <min or >max, at least the mga Xv does so.

They should but we might want to avoid relying too much on other
people's code :)


-- 
Best regards,
  pl



More information about the MPlayer-cvslog mailing list