Ut Video Codec Suite - a new lossless video codec for Windows!

[richardpl]

Yes there is a way, use something like this:

ffmpeg -i input -vf mergeplanes=0x000102:yuv420p -vcodec utvideo ....

[WorBry]

Thanks. Can't say I fully understand how it works, but indeed it does.

I think I need to educate myself on planes and the merging thereof:

https://ffmpeg.org/ffmpeg-filters.html#mergeplanes

Over my head at this point.

Edit: Meanwhile, Is it possible to do the same type of thing with a 8-bit YV12 to YUY2 conversion?

i.e. the equivalent of

ffmpeg -i path..../DSCN0968.MOV -vcodec rawvideo -r 30000/1001 -pix_fmt yuvj422p -s 1920x1080 path..../DSCN0968_RawYUY2_Fullscale.mkv

and then:

ffmpeg -i path...../DSCN0968_RawYUY2_Fullscale.mkv -vcodec utvideo -r 30000/1001 -s 1920x1080 path /DSCN0968_UTVYUY2_Fullscale.mkv

[WorBry]

Thanks. Can't say I fully understand how it works, but indeed it does.

I think I need to educate myself on planes and the merging thereof:

https://ffmpeg.org/ffmpeg-filters.html#mergeplanes

Over my head at this point.


OK, based on this VapourSynth ShufflePlanes filter documentation:

http://www.vapoursynth.com/doc/functions/shuffleplanes.html
http://www.vapoursynth.com/doc/avisynthcomp.html

it appears that the same can be done in VapourSynth, so making provision for any additional (full scale) YV12 filtering prior to transcoding:

import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source("Path....../DSCN0968.MOV")
Other YV12 filtering
clip = core.std.ShufflePlanes(clip, planes=[0,1,2], colorfamily=vs.YUV)
clip = core.std.AssumeFPS(clip,fpsnum=30000,fpsden=1001)
clip.set_output()

and

vspipe Path...../YV12Fullscale.vpy - | ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -r 30000/1001 -i pipe: -vcodec utvideo Path....../DSCN0968_VSP_UTVYV12FS.mkv

Is that correct ??? If so, then I've learned a bit ...kind of. But I still can't figure how to do:


Meanwhile, is it possible to do the same type of thing with a 8-bit YV12 to YUY2 conversion?

i.e. the equivalent of

ffmpeg -i path..../DSCN0968.MOV -vcodec rawvideo -r 30000/1001 -pix_fmt yuvj422p -s 1920x1080 path..../DSCN0968_RawYUY2_Fullscale.mkv

and then:

ffmpeg -i path...../DSCN0968_RawYUY2_Fullscale.mkv -vcodec utvideo -r 30000/1001 -s 1920x1080 path /DSCN0968_UTVYUY2_Fullscale.mkv

[richardpl]

Currently not with ffmpeg, i guess adding support for yuy2 to extractplanes and than using extractplanes+mergeplanes should do it.

[WorBry]

Oh, hang on, some needless complication there:



import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source("Path....../DSCN0968.MOV")
Other YV12 filtering
clip = core.std.ShufflePlanes(clip, planes=[0,1,2], colorfamily=vs.YUV)
clip = core.std.AssumeFPS(clip,fpsnum=30000,fpsden=1001)
clip.set_output()

and

vspipe Path...../YV12Fullscale.vpy - | ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -r 30000/1001 -i pipe: -vcodec utvideo Path....../DSCN0968_VSP_UTVYV12FS.mkv



No need to do the shuffle planes thing in VapourSynth:

import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source("Path....../DSCN0968.MOV")
clip = core.std.AssumeFPS(clip,fpsnum=30000,fpsden=1001)
clip.set_output()
with
vspipe Path...../YV12Fullscale.vpy - | ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -r 30000/1001 -i pipe: -vcodec utvideo Path....../DSCN0968_VSP_UTVYV12FS.mkv

and for YUY2:

import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source("Path....../DSCN0968.MOV")
clip = core.fmtc.resample (clip, css="422")
clip = core.fmtc.bitdepth (clip, bits=8)
clip = core.std.AssumeFPS(clip,fpsnum=30000,fpsden=1001)
clip.set_output()
with
vspipe Path...../YV12Fullscale.vpy - | ffmpeg -f rawvideo -pix_fmt yuv422p -s 1920x1080 -r 30000/1001 -i pipe: -vcodec utvideo Path....../DSCN0968_VSP_UTVYUY2FS.mkv

