[MPlayer-cvslog] CVS: main/libmpcodecs ve_lavc.c,1.113,1.114

[Rich Felker]

On Mon, May 09, 2005 at 03:07:42AM +0200, Michael Niedermayer wrote:
> i meant that i splited the double meaning strict=-1 into
> -1 -> "unofficial extension" 
> -2 -> "might not be playable in later versions"

i see... now we should think about making vstrict=-1 the default,
imo.. anyone have opinions on this?

> > > > Also colors didn't really look wrong to me (though my eyes (and esp.
> > > > LCD) aren't that good).
> > >
> > > well, tell this to the first user who notices that his lossless jpeg
> > > encodings look the same but arent
> >
> > They're lossless if you decode them with MPlayer/MEncoder, which also
> > assumes standard YUV colorspace when decoding jpeg..
> 
> a bug in mplayer canceling out a bug in mencoder ...

imo it's not a bug. conversion back and forth between standard yuv and
jpeg yuv is not lossless, so if you have a yuv image to begin with and
you want to compress it _losslessly_ with jpeg, the only way to do so
is to treat it as if it were jpeg colorspace even though it's not..

the fact that the jpeg stream doesn't carry with it a tag for the
original colorspace is a loss of sorts, but as long as you keep your
files tagged properly it's not a problem.

> > > anyway, ill reverse this if you dont
> >
> > Just don't use cvs admin -o...
> 
> editing the RCS files by hand sucks but if you insist ...

i meant to commit a patch that changes it back, rather than removing
revisions. there was a discussion recently about cvs admin -o and we
basically decided that it shouldn't be used (at least in mplayer cvs)
except in the most extreme cases. especially if the bad code has been
around for a while, using cvs admin -o will break the checkouts of
everyone who's gotten the bad code, and they have to manually fix
their checkout before it will work again.. :(

rich