Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ The whole reason of FOURCC codes is to prevent this mess

I really hate it when people overload four-character (FOURCC) codes for video formats they weren't intended to handle. Why?

Because it creates a mess that the user has to clean up manually.

The whole point of FOURCC codes and format structures is to unambiguously identify the format and color space of image data. When you overload an existing FOURCC with a new meaning, it creates ambiguity that causes conversion errors throughout a video processing pipeline that can be hard to track down. One common transgression is writing full range YCbCr data into the YUY2 FOURCC instead of 16-235 luma range. This creates all sorts of situations where video ends up either 14% higher or lower in contrast because two modules disagree on what range is being used, and they can't autonegotiate because the same code has been overloaded. Ditto for Rec. 601 vs. Rec. 709 coefficients, or interlaced vs. noninterlaced.

One solution that is often suggested is to make it a user choice. Well, that's one way to "solve" the problem, but it propagates the mess, and it also assumes that the user knows the answer to the question. Do your users whether the video codec you are using uses full-range luma or not? Does the vendor who makes the video codec document that? Probably not. It gets worse, though, when you consider that there may be hidden conversions in the pipeline. You can argue that hidden conversions are bad, and in general it's better to avoid them for performance and quality reasons. However, they're sometimes unavoidable, particularly for display. What would you do if you saw this dialog:

[Absurd warning]

...followed by more for the video compressor and for the video driver. Heck, at this point, why bother having FOURCCs at all? Just make the user enter in the color space and chroma subsampling information too.

I've also heard the suggestion to make the determination based on whether the frame size is SD or HD. That's not really any better. So now you can't resize video temporarily across the SD/HD boundary without incurring a color conversion... yuck.

An additional reason I've heard to put in options is to recover blacker than black (BTB) and whiter than white (WTW) areas. Well, yes, you can do that via changing the color space, but that's not really what you're trying to do -- you need some sort of conversion to map those values in range, but the full range YCbCr color space is unlikely to be the one you want, and by changing the color space you're also whacking chroma as well as luma. What you really need is a custom color conversion matrix or at least to remap the luma range. Otherwise, you're likely reducing contrast more than necessary or introducing slight color shifts into your video.

At this point, I've resigned myself to having to eventually add some of these options to VirtualDub, because I see far too many cases where people have broken color conversions in their pipeline and they need to be able to compensate for codecs and players that use the wrong conversion formula. However, I fully intend to put a big "THIS IS NON-STANDARD" flag on the options, because I do not want to further the idea that this is the way that FOURCCs are supposed to work. Doing this is a big change to the blitter and display libraries, too, so I have no idea when this would be implemented.

Comments

Comments posted:


I load HD video from my Sony CX7 and I never figure this color thing out.

The video is stored using x.v color (better apparently) and then I lose black and white contrast cause it does not know its BT.709* [2] instead of the usual! It says its getting yuv12 from avisynth but is it getting the full color range??

Wilf - 14 10 09 - 18:34


Is there a Microsoft document that specifies luma and chroma range, color transform matrix, or interlaced characteristics of each YUV FOURCC? In QuickTime, it is all documented in the Letters from the Ice Floe. Even then, some codec developers implemented their pixel format conversion routines incorrectly, so we sometimes see color shift problems. Instead of overloading FOURCCs or creating new ones, the CoreVideo API replaces the FOURCCs with image buffer tags (CVImageBuffer) for all the relevant color and sampling parameters so that developers can get better color matching.

pshufb - 14 10 09 - 18:40


> Is there a Microsoft document that specifies luma and chroma range, color transform matrix, or interlaced characteristics of each YUV FOURCC?

Yes, there is. It's a document called "Video Rendering with 8-bit YUV Formats":
http://msdn.microsoft.com/en-us/library/..

It covers some of the more common formats, but unfortunately it doesn't cover as many as it could. You'll have to fill in from fourcc.org. It also doesn't cover some of the edge cases, such as how to deal with interpolation along the edges of the image or whether sizes that result in fractional chroma plane sizes are valid (some drivers and codecs will take them, but usually with major artifacts).

There are two questionable statements in the MS document, however:

1) It says that Rec. 601 should be used for SD resolutions and Rec. 709 for HD resolutions. Besides this being a breaking change -- it's news to anyone who originally started using the formats in the 16-bit Windows days -- MS also forgot to define the boundary between SD and HD. (Perhaps this is just as well, as in the MJPEG spec they defined 'interlaced' as >240 scanlines, forgetting about PAL.)

2) It says that Studio RGB is the preferred output format for video in Windows. That's news to me. Nobody I know of follows this, since it's awful unless you have a monitor or video card that can be easily reconfigured to accept that. Everyone else who isn't using an HD projector would get muddy blacks and whites instead.

Unfortunately, they also didn't address whether the interlacing flag in VIDEOINFOHEADER2 means anything for the 4:2:0 format or how it should map to APIs/formats that use the same FOURCCs without an interlaced flag (DirectDraw, Direct3D, AVI).

Phaeron - 14 10 09 - 18:52


It might be simplest to put two or three renderings nest to each other in a way that allows us to see which one "looks" right.

Dragorth - 07 04 10 - 19:04

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.