In both cases the full (0-255) YUV scaling is preserved. Figures really :rolleyes:

[zerowalker]

does UTVideo on ffmpeg support Multithread, cause i can't seem to be able to make it work;(?

[umezawa_takeshi]

Version 15.5.0 (http://umezawa.dyndns.info/wordpress/?p=5860) is released.

New features

Windows: Priority of worker threads can be now modified.

Bug fixes

VCM codecs suggested output formats for some unsupported input formats.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.5.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.5.0-win.exe) Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.5.0-macosx.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.5.0-src.zip)

[Sparktank]

Glad to see this getting continual updates.
Between this and MagicYUV, lossless video is always a good option.

Thanks for the updates.:goodpost:

[WorBry]

does UTVideo on ffmpeg support Multithread, cause i can't seem to be able to make it work;(?

Yes - just tested to reconfirm with latest Zeranoe build git-a7b8a6e (2016-03-18) 64-bit.

OS: Win7 64-bit
CPU: AMD FX-6300

Set for -threads 6, Task Manager shows all 6 cores firing uniformly.

[roman]

Just now I installed UtVideo 15.5.0 version on my Win7SP1 x64.Trying to use with VirtualDUB 1.10.4 for video capturing, then just for reencoding - in all cases VirtualDUB crashes immediately after starting.
And other capturing app (BeholderTV) - too. I've choosing 422 and 420, bt601 and bt709.
They are not crushing when I choose another codec - Lagarith or MagicYUV. Only with UtVideo 15.5.0
Is it my problem only?

[filler56789]

......
Is it my problem only?

Apparently the answer is «yes». I have just tested the latest 32-bit build of UTVideo with the latest ("stable") 32-bit VirtualDub on my 2nd Windows 7 x64 machine, and everything went fine :confused:

[Taurus]

@roman:
Maybe Visual C++ redist 2013 is missing on your end?
Make sure you have the 32bit version for this...

[Ignus2]

Sorry for the delay in coming back on this. I'm afraid needs required that I reinstall FFDShow for some other work, but I did check VCSwap at the stage when FFDShow was uninstalled and I had gone on to try those other suggestions - as per posts #446 and #447:


Did you get this problem sorted out finally (would be curious)?

Greets,
I.

[roman]

2_Taurus
Yes, I have they both.
Upset that this program only does crash on my PC. All other hood on my PC worked and works perfectly.

[roman]

Seems I got it. I reinstalled Visual C++ redist 2013 and problem was resolved. Thanks Taurus! And of cource thanks Ignus2!

[WorBry]

Did you get this problem sorted out finally (would be curious)?


No, I'm afraid I didn't go on to try the last suggestion, as per:

http://forum.doom9.org/showpost.php?p=1756988&postcount=460

Like I said:


.....for now I can transcode my clips to UTVideo RGB with FFMPEG, directly or piped from VapourSynth.

[umezawa_takeshi]

@roman:
Maybe Visual C++ redist 2013 is missing on your end?
Make sure you have the 32bit version for this...

Seems I got it. I reinstalled Visual C++ redist 2013 and problem was resolved. Thanks Taurus! And of cource thanks Ignus2!

Oh, really? DLLs in Ut Video Codec Suite are statically linked so I think that Visual C++ redist is not required (and/or is unrelated).

[Taurus]

Oh, really? DLLs in Ut Video Codec Suite are statically linked so I think that Visual C++ redist is not required (and/or is unrelated).
Oh yeah,
I just realized this too.
Sorry, for my misleading suggestion.
But as long as roman got his issue fixed with this hint....:D

[raffriff42]

Then the first post is out of date...Minimum Requirement (from readme file)
...
Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647) is required. Installation of Ut Video Codec Suite will fail unless Redistributable Package is installed.

[umezawa_takeshi]

Sorry, for my misleading suggestion.
But as long as roman got his issue fixed with this hint....:D

It's OK.
roman said that he have fixed this issue by reinstalling redist. It's mysterious...

Then the first post is out of date...

Yes, That sentence is outdated. But I cannot edit it.

Redist is not required since UtVideo 6.0.1.

[roman]

Really, I reinstalled not only VC2013. The full list was just more complicated:

0. Unplug Internet. Deinstall UtVideo pack.
1. Deinstall VC2005, 2008, 2010, 2012, 2013
2. Deinstall net 4.6.1 and 4.5.2
3. Reboot
4. Deactivate net 3.5.1 in Windows Components
5. Reboot
6. Activate 3.5.1 in Windows Components
6. Reboot
7. Install VC 2010, 2012, 2013, 2015 both 32&64, full versions, early downloaded from Microsoft site. Reboot.
8. Install DirectX 9.0.8112.16421 full version early downloaded from Microsoft site. Reboot.
9. Install net 4.6.1 full... blablabla... Reboot.
10. Plug Internet In.
12. Catch VC2005, 2008, and some securityupdates, install it, reboot.
13. Install UtVideo again.

Then try to compress in VirtualDUB with Ut - ok. Try to capture in my BeholderTV app - ok.
Seems all ok.

[roman]

And of cource thanks Ignus2!
ups, I confused a bit :)
In this thread I should thank umezawa_takeshi!
Ignus2 I should appreciate at the nearby thread
Gentlemen excuse me :o

[foxyshadis]

It's OK.
roman said that he have fixed this issue by reinstalling redist. It's mysterious...



Yes, That sentence is outdated. But I cannot edit it.

Redist is not required since UtVideo 6.0.1.

I've edited out the line. If there are any other corrections you'd like, you can PM me.

[Emulgator]

Thanks, foxy. The download links in post 1 still point to 7.0.1.
Maybe they could be edited to point to the containing folder, so one up ?

[umezawa_takeshi]

I've edited out the line. If there are any other corrections you'd like, you can PM me.

Thank you.

[umezawa_takeshi]

Hello, all.

I am implementing UQRG (UtVideo Pro RGB 10bit) and UQRA (UtVideo Pro RGBA 10bit), and their QuickTime components. their encoders only accept 'b64a' as input format.

I have tested them with EDIUS Pro, and I have confirmed that UQRG/UQRA are compatible with EDIUS Pro.

However, it seems that they are not compatible with Premiere Pro / After Effects. For example, on AE, if I select "UtVideo Pro RGB 10bit", "trillions of colors" (i.e. 16bit/channel) is grayed out and I can only select "millions of colors" (i.e. 8bit/channel). Of course, this is not a expected behavior.

What shall I do to make UQRG/UQRA be compatible with Pr/AE ???

[kolak]

Great news!

Few things:
-are you sure Edius talks to codec at 10bit over b64a pixel format? Edius 7 only used on import 10bit+ pixel formats for ProRes (r4fl not b64a)- for all other codecs never tried to use anything above 8bit (it would also pass only v210 to MOV exporter). It may be different in Edius 8.
-it would be nice to have also some common packed pixel format supported, like BlackMagic R210, AJA R10K and DPX 10bit packed format. They are all very similar.

Regarding Adobe.
Both apps are very happy with b64a pixel format (specially AE), but you need to edit Adobe xml codecs rule file.

It should be stored in:

[drive]\Users\[user_name]\AppData\Roaming\Adobe\Common

Edit xml (MediaCoreQTCodecRulesCC xx.xml) and add lines for both fourCC for encoding and decoding part:

<QTCodec codec='UQRG' vendor='****' platform='windows' direction='encode' versionlow='0x00000' versionhigh='*' gammatag='false' cvbuffertag='2.2' deepdecodefourcc='b64a' decodefourcc='argb'/>
<QTCodec codec='UQRG' vendor='****' platform='windows' direction='decode' versionlow='0x00000' versionhigh='*' gammatag='false' cvbuffertag='2.2' deepdecodefourcc='b64a' decodefourcc='argb'/>

You may want to change decodefourcc='argb' also to b64a if codec doesn't provide internal conversion to RGB. This is for PC side.

Restart AE/Premiere and than it should read codec at 10bit and give you Trillion Colors option in AE exporter. If it doesn't work try lower case fourCC (uqrg) and make sure xml files hasn't been overwritten (again) by Premire or AE.

[umezawa_takeshi]

-are you sure Edius talks to codec at 10bit over b64a pixel format? Edius 7 only used on import 10bit+ pixel formats for ProRes (r4fl not b64a)


As far as I saw data in PixelBuffer, 10bit+ data is there. More detailed inspection should be needed.


