[libdv-dev] Re: yuv2lav problem and NTSC DV decoding (Christoph Scheurer)

[Stefan L. <Ste...@sn...>]

On Fre, 20 Apr 2001, Christoph Scheurer wrote:
> Date: Fri, 20 Apr 2001 08:29:44 -0400
> To: mjp...@li...
> Subject: Re: [Mjpeg-users] yuv2lav problem and NTSC DV decoding
> From: Christoph Scheurer <ch...@ne...>
> Reply-To: mjp...@li...
> 
> > As for YUV422 - I think the mjpeg tools should work with this.  At least
> > the main change I made some time ago to support JPEG from bttv capture was
> > to make things work with YUV422 JPEG.   You'll need to have a hunt around
> > inside the mjpeg lib and/or the io libraries if it doesn't work.  The
> > biggest likelihood is simply that the YUV422/YUV420 info is getting lost
> > somewhere.
> Support for YUV422 would be really good since that is now the default output
> format from libdv for all DV formats (YUV 420 and 411 are upsampled) and it

NO. libdv does no upsampling. Color information is just repeated. A common planar
output format for post processing would be very useful.

Interlacing:
Some DV camcorders are able to record progressive mode sequences at full
frame rate. If this information is useful for encoding in into other formats
it is possible to provide this information per frame. An example for
progressive mode recording is pond.dv .

> would mean that it wouldn't be necessary to compile libdv with a special
> configure flag to support planar YUV 420.
> 
> But, if I understand it right, you mean planar YUV 422? Or can I also send
> packed YUV 422 through a YUV4MPEG pipe? I think by accident I used packed YUV
> 422 in the beginning, when I starte using libdv and the results from mpeg2enc
> were bright green and scrambled. So I would just have to reorder packed ->
> planar, which is simple enough.  And how do I tell the receiver of the
> YUV4MPEG data that the stream is 422 not 420? Or do the tools autodetect that
> by the size?
> 
-- 

mfg

  Stefan Lucke (Ste...@sn...)