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

[Chikuzen]

@_gl
I recommend you to test high compression mode instead of fast decode mode.
In my experience, fast decode mode slows more than High compression mode because the speed of HDD be a bottleneck when the resolution is larger than QCIF (176x144) :eek:
For uly0 of 720p, my Q9450 machine can be encoded/decoded with 72fps/148fps on high compression mode.
however, on fast decode mode, the speeds are down to 67fps/138fps.

[_gl]

I recommend you to test high compression mode instead of fast decode mode.
In my experience, fast decode mode slows more than High compression mode because the speed of HDD be a bottleneck when the resolution is larger than QCIF (176x144) :eek:
For uly0 of 720p, my Q9450 machine can be encoded/decoded with 72fps/148fps on high compression mode.
however, on fast decode mode, the speeds are down to 67fps/138fps.

Thanks for the tips Chikuzen, I will spend more time with UT for sure. However I'm currently most interested in real-time lossless 1080p playback, so CPU usage is my biggest concern.

[johnsonlam]

version 8.5.0
Performance Improvements
*common: Speed up decoding (x86) about 10%.
*common: Speed up decoding (x64). Almost fast as x86 version.

Thank you very much for the improvement!

subarashi! hondo ni arigato gozaimasu!

[yup]

:thanks: to author!
This only one lossless codec which can play at realtime on my EEEPC netbook (SD source 720x576 25fps). I try before Huffyuv, multithreaded huffyuv, Lagarith. Only Ut can play at realtime AVI file. Very good optimized code it is main reason I think.
yup.

[GoodzMastaJ]

Thanks for this codec, the speed improvements over Lags and even Huffyuv are amazing.
One thing I have noticed is that ULRA files compress incredibly well with ZIP or RAR. For example, a simple overlay I pre-rendered from After Effects with either predict-left or predict-median came out to 10.4MB (static image approx 5 second, 24fps, 848x480 clip).
Adding the output file to a rar with default settings dropped that to 192KB and a zip with default settings came out to 2MB. Could some simple compression algorithm like this be applied directly to the output file?

This goes towards the goal of improving compression compared to Lagarith, but it would work against the goal of being faster than Huffyuv so perhaps the additional compression could be applied only when the user selects the better compressing predict-median. I suspect this is only useful with RGBA clips clips with large blank areas, YV12 would not be so lucky.

[nm]

One thing I have noticed is that ULRA files compress incredibly well with ZIP or RAR. For example, a simple overlay I pre-rendered from After Effects with either predict-left or predict-median came out to 10.4MB (static image approx 5 second, 24fps, 848x480 clip).

[...]

I suspect this is only useful with RGBA clips clips with large blank areas, YV12 would not be so lucky.

It's only useful with sequences of static images since Ut is an intraframe codec (it doesn't compress temporally across frames).

Lossless H.264 encoded with x264 is a good option if you want interframe encoding. Encoding and decoding is multithreaded, so it can also be pretty fast. But x264 only supports YV12 for now.

[kypec]

