x264 and yv12

[marcio]

So, x264 can only take yv12?
There is some serious color degradation when things are converted from better colorspaces to yv12. Looks as if the footage loses some contrast, and the colors are not as vivid. This is not much of a problem for movies, but for people that creates animation, graphics, this makes x264 a very BAD solution. I just made a 3D render in 3DS and some animation in After Effects, and there is no way to use x264 to encode those. You can pop --bitrate 10000 and it doesn't matter, colors will look BAD. So I guess that is why every professional in graphics animation who really cares about high quality and fidelity uses quicktime and other codecs. I think everybody knows what I am talking about, if not, then I can post some pics to make it clear.

Will x264 in future take better colorspace as input or what? Are the developers working on it?

[mp3dom]

The final colorspace will always be YV12 since we're talking of 4:2:0. If you have RGB sequences it's better if you do the proper conversion directly in Avisynth (convert to yv12 colorspace, add dithering if necessary and so on). An encoder that works in YUY2, will convert the colorspace internally in YV12 in its conversion chain. For your kind of work, the "problem" is the lack of color information that are discarded in a YV12 colorspace (not x264 itself) but you can overcome this with proper adjustement in Avisynth. Anyway, I think that the latest version of x264 (those with Lavf/ffms) can accept yuy2/rgb colorspace and convert directly to yv12 (but I don't know about the conversion quality, but most of all, I doubt you can have some sort of dithering)

[marcio]

so, you are telling me to export to avisynth, converttoyv12, and then use some filters such as curves, etc, to try to make the colors as close as possible to the original.

thats to crazy and would never be 100%. I would just use a better codec like quicktime for example, that can keep color just as good as the original.

Its true that x264 would compress better, but when you are doing 3 minutes comercial videos, who cares if the output is 50mb or 100mb? When the filesize is not that important, I would go with better quality for sure.

Again, will x264 work with better colorspaces in future?

[J_Darnley]

1) keep you content as PC-range, set --fullrange on when using x264 and then make sure your decoder/renderer respects that.
2) let your content be converted to TV-range and then let your decoder/renderer convert back.

Also, what colour space is better? x264 might support 422 and 444 at some point but this doesn't have an effect on contrast.

[mp3dom]

so, you are telling me to export to avisynth, converttoyv12, and then use some filters such as curves, etc, to try to make the colors as close as possible to the original.

You can export in image sequence and then use Avisyth to import the images and made the conversion. Alternatively you can export to i.e. Lagarith/Huffyuv/Canopus Lossless/whatever you want and then frameserve with Avisynth (and so on). Regarding RGB/YUY2->YV12 colorspace conversion, the major drawback are color banding but you can fix (or attenuate) this with dithering. The problem of color change/shift is a problem in your working chain/settings. I've never had a colorshift/change in that kind of conversion and I've worked on almost any kind of source (mainly animation/cg but also movies)


Its true that x264 would compress better, but when you are doing 3 minutes comercial videos, who cares if the output is 50mb or 100mb? When the filesize is not that important, I would go with better quality for sure.

If the filesize is not important and you can go that far (in bitrate terms) I will surely go for a lossless codec which:
1) works in RGB/YUY2
2) are 100% like the original

Is there a particular reason why you're working in h.264? If you need to made a "master tape" go with lossless codec or near-lossless codecs like ProRes or Avid DNxHD which are used for postproduction purpose.

[marcio]

J_Darnley,

Its not that. When you create some digital animation, it will be 0-255 (pc scale) by default. And even if you crop it to say 16-235 (tv scale), doesn't matter because when x264 converts it to yv12, the color is degraded. It happens with 0-255 or 16-235 range, that is not the issue.

Like I said, yv12 is not much of an issue for movies. That is because some movies (most) are already yv12, and even if it is not, the color degradation in a movie, will just look like a less saturated and less contrast image, which is ok ofr movies, they will still look good. That is why x264 is a good thing for movies.

But when you create some 3D animation or any kind of digital footage in programs such as after effects, maya, 3ds, or for example when you capture some ingame footage, for example counter strike, crysis, etc, etc, you can't really convert it to yv12, because the degradation is NOT ACCEPTABLE.

That is because, as people already said here, those things have native more color information then what yv12 can handle. Most of those are AT LEAST 4:2:2. You can't convert those into yv12, without degradation.

So, x264 is not a good solution for those things, if you are looking for quality.