-it would be nice to have also some common packed pixel format supported, like BlackMagic R210, AJA R10K and DPX 10bit packed format. They are all very similar.


If layouts of those pixel formats are open to the public, I would be able to support. How shall I test? I have BlackMagic Intensity, so I can probably test r210 input. but r210 output and R10k input/output are not.

By the way, are r210 and r10k "full-range" ?



Edit xml...


I tried editing XML... it does not solve the problem. "trillions of colors" is still grayed out.

There are another QT codec that support 10bit. GrassValley HQX (CHQX). By default, AE does not support "trillions of colors" for CHQX. I edit XML for CHQX slimlarly, then "trillions of colors" can be selected.

What differences are there...

(note: latest source code is on GitHub https://github.com/umezawatakeshi/utvideo)

[kolak]

Yes, I've noticed that. I wasn't able to make it working for 10bit YUV UTvideo neither. Something is not right, as I was able to make it working for GV HQX, ProRes444 XQ, MagicYUV private builds etc.

What about vendor? Do you use anything specific?


R210, R10K are full range and pixel formats can be found here:

http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php

together with many others.

DPX pixel format is here:

http://www.simplesystems.org/users/bfriesen/dpx/S268M_Revised.pdf

they are all very similar and pack 3x10bit into 32bit word. Please note that for DPX method B is more common (as far as I know), so 30bits+2 dummy bits.

You can also generate (decode) r210/R10K with ffmpeg/ffplay:

ffmpeg -i "source" -c:v r210 ( or r10k) -an "output.mov"

or

ffmpeg -i "source" -c:v r210 ( or r10k) -an -f image2 "test_%04d.raw"

to get raw (r210/r10k) data as image sequence.


I'm not that familiar with programming, so you would have to send compiled version, so I can try.

[umezawa_takeshi]

What about vendor? Do you use anything specific?


The vendor type (such as 'appl' for Apple, 'gvkk' for GrassValley)?
I use 'Umzw' as vendor type. Of course, it stands for my name.


I'm not that familiar with programming, so you would have to send compiled version, so I can try.


All right. After all, I cannot make UQRG/UQRA compatible with Pr/AE at this rate, so I will release current snapshot as next version (16.0.0) on the weekend.

[kolak]

Umzw still doesn't help. It has to be something in the codec module.

[umezawa_takeshi]

oh, then I don't know what you call 'vendor'

[kolak]

I think it's the same thing as you think. I just said that specifying it doesn't help :( It has to be something else.

[umezawa_takeshi]

Version 16.0.0 (http://umezawa.dyndns.info/wordpress/?p=5903) is released.

New features

Add codecs whose internal formats are RGB 10bit and RGBA 10bit. (FourCC: UQRG, UQRA). Very slow.

Bug fixes

DMO codecs suggested output formats for some unsupported input formats.
VCM/DMO codecs did not suggest raw formats that should be supported.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-16.0.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-16.0.0-win.exe) Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-16.0.0-macosx.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-16.0.0-src.zip)

[shekh]

I have added b64a support to vdub, UQRG/UQRA VCM codecs work as expected.

[kolak]

Edius 8 doesn't export/import codec at 10bit.
Not sure if it's just import, but files don't carry real 10bit data.

During MagicYUV development we established that Edius doesn't attempt to ask on import for higher bit depths pixel formats for any 3rd party codecs except ProRes (which is done over r4fl pixel format). On the export side Edius will pass 10bit to MOV exporter, but only over v210 format.

Simple test:
Create Colo Matte in Edius with 2 colors (black and white), so you get gradient (or better create v210 MOV gradient in AE). Export it to eg. v210 AVI and your codec. Import both files back, add heavy YUV curve and compare both files. You will see that v210 stays smooth were other file shows clear banding.

Do you support fall-back 8bit ARGB pixel format also or strictly b64a only on input/output?
It's also possible that QT engine is internally converting b64a to RGB 8bit and than Edius reads this, which is of course not any more 10bit data. It did not happen for v210 on PC, but it may happen for b64a depending if Apple added b64a->ARGB conversion.

Test done in latest Edius 8.2.

[umezawa_takeshi]

hmm... According to my test result just now, EDIUS Pro 8 (version 8.11.94) passes 10bit data to my codec via b64a. Testing method is same as that of yours... exporting/importing monochrome color matte. Is video quantization bits(*) of your testing project set to 10bits?

(*) I don't know that how this parameter has been translated into English.

Do you support fall-back 8bit ARGB pixel format also or strictly b64a only on input/output?

UQRA/UQRG/UQY2 SHOULD reject 8bit format in order to avoid accidental color conversion. If editing software does not support 10bit+ format, we SHOULD use 8bit codecs... ULRA etc.

[Ignus2]

My bit of experience here:
Don't take anything as is from QuickTime. Neither the app, nor the codec has full control over what (horrible things) are happening inside QT. Getting b64a (or especially b48r) doesn't mean by far that Edius really gives deep color data to compress.
All too often I saw apps giving 8 bit data and QuickTime silently converting to 16-bit for my codec to be happy. You can only be sure if you do extensive checks with smooth gradients and look at the numbers.
The reverse is probably even more common: your codec decodes b64a, QT dithers silently to 8-bit (!), then the app converts again to 16-bit for whatever reason. All looks dandy until you actually look closely at the mess this results in.

The only apps I could get 10bit+ working reliably was Adobe AE, BM Fusion and Assimilate Scratch. Edius had various funny problems and I decided to forget about it.
AE and Scratch needed additional config file tweaks to work, Fusion worked as-is.
I also looked at Sony Vegas, but their generic QT interface doesn't support 16-bit depth at all.

The no.1 reason why 10+ bit MagicYUV is not released in general is exactly this horrible mess what QT is. Even if it seems to work technically, you can all too easily fall into some dithering or similar nasty traps.

Greets,
I.

[kolak]

hmm... According to my test result just now, EDIUS Pro 8 (version 8.11.94) passes 10bit data to my codec via b64a. Testing method is same as that of yours... exporting/importing monochrome color matte. Is video quantization bits(*) of your testing project set to 10bits?

(*) I don't know that how this parameter has been translated into English.



UQRA/UQRG/UQY2 SHOULD reject 8bit format in order to avoid accidental color conversion. If editing software does not support 10bit+ format, we SHOULD use 8bit codecs... ULRA etc.

It was 10bit project with Alpha.
In the same project ProRes (over Miraizon plugin) works fine- smooth gradient. Utvideo was clearly banding.
Always add crazy YUV curve to force data to be "shrank", as it's way easier to judge. QT quite often also adds dithering (low quality dithering)!

QT probably does internal conversion to 8bit.
Foundry Nuke (you can get trial version) is another good tool for tests, as it reads supported pixel formats from the codec and allows you to choose from them.
I'm still not sure why Adobe apps don't work with UTvideo over 8bit+.

[umezawa_takeshi]

Getting b64a (or especially b48r) doesn't mean by far that Edius really gives deep color data to compress.

Of course I know. I saw passed data, and the data have smooth 10bit gradient.

And then, I have additional test on EDIUS Pro 8.

The reverse is probably even more common: your codec decodes b64a, QT dithers silently to 8-bit (!), then the app converts again to 16-bit for whatever reason. All looks dandy until you actually look closely at the mess this results in.

Probably this!
First, export color matte with UQRA. this data have smooth 10bit gradient.
Next, place output mov file on timeline(*1) and remove color matte. UQRA passes smooth 10bit gradient to EDIUS, of course.
Then, export it again... this data passed to codec have only 8bit gradient (via b64a). Oh, god.

I add YUV curve to *1 file on the timeline (like kolak did), I see obvious banding.

---

by the way, I probably succeeded to let Pr/AE pass "trillions of colors" data to UQRA. I will do more detailed tests.

[kolak]

Yes, on import side in Edius everything 3rd party, except ProRes (also some DNxHD modes) is 8bit.

On export MOV side- if codec supports v210 pixel format than it should work, so UTvideo 10bit YUV should export properly at 10bit.
If you make Adobe working than we can verify this by importing to AE.

[poisondeathray]

And on the import side , for 8bit, if either AVI decompresses as "UYVY", or MOV decompresses as "2vuy", then 8bit YUV 4:2:2 (either "uly2", or "ulh2") should get treated as YUV instead of RGB in Adobe

[GMJCZP]

I obtain a error Message to try install the last version:

C:\...\utv_dmo.dll
Unable to register the DLL/OCX: RegSvr32 failed with exit code 0x5
Click Retry to try again, Ignore to proceed anyway (not recommended), or Abort to cancel installation.

With the version 15.5 I have not problems. My OS is W XP SP3

[kolak]

Uninstall old version and install new one. Make sure codec is not in use, by some software.

[GMJCZP]

I tested all posibilities, and nothing. Seems a incompatibility with W Xp SP3 and a new type of building of the software.

[Groucho2004]

Seems a incompatibility with W Xp SP3 and a new type of building of the software.
Indeed:
http://s32.postimg.org/yxldtbflx/Image1.png

OS version has to be at least NT6.0 (Vista/Server 2008). The developer switched to VS2015 for UTVideo v16 and the problem with XP is most likely the same as the one described here (http://forum.doom9.org/showthread.php?p=1763240#post1763240).

Edit: Just checked the previous versions of utv*.dll, they also state 6.0 as OS Version. According to Microsoft, this is the minimum required OS version for a given PE image. Yet, it loads and functions on XP (5.1). I'll have to do some research on that oddity.

Anyway, it seems that the move to VS2015 and the XP compatibility switches are the reason it won't work on XP.

[GMJCZP]

Thank you, Groucho2004.
I stand with the version 15.5, for now.

[Rush_iam]

Why I get wrong colors?

Cases:
1) NLE -> Ut RGB -> OK .avi colors in VDub/VLC -> OK .mp4 colors after MeGui conversion
2) NLE -> Ut YUV420 BT.601 -> OK .avi colors in VDub/VLC -> OK .avs colors in VDub -> NOT-OK (EDIT: checked again - it's ok) .mp4 colors after MeGui conversion
3) NLE -> Ut YUV420 BT.709 -> OK .avi colors in VDub -> NOT-OK .avs colors in VDub -> NOT-OK .mp4 colors after MeGui conversion