You can find my short performance tests of this codec against Lossless x264 mode in this thread (http://forum.doom9.org/showthread.php?t=158361).

[jmac698]

I thought UTVideo was great for real-time capture on a low end machine. I did a big comparison here:
http://forum.doom9.org/showthread.php?t=158420

[ChiDragon]

version 8.3.0

[...]

others
* ULY2: Abolition of support to I/O of YVYU and VYUY.
* ULY0: Abolition of support to I/O of YVYU and VYUY.

Hi, first off thank you guys so much for this codec! It's extremely useful for realtime lossless 720p/1080i to one drive instead of RAID0.

Is there any chance of getting support for YVYU added back in the new versions? For some reason my card's Overlay only works in YVYU mode when capturing at 480p and I think 480i.

[Chikuzen]

Is there any chance of getting support for YVYU added back in the new versions?

The reason to discontinue the support of YVYU/VYUY is without the environment that the author can verify. (Up to now, the confirmation concerning it had not been done at all:eek:)

I asked him, and he said that there is no schedule to restart because he can't debug.

[zcream]

@Chikuzen san

I found a mention on this thread about UT Video 422
http://www.dvxuser.com/V6/showthread.php?237584-HDMI-Capture-Problem-SOLVED-AviSynth-RULES!

>>
You also must record to a 4.2.2 codec. The script will not work well if you record to a 4.2.0 codec.
The following codecs have been successfully tested: UT 422 codec, Cineform, Blackmagic MJPEG codec.
>>

Can I confirm
a. UT 422 lossless takes care of the color shift issues with the HDYC output by Blackmagic Intensity ?
b. UT 422 is cross platform (at least for Mac and Win)

Thanks!

[zcream]

Also, any chance of ut video on Mac ? Maybe only a decoder to begin with ?

[JeffBDVS]

When I encode to UT and select the ULY2 codec, MediaInfo reports that the encoded file has 4:2:0 chroma subsampling instead of the expected 4:2:2.

But when I encode to UT and select the ULY0 codec, MediaInfo reports that the encoded file has 4:2:2 chroma subsampling, yet 4:2:0 is expected.

Are things mixed up in UT, or is MediaInfo wrong?

Additional Question: Is it still true that ULY0 does not support interlaced video as of version 8.5.0?

Thank you,
-Jeff

[Boolsheet]

MediaInfo assumes a lot of things and it's very possible that it displays something wrong.

The UT Video is completely lossless if the applications support the color spaces and correclty ask for it. What goes in comes out. I don't understand what you mean with it not supporting interlaced video.

[JeffBDVS]

I don't understand what you mean with it not supporting interlaced video.
At Codecs.com, which is the first hit you get with Bing when you search for "ut video codec", there is a long description of the codec and its abilities. Here is the text that concerned me:

ULY0(YUV420) doesn't support interlaced videos. So, in converting RGB into YUV420, it always converts mistaking the video as it's progressive.

I just want to make sure that issue is fixed in 8.5.0.

As for the other stuff, it's possible MediaInfo is wrong, but I think it's worth double-checking ULY2 output versus ULY0 output.

Thanks,
-Jeff

[kolak]

There is setting to tell for codec that source is interlaced and I assume it should be ticked for such a source.
I don't have any issues with all source- it works great.

Andrew

[Chikuzen]

@zcream
The author talked as follows.
Current version of ULY2/ULY0 doesn't especially have problems because they compresses it as is when input is YUV.
If you want to preview captured video in the same color as the original, you only have to convert YUV to RGB by BT.709 with the DirectShowFilter such as ffdshow, Haali renderer or something.
It is also easy to mount the mode that convert RGB-YUV with BT.709 like HDYC, however, it means FourCC increases from four(ULRA, ULRG, ULY2, ULY0) current states further.
This has the possibility of causing confusion to the users (especially newbies).
Thus I have not done anything up to now.
But, if there are some of requests, i might to do it.

I have no schedule to port UtVideo to other platforms at present.
My present concern is improvement of the compressibility and support high bit depth.
a lot of time is necessary for those investigation and preparation.
Especially, correspondence to QuickTime is impossible because I don't have Mac.
(and, I don't have a good impression for the recent Steve Jobs's remark about Flash. )


@JeffBDVS
ULY0 has supported interlaced video from version 6.0.
If input is interlaced YUV420, ULY0 compresses it as lossless.

[Boolsheet]

ULY0(YUV420) doesn't support interlaced videos. So, in converting RGB into YUV420, it always converts mistaking the video as it's progressive.
Ah, looks like that was some weird bug in the internal color space conversion. It is fixed as mentioned by Chikuzen.

The subsampling error is indeed a mistake in the MedaInfo source and is already fixed (http://mediainfo.svn.sourceforge.net/viewvc/mediainfo?view=revision&revision=3789).


Oh wow, he's going for high bit depth? This is the best codec ever! ;)

[Chikuzen]

oops :eek:, please wait.

Author is interested in high bit depth, but PRIORITY IS CONSIDERABLY LOW.
Softwares that can treat High bit depth is large amount of money, he doesn't have testing environment.
If some trial version is used, it is likely to be able to write it.
but it will not be released because he can't do a continuous support :(

[JeffBDVS]

@Boolsheet:
Thanks for confirming the bug in MediaInfo and its fix. It took me a little while, but I reached the same conclusion by comparing the file sizes of the ULY0 and ULY2 files (doh!). :)

@Chikuzen:
Thank you for the clarification about UT supporting interlaced video. Maybe the author can get Codecs.com to update their description of the codec? I refer people to that site often as an easy way to get the latest version of UT.

@Andrew:
Thanks for letting me know about your success with UT.

-Jeff

[Chikuzen]

@Chikuzen:
Maybe the author can get Codecs.com to update their description of the codec? I refer people to that site often as an easy way to get the latest version of UT.
sorry I'm lazy, and I don't use codecs.com.
I think that you should do it yourself if you encourage your friends to go there.

[kolak]

codecs.com - codes descriptions on this site are way not accurate and misleading. Never heard of this site before.


Andrew

[JeffBDVS]

sorry I'm lazy, and I don't use codecs.com.
I think that you should do it yourself if you encourage your friends to go there.
I don't even know if they'd accept input from someone other than the author. It's not that important to me, but I mentioned it because I thought an accurate description might be important to UT's author.

-Jeff

[JeffBDVS]

I may have found a bug in how interlaced ULY0 video is decoded. Using Sorenson Squeeze 7 to encode an interlaced 720x480 ULY0 AVI to 320x240 deinterlaced MPEG4. Encoding times for a ULY0 source file are significantly longer than the time required for interlaced ULY2 or ULRG source files. The source video is 20 mins and 46 secs long. All times displayed as mins:secs.

Interlaced ULY2 time to encode: 15:53
Interlaced RGB time to encode: 18:21
Interlaced ULY0 time to encode: 32:59

Progressive ULY2 time to encode: 12:29
Progressive ULY0 time to encode: 12:18

All interlaced UT source files had the "Assume Interlaced Video" checkbox checked when they were exported from Premiere Pro CS5. These results are repeatable over multiple test runs.

-Jeff

EDIT: By way of comparison:
Interlaced Lagarith YV12 source to progressive MPEG4: 16:45
Interlaced Lagarith YUY2 source to progressive MPEG4: 15:59
Interlaced Lagarith RGB source to progressive MPEG4: 15:45

I believe the Lagarith results eliminate Squeeze as the source of the issue.

[Boolsheet]

Interesting. I can't confirm it though.
My system is able to decode 640x480 or 1920x1080 ULY0 streams at the same speed regardless if the interlaced optimization is activated or not.
I tested it in VirtualDub, but there might be still something wrong with Squeeze.

I believe the Lagarith results eliminate Squeeze as the source of the issue.
That probably just means Lagarith handles things differently. We don't know how many color space conversions take place between UT and Squeeze.

Going there, I have to ask if Premiere Pro CS5 now supports YUV and are you using it? If not, why not stay in RGB? It gets bigger of course, but it's a easy way to avoid the conversion mess until the last encoding step.

[JeffBDVS]

Going there, I have to ask if Premiere Pro CS5 now supports YUV and are you using it? If not, why not stay in RGB? It gets bigger of course, but it's a easy way to avoid the conversion mess until the last encoding step.
Pr CS5 does support YUV as long as you don't add any effects or filters that are RGB-only. As a practical matter, I do adjust my exports based on timeline content. For testing, it's instructive to see how each pipeline performs using the same sequence as the source.

I don't think it's reasonable to expect such huge time differences based on color space conversions alone. But I'm willing to listen if others have evidence to the contrary.

-Jeff

[Boolsheet]

I don't think it's reasonable to expect such huge time differences based on color space conversions alone.
You're right. The converisons should not slow it down this much.
I'll try to test it with Squeeze later.

Edit: Actually... it's possible, but unlikley.

[JeffBDVS]

More testing/troubleshooting:

I fed x264 a ULY0 AVI file via AviSynth and MeGUI. I also tried a ULY2 AVI file through the same pipeline.

This time, ULY0 was noticeably faster. That's an expected result since MeGUI requires YV12 video. The ULY2 AVI file had to have its color space converted.

At this point, because I got good and expected results from ULY0 using a different encoding pipeline, I have to assume that UT is OK and that the speed bottleneck lies somewhere else.

So maybe it's down to the MainConcept H.264 encoder that Squeeze uses. Pr also uses MainConcept, so I'll test render times there to see if I can reproduce the issue.

-Jeff

[kolak]

If you search doom9 you will find tests for UT Video codec itself.
It's more than fine- speed is simply amazing if used properly.


Andrew

[Mr_Khyron]

version 8.5.1

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.1-readme.en.html ) / installer (32bit (http://umezawa.dyndns.info/archive/utvideo/ utvideo-8.5.1-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.1-x64.msi)) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.1-src.zip)

Bux fixes

ULY2: Encoder may crushes and/or video may be broken when encoded from RGB (x64)

Others

Extract VCM interface from utvideo.dll, into utv_vcm.dll.

[Chikuzen]

version 8.5.2

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.2-readme.en.html) / installer (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.2-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.2-x64.msi)) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-8.5.2-src.zip)