So my question is, again, if x264 developers are thinking about this.

[Dark Shikari]

J_Darnley,

Its not that. When you create some digital animation, it will be 0-255 (pc scale) by default. And even if you crop it to say 16-235 (tv scale), doesn't matter because when x264 converts it to yv12, the color is degraded. It happens with 0-255 or 16-235 range, that is not the issue.

Like I said, yv12 is not much of an issue for movies. That is because some movies (most) are already yv12, and even if it is not, the color degradation in a movie, will just look like a less saturated and less contrast image, which is ok ofr movies, they will still look good. That is why x264 is a good thing for movies.

But when you create some 3D animation or any kind of digital footage in programs such as after effects, maya, 3ds, or for example when you capture some ingame footage, for example counter strike, crysis, etc, etc, you can't really convert it to yv12, because the degradation is NOT ACCEPTABLE.

That is because, as people already said here, those things have native more color information then what yv12 can handle. Most of those are AT LEAST 4:2:2. You can't convert those into yv12, without degradation.You are being completely inconsistent: you talk about "vividness" or "contrast", despite the fact that 4:4:4 is no better than 4:2:0 at any of those. If you are getting changes in contrast or saturation during an RGB->YUV conversion, you likely have some issue with BT.601/709 mismatch or similar.

The weakness of 4:2:0 is resolution, not "contrast" or "vividness". While I agree that there are certainly cases YV12 can have issues (notably sharp colored text), you have yet to describe any of those cases, so I'm pretty much inclined to assume that you have absolutely no idea what you're talking about. I encode game videos all the time in YV12, and by and large, they look pretty good (http://mirror05.x264.nl/Dark/Flash/extra.html).

Furthermore, if you can tell the difference between YUV 4:4:4 and RGB, you're doing something very, very wrong.So, x264 is not a good solution for those things, if you are looking for quality.Better not use any lossy video format then. Almost nobody supports anything other than YV12 nowadays.So my question is, again, if x264 developers are thinking about this.Start by adding support for 4:2:2, 4:4:4, and RGB coding to the ffmpeg decoder. Currently, practically nothing besides the reference decoder supports them. That pretty much stops us from writing an encoder implementation, since it's rather hard to write an encoder if you don't have a decoder.

Of course, perhaps more importantly, there exists no hardware implementations at all.

It's a Summer of Code project (http://wiki.videolan.org/SoC_x264_2010) as well. I proposed it last year due to the fact that 4:2:2 has been demanded by a lot of interlaced-obsessed whackos and 4:4:4 might be useful for 2D graphics, slideshows, and maybe some game captures.

[nurbs]

I think Theora does 4:4:4. The format is supposed to support it, but I don't know if the encoder does.

[Dark Shikari]

I think Theora does 4:4:4. The format is supposed to support is, but I don't know if the encoder does.Yes, there are quite a few things that in theory support 4:4:4, but for which most implementations don't actually...

[marcio]

Dark Shikari,

First one is x264 --crf 16. Second is quicktime JPEG 50% (LOL). Final filesizes are pretty much the same (300mb vs 350mb).
Converting to yv12 loses too much (check texts, check sky, check overall colors, the quicktime encode looks MUCH more like the source), and makes x264 a bad solution for encoding game material, 3d renders, graphics animation and pretty much anything that was original in a higher colorspace.

Anyway, I see this is going no where, I made my tests, and I already know what codec to use when I am dealing with this kinda material.
All I wanted to know is if x264 will support higher colorspaces in future. And still, thats all I want and need to know. Don't want to discuss anything, I just want to know that.

Thanks anyway.

X264 --crf 16
http://img203.imageshack.us/img203/2756/mkv27250000.png

QuickTime (JPEG 50%)
http://img690.imageshack.us/img690/1650/mov27250000.png

[Dark Shikari]

Dark Shikari,

First one is x264 --crf 16. Second is quicktime JPEG 50% (LOL). Final filesizes are pretty much the same.
Converting to yv12 loses too much, and makes x264 a bad solution for encoding game material, 3d renders, graphics animation and pretty much anything that was original in a higher colorspace.

Anyway, I see this is going no where, I made my tests, and I already know what codec to use when I am dealing with this kinda material.Erm, your colorspace conversion is completely borked. The two images aren't even the same. This has absolutely nothing to do with YV12 or x264. This should have been obvious, since JPEG uses YV12 too!

It looks like you have both broken luma levels and maybe also a BT.709/601 problem. Use search if you're not familiar with said issues, which you probably aren't. In short, whatever program you're using to convert to YV12 before x264 is likely ignoring some aspect of the source--or, equally, whatever program you're using to display the video is making a mistake. The error can be on either end.

You should be a bit less eager to blame everyone except yourself, lest you look sillier when it turns out to be your mistake.

[marcio]

I have the same script feeding quicktime encoder and x264, only difference is that in the x264 one I have converttoyv12().
I will search the forums for those issues you mentioned.

[Dark Shikari]

I have the same script feeding quicktime encoder and x264, only difference is that in the x264 one I have converttoyv12().
I will search the forums for those issues you mentioned.The Quicktime encoder is still doing its own YV12 conversion internally. The fact is that the two YV12 conversions are being done differently.

There are four types of YV12:

1) BT.601, PC levels
2) BT.601, TV levels
3) BT.709, PC levels
4) BT.709, TV levels