NOT-OK = blue sky became slightly greener/darker, skintones shifts slightly to magenta.

Can anybody help? Thanks!

[LigH]

Without additional parameters, x264 will probably assume ITU-R BT.601 color matrix for SD resolutions and BT.709 for HD resolutions. You may have to add colorimetry parameters to the custom command line to enforce the encoder storing the matching information in the encoded video stream.

There may be a similar issue when you check colors of an AviSynth script output, it may depend on the displaying application which colorimetry it assumes to be used (it can't know from the raw YUV output which matrix to use for displaying the video on an RGB monitor, it may possibly use a similar resolution threshold to decide).

[Rush_iam]

LigH, thanks. Tried that but it don't changes anything...
Now I got new tests and results are very confusing!

Here is table:
Format: .AVI in VDub |.AVI in WMP|.AVS AVI | .MP4 in WMP/MPC | .MP4 in VLC | Vimeo Opera/Chrome | Vimeo IE | Vimeo Thumbnail in any browser
Ut RGB: OK | OK | OK | Warm | OK | OK | Warm | Warm
Ut 601: OK | OK | OK | Warm | OK | OK | Warm | Warm
Ut 709: OK | Magenta | Magenta | OK | Magenta | Magenta | OK | OK

Workflow:
NLE Sony Vegas to .AVI -> .AVS file for that AVI (AviSource()) -> Coded with MeGUI to x264 MP4 -> Uploaded to Vimeo
Tried to replace .AVS+MeGui steps with HandBrake - same results.

WMP = Windows Media Player in Win8.1
MPC = Media Player Classic
Warm = Skintones became warmer
Magenta = Skintones became more magenta
Opera 36, IE 11, Chrome 50
All video/player settings are default, footage is 1920x1080.

I am sure that all messing with colors are related to wrong BT.601 or BT.709 decoding.
If I add "BT.601 to BT.709" shader in MPC - it makes colors more warmer (OK skintones became warm, and wrong warm skintones became even warmer).
Is there any fix for diplaying it correctly? May it be related to my video card, or something else?

... and it seems not completely related with UT video... sorry... seems like all my videos have different color in different players...

although - Ut 709 .AVI differs when playing back in WMP (or trancoding, except VDub) from RGB and 601 (which are same-looking)...
In VDub all three formats in .AVI are same looking (and transcoding keeps them same looking)
Comparing to Lagarith - Lagarith keeps his YV12 and RGB formats same in VDub/WMP, slightly more magenta in VLC and after converting to .mp4 in VLC keeps same slight magenta (all else same as RGB/BT.601 of Ut).

so... BT.709 codec in Ut Video have "bug"?