[Lossless] Ut Video Codec

[Johny-115]

i am using cs5 64bit adobe media encoder, after effects, premiere pro ..

which has nothing to do with storage problem for your Codec.

The editor is not utilizing 32bit-Alpha Level Images. Use Huffy to store what your working-on.

All of your images suggest that your using 16-bit color pallets instead of 32-bit color pallets.
[[ you might as well be editing in Xvid! ]]

why do u mention alpha ... where is alpha involved ... also iam not even using editor yet, no utilizing
i just re-encode original mkv video stream in adobe media encoder to UT video ... thats origin of samples (but ofc its same even in premiere and AAE)
and as i said ... there are only two options considering color pallets ... 8-bit and 24-bit ("render at maximum depth" option) ... they both look same in case of 420 and 422

also huffy is much slower isnt it ?

[Mister Hatt]

Adobe Media Encoder? Found your problem. Related: the green shift is caused by converting to RGB using the wrong colour matrix, not using AME will probably fix that as well. Either way, there is no problem with UTVideo here, just your stupid method of conversion and handling.

[Johny-115]

Adobe Media Encoder? Found your problem. Related: the green shift is caused by converting to RGB using the wrong colour matrix, not using AME will probably fix that as well. Either way, there is no problem with UTVideo here, just your stupid method of conversion and handling.

source > UT RGB .... i checked "render at maximum depth" option ... and its 100% lossless, its same
source > UT YUV 420/422 ... still nothing helps
source > Lagarith ... does the same thing as UT YUV, slight banding of gradients
source > Cineform ... its OK

- i dunno maybe its normal ? ... if the image isnt color manipulated like i did, it gets slightly visibly only after few re-encodes, but point is its just not lossless process
- Lagarith does it too, so it doesnt look like UTV problem ... but why is cineform and RGB UTV allright ?

Also how can you say my method is stupid ... UT video codec is meant for editing isnt it ? then how should i edit it if Premiere Pro CS5 doesnt work lossless, it should ... i get it, its not probably coz of codec, but then tell me how to approach this, if i recall ... after effects from adobe package has extra option of actually choosing color space ? could try that ... but dunno which ... i thought point of this forum is to help and give advices, not call people stupid .. i just wanna understand this 100% so my process is 100% ok

[Cannonaire]

Even though you're using lossless codecs, which is great, changing the colorspace is not lossless. It has an acceptable amount of loss when done sparingly and only when required, but there is also the chance of things getting messed up if it is converted using the wrong matrix.

UT Video most likely isn't the problem. The problem is probably that Adobe is converting using the wrong color matrix. The solution is to change the colorspace to RGB in Avisynth instead and use the correct color matrix. Put the color conversion on the last line of your script. Since it will already be RGB, the Adobe application will not need to convert the colorspace. Also, be sure to use UTVideo in RGB mode after converting.

[Mister Hatt]

Technically if you use the correct colourimetry and matrix it is 'lossless', although different manufacturers of gear still have their own unique spin on things. Might want to explain how to convert planar colour to RGB with the correct matrix though, I doubt the guy is going to actually read the docu.

[Cannonaire]

I'm not exactly knowledgeable when it comes to colourimetry, but let's see how well I do after a quick wiki primer.

Your screencaps are 1280x720, so I'm guessing you're either using an HD source or upscaling for some reason. Anyway, if it is an HD source, I think the correct matrix to use in avisynth is 'rec709' (DVD would be 'rec601' I believe, and this probably isn't accurate for all DVDs).

Try this line at the end of your script:

Code: Select all

ConvertToRGB(matrix="rec709", interlaced=false)

Like I said, I'm not an expert on this particular topic, but this might be the solution to your problem.
Now please excuse me while I read more about colourimetry.

[Johny-115]

so iam back after some testing, i played with changing color space in AAE and rendering different versions, didnt worked though, tried sRGB, AdobeRGB, HDTV 709, HDTV 709 16-235 and few others

but what i noticed though is ... i exported with uncompressed "V210 10-bit YUV" (its 4:2:2) and that was 99,9% OK, just few pixels different but no slight banding
so also if i recall cineform is somehow 10-bit okay ?

so .... so far
source >>> any RGB (including UT Video) = 100%
source >>> 10-bit YUV (cineform, V210) = 99,9%
source >>> 8-bit YUV (UT Video, Lagarith) = like 98%, slight banding

so anybody can tell me whats happening here ? because am i wrong in thinking it cant be wong color matrix issue ? coz otherwise V210 which is YUV 4:2:2 would be wrong in same way as UT Video YUV 4:2:0 ... coz its same situation of source into YUV

so i dont understad these color depth (8-bit, 10-bit) vs. color space (RGB, YUV) relations .... but whats even more confusing is that source should be just YUV 4:2:0 and 8-bit !!! ... wo why V210 10-bit works perfect and 8-bit UT video does not ... isnt it possible that MediaInfo says it wrong, that it is not 8-bit source or something ?

here is source video mediainfo screen http://dl.dropbox.com/u/3358708/temp/orig-sds.png .. its one of those sort of overkill [Redacted.]

[Johny-115]

PS: i manged to import unchanged video stream from source to AAE and under "Interpret Footage > Color Management" i found that "Embedded Profile" realy is "HDTV (Rec. 709)"
but no difference with that, also if iam not wrong that must mean that AME, and Premiere read that "Embedded Profile" too

[mirkosp]

Read the rules!

There shall be no posts containing or on how to obtain warez, crackz, serialz, emulators, porn/hentai, bootlegs, or illegally obtain downloadable anime episodes, music, or any other sort of copyrighted material. You will be banned without warning for such posts.

Post redacted. And this is just a warning, but next time it will be a ban.
One thing to notice is that the group you mentioned zeroes the SEI, as it's clearly visible in the screenshot you made (Writing Library and Encoding Settings are zeroed, if you look). That breaks compatibility with some decoders. Their encodes have varying quality depending on how they're handled, too, and they often keep upscales even if they are obvious. Another thing is that the filesize is just inflated much more than could ever be needed...

Also, my guess at your issue is that what's handling the YUV to RGB conversion during playback is bad at it (hint: swscale has some quirks with it and does in fact introduce banding when converting colorspace).
Keep everything YV12 even if you see banding on screen, as long as you're not doing an actual conversion to RGB in the content, that's not actually representing the actual video it's there. Rather, what you should care for is make sure that, when watching the final x264 encode, it looks fine when viewed with a good renderer, like for example madVR.

[Mister Hatt]

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.