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

[tobinaka]

The following was edited last on 16th November 2009 at 23:16.
To find the latest info, please check newer posts or the author's blog.

----

Ut Video Codec Suite is a new free-software lossless video codec for Windows which Takeshi UMEZAWA has developed. It's implemented as a VCM codec (also called "VfW codec"). It can currently encode YUV422 and RGB sources.

You can encode YUV420 but it's just-released and needs to be tested more. YUV420 might NOT have the compatibility with another version. But I can say its decompression (decoding) speed (especially on maltithreading) is very good, better even than Huffyuv maltithreaded version.


Then you should use Ut Video YUV420 to encode with x264. For example,

-make AviSynth scripts to imput and edit a video file (with ConvertToYV12),
-save the file at VirtualDubMod with Ut Video Codec YUV420(ULY0) on the setting of your numbers of CPU cores and "predict left" for decode preference ("predict median" is for compression-ratio preference),
-make x264 imput the video by "AviSource" of a new AviSynth scripts.


Known Problem (Reported Bugs. Please advise us if you know how to fix them!)

-EDIUS crashes or hangs up when the videos are put on the timelines or the video on the timeline goes to be played.
-ULY0(YUV420) doesn't support interlaced videos. So, in converting RGB into YUV420, it always converts mistaking the video as it's progressive.
-NOTE: UtVideo supports interlaced images from ver 6.0.0.

Attention

Takeshi, the developer, has only INTEL Conroe-based processer, then he can't test on AMD (especially Athlon and Turion), Core i7 and so on. I would seem that Ut Video Codec's performance depends on the CPU architectures. For example, known so far, Ut Video Codecs Suite mainly use SSE2, then Ut Video can't exercise the ability with such CPUs which aren't good at SSE2 as Athlon64 and P2/P3.

Not only the test results, but also the optimizations for the other CPUs are needed. If you can, please post the patches. Of course, the testing reports with the CPU name are welcome!


Its Implementation Goal (from readme file)

-Realtime high definition capture with Core 2 Duo class CPU
-Better compression ratio than Huffyuv
-Near compression ratio as Lagarith, if possible


Achievement (from readme file)

-Enough speed for realtime high definition capture because of multithreading and assembly language.
-Usually better compression ratio than Huffyuv (Predict median) for progressive sources.
-May worse compression ratio than Huffyuv for interlace sources whose height is greater than 288 pixels.
-Usually worse compression ratio than Lagarith, but rarely better.


Minimum Requirement (from readme file)

-OS: Windows XP or later
-CPU: i686-compatible CPU with SSE2 support (e.g. Pentium 4 or later)



Download

-readme (English)
-x86 installer (.msi)
-x64 installer (.msi)
-source code (zipped)


I'm not its developer but I can contact with him easily. Give me your comments, ideas, patches and bug reports. Thanks!

[squid_80]

I did some quick tests with YV12, here's some short comments:
- compression speed seems a little bit slower than huffyuv
- compression ratio is about the same as adaptive huffyuv
- For the tests I did it was indeed 100% lossless (just checking )
- Something you didn't mention but I would definitely be drawing attention to, decompression speed is a MASSIVE improvement compared to huffyuv. For example the figures I saw were ~70fps (huffyuv) vs. ~360fps (Ut). The multithreading obviously makes a big difference here.

[tobinaka]

Thank you squid_80 for your testing and comment! I'll tell it to him soon and add some notion on my privious post.

aquid_80, I have a question for you. What CPU did you use for the test? I must have noted that the developer UMEZAWA has only INTEL Conroe-based processer, then he can't test on AMD (especially Athlon and Turion), Core i7 and so on. I would seem that Ut Video Codec's performance depends on the CPU architectures.


Not only the test results, but also the optimizations for the other CPUs are needed. If you can, please post the patches. Of course, the testing reports are welcome!


For reference, I show here the codec comparing test results by UMEZAWA the Ut Video Codec developer. I don't know how to make tables on this forum then I got the screen shots from his blog.

His test enviloment

-CPU : Intel Core 2 Quad Q6600 @2.4GHz G0-stepping rated operating
-motherboard : ASUS P5K (Intel P35 + ICH9DH)
-RAM : DDR2-800 1GBx4 (CL 5-5-5-15)
-OS : Microsoft Windows XP SP3

