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 (http://umezawa.dyndns.info/wordpress/?cat=28).

----

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 (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-readme.en.html) (English)
-x86 installer (.msi) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x86.msi)
-x64 installer (.msi) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x64.msi)
-source code (zipped) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-src.zip)


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 (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html) 2.1.1
-Huffyuv_mt (http://www29.atwiki.jp/lossless/pages/11.html) >>712
-YUY2 Lossless Codec (YLC) (http://ruriruri.zone.ne.jp/aviutl/) 0.25
-Lagarith (http://lags.leetcode.net/codec.html) 1.3.16
-FastCodec 1.0beta (http://videosoft.org/codecs/fastcodec/)
-Arithyuv 1.1.1
-MSU Lossless Video Codec (http://www.compression.ru/video/ls-codec/index_en.html) 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 (http://spring-fragrance.mints.ne.jp/aviutl/) (Japanese).

The results

-Armored Core 4 Opening he captured 720p YUV422 8bit (the 29th June 2008 (http://umezawa.dyndns.info/wordpress/?p=348))
http://www.tobinaka.com/files/ut_test_sd1.jpg

-live-aciton video in HD(1080i : interlaced)　(the 14th July 2008 (http://umezawa.dyndns.info/wordpress/?p=362))
http://www.tobinaka.com/files/ut_test_hd1.jpg

-HD video above but de-intelaced (1080p : progressive) (the 14th July 2008)
http://www.tobinaka.com/files/ut_test_hd2.jpg


The development of Ut Video YV12 has just begun. He said on his Japanese blog (http://umezawa.dyndns.info/wordpress/) 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]

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!

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]

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 :rolleyes:

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

;)

[squid_80]

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]

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...

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

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!

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.

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!

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.


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 :p)

We look forward to your continued support. Thanks!

[Lugia25000]

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]

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 practicallyHuh? This statement is nonsensical.

[LoRd_MuldeR]

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 :p)

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]

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 :p)
Maybe he got confused by the topic Avery discusses here (http://www.virtualdub.org/blog/pivot/entry.php?id=107)?

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

[squid_80]

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.

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 (http://forum.doom9.org/showthread.php?p=583368#post583368) 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 (http://umezawa.dyndns.info/wordpress/) 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.

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! :p
Thanks for your report! I can reproduce the crash as you posted. I'll tell him soon.

[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 :p)

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!


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!


Maybe he got confused by the topic Avery discusses here (http://www.virtualdub.org/blog/pivot/entry.php?id=107)?

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.

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. :cool: 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 :p

[tobinaka]

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.

I wish I were as fortunate as you. My first few posts (http://forum.doom9.org/showthread.php?p=583368#post583368) 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.

[tobinaka]

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.

Thanks for your report! I'll tell him ASAP. Does anybody have the experience of installing failure? Core i7 may be difficult to reproduce the bug with for us. More reports help us.

[Lugia25000]

[URL="http://umezawa.dyndns.info/wordpress/"]
Don't mind, your english is very well, much better than me! :p


Thanks. :)


Maybe he has not installed -Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) or -Microsoft Visual C++ 2008 Redistributable Package (x86) ?

Or is Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) include in SP3?

The installer works fine on my WinXP Sp3.

[easy2Bcheesy]

I installed 'Microsoft Visual C++ 2008 Redistributable Package (x86)' and it still doesn't install.

[tobinaka]

Maybe he has not installed -Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) or -Microsoft Visual C++ 2008 Redistributable Package (x86) ?

Or is Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) include in SP3?

That's a possibility. I sometimes take mistakes like that.:p Is it OK his way with you, easy2Bcheesy?

I've made highlighted the notice of my fist post to install the package installation. Thanks.
By the way, it doesn't matter, today is UMEZAWA's birthday. Happy birthday to you!

[tobinaka]

I installed 'Microsoft Visual C++ 2008 Redistributable Package (x86)' and it still doesn't install.

Hmm... What's the reason? Anyway, I'll tell him your report.

[easy2Bcheesy]

I've solved the problem by reinstalling the .net frameworks. I'll post comments on HD 720p and 1080p performance at RGB.

[tobinaka]

I've solved the problem by reinstalling the .net frameworks. I'll post comments on HD 720p and 1080p performance at RGB.

Good! I'm happy that you can go trying Ut Video. I'm looking forward to seeing your report with your message of joy! Thanks.

[easy2Bcheesy]

Yes, joy would be the right word.

I have managed to encode 1080p RGB at 50fps with no frame loss (!). I physically can't get any more frames from the capture hardware, but I have no doubts this codec could do 1080p 60fps if it had the input. It is eating 720p RGB at 60fps for breakfast.

As i7 uses Hyper-threading it's difficult to tell how much CPU I'm using, but I'm guessing that for 1080p at 50fps it's about 60-70%.

[Lugia25000]

The new Version utvideo-5.1.2 works without problems. The Explorer Crash is fixed.

Thank you@Takeshi UMEZAWA and Happy Birthday to you. :)

