YV24/I444 for Capturing.

[zerowalker]

Not really sure where to put this, but i think this is somewhat right.

I am recording gameplays and have been using Fraps, but don´t like how it first records YV12 then decode to RGB to later convert to YV12(for encoding), it´s unecessery chroma loss.

I then changed to dxtory(still use fraps when dxtory don´t work though), and it allows me to use whatever codec i prefer.

Here is the thing:

I prefer to use Lagarith or UT Video Codec.

both of them are pretty much the same on compression, except that Lagarith has some Insane advantages for simple 2D games (Gameboy etc).

But the problem is, i do music videos so i want to have as much original quality as possible.

I noticed how bad YV12 sadly is thanks to it crushing the Chroma.

YUY2 is much better but still not "Good".

YV24/I444 is Perfect, almost identical to RGB except for Banding issues which occurs in all YV formats (don´t know why, but i guess it´s the color formula or something).


The thing is, none of the codecs or any other i can find, support YV24, only Yuy2, YV12 and RGB.

And RGB is just to intensive and too big.

And i know FFV1 supports YV24, but it´s too slow, good compression though:)


Anyone knows if it´s easy to add YV24 to Lagarith as the source code is available?

Or is it much programming to do, and not just Add the format and let it compress it?

[vivan]

And RGB is just to intensive and too big.

...

Anyone knows if it´s easy to add YV24 to Lagarith as the source code is available?YV24 is as intensive and big as RGB, since it's 24 bit/pixel format too.

[zerowalker]

Really?
YV12 and YUY2 are extremely close in size.
And when i did some X264 encodings from RGB to YV12/YU16/YV24 with CRF, they all had the same size, but YV24 kept most color details.

Though if i save YV24 to lagarith, it upscales to RGB.



But if YV24 is as intensive and big as RGB, what it the difference between them?
I really can´t find any difference from the information, just some formulas that i don´t understand.

[SassBot]

YV12 and YUY2 are similar in size because they use close to similar bits per pixel (12 for YV12 and 16 for YUY2).

[zerowalker]

Ah i see, but is it really the same?
Cause even if YV12 and YV16 is close, RGB is insane.
21gb YV16 became about 33gb if i upscaled it to RGB.

Isn´t Yuy formats smaller thanks to the formula in how it stores colors etc?

Or is YV24 going to become 33gb aswell?

[SassBot]

Ah i see, but is it really the same?
Cause even if YV12 and YV16 is close, RGB is insane.
21gb YV16 became about 33gb if i upscaled it to RGB.

What else did you expect when you increased the bpp from 16-bits to 24-bits? You increase that by 33% and you get a ... 33% increase in size.

Isn´t Yuy formats smaller thanks to the formula in how it stores colors etc?

Or is YV24 going to become 33gb aswell?

No, it isn't smaller due to that. YUY2 is smaller because of the lower bpp and through the use of subsampling to further decreases the bits used per sample. If YUY2 used 24-bits per pixel it and had no subsampling it would be just as large as 24-bit RGB.

[pandy]

Use YCoCg space instead YUV.

[SassBot]

Does Lagarith or UT Video Codec support YCoCg? If not, that doesn't really help him since he's trying to find a format to use for lossless capturing and it doesn't seem like he wants to use H.264 lossless.

[pandy]

If he provide YCoCg to codec (flagged as YUV) then codec use is transparent - conversion YCoCg <> RGB is reversible.

[SassBot]

If he provide YCoCg to codec (flagged as YUV) then codec use is transparent - conversion YCoCg <> RGB is reversible.

I think you misunderstand what he is doing. He is trying to find a good colorspace format to use for doing screen captures. How exactly is he going to provide YCoCg to Lagarith or UT Video Codec when doing screen capturing?

[zerowalker]

YEs as Sassbot is saying, i am Capturing Games.

RGB is the Best of course, but it´s just to extensive.
And as YV24 is the same in size, that sadly isn´t the way to go, nor can i use it.

though YCoCg(component??) isn´t something i am familiar with at all.

Is it small, how does it work?

And is there a way to use it with Lagarith, or is there any other codec that´s good with it?

If there isn´t a way, i guess i will have to use YUY2 currently, till i can capture RGB.

Though i think my CPU and hardrive is bottlenecked.

80mb write, and 4ghz cpu 4 cores (i5).

[SassBot]

You can always try using VfW x264 and use lossless H.264 and see what colorspaces you can select. Should give you better results even with the same colorspace as you tried with Lagarith or UT.

[Bloax]

Just don't forget to use a really fast preset if you do so.

[zerowalker]

is it really any good?
I haven´t really heard of anyone using x264 for capturing?

If i can use it, i sure will, as games use 1-2 cores, the x264 can use 2-3 cores, it should be pretty stable i guess?
Can anyone give me some more information, is it the same as normal encoding (Megui), if so i will have to go with Faster-Veryfast maybe even Ultra Fast;O

EDIT:

Tried playing around, but can´t say i like it though, and i can´t get "--output-csp" to work, it just Tabs to desktop everytime i take the game windows up and it tries to capture.
I tried normal, and it becomes YV12, and i tried "Keep Internal Colorspace" and it still became YV12 for some reason, and it´s bigger than Lagarith but slower;S

Btw, i have to use Zero Latency, else it doesn´t capture.


PS:

