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

[Rich Felker]

On Sun, May 08, 2005 at 08:41:00PM +0200, Reimar Döffinger wrote:
> Hi,
> On Sun, May 08, 2005 at 02:56:49PM +0200, Michael Niedermayer wrote:
> > On Sunday 08 May 2005 12:31, Reimar Döffinger CVS wrote:
> > > @@ -614,7 +614,8 @@
> > >      {
> > >  	case IMGFMT_YV12:
> > >  	    // HACK, mjpeg accepts PIX_FMT_YUV420P only with vstrict=-1
> > > -	    if (strcasecmp(lavc_param_vcodec, "mjpeg") == 0)
> > > +	    if (strcasecmp(lavc_param_vcodec, "mjpeg") == 0 ||
> > > +	        strcasecmp(lavc_param_vcodec, "ljpeg") == 0)
> > >  	      lavc_venc_context->pix_fmt = PIX_FMT_YUVJ420P;
> > 
> > reverse this! and the 1.108 -> 1.109 change too
> > the correct way to store IMGFMT_YV12 in jpeg is to set strict=-1
> > the difference is that your (stupid) hack leads to wrong colors on all encoded 
> > mjpeg&ljpeg as libavcodec wont know the correct colorspace and so cant store 
> > the correct colorspace in the jpeg
> 
> Well, but the problem I see is that strict=-1 might also mean that the
> encoded file might not be playable in later versions. I found it
> unacceptable to set that automatically (actually I'd prefer people to
> have an alternative to specifying that anyway).
> Also colors didn't really look wrong to me (though my eyes (and esp. LCD)
> aren't that good).
> Feel free to reverse it, but I can't see any solution that would be much
> better - except actually supporting YUVJ (for which I don't even know
> the exact specification).

Even this would not be better. It would require slow colorspace
conversion prior to encoding.

IMO the point of your change is that anyone using mencoder for mjpeg
encoding is just making live-capture files for later reencoding, and
does not care about compatibility with slight differences in the
colorspace spec for jpeg.. I don't see it as a major problem, but
maybe there's some better way to handle it.

Rich