[easy2Bcheesy]

Is there any particular reason that four different versions of the codec are registered - eg on for YV12, one for YUY2, one for RGB, one for ARGB etc, etc... couldn't it simply be one complete codec in the same way that Huffyuv works?

[tobinaka]

The new Version utvideo-5.1.2 works without problems. The Explorer Crash is fixed.

How fast you are...

ver 5.1.2 (http://umezawa.dyndns.info/wordpress/?p=817) released

-readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.1.2-readme.en.html) (English)
-installer (.msi) (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.1.2.msi)
-source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.1.2-src.zip)

-fix the bug that ULY0(YUV420 codec) sometimes didn't set the correct size (byte count) of the output image. The problem was only with ULY0.

That fixes the problem of the crash when Explorer goes getting the thumnail of the video.

He said it's a bush mistake as you can see in the diff...

[tobinaka]

As i7 uses Hyper-threading it's difficult to tell how much CPU I'm using, but I'm guessing that for 1080p at 50fps it's about 60-70%.

It's also my joy to hear such a report. Ut Video Codec is confirmed as new codec for post-P4 CPUs.

Is there any particular reason that four different versions of the codec are registered - eg on for YV12, one for YUY2, one for RGB, one for ARGB etc, etc... couldn't it simply be one complete codec in the same way that Huffyuv works?

Maybe that's because he's developed the codecs one after another. At the first release, Ut video had only one codec, YUV422 (YUV2).

But I agree with you. It'll be better to put them into one pack. Your idea will be received as a request.

[tobinaka]