In avisynth i noticed if i use Info(), the x264 files all say YV24 in Colorpace, while Lagarith says YUY2 (i have chosen that), but in the right corner it says YV12 for x264 for some reason.
So it´s downsampling on decoding?

[pandy]

I think you misunderstand what he is doing. He is trying to find a good colorspace format to use for doing screen captures. How exactly is he going to provide YCoCg to Lagarith or UT Video Codec when doing screen capturing?


YV24/I444 is Perfect, almost identical to RGB except for Banding issues which occurs in all YV formats (don´t know why, but i guess it´s the color formula or something).



If he is happy with YV24 then banding can be reduced by use YCoCg.

[zerowalker]

pandy can you explain more?
I really don´t know what YCoCg is, the only thing i think of is the color transfer in Component.

Thanks:)

[SassBot]

If he is happy with YV24 then banding can be reduced by use YCoCg.

Great, but again what screen capture codec allows you to select YCoCg? He isn't talking about the colorspace format of the final encode but the colorspace to use while capturing. Saying "use YCoCg" over and over doesn't help them.

[pandy]

Great, but again what screen capture codec allows you to select YCoCg? He isn't talking about the colorspace format of the final encode but the colorspace to use while capturing. Saying "use YCoCg" over and over doesn't help them.


Yes, You have right - my fault - i can't provide ready to use tool - however source for Lagarith is available and this should be doable - if not by topic author then perhaps someone will make such modification (or Lagarith Author - this can be good from Lagarith popularity point of view - first codec supporting YCoCg - conversion seems to be easier than for RGB<>YUV so new functionality for almost free?).

[zerowalker]

I don´t get it, what is YCoCg?
Is it comparative to RGB or what?

[Bloax]

http://forum.doom9.org/showthread.php?t=161736

[zerowalker]

So i can Encode YV12 with "--colormatrix YCgCo --range pc --input-range pc" in x264 and it will produce the same quality but for less bitrate?
Or am i out in the woods;D?

[zerowalker]

Sorry Double post!

[pandy]

So i can Encode YV12 with "--colormatrix YCgCo --range pc --input-range pc" in x264 and it will produce the same quality but for less bitrate?
Or am i out in the woods;D?

So without for example Lagarith that change incoming RGB 4:4:4 samples to YCoCg 4:4:4 or 4:2:2 will be impossible to use YCoCg - however benefits from YCoCg can make this space more useful than YUV with higher compression than for example plain RGB.
Ask Lagarith author or perhaps someone on Doom or perhaps You can try to do this by Yourself modifying Lagarith source.
Rule is similar to RGB<>YUV conversion however matrix coefficient are simply 0.5 thus easier to calculate and with some restriction RGB<>YCoCg can be fully reversible.

In other words - You can't capture in YCbCr (YUV) and signal that Your samples are YCoCg, You can capture in RGB - convert space to YCoCg and signal this as YCbCr if codec is incapable to directly use YCoCg, then at the decoder side, You must know that Your YCbCr is in fact YCoCg.

Or add to the capture or to the compression filter/codec YCoCg support wich should be good trade-off between RGB and YCbCr(YUV) for CG capturing.

[zerowalker]

Oh, so YCbCr can look exactly the same as RGB, and can go forth and back without loss of information?

Sadly though, i myself can´t program it, as i can´t even compile the source, i am really bad at this stuff..
And i don´t know someone who can do this either.

I don´t think it´s hard though, i mean, it sounds like you just have to Add a Color Space, and then write the conversion that it needs to do from RGB right?
I can´t see that it´s that hard if you can program, and the calculations are available, though i may be wrong.

Will try to contact the Author about it:)

[pandy]

Oh, so YCbCr can look exactly the same as RGB, and can go forth and back without loss of information?

YCbCr not, YCoCg under some conditions yes.
For RGB all compnent must have equal bandwith ie there is no sens to for example sample G with full bandwidth and R with B with half - YCbCr and YCoCg are based on some special conditions - human vision system is more sensitive for luminance resolution than for chrominance.
If you stick with 4:4:4 then RGB have small advantage over any differential color space - there is no need to convert color space from capture source to render device - both are (usually) the same.
However converting to differential 4:4:4 or even 4:2:2 can create situation where compression can be slightly more efficient than for plain RGB or it will be more efficient thanks to data decimation even before compression without hurting (to much) overall perceived quality.
Issue with YCbCr is that RGB and YCbCr are slightly different color spaces and conversion between them is always lossy (if full quantization range is used) - YCoCg is free from this and this can be fully reversible (quasi lossless) conversion of RGB and still provide some gain when compressed even with codecs that can operate only in YCbCr space.



Sadly though, i myself can´t program it, as i can´t even compile the source, i am really bad at this stuff..
And i don´t know someone who can do this either.

I don´t think it´s hard though, i mean, it sounds like you just have to Add a Color Space, and then write the conversion that it needs to do from RGB right?
I can´t see that it´s that hard if you can program, and the calculations are available, though i may be wrong.

Will try to contact the Author about it:)

I share Your pain - even if i understand (i think) code still i can't code myself - for Lagarith all You need (my impression) to do is a change of the coefficients in existing YCbCr <> RGB - but perhaps it is better to write new conversion exploiting YCoCg characteristic ie instead float or float approximation shift can be used - and i think that YCoCg support especially for lossless codecs can be quite important.
So count me as second vote for adding to Lagarith YCoCg support when source is RGB.