[Lossless] Ut Video Codec

[Johny-115]

Another thing to note is that the colour profiles in AE are completely separate from colour matrices, as is the bit-depth of each channel. 10-bit is useless for you seeing as your decoder is only capable of 8-bit and even worse your monitor is probably only 6-bit (particularly common for laptops, and EVERY apple product.)

The correct thign to do is ignore colour related everything in your app entirely and handle it in avisynth. The function and parameters to use are as Cannonaire suggested. I would also advise that you quit right now as judging on the content of mirko's post, your source material was encoded by the idiots at THORA who have destroyed anything in it resembling HD or allowing for proper decoding, which might in fact be your problem in the first place. Start again with decent footage.

man do you understand that my original samples were hardly manipulated ? ... so that that differences could be more visible ?
coz i have still feeling like everybody thinks my problem is it looks like i posted it ... i said i "darkened" them ... the banding gets visible only after 2nd re-encode and still, not that much ... thats why i changed levels and contrast drastically ... but i wrote that, did you read that or just looked at pics and then talked ?

these are origs, and i dont think they can be much better
http://dl.dropbox.com/u/3358708/temp/00 ... ill009.png
http://dl.dropbox.com/u/3358708/temp/00 ... ill010.png

but anyway checking now other sources if they are handled different ...

[Cannonaire]

The screenshots you posted originally look as if they had been converted from one colorspace to another with the wrong matrix, so forgive us for jumping to conclusions. At least in my experience, after multiple successive re-encodes UTVideo remains lossless, and that is why we're blaming other steps in your process. Remember, we are trying to help.

- my editing process involves re-encoding it 3x times, so after that with what happens with 420/422, it damages visibly even without darkening it
- so also once it transfers chroma subsampling to that of codecs, why it gets worse and worse after every other recompress, its basically lossy

Would you explain your editing process to us please? It might give us better understanding to help you fix this problem.

[Johny-115]

The screenshots you posted originally look as if they had been converted from one colorspace to another with the wrong matrix, so forgive us for jumping to conclusions. At least in my experience, after multiple successive re-encodes UTVideo remains lossless, and that is why we're blaming other steps in your process. Remember, we are trying to help.

- my editing process involves re-encoding it 3x times, so after that with what happens with 420/422, it damages visibly even without darkening it
- so also once it transfers chroma subsampling to that of codecs, why it gets worse and worse after every other recompress, its basically lossy

Would you explain your editing process to us please? It might give us better understanding to help you fix this problem.

well
1. i convert source to lossless intra frame with AME for AAE (coz while it can read source it encodes from it with errors)
2. process that in AAE (scene detection), export again in same lossless but individual clips
3. will edit that in Premeire and export to last (3rd) lossless ... and that encode to lossy etc.

i did this in short version to see how it goes with UTV 422 (as in my cpu utilization in premiere editing test, it was fastest) ... but noticed slight banding in last 3rd encode ... i dunno, its like every time it did that it lost bit of color definition, its not something u would probably notice in real live footage, but cgi advent children has some gentle gradients and i just noticed that sky was not perfect

but i think il go with the RGB editing, size is larger lot (but i dont care) and cpu utiliztion in premiere pro playback is about 10% higher (35% instead 25%) ... yeap theres definitely something wrong in process, coz even if it was really weird first convert of color matrix or whatever .. then it should be same all other encodes, but it isnt, it degrades every other, so everytime it understands the specification of file in wrong way and does some difference in re-encode ... but well ... RGB is 100% same and i think it shouldnt do any problem

also just now, just to be sure if its that particular release issue or what ... i tried to do same stuff with clip from my camcorder 1080p AVCHD
i encoded it into 422 and 420 UT Video ... it did exactly same thing .. then i took the encodes did 2nd encodes from that in AME again, it got even worse, its same, and its completely different source (yet 420 YUV) ... although iam quite sure it wouldnt be possible to see these differences in this live footage in result, but nontheless theres something wrong as its little different every other reencode

also last idea, can monitor color profile interfere into this stuff ? my photoshop says at startup "the monitor profile "samsung natural 1 icm" appears to be defective. please rerun your calibration software" ignore profile/use anyway... i just hit ignore, everything seems ok

[Mister Hatt]

I skipped over most of your last post as it's irrelevant and it shows you don't understand colourimetry at all. The problem is the colourspace conversion done by AME and as such we've told you NOT to use Adobe to convert your footage into a format you can more easily manipulate, which is what I have said quite possibly three times now.