I contacted with Takeshi (UMEZAWA's first name) and told him about the discussions until now. His misunderstanding on MMX with 64bit Windows has been removed. But, I'm afraid to tell the users of Athron64 and P2/P3, he still won't use MMX because that doesn't pay for his enviroment. :p

If you want MMX for Ut Video, please give him the patches. Ut Video is opensouced and GPL licensed. He said he's willing to accept its patches for improvement, of course also about MMX, though he don't make a code for MMX by himself. I think that's fair, isn't it? :cool:

Is there any particular reason that four different versions of the codec are registered - eg on for YV12, one for YUY2, one for RGB, one for ARGB etc, etc... couldn't it simply be one complete codec in the same way that Huffyuv works?

He said that if the four different versions apper you can easily see the internal format you are going to use. It's very important for lossless encoding. I'm interested when I see different codecs of Ut Video with different ways to make AVI files. That's simple and safe.

He also said it may be good to make such a wrapper as changing the output ways depending on the imput formats.

For reference, he said, Ut Video has its setting on local while Huffyuv has on global. This is another point Ut Video differs from Huffyuv.

[turbojet]

I did a benchmark with a 5000 frame mpeg2 720x480 progressive video via dgindex and avisynth which is the encode part. Then I used vdub to encode the lossless file to xvid which is the decode part with no crop or resize.

Here's the results

ENCODE DECODE TOTAL SIZE(MB)

ffhuffy-left 0:40 1:26 2:06 622
ffhuffy-plane 0:38 1:25 2:03 539
ffhuffy-median 0:39 1:42 2:21 503

huffyuvmt-left 0:44 1:35 2:19 817
huffyuvmt-grad 0:42 1:29 2:11 717
huffyuvmt-medi 0:40 1:36 2:16 779

lagarith 0:44 2:04 2:48 498
lagarith-mt 0:57 1:10 2:07 498

ut-median(ULY2) 0:48 1:29 2:17 573
ut-left(ULY2) 0:48 1:32 2:20 788

x264 1:05 1:41 2:46 523

amv2mt-r1 0:43 1:17 2:00 1921
amv2mt-r2 0:43 1:18 2:01 916
amv2mt-y1 0:43 1:18 2:01 1921
amv2mt-y2 0:43 1:18 2:01 916

amv2-r1 0:40 1:22 2:02 1953
amv2-r2 0:39 1:26 2:05 914
amv2-y1 0:41 1:22 2:03 1953
amv2-y2 0:42 1:25 2:07 914



this is on an athlon X2 3800+ with a goal of being the fastest as I use lossless only as an intermediate file
ut divided into 2
x264 used --qp 0 --no-cabac --subme 1 --partitions none --me dia --threads auto --thread-input --aq-strength 0.0 --progress --no-psnr --no-ssim
ffhuffy was from ffdshow-mt build 2552 using adaptive huffman tables
lagarith-mt encode result is real, I double checked. Strange that it encodes faster with 1 thread then it does 2.
AMV3 crashed vdub when starting an encode
AMV2 has a watermark (shareware) and a long delay when a file is renamed

ut seems competitive and I'm excited to see if it gets some more performance to beat ffdshows huffyuv and lagarith in this particular test.

EDIT: I noticed on the ut encodes vdub crashed at the end.
EDIT2: added AMV2 results, more specific with x264 settings used

[tobinaka]

this is on an athlon X2 3800+ with a goal of being the fastest as I use lossless only as an intermediate file


Thank for your report! It's interesting to see the result with Athlon X2. Ut should be competitive with them but it's important to be confirmed as the fact.

Another Japanese programmer Amaman, the developer of AMV2/3 shareware lossless video codec, showed a result (http://amamaman.hp.infoseek.co.jp/hosoku/amv210benchi.htm) (Japanese) of codec benchmarks mainly in Athlon64 CPUs. It said that Ut is a little faster than Huffyuv, and that Amaman's AMV2 is much faster. Ut in other than YUV2 is worse.

That means two things: Athlon64 is not good at SSE2, and there is a way to improve Ut greatly in Athlon64. We can't know the source of AMV2/3 because it's shareware and Amaman don't open the source. I think Doom9's Forum CAN do that, though I don't know if it DO that.

Anyway, Amaman's report is Japanese and too long, then your simple English report helps many Forum users (and me!):)


EDIT: I noticed on the ut encodes vdub crashed at the end.

Didn't you use Ut Video 5.1.0? The previous version that I introduced here first had a bug causing crashes. In 5.1.0, I saw VDubMod crashing with Ut as you said, but it's fixed now. Use 5.1.2, then if you have a crash even with 5.1.2, please report it in detail.

[turbojet]

It must have been 5.1.0 as I just downloaded 5.1.2 and it didn't crash vdub. I've never heard of AMV2 but I'll give it a try, thanks.

[tobinaka]

It must have been 5.1.0 as I just downloaded 5.1.2 and it didn't crash vdub. I've never heard of AMV2 but I'll give it a try, thanks.

AMV's English page is here (http://amamaman.hp.infoseek.co.jp/english/top_e.html). You'll see AmaRecCo above the link to AMV. I've never used AMV because it's shareware, but AmaRecCo is so good free-software screen video capture that I always use it to capture my Windows desktop. I you're interested, try AmaRecCo, too.

[easy2Bcheesy]

AMV Codec looks very interesting... but am I right in assuming it is downsampling my 24-bit RGB input into YV12 in all cases?

I have to admit that even the lossy quality isn't bad at all.

EDIT: Oh I see, just like UT, there are different codecs for different colour-spaces. The RGB codecs appear to crash my capture tool with out of bound memory access errors.

It's great to see lossless encoding for the HD era being taken seriously, and also that both AMV and UT can decode in real time too - something that has long been a problem for Huffyuv.

[tobinaka]

The RGB codecs appear to crash my capture tool with out of bound memory access errors.

I don't know how AMV is because I've never used it. If you notice any error, please report the author Amaman directly. I've never contacted with Amaman. But if you have any difficuty to contact with him by e-mail, tell me, and I'll help you by translating it into English, for example.

[johnsonlam]

Glad to see a new codec targeted for high speed capturing!

I'm please to know somebody still coding assembly, this is the best language and have highest efficiency.

Hope UT will be even better.

[easy2Bcheesy]

I don't know how AMV is because I've never used it. If you notice any error, please report the author Amaman directly. I've never contacted with Amaman. But if you have any difficuty to contact with him by e-mail, tell me, and I'll help you by translating it into English, for example.

Do you have his email address? I tried emailing him via his PayPal email address but have had no reply.

[tobinaka]

Do you have his email address? I tried emailing him via his PayPal email address but have had no reply.

I found his hotmail address at the license agreement in AMV installer. But I don't know this address can be the solution if you haven't received any reply yet... If you don't receive the reply after sending e-mail to hotmail address, please tell me again. Then I'll ask him by e-mail by myself in Japanese.

[easy2Bcheesy]

Thanks - I've just written to the Hotmail address.

UT codec is very nice... on my i7 machine I can run multiple 720p60 RGB streams in realtime in Premiere Pro. The decoding speed of this codec makes it great for video editing.

Is higher compression ratio possible?

What does your friend think of the lossy mode in AMV? Is it something he would look to implement in UT?

A good quality lossy RGB/YUY2 mode would make UT a competitor/alternative to paid-for codecs like CineForm and you wouldn't need to use a RAID array for capture.

[johnsonlam]

Is higher compression ratio possible?


Sorry for breaking in.

IMO, if higher compression rate will reduce the capture speed, I'd prefer UT keep the fast capture ability.

There're other codec which focus at compression ratio such as Largarth or MSU, their compression ratio is higher, maybe you can consider them as codecs for archive purpose.

[easy2Bcheesy]

I've been using UT extensively in the last couple of days and can suggest an improvement. Right now, the codec doesn't remember its settings (ie the compression mode utilised). So every time you start a new capture session, you need to reset which compression mode you want to use. It would be VERY useful if the codec would use the last mode you selected rather than having to reset it all the time.

I really want to use the Median mode extensively - it offers a big compression boost over the other mode, and on the Core i7, it plays back in realtime too.

[tobinaka]

I've been using UT extensively in the last couple of days and can suggest an improvement. Right now, the codec doesn't remember its settings (ie the compression mode utilised). So every time you start a new capture session, you need to reset which compression mode you want to use. It would be VERY useful if the codec would use the last mode you selected rather than having to reset it all the time.

I successed to reproduce your report... I didn't mind of it because I've used Ut on "Predict left" mode. Thanks for your request, I'm agree with you. I'll tell him right now. But I'm jealous of you to be able to use Core i7!:cool:

[Dark Shikari]

Sorry for breaking in.

IMO, if higher compression rate will reduce the capture speed, I'd prefer UT keep the fast capture ability.

There're other codec which focus at compression ratio such as Largarth or MSU, their compression ratio is higher, maybe you can consider them as codecs for archive purpose.Let's just say that if you need a fast, high-compression lossless codec, there's something good coming Soon™. ;)

[Tommy Carrot]

Let's just say that if you need a fast, high-compression lossless codec, there's something good coming Soon™. ;)
You're talking about FFV2, right? Can you tell something about it (speed and compression efficiency compared to FFV1), or it's still too early to tell anything?

[Dark Shikari]

You're talking about FFV2, right? Can you tell something about it (speed and compression efficiency compared to FFV1), or it's still too early to tell anything?Too early to tell. Preliminary analyses suggest an intra compression efficiency about halfway between FFVHuff+Adaptive Huffman Tables and FFV1 with faster decoding speed than FFVHuff. Might get a lot better when context-adaptive VLC tables are added. But it isn't going to be intra-only, and we won't know about inter compression efficiency until we try it.

Some data (http://i39.tinypic.com/2uojolv.png)

[tobinaka]

Ut Video ver 5.2.2 has come today.

Version 5.2.0
New features
ULY2: Add support for RGB32 input when encoding.
ULY0: Add support for RGB32 input when encoding. (but low speed)
ULY0: Add support for RGB32 output when decoding. (but low speed)

5.2.1 and 5.2.2 are for fixes.

He's already known about easy2Bcheesy's request when I told him because he watched here... wait a moment.

Too early to tell. Preliminary analyses suggest an intra compression efficiency about halfway between FFVHuff+Adaptive Huffman Tables and FFV1 with faster decoding speed than FFVHuff. Might get a lot better when context-adaptive VLC tables are added. But it isn't going to be intra-only, and we won't know about inter compression efficiency until we try it.

Some data (http://i39.tinypic.com/2uojolv.png)

That sounds interesting. I'm looking forward to trying to use it someday.