YV12 RGB color space questions

[Kraise]

Hey, I usually fraps stuff right and I just now found out fraps uses YV12 (I had thought RGB), well after I've edited the footage I guess I've been exporting it RGB lossless because everytime I import it into megui I have to add ConvertToYV12() at the end of my script

now I'm just wondering if this causes any luma/color issues going form YV12>RGB>YV12 because I think I noticed a decrease in luminance in my last video after encoding but I thought that was just encoded quality.

my second question is

YV12 is 12bit right? (totally unsure of anything, haven't read up)

so if I edit in 32bit color space in after effects or so, and export to YV12 will I lose all the detail I gained in 32bit? Is RGB the only color space to use 32bit?

3rd question:

What lossless codecs provide YV12 as an output, Lagerith lags like 20x more on windows 7 and huffyuv just doesn't work so are there any other codecs?

Edit//

Alright, so I just found out Vegas converts the YV12s I put into it to RGB32 regardless, so I should be outputting RGB32 lossless like I have been...

so if my original clip is YV12 there's no way to stop the YV12>RGB32>RGB32>YV12(source > editor > lossless > final) that I'd be doing? Is there anyway to do the conversions without losing detail? And why the hell don't video editing programs work in YV12 color space if broadcast and DVD and internet is all YV12? :S

Oh and a question about this two lossless codecs:

I've been using quicktime image sequence PNG as a lossless as it's pretty fast, I'm wondering if thats RGB or YV12 as it's just images it really doesn't tell me err loll

[J_Darnley]

YV12 is 12 bits per pixel but each channel uses 8 bits per sample. The chroma channels are 2x subsampled (half the width, half the height) so in total it only requires 12 bits per pixel. Also, RGB is only 32-bit if you use the alpha channel. The red, green and blue channels are all 8 bit/sample.

The YV12>RGB>YV12 conversion doesn't have to cause PC-TV range problems if they are all done with the same range. If you want to edit in YV12 then use avisynth.

As far as I know, PNGs only support RGB

Other lossless codecs/formats are ffv1, ffvhuff and H.264 lossless. All three support YV12.

[Flux]

Fraps does some kind of color compression and it can be seen easily by looking the game interface. Health bars for example are not pure red anymore. They look a bit washed out. I can understand why they do that because it can cut hard drive speed and filesize requirements around 50%, if the compression is similar to YV12.

Some old Fraps versions won't compress the colors. They are freeware now, but getting solid 30 fps might be a challenge even for modern hard drives.

[Kraise]

Fraps is RGB32, I have no idea why it said YV12 earlier when I had the .info() avs script on it, I must of had the wrong path. Thanks for pointing that out to me.

Anyway what I was most worried about color changing when converting RGB32 to YV12 in megui to make a H264

It was showing a pretty bad color change earlier for some reason, it must of been those odd codecs I was using
(Fraps>Vegas>QuickTime Animations>PNG>Quicktime Animation>AVS>megui)
so that was like
RGB32>RGB32>YUV>RGB32>YUV>YV12, maybe it was just the quicktime to megui that went weird (first time doing that)

Anyway I managed to find a huffyuv that works on Windows7 x64 (It's a 64bit version but it crashes after effects for some reason) but anyway did some tests
Fraps>Vegas>HuffyUV>Megui
which is RGB>RGB>RGB>YV12 and I didn't notice the color change this time, I loaded the files all into VirtualDub with DirectShowSource and they all looked the same. Being really weird I took the a screen shot of RGB32 and the YV12 file and took them into photoshop selected the same pixel and sampled the color and there was like 5 number difference in all the little readings, I don't know if that's from compression or not but it wasn't noticeable.

I only got one last question now
The codec: Quicktime 7 PNG 32BBBP creates a .mov file, and from what I seen it's lossless and RBG32 right?

Just wanted to make sure because I'm probably going to using that from now on since AE isn't working with huffy on W7 x64

Atleast I learned more about color spaces from this, I hadn't given them much thought before.

[imk]

I recently ran into this when capturing a short clip for someone. The color when converting to YV12 was darker overall.

I did various tests and came up with some results.

Using ffvideosource() or ffmpegsource(), those two would automatically convert the video from RGB32 to YV12. I checked this with info(), and whether I used converttoyv12() or not, the output was always YV12. Both ffvideosource() and ffmpegsource() would output the video with darker colors.

Using directshowsource() with info() would show the video as RGB32, which is correct. If I then used converttoyv12() on it, info() would report the output as YV12 and the colorspace was correct.

It appears to be something internally with ffvideosource() and ffmpegsource() that convert it wrong.

I'm not sure what MeGUI uses since I don't use that, but if it's using ffvideosource(), that might be your problem.

[Boolsheet]

Looking at the FFmpeg source code for the Fraps decoder (http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/fraps.c), Fraps really can record in YUV420. I just captured 2 videos at 320x240 and 1680x1050, the first is in rgb24 and the second in yv12 (coded with the PC.709 matrix). So it looks like it's a case of wrong luma levels. ;)

The fps1 decoder installed by the Fraps installer apparently converts every video back to RGB.