Bug fixes
* Codec cannot be used via VCM interface because utv_vcm.dll is installed to wrong directory.

[Fullmetal Encoder]

I'm glad the confusion with the color spaces was brought up recently. I too have experienced a lot of confusion over this. My UT Codec encodes still show an output of RBG32 which bothers me but I don't quite understand it. When playing a file the decoder FFDShow and a renderer are all in the chain and each one can request and/or implement their own color space conversion(s) behind the scenes. I have no idea how to see through that and prevent/control it. I can only hope that when I feed the UT Codec encoded video to x264 via Avisynth that it's going through in YV12 since that's how it originally started out. Right now I am experimenting with avs2avi 64-bit as I'm trying to get away from VirtualDub.

Does anyone know of a way to determine with certainty the color space of a video by directly looking at the video data instead of consulting a database the way MediaInfo does?

Chikuzen: Please relay my sympathies to Umezawa Takeshi for what has been happening to Japan after this recent horrible earthquake. I can only hope that neither he nor you have lost any loved ones in the devastation. And please thank him for his continued support of this great codec.

[Mr_Khyron]

version 9.0.0

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.0-readme.en.html) / installer (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.0-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.0-x64.msi)) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.0-src.zip)

New features
- Add DMO decoder.

[kypec]

version 9.0.0
New features
- Add DMO decoder.
Ehm, what exactly does it mean for Windows 7 users like me? :stupid:

