[Lossless] Ut Video Codec
-
Mister Hatt
- Joined: Tue Dec 25, 2007 8:26 am
- Status: better than you
Re: [Lossless] Ut Video Codec
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
- The Absolute Mudman
- Joined: Mon Apr 24, 2006 6:24 am
- Status: (」・ワ・)」(⊃・ワ・)⊃
- Location: Gallarate (VA), Italy
- Contact:
Re: [Lossless] Ut Video Codec
Lol... somehow I didn't think of that while writing the post, wonder why it didn't cross my mind.Mister Hatt wrote: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~
-
Johny-115
- Joined: Sun Oct 15, 2006 6:15 am
Re: [Lossless] Ut Video Codec
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
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
- The Absolute Mudman
- Joined: Mon Apr 24, 2006 6:24 am
- Status: (」・ワ・)」(⊃・ワ・)⊃
- Location: Gallarate (VA), Italy
- Contact:
Re: [Lossless] Ut Video Codec
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.
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
- Joined: Wed May 14, 2008 7:19 pm
Re: [Lossless] Ut Video Codec
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.
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.
-
Mister Hatt
- Joined: Tue Dec 25, 2007 8:26 am
- Status: better than you
Re: [Lossless] Ut Video Codec
We already told you MULTIPLE TIMES that your problem is not VirtualDub, IT IS YOUR INITIAL FUCKING CONVERSION WITH ADOBE. IF YOU STOP USING THAT HEAP OF CRAP YOU WILL STOP HAVING PROBLEMS.
[Kariudo: You can be angry, but don't start personal attacks]
[Kariudo: You can be angry, but don't start personal attacks]
- Cannonaire
- Joined: Wed May 05, 2010 5:59 pm
- Status: OVERLOAD
- Location: Oregon
Re: [Lossless] Ut Video Codec
To answer your question, it shouldn't be an issue to edit in RGB, just make sure you use the right matrix (use exactly the line I gave you before). AFAIK After Effects is 100% RGB anyway, so you'll have to convert at some point anyway if you're using that; better to do so with a competent program like avisynth. Someone please correct me if I'm wrong about After Effects be all RGB.
HalOfBorg:
UTVideo is great for importing into and editing with in Vegas, but I also have problems trying to render out to it from Vegas. I render my footage/clips, etc. with UTVideo via avisynth/virtualdub then just render the final edited video in Lagarith, which I then encode with x264. This solution provides the faster speed of editing with UTVideo and never loses quality due to encoding issues.
HalOfBorg:
UTVideo is great for importing into and editing with in Vegas, but I also have problems trying to render out to it from Vegas. I render my footage/clips, etc. with UTVideo via avisynth/virtualdub then just render the final edited video in Lagarith, which I then encode with x264. This solution provides the faster speed of editing with UTVideo and never loses quality due to encoding issues.
Think millionaire, but with cannons. || Resident Maaya Sakamoto fan.- mirkosp
- The Absolute Mudman
- Joined: Mon Apr 24, 2006 6:24 am
- Status: (」・ワ・)」(⊃・ワ・)⊃
- Location: Gallarate (VA), Italy
- Contact:
Re: [Lossless] Ut Video Codec
Not sure about AE, but in Premiere Pro some effects are YUV and other are RGB, so my guess is that, depending on the effects you use, the whole process stays YUV without conversion.Cannonaire wrote:Someone please correct me if I'm wrong about After Effects be all RGB.
I'd think that it'd be the same in AE as well.
-
Mister Hatt
- Joined: Tue Dec 25, 2007 8:26 am
- Status: better than you
Re: [Lossless] Ut Video Codec
You're both still missing the point that his initial transcode itself is wrong, and what he does in AE/Premiere makes no difference at this stage. He needs to redo the rip to begin with. That or I've REALLY misunderstood.
- HalOfBorg
- Joined: Wed May 14, 2008 7:19 pm
Re: [Lossless] Ut Video Codec
I could do a lot of that (in fact I make my lossless clips with Xvid4PSP, so doing it with Virtualdub would be easy enough), but a lot of the editing I do involves adding elements, removing elements, so I usually render and re-render several times (though not always - 'Pump' was almost all scene selection).Cannonaire wrote:HalOfBorg:
UTVideo is great for importing into and editing with in Vegas, but I also have problems trying to render out to it from Vegas. I render my footage/clips, etc. with UTVideo via avisynth/virtualdub then just render the final edited video in Lagarith, which I then encode with x264. This solution provides the faster speed of editing with UTVideo and never loses quality due to encoding issues.
I'm using Vegas 8, but I do have 10. Maybe it will render from Ut better. Would be little trouble to load my project into 10, render the clip in question and load that into 8.