If the image appears brighter with a bit lower contrast, you've ended up with a TV levels image being displayed as PC. If it ends up darker with some pixels clipped, you've ended up with a PC levels image being displayed as TV.

If the image appears to have slightly wrong colors (tinted), you've ended up with 601 instead of 709 or vice versa.

In general, 709 is used for HD and 601 for SD.

[marcio]

Thanks, looks like it could be related to it.
I will give it a try with those different settings. Maybe that is why I get two very different screens.

I will try those and report back. Looks like BT.709, PC levels is what I want.

[Rumbah]

If you capture your content with Fraps you should try Fraps 3 in RGB lossless mode. That way you get the colors the way you want them.

I noticed that when captured with Fraps in normal lossy mode, you get slightly off colours no matter what colour space and levels conversion you try (even let the original fraps decoder decode to RGB results in slightly off colours).

You can try the different settings with the Colormatrix Avisynth plugin. If I remember correctly Fraps captures in BT.601 fullrange YUY2 but I'm not sure. Then you would either have to convert to BT.709 and TV levels and encode it or convert to BT.709 and encode with --fullrange and hope that the decoder supports it.

Also just to be sure try to set your H264 decoder to RGB output, that way you can rule out that your video card does a wrong conversion to RGB (pretty common).

[Snowknight26]

The color difference between the true lossless mode and the normal mode in Fraps is negligible. The real issue is the RGB -> YV12 conversion that you have to do before encoding. Depending on how you're encoding with x264, there's only a handful of things you can do to lessen the issue. To get truely perfect colors, you should stick with an RGB format.. that way you don't get bleeding reds, greens, and blues.

[Stephen R. Savage]

This should have been obvious, since JPEG uses YV12 too!

It can use YUV 4:4:4 as well. Actually, JPEG is one of the cases where this is widely supported.

[Dark Shikari]

It can use YUV 4:4:4 as well. Actually, JPEG is one of the cases where this is widely supported.True, though most JPEG encoders default to YV12 and either don't support 4:4:4 or require that you explicitly specify it.

[Rumbah]

The real issue is the RGB -> YV12 conversion that you have to do before encoding.

Well, then try and capture WoW with the standard chat colors with Fraps and make a screenshot directly with WoW. The resulting jpeg in YV12 looks like the original (of course with chroma undersampling) but I never got the video to look like that. Especially the guild green suffers.

[Dark Shikari]

Well, then try and capture WoW with the standard chat colors with Fraps and make a screenshot directly with WoW. The resulting jpeg in YV12 looks like the original (of course with chroma undersampling) but I never got the video to look like that. Especially the guild green suffers.Your problem is separate from the OP's. The OP's problem is one of incorrect conversion/levels issues; yours is one of actual resolution deficiency that can't really be solved in YV12.

Though I imagine someone could try to make an improved downscaling algorithm that tries to retain sharp edges at the cost of overall quality.

[Snowknight26]

On a similar note, any chance of setting those two extra sws flags as default in x264?

[Dark Shikari]

On a similar note, any chance of setting those two extra sws flags as default in x264?Once kemuri9's resizer patch gets in.

[kemuri-_9]

On a similar note, any chance of setting those two extra sws flags as default in x264?

2? I've managed to look at swscale again and found 4 flags dealing with swscale cutting corners for speed.

[Snowknight26]

That may be the case but I was personally only interested in SWS_FULL_CHR_H_INT and SWS_ACCURATE_RND (with the default SWS_BICUBIC).