[Chikuzen]

Ehm, what exactly does it mean for Windows 7 users like me? :stupid:

In the case to use DirectShow, it becomes possible to do various operations.

e.g.
* you will be able to use ffdshow raw video filter to convert YUV to RGB.
　(it has crashed when this is tried before 9.0.0)
* It came to be able to decode with YUY2/YV12 in avisynth's DirectShowSource.
　(it was able to choose only RGB32)

[yup]

Hi All!
please advice why not work simple code?
DirectShowSource("tape1.avi", pixel_type="YUY2")
tape1.avi YUY2 colorspace. I am using 9.00 version Ut codec.
yup.

[kypec]

@Chikuzen: Thanks for explanation. I'm not using ffdshow nor DirectShowSource() so I don't plan to upgrade UtVideo.
@yup: Have you tried AVISource() instead? I've no experience with other colour spaces than YV12 but simple AVISource("myfile.avi") has always worked for me without any problems and I'm using UtVideo version 8.5.0

[yup]

@kypec I could use DirectShowSource because I use MT Avisynth build, AVISource do not work properly.
yup.

[kypec]

AFAIK no source filters in Avisynth should be used in MT mode, it's a general recommendation of Dideé and other experienced members of this forum.
I don't understand why AVISource() wouldn't work for you whereas DSS() does :(

[Chikuzen]

Hi All!
please advice why not work simple code?
DirectShowSource("tape1.avi", pixel_type="YUY2")
tape1.avi YUY2 colorspace. I am using 9.00 version Ut codec.
yup.

Which AVI Splitter are you using?
If it's not Microsoft's one(e.g. LAV Splitter), then disable it.

[yup]

@Chikuzen
How I can known which splitter I am using during call DirectShowSource? I have installed ffdshow and matroska.
@kypec
With AVISource I periodically get bad frames with green block.
yup.

[Chikuzen]

@Chikuzen
How I can known which splitter I am using during call DirectShowSource? I have installed ffdshow and matroska.

GraphEdit

[yup]

@Chikuzen
I see only AVI Splitter.
Changing to RGB work without problem, but I am need YUY2.
yup.

[Chikuzen]

@Chikuzen
I see only AVI Splitter.
Changing to RGB work without problem, but I am need YUY2.
yup.
Are you using ULY2?
Don't you use other codecs(ULY0,ULRA or ULRG)?
If avi splitter is not a cause, I hit on only it.
Because I can use DirectShowSource without any problem.
http://i55.tinypic.com/24d3dvl.png

[yup]

@Chikuzen!
Your version Avisynth?
I am now using SEt 2.6 build.
I try clear setup at other PC all work, probably problem at my work horse.
yup.

[Chikuzen]

@Chikuzen!
Your version Avisynth?

I'm using avisynth2.60alpha JEEB's VS2010 build (http://forum.doom9.org/showpost.php?p=1474204&postcount=134) now.
I completely stopped it several months ago though I also had used avisynthMT.

[yup]

@Chikuzen
Under Win7 work all release 2.58 and 2.6 for Win XP need update DirectShowsource.dll 27.01.2010.
yup.

[3ds]

A short test by me (300 Frames CGI sequence in 1080p):

Lagarith in YV21 mode -> 201MB
Ut YUV420 with "decoding speed" -> 210MB
Ut YUV420 with "compression ratio" -> 213MB

normal?

[Chikuzen]

normal?

There is a possibility though it is a special case.

[3ds]

There is a possibility though it is a special case.
OK, than should Ut generally better compress than Lagarith?

I made a new test with a other 1080p sequence:

in RGB:
Lagarith - 518MB
Ut - 517MB

in YUV (same sequence as in RGB):
Lagarith - YV12 - 223MB
Ut - YUV420 - 234MB