[Ffmpeg-devel] [PATCH] MJPEG wrongly displayed with vertical YUV422

[Michael Niedermayer]

Hi

On Mon, Jul 31, 2006 at 11:05:26AM +0200, Diego Biurrun wrote:
> Hmmm, it seems that this one slipped through the cracks ...
> 
> On Sun, May 28, 2006 at 12:20:00AM +0200, Eric Piel wrote:
> > (please CC: me as I'm not subscribed to this mailing list)
> > 
> > ffmpeg doesn't handle the mjpeg files with a "vertical" YUV422. Here is 
> > an example:
> > * A fine video: http://pieleric.free.fr/ffmpeg/sevilla-mjpeg-yuv422h.avi 
> > (directly from my camera)
> > * Mostly same video which "ffplay" displays with wrong colors: 
> > http://pieleric.free.fr/ffmpeg/sevilla-mjpeg-yuv422v.avi (lossless 
> > rotation of the previous file)
> > (both files are 9 Mb)
> > 
> > Actually there is even a comment in mjpeg.c which explains the problem : 
> > /* XXX: not complete test ! */
> > 
> > The test "switch((s->h_count[0] << 4) | s->v_count[0]) {" needs to also 
> > handle 0x12. Like 0x21, it's also YUV422 but this one is "vertical". The 
> > problem is that there is currently no PIX_FMT_* in ffmpeg which 
> > corresponds to this coding. So here is a patch (against SVN 5414) to add 
> > the support for this format. It adds the types PIX_FMT_YUV422VP and 
> > PIX_FMT_YUVJ422VP. With this patch I can correctly display both videos :-)
> > 
> > Let me know if that's the right way to fix the bug. Also, I've added 
> > PIX_FMT_YUV*422VP to the minimum of places as possible, maybe I forgot 
> > some places...
> 
> Just checked the patch, it works as advertised ...

PIX_FMT_YUVJ422VP is unaceptable, it should be called PIX_FMT_YUVJ440P
and such vertical subsampled format can pretty much only occur
if you rotate 4:2:2 video, should we really support that? what about
rotated interlaced video?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is