Codecs

-Ut Video Codec Suite 4.0.2 (not 5.1.0 of today. 4.0.2 didn't have YUV420 mode)
-Huffyuv 2.1.1
-Huffyuv_mt >>712
-YUY2 Lossless Codec (YLC) 0.25
-Lagarith 1.3.16
-FastCodec 1.0beta
-Arithyuv 1.1.1
-MSU Lossless Video Codec 0.6.0

YLC is a YUY2 Lossless Codec (requires SSE) developed by KEN-kun a Japanese programmer who has made AviUtl. You can download YLC from his site (Japanese).

The results

-Armored Core 4 Opening he captured 720p YUV422 8bit (the 29th June 2008)


-live-aciton video in HD(1080i : interlaced)　(the 14th July 2008)


-HD video above but de-intelaced (1080p : progressive) (the 14th July 2008)



The development of Ut Video YV12 has just begun. He said on his Japanese blog that he enabled at 5.1.0 to encode on YV12 from RGB24 imput and to decode YV12 into RGB24 output. Your test result is good as the first step for the newborn, isn't it?

[Lugia25000]

Hm when i go in the Folder with the Encode, WinXP Sp3 Crashed.

But the codec is very good, Faster as Lagarith and huffyuv with my Dual Core.

Thanks.

[TEB]

Interesting Please ask him if he'll compile a x64 version (if he can get hold of a 64bit proc tho )

[video_magic]

Very, very interesting for me.

Thankyou very much to your friend for the work on his lossless codec.

I am mainly trying to capture both as small and as fast as possible on a BT878a conexant/fusion PCI capture board.

I currently use the arithyuv codec in YUY2, and then have to convert to YV12 in my avisynth script (encoding to x264); I would rather be able to capture straight to YV12 - smaller capture files and no 'converttoyv12' in my avisynth script - but my 3.2ghz based system appears to be crap and only able to capturw with best results at the moment with arithyuv to YUY2.

Please god, a YV12 lower-CPU capture codec would be fantastic - thankyou! Hyper-threading P4 enhancements would be nice.

[tobinaka]

Originally Posted by Lugia25000

Hm when i go in the Folder with the Encode, WinXP Sp3 Crashed.

Wmm, I've an experience like that. At that time, the folder was on thumbnails shown mode. It may have a problem when WinXP gets the theumbnails of videos. I'll tell it to him. Thanks!

Originally Posted by TEB

Interesting Please ask him if he'll compile a x64 version (if he can get hold of a 64bit proc tho )

x64 version... I'll ask him, but please don't expect a good answer. I think it's much faster to get a good result that you ask the other on the forum to develop x64 version of this codec because the source code is available.

Please give me here your reports, ideas or patches for improvement if you can. UMEZAWA the developer said on his blog that he can't optimize it for the other CPU than Intel Core series he has and that he felt short on ideas to improve it.

Your comments must drive him to improve the codec suite!

[LoRd_MuldeR]

Originally Posted by tobinaka

Wmm, I've an experience like that. At that time, the folder was on thumbnails shown mode. It may have a problem when WinXP gets the theumbnails of videos. I'll tell it to him. Thanks!

Video thumbnails in Explorer tend to cause trouble and drastically decrease performance

But there is an easy way to turn that "feature" off:
regsvr32.exe /u shmedia.dll

[squid_80]

Originally Posted by tobinaka

squid_80, I have a question for you. What CPU did you use for the test? I must have noted that the developer UMEZAWA has only INTEL Conroe-based processer, then he can't test on AMD (especially Athlon and Turion), Core i7 and so on. I would seem that Ut Video Codec's performance depends on the CPU architectures.

I was testing on a Core2 Q6600@2.4GHz B0 stepping, 8GB ram, windows XP64. I have another box with a Core2 E6600 but no AMD based machines. The codec seems to mainly use SSE2 assembly, I know Athlon64's perform very poorly with SSE2 but don't know about Phenoms since I've never had one. Penryn and i7s normally get a big boost with lossless codecs (prediction+entropy based) since they love big data caches.

Since it's GPL, I'd be happy to compile a x64 version when the author considers it to be stable enough.

[tobinaka]

Originally Posted by video_magic

Please god, a YV12 lower-CPU capture codec would be fantastic - thankyou! Hyper-threading P4 enhancements would be nice.

Yes, I'll tell him. But I don't know if he thinks of the lower-CPU performance...

Originally Posted by LoRd_MuldeR

Video thumbnails in Explorer tend to cause trouble and drastically decrease performance

But there is an easy way to turn that "feature" off:
regsvr32.exe /u shmedia.dll

Thanks for your advise. I don't like the video thumbnails showing function of Explorer, and always cut it when I use nLite to re-install WinXP. But sometimes it appears and annoys me. I'll try your approach.

By the way, LoRd_MuldeR, I'd like to express my gratitude to MPlayer for Windows which I use to estimate the decoding speed of MP4 with various x264 options used. Thanks!

Originally Posted by squid_80

The codec seems to mainly use SSE2 assembly, I know Athlon64's perform very poorly with SSE2 but don't know about Phenoms since I've never had one. Penryn and i7s normally get a big boost with lossless codecs (prediction+entropy based) since they love big data caches.

Oh, yeah, that should be the reason. I'll tell it to him to think about the extention sets of CPUs.

Originally Posted by squid_80

Since it's GPL, I'd be happy to compile a x64 version when the author considers it to be stable enough.

Great! When the time is right, please. I'll announce here whenever the next version is released. Come back again!

[tobinaka]

I told UMEZAWA, Ut Video developer, about the comments here. He can read the posts in English, then please keep it coming!

Originally Posted by Lugia25000

Hm when i go in the Folder with the Encode, WinXP Sp3 Crashed.

Both UMEZAWA and me can reproduce the crash. He said the bug that Edius crashes when a video encoded by Ut video is on timeline was reported. They may be from the same reason. I searched the web for "thumbnail(s) crash explorer(.exe)" and found many reports like it, but I can't find yet how to fix it on the source code. If you know, tell us please. It should be fixed on the developer's side as well as video thumbnails are made disabled on the users' side.

Originally Posted by squid_80

Since it's GPL, I'd be happy to compile a x64 version when the author considers it to be stable enough.

UMEZAWA is concerned that it will be all C++ on x64 version compiling with doing nothing special. It's OK?


UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )

We look forward to your continued support. Thanks!

[Lugia25000]

Originally Posted by tobinaka

Both UMEZAWA and me can reproduce the crash. He said the bug that Edius crashes when a video encoded by Ut video is on timeline was reported. They may be from the same reason. I searched the web for "thumbnail(s) crash explorer(.exe)" and found many reports like it, but I can't find yet how to fix it on the source code. If you know, tell us please. It should be fixed on the developer's side as well as video thumbnails are made disabled on the users' side.

I disable the thumbnail view in the folder with the Encode, but when i click on the file, than have i the same error.
Its a explorer crash and the folder will be closed.
It always happens when I click on the file or in a folder with a thumbnail view with a Encode file.

I've tested it with 2 PCs and WinXP SP3.

I hope Takeshi UMEZAWA can fix it.

Sorry my english is not so good.

[Dark Shikari]

Originally Posted by tobinaka

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically

Huh? This statement is nonsensical.

[LoRd_MuldeR]

Originally Posted by tobinaka

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )

Any CPU that supports SSE also supports MMX. And that won't change with future CPU's, unless they want to break compatibility to millions of existing applications.

Also why should MMX not work under 64-Bit Windows? I never heard anything like that before.

It's not like SSE is intended to replace MMX. They are two distinct sets of instructions. Why limit yourself to SSE, when you have both, MMX and SSE, available?

You would only make your assembly code slower than it could be...

[Leak]

Originally Posted by tobinaka

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )

Maybe he got confused by the topic Avery discusses here?

np: Tocotronic - Ich Bitte Dich (Digital Ist Besser)

[squid_80]

Originally Posted by tobinaka

UMEZAWA is concerned that it will be all C++ on x64 version compiling with doing nothing special. It's OK?

I think what you mean is if I compile a x64 version all the assembly code will be left out? No, I can modify the assembly so it runs under x64.

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )

If that's what he wants then fair enough. Since the code is GPL there's no reason to pressure the author to add something he doesn't want to.

Originally Posted by LoRd_MuldeR

Also why should MMX not work under 64-Bit Windows? I never heard anything like that before.

I wish I were as fortunate as you. My first few posts on this forum (and a few other forums) were spent trying to explain this. Eventually it became the accepted opinion (probably Avery's blogpost helped, as did clarification added to Agner Fog's Calling Convention doc) and these days we think someone is crazy if they say MMX can't be used in windows 64-bit code.

(lol@my comments on the virtualdub blog; it moved to using YASM earlier this year.)

[tobinaka]

UMEZAWA's Japanese blog updated, and the known problem was listed. I added them my first post on this threads, too.

-Exploere crashes when it shows the video thumbnails.
-EDIUS crashes or hangs up when the videos are put on the timelines or the video on the timeline goes to be played.
-ULY0(YUV420) doesn't support interlaced videos. So, in converting RGB into YUV420, it always converts mistaking the video as it's progressive.

Originally Posted by Lugia25000

I disable the thumbnail view in the folder with the Encode, but when i click on the file, than have i the same error.
Its a explorer crash and the folder will be closed.
It always happens when I click on the file or in a folder with a thumbnail view with a Encode file.

I've tested it with 2 PCs and WinXP SP3.

I hope Takeshi UMEZAWA can fix it.

Sorry my english is not so good.

Don't mind, your english is very well, much better than me!
Thanks for your report! I can reproduce the crash as you posted. I'll tell him soon.

[tobinaka]

Originally Posted by tobinaka

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )

Originally Posted by Dark Shikari

Huh? This statement is nonsensical.

I've just began to learn C programming, and CPU extentions are long way for me to go... My posts of the introductions into Japanese programs have two problem: my English and my knowledge. Hmm, I should learn the extentions... Thanks!

Originally Posted by LoRd_MuldeR

Any CPU that supports SSE also supports MMX. And that won't change with future CPU's, unless they want to break compatibility to millions of existing applications.

Also why should MMX not work under 64-Bit Windows? I never heard anything like that before.

It's not like SSE is intended to replace MMX. They are two distinct sets of instructions. Why limit yourself to SSE, when you have both, MMX and SSE, available?

You would only make your assembly code slower than it could be...

Oh, yeah, you have a point. I'll ask him about that. Thanks!

Originally Posted by Leak

Maybe he got confused by the topic Avery discusses here?

That article is easy to understand for me, thanks! OK. It helps me how he came to think MMX can't use on 64bit Windows, then I can tell him about the discussion on MMX here easier.

Originally Posted by squid_80

If that's what he wants then fair enough. Since the code is GPL there's no reason to pressure the author to add something he doesn't want to.

Certainly. You're the gentleman. But I think the discussion here helps him very well. And, don't worry, however you tell him to do anything he doesn't want to, he won't do

[tobinaka]

Originally Posted by squid_80

I think what you mean is if I compile a x64 version all the assembly code will be left out? No, I can modify the assembly so it runs under x64.

Thanks for your words. I thought you can, but he isn't familiar to this forum. That's to assure him. Sorry for my doubt.

Originally Posted by squid_80

I wish I were as fortunate as you. My first few posts on this forum (and a few other forums) were spent trying to explain this. Eventually it became the accepted opinion (probably Avery's blogpost helped, as did clarification added to Agner Fog's Calling Convention doc) and these days we think someone is crazy if they say MMX can't be used in windows 64-bit code.

(lol@my comments on the virtualdub blog; it moved to using YASM earlier this year.)

I read your discussions 4 years ago. Yes, I'm lucky and very grateful for all the discussions build up until now.

(Note for UMEZAWA. Avery Lee is Phaeron, the developer of virtualdub)

[easy2Bcheesy]

The installer doesn't work for me - "the installer was interrupted before Ut Video Codec Suite could be installed. You need to restart the installer to try again. Click 'Close to exit'."

I am running a Core i7 920, 3GB DDR3 and Gigabyte EX58-UD5 motherboard and I am very curious about capturing 1080p in the RGB colourspace.

I'm using a freshly installed Windows XP SP3 with all updates applied.