Monitor colour profiles are not the same as colourspaces or colour matrices and have no bearing on your problem at all. From looking at your images (and largely ignoring what you actually wrote seeing as it's either wrong or irrelevant) it seems to be that your problem is a colourspace conversion issue.

Also, arbitrarily switching between 422 and 420 can cause banding although on the chroma plane and not the luma, which is what you're actually seeing, so this is not the issue. Just a warning though, carelessly switching between planar formats is something you should avoid when possible unless you actually know what you are doing, which I am fairly confident you don't.

tl;dr your RGB conversion or AVC decoding is the problem, do either of these a different/better way and your problem should disappear.

[mirkosp]

What Mister Hatt said is correct. You should do the first two steps with avisynth and virtualdub, while keeping everything yuv420. At that point even if it looks wrong on screen while editing, it's not of your concern, as you're keeping the info yuv420 and the banding is introduced from a bad convertion to rgb in premiere, if there happens to be banding in premiere anyway, at that point.
When you export from premiere make sure once again that you export as yuv420, and then load that into zarx264gui and encode. If the final encode has the banding it means one of two things
1) The decoder or renderer or whatever is handling the yv12 to rgb conversion during playback is doing it wrong
2) There was banding to begin with
Now however, since your source does not appear to be banded, it would just have to be the former option, which is why I suggested to use madVR in case, after using avisynth+virtualdub to make lossless clips and making sure you properly keep everything yv12 from start to finish, you still see banding.
In the off-chance you do not know how to make lossless clips with avisynth and virtualdub, I suggest that you Read <a href=http://www.a-m-v.org/guides/avtech31/>ErMaC & AbsoluteDestiny's Friendly AMV Guides Lovingly Overhauled Largely by Zarxrax</a>.

[Mister Hatt]

Silly mirko, you forgot that banding can be caused by over quantization too! CRF and decent AQ settings should make sure that doesn't happen though~

[mirkosp]

Silly mirko, you forgot that banding can be caused by over quantization too! CRF and decent AQ settings should make sure that doesn't happen though~

Lol... somehow I didn't think of that while writing the post, wonder why it didn't cross my mind.

[Johny-115]

i tried to encode with virtualdub, but it was same, slight banding
i did accidentaly one thing though ... encoded from "Uncompressed 16bpp. YUV 4:2:2" encode (that was 100% same as source visually) with virtualdub ...
and chosen matching color depth settings "4:2:2 UYVY" > "4:2:0 planar" or "4:2:2 planar" ... and exported this into UT Video ... and result was - finaly luma was okay, no banding, but instead chroma moved to more greenish
i tried did the same thing with AME to see what does it do ... ie "Uncompressed 16bpp. YUV 4:2:2" to UT Video ... but it was old color ok, luma not ok, banding

i think i wont be able to handle this kind of problem, iam just no expert or something, is it really bad edit it in RGB UT Video ? why could it be wrong ? it just uselessely makes it larger and slower, but otherwise quality should be untouched ? visually it looks 100% same every other encode

[mirkosp]

Here's the thing. YUV and RGB are very different ways to represent colors. YUV is much like the human eye: the Y represents the luma (you could say a b/w image), the UV the chroma.
In the chroma red is opposite of blue and yellow is opposite of green. On the other hand, RGB represents colors by additively combining red, green, and blue information for each pixel.

What this means is that some colors that a colorspace can represent aren't necessarily standard or representable in the other colorspace. This then means that doing colorspace conversions from one colorspace to another will introduce VERY slight roundings in these values to represent valid colors, thus why colorspace conversion is not lossless. Of course, if kept to a minimum, this should be visually unnoticeable, but if you can go without converting colorspace entirely, it is for the better.

Of course, though, you'll have to convert YUV to RGB eventually. LCDs are RGB, for once, so in order to show the video on the screen you'll eventually need to convert these colors from YUV to RGB.
This means that you have to make sure as best as you can that the colors are being converted as properly as possible. The one thing that matters the most in this is the colormatrix. It basically is a matrix that says how colors should be weighted and represented in the conversion. Getting this wrong will introduce the green alteration you're noticing, for example.
The banding is introduced for similar reasons, namely if a conversion to rgb is not done properly, then you'll have steps in the luma (and possibly chroma too, but luma is obviously more noticeable to the eye).
As a rule of thumb for colormatrix, SD video is generally bt601, whereas HD video is generally bt709. Also, H.264 encodes generally do specify this in the SEI info as well (if it was properly set when encoding), so you can even check and make sure that what you're working with is of a given colormatrix just to be sure (though THORA encodes have the SEI zeroed, so the colormatrix info is prolly removed as well ─ and I don't see it in your screenshot, so yet again further proof).

As for virtualdub, you should be selecting "Fast recompress" under compression. If you don't do so, it will internally convert colorspace, afaik, and possibly colormatrix too, thus why you get the slight chroma change and slight banding as well.

[HalOfBorg]

On at least two PCs I have had problems with Ut so far. Sony Vegas crashes/errors just as the render reaches %100, or rendered clips that won't play - MPC errors when the clip is launched.

Other than this, SV and MPC seem to work well with the codec, rendering and preview window playback is much smoother.

I have seen these problems when I use one of my Ut clips as the source for another render.