>> With the patch, if you specify "-i 2" to smil2yuv, then the output >> stream will be in the 4:1:1 subsampling mode native to NTSC DV --- >> which can then be converted properly to 4:2:0 by y4mscaler. (The > > Uh, does this mean what I think it means? That all this time > smil2yuv has been producing the wrong output for NTSC folks which I/we > have been making SVCD/DVDs with?
And lav2yuv, too. Not exactly "wrong"... PAL-DV uses 4:2:0 chroma subsampling, like MPEG-1 and MPEG-2 (albeit all three uses slightly different varieties of 4:2:0). NTSC-DV uses 4:1:1. The libdv API uses a common data format for both, packed 4:2:2. This has its pros and cons. The only pro I can think of is that this can be fed directly to Xv-enabled video hardware (which pretty much all understand packed 4:2:2). The big con is that, when all you really want is the raw pixel planar pixel data from the frame, libdv is wasting your time rearranging it into a packed format. (The DV stream itself encodes each plane separately.) Packed 4:2:2 has twice as many chroma samples as 4:1:1 or 4:2:0 --- to create the extra samples from a DV frame, libdv simply doubles them. It doubles every chroma scanline to create 4:2:2 from 4:2:0, and it doubles every sample horizontally to create 4:2:2 from 4:1:1. Now, all the MJPEGtools operate on planar 4:2:0 --- because MPEG1/2 and MJPEG use 4:2:0 subsampling. So, when lav2yuv and (pre-patched) smil2yuv are handed a packed 4:2:2 frame by libdv, they unpack it back into a planar 4:2:0 format. And they do this by throwing away every other chroma scanline. For PAL-DV, this is fine, although a waste of cycles: the pixels that were cloned by libdv are thrown back into the bit bucket, leaving the original 4:2:0 samples. For NTSC-DV, this isn't that great: half of the original chroma samples are doubled, and half are thrown away. Essentially, the chroma signal has been badly upsampled horizontally and badly downsampled vertically. So, NTSC-DV has been getting the short-end-of-the-stick since the beginning. This was one of the reasons I started writing y4mscaler. ... > Or is it the case that y4mscaler's 4:1:1 -> 4:2:0 conversion is > more accurate (better) than what is currently being done? That's a good way to put it. >> subsampling mode is identified by an 'X' tag in the YUV4MPEG2 header. >> This patch also will identify PAL streams as the PAL-DV variant of >> 4:2:0, so that they can be processed appropriately by y4mscaler.) > > Hmmm, anything outside of y4mscaler know about that 'X' tag yet? ;) 'X' tags are in general ignored, but passed along unmolested. It's a feature of the YUV4MPEG2 spec that allows apps to throw more metadata into the stream. It's X as in "eXtra" or "eXperimental". (See "man yuv4mpeg" :) But, nothing else currently understands "XYSCSS=411" --- it's a happy coincidence that 4:2:0 and 4:1:1 carry the same number of chroma bytes. -matt m. ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
